OpenID Federation Trust Marks

Trust Marks are signed, machine-readable attestations that an entity conforms to a specific, predefined set of requirements (for example, is a certified OP under profile X or meets a particular security baseline). In OpenID Federation, they are core building blocks for expressing and automating trust in a dynamic Federation without hard‑coding bilateral agreements.

What OpenID Federation Trust Marks Are

Trust Marks represent a statement of conformance to a well-scoped set of criteria defined by some accreditation or scheme authority, as defined in the OpenID Federation specification's Trust Marks section. They let a third party assert this entity satisfies policy P in a way that is both legally meaningful at the business layer and verifiable at the protocol layer.

Their purpose is to separate “who evaluates compliance” from “who consumes identity,” so RPs, or AS/OPs can rely on structured compliance assertions instead of bespoke, static allow‑lists. This enables more scalable onboarding, clearer role separation, and easier policy evolution inside and across federations.

OpenID Federation Trust Mark Technical Form

In OpenID Federation, Trust Marks are implemented as signed JSON Web Tokens (JWTs) containing at least:

• Subject (sub) - the Entity Identifier of the Entity being certified

• Trust Mark Type (trust_mark_type) - The collision-resistant identifier of the Trust Mark. Commonly a URL

• Issuer (iss) - the Entity Identifier of the Entity that issued the Trust Mark

• Issued At (iat) - The time at which the Trust Mark was issued expressed in seconds since the Epoch as per RFC-7591

The Trust Mark is signed by a Trust Mark Issuer, and its signature is validated against the Issuer’s public keys published via federation Metadata.

Verification typically involves: resolving and validating the Trust Mark Issuer as a Federation Entity, checking the JWT signature and standard claims, and optionally consulting a status endpoint to confirm the Trust Mark is still valid (not revoked or expired).

Roles Involved in OpenID Federation Trust Mark Issuance

A Trust Mark Issuer is a Federation Entity (often an accreditation authority, scheme operator, or compliance body) whose role is to evaluate candidates and issue Trust Marks. The Trust Mark Subject (or recipient) is the entity that has been assessed and to which the Trust Mark’s conformance statement applies.

Trust Anchors and Metadata operators can publish which Trust Mark Types and Issuers they recognise as trustworthy using dedicated claims in their Entity Configurations. Any Entity within the Federation then use these published rules to decide which Trust Marks they will honor, closing the loop between policy and technical enforcement.

Who Publishes Trust Mark Types and Issuers in Raidiam Connect

In Raidiam Connect, publishing Trust Mark Types and Issuers is the Directory's responsibility, not the OP's. There is no separate step to "define" a Trust Mark Type: a Trust Mark Type identifier is generated automatically from an existing Authorisation Domain and Role combination already configured in Reference Data.

To make an organisation a Trust Mark Issuer, map that organisation's Authority to the relevant Domain and Role. Once mapped, the Directory automatically computes the Trust Mark Type identifier and includes it, together with its Issuer, in the trust_mark_issuers claim of the Trust Anchor's own Entity Configuration - no manual Entity Configuration editing is required, and this is not something the OP configures itself.

OpenID Federation Trust Mark Publication and Discovery

Trust Marks are usually exposed in two main ways: directly embedded in an entity’s configuration and via Issuer-hosted endpoints. An Entity Configuration may contain trust_marks claim containing a set of Trust Marks alongside their respective Trust Mark Type, enabling automatic discovery during Trust Chain resolution.

Trust Mark Issuers may additionally publish dedicated endpoints such as a federation_trust_mark_list_endpoint to list marks they have issued and a trust_mark_status_endpoint to provide current status (valid, revoked, etc.). This allows verifiers to check ongoing compliance and revocation without needing full re‑accreditation flows for every interaction.

OpenID Federation Trust Mark Validation

