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

1. The Relying Party fetches the OpenID Provider’s Entity Configuration.
2. The Relying Party resolves and validates the trust chain using the Resolver to the Trust Anchor.
3. If trust is valid, the Relying Party registers with the OpenID Provider.
4. 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, -s silences 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.