Disclaimer
This document provides an overview of the Swefed OIDF Sandbox environment. It focuses on metadata handling, trust chain validation, and Trust Mark usage in the context of OpenID Federation 1.0. For complete details, consult the OpenID Federation 1.0 specification - draft 43.
Introduction
The Swefed OIDF Sandbox is an isolated environment for testing OpenID Federation. It allows Relying Parties, OpenID Providers, and supporting entities to validate interoperability, metadata exchange, and trust chain resolution under a Trust Anchor.
Federation Architecture and Core Entities
The federation has a hierarchical structure with the Trust Anchor as the root of trust. Subordinate entities include Resolvers, Intermediates, Trust Mark Issuers, OpenID Providers, and Relying Parties.
Entities and Their Roles
Trust Anchor: Root of trust. Defines policies and signs metadata.
Resolver: Provides trust chain resolution services, enabling entities to validate metadata against the Trust Anchor.
Intermediate: Manages subordinate entities and aggregates metadata.
Trust Mark Issuer: Issues signed Trust Marks certifying compliance with federation requirements.
OpenID Provider: Authenticates users and issues tokens under federation policies.
Relying Party: Consumes identity information from OpenID Providers through validated trust chains.
Trust Workflow
Each entity publishes an Entity Configuration at /.well-known/openid-federation. This is a signed JWT containing the entity identifier, role-specific metadata, authority hints, and a JWKS by value. Trust Marks may be included.
Validation is done by building a trust chain from the entity to the Trust Anchor. The chain is verified using the Trust Anchor's keys. Trust Marks add assurance of policy compliance.
Trust is established dynamically through metadata exchange and chain resolution, enabling scalable onboarding without static configuration.
Trust Mark Issuance
A Trust Mark Issuer evaluates an entity against defined requirements. If compliant, it issues a signed JWT Trust Mark including the required claims iss (issuer), sub (subject), id (trust mark identifier), iat (issued at), and exp (expiration).
Examples
RP to OP Interaction
- The Relying Party fetches the OpenID Provider’s Entity Configuration.
- The Relying Party resolves and validates the trust chain using the Resolver to the Trust Anchor.
- If trust is valid, the Relying Party registers with the OpenID Provider.
- Authentication and token flows proceed under validated trust.
Fetching Entity Configuration
The following command extracts and displays the payload of an Entity Configuration. It is useful for inspection, but it does not validate the JWT signature. Signature validation must always be performed with trusted keys.
curl -s https://trust-anchor.oidf.swefed.se/.well-known/openid-federation \ | cut -d '.' -f2 \ | tr '_-' '/+' \ | base64 -d 2>/dev/null \ | jq .
Explanation of each step
curl -s: fetches the JWT,-ssilences progress.cut -d '.' -f2: extracts the payload from the JWT (middle part).tr '_-' '/+': translates Base64URL alphabet into standard Base64.base64 -d: decodes the payload.jq .: pretty-prints the JSON.
Nodes
The following nodes are available in the Swefed OIDF Sandbox.
Trust Anchor
- URL:
https://trust-anchor.oidf.swefed.se - Role: Root of trust. Publishes federation policies and signing keys.
- Provides federation endpoints:
fetch,list,resolve.
Resolver
- URL:
https://trust-anchor.oidf.swefed.se(co-located with TA) - Role: Resolves trust chains by processing authority hints and building validated chains up to the TA.
- Endpoint:
/resolve.
Trust Mark Issuer
- URL:
https://trust-mark-issuer.oidf.swefed.se - Role: Issues and manages Trust Marks.
- Provides endpoints:
trust_mark,trust_mark_list,trust_mark_status. - Declares the Trust Anchor in
authority_hints.
Intermediate
- URL:
https://intermediate.oidf.swefed.se - Role: Aggregates and distributes metadata.
- Provides federation endpoints:
fetch,list,resolve. - Declares the Trust Anchor in
authority_hints.
OpenID Provider (OP)
- URL:
https://op.oidf.swefed.se - Role: Provides authentication and token services.
- Publishes OP metadata in the
metadata.openid_providersection. - Trust is established dynamically through its Entity Configuration and chain to the TA.
Relying Party (RP)
- URL:
https://rp.oidf.swefed.se - Role: Consumes tokens and user information from OPs.
- Publishes RP metadata in the
metadata.openid_relying_partysection. - Trust is established dynamically through its Entity Configuration and chain to the TA.
Usage Notes
- All nodes expose their Entity Configuration at
/.well-known/openid-federation. - Trust chains must always be validated against the Trust Anchor.
- JWT signatures must be verified with the published keys from trusted entities.
- Trust Marks must be validated against the Trust Mark Issuer’s published metadata.
Entity Integration
This section explains how to connect an entity to the Swefed Sandbox Trust Infrastructure. It covers metadata exposure, configuration of trust anchors, authority hints, and trust marks.
Prerequisites
- Network access from your entity to the Sandbox Trust Anchor
- Externally accessible HTTPS endpoint for your entity
Key Configuration Points
Entity Configuration
Each entity must expose its Entity Configuration at:
/.well-known/openid-federation
Trust Anchors
The Sandbox Trust Anchor (TA) is the root of trust for the federation. All trust chains must terminate at this Trust Anchor. Entities must include the TA in their configuration for proper validation.
Trust Anchor URL:
https://trust-anchor.oidf.swefed.seTrust Anchor Keys: Add the Trust Anchor’s public keys to your configuration
{ "jwks": { "keys": [ { "kty": "RSA", "use": "sig", "kid": "d2ZPZDVKa0Z4N1J4LTB2VWM1VFFhTUdSdnU3czZKQzhwc1F1U3ZHWEV3SQ", "e": "AQAB", "n": "lzLK1jAEMh4duP6Ym_pHWXYJZkJ-LuJvPHqIuQrxZnEhB4ODpA0hfj9g2UdBBVzbZdhOXKg9ObTQhG_TTISDliyjKAphxF5EObMpPtCoy_ImZ262zRdK4nii6AGVuABd5777GEBIwb-zZncWypjCX-1T6CBVECi4DnoHGDHDWhBTcIa9DE6ZDAjAgrKeiDz96gOL3BrGTYHDkjIpp__FP9dZJXJjgDV2n0cvC_MDmp8N8C-Rc1vd63lpmoXxvIqBy8bSM8jXSDxPTNkcJdlducNo9sR9j-7TsGdgE9PNK-iVzyp67QnmokreMCHx3NExkmi-MfkHrPAHwE_OneNVhw" }, { "kty": "EC", "use": "sig", "kid": "R180Y3dtOWY2TzVoU3NYT1I2OUcyay0waWdVYVJ2YkFQZmRqaDBJZHZPMA", "crv": "P-256", "x": "OSKZj-f9PT5UKWHiQ-VdhY-gfh0h-dA_weaYFqfkuUg", "y": "4y8u3C-CMWySQFMHN0tvafgwKWbDLS5XSQEo83HupyY" } ] } }
Registering as a Subordinate Entity
Entities are formally connected to the federation by registering under a superior. Registration consists of:
- Publishing the Entity Configuration with correct metadata and keys
- Supplying the entity identifier (URL)
- Ensuring the
authority_hintsfield points to the correct superior
Authority Hints
Entities must declare their immediate superior in the trust hierarchy.
- Example:
"authority_hints": [
"https://intermediate.oidf.swefed.se"
]Trust Marks
Trust Marks may be required depending on Sandbox policies.
Trust Mark Issuer URL:
https://trust-mark-issuer.oidf.swefed.seEntities can request signed Trust Marks to certify compliance with Sandbox requirements. Issued Trust Marks are included in the
trust_marksfield of the Entity Configuration.
Steps to Connect
Configure the Entity
- Publish a valid Entity Configuration at
/.well-known/openid-federation. - Include keys, metadata, and authority hints.
- Publish a valid Entity Configuration at
Reference the Trust Anchor
- Ensure the Trust Anchor URL is included in
authority_hints.
- Ensure the Trust Anchor URL is included in
Register with the Sandbox
- Share the entity identifier with the Sandbox operators to complete registration.
Request Trust Marks (if required)
- Contact the Trust Mark Issuer for any required Trust Marks and include them in your configuration.
Testing the Trust Relationships
Retrieve metadata Fetch your entity’s Entity Configuration and verify the payload:
curl -s https://<entity-host>/.well-known/openid-federation | cut -d '.' -f2 | tr '_-' '/+' | base64 -d | jq .Check authority hints Confirm that the
authority_hintsfield points to the Sandbox Trust Anchor or an Intermediate.Resolve trust chain Use the Resolver at
https://trust-anchor.oidf.swefed.se/resolveto validate your entity’s trust chain.Verify keys and signatures Ensure JWT signatures are valid against the keys published by the Trust Anchor and Trust Mark Issuer.
Validate Trust Marks If your entity includes Trust Marks, verify their signatures and claims against the Trust Mark Issuer.
Key Configuration Points
entity Configuration Information
The entity must expose an entity configuration document at:
/.well-known/openid-federation
The configuration endpoint publishes the entity Configuration document, which provides the entity’s configuration details for participants in the Trust Infrastructure.
- Define the Endpoint: The endpoint is defined under the following path: /.well-known/openid-federation
- Implementation: Ensure this endpoint serves the entity’s entity Configuration.
- Example entity Configuration: Below is a shortened example of an entity Configuration:
{
"sub": "https://my-entity.example.com",
"authority_hints": [
"https://mi-intermediate.example.org"
],
"metadata": {
"federation_entity": {
"organization_name": "Example Org",
"contacts": ["support@example.com"]
},
"oauth_authorization_server": {
"token_endpoint": "https://entity.example.com/token",
"authorization_endpoint": "https://entity.example.com/authorize",
"jwks_uri": "https://entity.example.com/jwks/oauth"
},
},
"jwks": {
"keys": [
{
"kty": "RSA",
"use": "sig",
"kid": "example-key-id",
"e": "AQAB",
"n": "example-modulus"
}
]
}
}
Trust Anchors
The Trust Anchor is the root of the Trust Infrastructure’s trust chain. Trust Anchors establish trust within the federation by defining policies and anchoring trust chains.
- Trust Anchor URL: For your setup, the Trust Anchor URL is:
https://trust-anchor.oidf.swefed.se - Trust Anchor Keys: Add the Trust Anchor’s and public keys to your configuration
{ "jwks": { "keys": [ { "kty": "RSA", "use": "sig", "kid": "d2ZPZDVKa0Z4N1J4LTB2VWM1VFFhTUdSdnU3czZKQzhwc1F1U3ZHWEV3SQ", "e": "AQAB", "n": "lzLK1jAEMh4duP6Ym_pHWXYJZkJ-LuJvPHqIuQrxZnEhB4ODpA0hfj9g2UdBBVzbZdhOXKg9ObTQhG_TTISDliyjKAphxF5EObMpPtCoy_ImZ262zRdK4nii6AGVuABd5777GEBIwb-zZncWypjCX-1T6CBVECi4DnoHGDHDWhBTcIa9DE6ZDAjAgrKeiDz96gOL3BrGTYHDkjIpp__FP9dZJXJjgDV2n0cvC_MDmp8N8C-Rc1vd63lpmoXxvIqBy8bSM8jXSDxPTNkcJdlducNo9sR9j-7TsGdgE9PNK-iVzyp67QnmokreMCHx3NExkmi-MfkHrPAHwE_OneNVhw" }, { "kty": "EC", "use": "sig", "kid": "R180Y3dtOWY2TzVoU3NYT1I2OUcyay0waWdVYVJ2YkFQZmRqaDBJZHZPMA", "crv": "P-256", "x": "OSKZj-f9PT5UKWHiQ-VdhY-gfh0h-dA_weaYFqfkuUg", "y": "4y8u3C-CMWySQFMHN0tvafgwKWbDLS5XSQEo83HupyY" } ] } }
Authority Hints
The authority_hints parameter specifies the URL of the Intermediate Entities or Trust Anchors that are Immediate Superiors of the entity. This helps other Trust Infrastructure participants understand upstream trust relationships.
- Add to Configuration: Add
authority_hintsin your entity’s metadata configuration
Registering the entity as a Subordinate entity
In the Trust Infrastructure, the entity must be registered as a Subordinate entity under a Superior entity (e.g., a Trust Anchor or an Intermediate entity). This ensures the entity's formal inclusion in the trust hierarchy.
To register the entity with the Trust Infrastructure, you need to create a JSON document containing the entity’s public keys.
Paste the following information in an editor
{
"<entity-entity-identifier>": {
"entity_types": [
"federation_entity",
"openid_credential_entity",
"oauth_authorization_server"
],
"jwks":
}
}
Change <entity-entity-identifier> to the entity_id of the entity
In OIDF the metadata object inside the Entity Configuration is structured by federation entity types, and each corresponds to a role that an entity can play.
The specification defines the following standard metadata types. insert the one that corresponds with the entity:
federation_entity- Mandatory for every participant.
- Contains federation-related endpoints such as
federation_fetch_endpoint,federation_resolve_endpoint,federation_list_endpoint, and optionallyfederation_trust_mark_endpoint, etc.
openid_relying_party- Used when the entity is a Relying Party.
- Contains metadata (like
redirect_uris,application_type, etc.), similar to OIDC Dynamic Client Registration metadata.
openid_provider- Used when the entity is an OpenID Provider.
- Contains metadata (like
authorization_endpoint,token_endpoint,userinfo_endpoint,jwks_uri, supported algorithms, etc.), aligned with OIDC Discovery.
oauth_authorization_server- Used when the entity acts as a generic OAuth 2.0 Authorization Server.
- Contains metadata per RFC 8414 (OAuth 2.0 Authorization Server Metadata).
- Open the file in a text editor of your choice
- Move the Public Keys into
jwks:- Locate the
"keys"array in theentity configuration
- Locate the
- Move it inside the
"jwks"section
- Move it inside the
The file should look like this:{
"https://entity.example.com": {
"entity_types": [
"federation_entity",
"openid_credential_entity",
"oauth_authorization_server"
],
"jwks": {
"keys": [
{
"kty": "RSA",
"use": "sig",
"kid": "example-kid",
"n": "example-n-value",
"e": "AQAB"
}
]
}
}
}
Option 2: One-Liner Command (Automated)
For users who prefer a quick and automated approach, use this single command to generate the JSON document:
Replace "https://entity.example.com" with the actual entity entity Identifier.
entity_entity_identifier="https://entity.example.com" && \
jq --arg uri "$entity_entity_identifier" \
'{($uri): {
"entity_types": [
"federation_entity",
"openid_credential_entity",
"oauth_authorization_server"
],
"jwks": .
}}' \
satosa/public/pid_fed_keys.json \
> entity_registration.json
Final Step: Send the Document
Once the file entity_registration.json is created using either method, send it to:
support@dc4eu.eu
Trust Marks
Trust Marks are JWTs issued by a Trust Mark entity to validate compliance with Trust Infrastructure policies.
Types of Trust Marks
The following Trust Marks are available for issuance:
- EHIC Credential:
- ID:
http://dc4eu.example.com/EHICCredential/se
- ID:
- PDA1 Credential:
- ID:
http://dc4eu.example.com/PDA1Credential/se
- ID:
Retrieving Trust Marks
For now, Trust Marks will be supplied when the entity is added to the Trust Infrastructure.
- Inputs to Trust Mark entity:
id: The identifier for the Trust Mark (e.g.,http://dc4eu.example.com/EHICCredential/se).sub: The entity's entity Identifier.
- Steps:
- Supply the
idandsubto the Trust Mark entity. - Retrieve the issued Trust Mark as a signed JWT.
- Supply the
- Validation:
- Use a JWT library to verify the Trust Mark's signature using the Trust Mark entity's public key:
- Retrieve public keys from the Trust Mark entity's /.well-known/jwks.json endpoint.
- Validate claims such as
iss,sub,id, andiatfor compliance.
- Use a JWT library to verify the Trust Mark's signature using the Trust Mark entity's public key:
- Include in Metadata: Add issued Trust Marks to your entity’s metadata:
config:
op:
trust_marks:
- "eyJhbGciOiJIUzI1NiIsInR..."
- "eyJhbGciOiJIUzI1NiIsInR..."
Add Trust Marks to the vc_up_and_running entity
To update the trust marks, you need to modify the trust_marks section of the satosa/plugins/oidc_frontend.yaml file. Follow the steps below to replace the existing trust marks with the ones received from the Trust Infrastructure operator.
Locate the trust marks section
In the current configuration, the trust marks are defined under:config: op: trust_marks: - "eyJhbGciOiJIUzI1NiIsInR..." - "eyJhbGciOiJIUzI1NiIsInR..."Replace these values with the updated trust marks provided by the operator.
Example update
If the operator provided the following new trust marks:
eyJhbGciOiJSUzI1NiIsImtpZCI6IjM2NWQ2MjY3LTI5MzQtNGJhNy05YjEyLWU4ZmFkNTYwj9... eyJhbGciOiJSUzI1NiIsImtpZCI6IjkwNTFjZTgzLTY1NzEtNDliYi04ODdjLTc3OWQzMDNmJ9...Then update your configuration as follows:
trust_marks: - eyJhbGciOiJSUzI1NiIsImtpZCI6IjM2NWQ2MjY3LTI5MzQtNGJhNy05YjEyLWU4ZmFkNY... - eyJhbGciOiJSUzI1NiIsImtpZCI6IjkwNTFjZTgzLTY1NzEtNDliYi04ODdjLTc3OWQyJ9...Restart the entity to Apply Changes
Once you've updated the configuration file, restart the entity container to apply the changes:
./stop.sh && \ ./start.shVerify the Changes
After restarting the entity, verify that the new Trust Marks are correctly applied:curl -k -s https://<entity-host>:8000/.well-known/openid-federation | \ cut -d '.' -f2 | tr '_-' '/+' | base64 -d 2>/dev/null | jq .
Look for the updated trust_marks in the JSON response.
Testing Trust Marks
- Decode JWT: Use tools like
jwt.ioto inspect the Trust Mark's claims and ensure all required fields are present. - Verify Signature: Validate the JWT signature against the Trust Mark entity's public key.
- Check Expiration: Ensure the
expclaim (if present) has not expired. - Validate References: Follow the
refURL (if provided) to confirm compliance with human-readable policy documents.
Steps to Connect the entity
- Configure the entity:
- Update the entity’s configuration to include
authority_hints,trust_marks, andtrust_anchors.
- Update the entity’s configuration to include
- Register with the Trust Infrastructure:
- Share your
entity_registration.jsonwith the Trust Anchor or superior entity for registration.
- Share your
- Validate Configuration:
- Test the entity using testing tools or with a sandbox environment.
- Monitor the Connection:
- Regularly verify the status and ensure Trust Marks are up-to-date.
Testing the Trust Relationships
Validate trust marks
Use tools like jwt.io to decode and verify trust marks using the Trust Anchor's public keys.Retrieve metadata
Ensure the.well-known/openid-federationendpoint correctly serves the entity’s entity configuration:curl -X GET https://your-entity.example.com/.well-known/openid-federationCheck authority hints
Verify thatauthority_hintspoints to the correct Trust Anchor:authority_hints: - https://openidfed-test-1.sunet.se:7001Validate public keys
Confirm that the Trust Anchor’s public keys match those provided in your local configuration.