Trust Mark validation in OpenID Federation is a two-phase process: first the Trust Mark JWT is syntactically and cryptographically validated, and then it is evaluated against the selected Trust Anchor’s policy - concretely, the trust_mark_issuers and trust_mark_owners claims published in that Trust Anchor's own Entity Configuration (its /.well-known/openid-federation document) - including constraints on Issuers, Owners and (if used) delegation. A Trust Mark is never “valid in the abstract”; it is only valid relative to a particular Trust Anchor and its resolved Trust Chain.

Prerequisites and Context

An Entity MUST select which Trust Anchor it is using before validating a Trust Mark, as the Trust Anchor's Entity Configuration determines which Trust Mark Types are acceptable. the verifier must also be able to build and validate a Trust Chain from that Trust Anchor to the Trust Mark Issuer, so as to obtain the Issuer’s effective Metadata and public keys.

The Trust Anchor expresses which Entities are allowed to issue which Trust Mark Types or Identifiers using claims such as trust_mark_issuers and (where applicable) trust_mark_owners in its Entity Configuration. If the Trust Anchor knows that the owner for a given Trust Mark Type or ID is different from the Issuer, that relationship must be expressed in these Trust Anchor's Entity Configuration claims and is ignored when present on Entities not currently acting as a Trust Anchor.

Phase 1: Trust and Policy Evaluation

Trust evaluation is where the Trust Mark is linked to a Trust Anchor and its policies, and may be performed as a separate step from syntactic validation. The verifier:

• Builds and validates a Trust Chain for the Trust Mark Issuer, applying Metadata policy from the Trust Anchor and Intermediates to derive effective Metadata for the Issuer.

• Checks that the Issuer is allowed to issue the specific Trust Mark Type or ID according to the Trust Anchor’s trust_mark_issuers claim (and, if present, that any trust_mark_owners mapping is satisfied).

• If issuance of the Trust Mark has been delegated, verifies the associated Trust Mark Delegation JWT(s) and ensures the Issuer is covered by a still-valid delegation from the owner for that Trust Mark Type.

Issuer trust establishment is carried out before JWT processing. A consumer must not attempt to process any Trust Mark JWTs before verifying the type is applicable to the current Federation they are operating within.

Resolve Entity Endpoint

The Resolve Entity endpoint is an OpenID Federation facility that returns an Entity’s resolved Metadata, Trust Chain and associated Trust Marks as evaluated by a Resolver or Trust Anchor. It can therefore be used as a building block when validating that a given entity holds appropriate Trust Marks under a particular Federation’s Trust Framework.

The Resolve Entity endpoint allows participants to delegate Trust Chain construction and evaluation to a Federation Resolver, which returns a signed representation of the Entity “as seen” by that Resolver. This response includes effective Metadata and Trust Marks derived from the Entity’s Configuration and Intermediate Entity Statements, giving the party a single, cacheable object to use for trust decisions.

The trust_marks element of the Resolve response is defined as containing only Trust Marks that have passed verification by the Resolver and that come from Trust Mark Issuers trusted by the Trust Anchor for that Trust Mark Type.

An Entity can therefore treat the presence of a given Trust Mark in the Resolve response as a statement this mark is valid under this Trust Anchor, and does not need to reperform the generic Trust Mark validation algorithm.​

The client may still apply local policy, such as requiring specific Trust Mark Type Identifiers, checking optional status via the Trust Mark Status Endpoint, or combining multiple marks, but that is policy evaluation on already‑validated Marks, not primary Mark verification.

Phase 2: Syntactic and Cryptographic Validation

At minimum, the verifier must:

• Parse the Trust Mark as a signed JWT and ensure the header and payload follow the Trust Mark profile (presence of required claims–trust_mark_type, iss, sub, iat).

• Verify the signed JWT's signature using the Issuer’s Federation keys obtained via the Issuer’s Entity Configuration and validated Trust Chain from the selected Trust Anchor.

• Check time-based claims and any format-specific constraints, rejecting Trust Marks whose exp has passed, which are not yet valid, or whose Issuer/subject Entity Identifiers are malformed.

Status and Introspection Endpoints

