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.
Introduction
The Swefed OIDF Sandbox is an isolated environment for testing OpenID Federation. It allows Relying Parties (RPs), OpenID Providers (OPs), 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 (TA) as the root of trust. Subordinate entities include Resolvers, Intermediates, Trust Mark Issuers, OPs, and RPs.
Key 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 TA.
Intermediate: Manages subordinate entities and aggregates metadata.
Trust Mark Issuer: Issues signed Trust Marks certifying compliance with federation requirements.
OpenID Provider (OP): Authenticates users and issues tokens under federation policies.
Relying Party (RP): Consumes identity information from OPs 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 TA’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.
Standards and Protocols
- OpenID Connect
- OpenID Federation 1.0
Trust Mark Issuance
A Trust Mark Issuer evaluates an entity against defined requirements. If compliant, it issues a signed JWT Trust Mark containing iss (issuer), sub (subject), id (trust mark identifier), iat (issued at), and exp (expiration).
Examples of Trust Workflows
RP to OP Interaction
- The RP fetches the OP’s Entity Configuration.
- The RP resolves and validates the trust chain using the Resolver to the TA.
- If trust is valid, the RP registers with the OP.
- Authentication and token flows proceed under validated trust.