Implementations often complement local validation with Issuer-operated status endpoints. The specification allows a Trust Mark Issuer to expose a federation_trust_mark_endpoint for validating an individual Trust Mark and a federation_trust_mark_list_endpoint for enumerating marks issued to a given subject, both under https URLs in its Metadata.

A Verifier can call these endpoints to confirm that a syntactically-valid and policy-valid Trust Mark is still active, for example to account for Issuer-side revocation before natural expiry.

Lifecycle and Revocation

The lifecycle starts with an assessment or audit against the criteria defined for the Trust Mark Type, followed by issuance of the signed Trust Mark JWT to the subject. Trust Marks can be issued with a validity period, after which they expire.

Revocation or status changes cannot be applied “top-down” directly to an Entity’s Configuration. The only mechanisms to communicate changes are via the Trust Mark Listing, Status, or Trust Mark endpoints. Even in deployments where control over Entity Configurations is tight, administrators cannot fully enforce changes directly on an Entity; verifiers must combine JWT validation with status checks according to Federation policy to maintain near‑real‑time confidence in an Entity’s compliance posture.

Trust Mark Delegation

Trust mark delegation in OpenID Federation is modelled as a separate, explicitly typed JWT that conveys authorization from a Trust Mark Owner to a Trust Mark Issuer, and it must be validated alongside the Trust Chain and Metadata policies before any Trust Mark issued under that delegation is accepted. The mechanism is deliberately orthogonal to Entity Statements, but uses the same JWT tooling and identifier model to keep delegation decisions machine-verifiable and tightly scoped.

Token and Header Structure

A Trust Mark Delegation is a standalone JWT with a typ header set to the registered media type trust-mark-delegation+jwt, which lets verifiers distinguish it from Trust Marks and Entity Statements at parse time. Normal JOSE header parameters apply (alg, kid, etc.), and the key used to sign the delegation JWT must be verifiable via the Issuer’s Entity Configuration and the Trust Chain rooted at a Trust Anchor that is acceptable to the verifier.

At the claims level, the delegation JWT uses iss as the Trust Mark Owner’s Entity Identifier and sub as the delegated Trust Mark Issuer’s Entity Identifier, mirroring the semantics of Entity Statements but applying them to issuance rights instead of Metadata or keys. The payload must also bind the delegation to a specific Trust Mark Type (for example, via a trust_mark_type claim) and carry time when the Trust Mark was issued (iat).

Validating Delegated Trust Marks

When a verifier encounters a Trust Mark attached to an Entity’s Federation Metadata (for example in trust_marks within an Entity Configuration), it must process three artifacts: the Issuer’s Trust Chain, the Trust Mark JWT itself, (Entity Statements and Entity Configuration), and one or more Trust Mark delegation JWTs that authorize that Issuer for the Trust Mark Type. Validation fails if any of these are missing or inconsistent, even if the Trust Mark’s own signature and claims are otherwise structurally valid.

A delegated Trust Mark requires the same Phase 1: Trust and Policy Evaluation and Phase 2: Syntactic and Cryptographic Validation checks described above, plus one additional step specific to delegation:

• Locate a Trust Mark Delegation JWT whose iss is recognized as the Trust Mark Owner for that Trust Mark Type, whose sub matches the Trust Mark Issuer, whose scope covers the specific Trust Mark Type, and whose validity window and any owner-defined constraints are satisfied.

Only if all three steps succeed and the Trust Anchor’s policy explicitly allows the combination of Trust Mark owner, delegated Issuer and Trust Mark Type should the verifier accept the mark for authorization or Metadata decisions.

Example Uses in Federations

In OpenI Federation, Trust Marks can indicate roles (e.g., this entity is an OP conformant to profile X), regulatory posture (meets payment scheme Y requirements), or technical capabilities tied to certification.

Beyond identity, the same pattern appears in other domains where certification marks or “trust badges” communicate compliance with security or quality standards, with machine-readable Trust Marks providing the technical equivalent of those visual marks for automated systems.