ADR: Extend TS11 TrustAuthority with OpenID Federation Trust Marks - #220
ADR: Extend TS11 TrustAuthority with OpenID Federation Trust Marks#220leifj wants to merge 1 commit into
Conversation
Proposes adding optional trustMarkId and trustMarkIssuers fields to the TS11 TrustAuthority model when frameworkType is openid_federation. This enables credential type metadata to express issuer authorization via Trust Marks, analogous to how ETSI Trusted Lists use service type identifiers.
| |-------|------|----------|-------------| | ||
| | `frameworkType` | string | yes | (existing) Trust framework type. One of `aki`, `etsi_tl`, `openid_federation`. | | ||
| | `value` | string | yes | (existing) Trust Anchor entity identifier (URI). | | ||
| | `isLOTE` | boolean | no | (existing) Set `true` for ETSI List of Trusted Lists. Only applicable when `frameworkType` is `etsi_tl`. | |
There was a problem hiding this comment.
| | `isLOTE` | boolean | no | (existing) Set `true` for ETSI List of Trusted Lists. Only applicable when `frameworkType` is `etsi_tl`. | | |
| | `isLoTE` | boolean | no | (existing) Set `true` for ETSI List of Trusted Lists. Only applicable when `frameworkType` is `etsi_tl`. | |
| | Field | Type | Required | Description | | ||
| |-------|------|----------|-------------| | ||
| | `frameworkType` | string | yes | (existing) Trust framework type. One of `aki`, `etsi_tl`, `openid_federation`. | | ||
| | `value` | string | yes | (existing) Trust Anchor entity identifier (URI). | |
There was a problem hiding this comment.
TS11 4.3.3 keeps value generic for openid_federation - it is just an "Entity Identifier," with no statement of whether it's the Trust Anchor, an intermediate, or the leaf. OID4VP accepts any Entity Identifier, yet in another section it rightly says that usually it is going to be the Entity Identifier of a Trust Anchor. Both are permissive, so this ADR should be more specific and fix the meaning for consortium use:
For simplicity we can say that for frameworkType: openid_federation, value MUST be the Entity Identifier of a Trust Anchor or an intermediate entity. The credential issuer is the leaf Federation Entity; the verifier resolves the issuer's trust chain up to the Trust Anchor named by value, possibly through intermediate entities.
|
|
||
| However, the current TS11 `TrustAuthority` model only carries a framework type and a value (trust anchor identifier). For OpenID Federation, this is insufficient: knowing the Trust Anchor entity identifier tells a verifier *where* to resolve a trust chain, but not *what authorization* the issuer must demonstrate for the specific credential type. OpenID Federation Trust Marks ([OpenID Federation 1.0, Section 7](https://openid.net/specs/openid-federation-1_0.html#section-7)) provide this missing binding — a Trust Mark is a signed assertion by a Trust Mark Issuer that an entity satisfies specific criteria. | ||
|
|
||
| ETSI Trusted Lists solve this binding internally through service type identifiers within the list itself. OpenID Federation has no equivalent built-in mechanism for tying a trust chain to a specific credential type authorization. Trust Marks fill this gap. |
There was a problem hiding this comment.
Although STIs are extensible, I expect them to stay coarse‑grained (provider/service‑type level, e.g. EAA, EAA/Q, EAA/Pub‑EAA), whereas Trust Marks can be fine‑grained, down to the credential‑type level. Might be worth noting this explicitly here, since it's really the reason Trust Marks add value over STIs.
|
|
||
| ETSI Trusted Lists solve this binding internally through service type identifiers within the list itself. OpenID Federation has no equivalent built-in mechanism for tying a trust chain to a specific credential type authorization. Trust Marks fill this gap. | ||
|
|
||
| Without this extension, a verifier evaluating an `openid_federation` trust authority can confirm the issuer has a valid trust chain to a Trust Anchor, but cannot determine whether the issuer is actually authorized to issue the specific credential type in question. |
There was a problem hiding this comment.
One interesting aspect here is harmonisation with the WRP's providedAttestations. That field already records which credential types an issuer including non qualified one may issue.
| | `frameworkType` | string | yes | (existing) Trust framework type. One of `aki`, `etsi_tl`, `openid_federation`. | | ||
| | `value` | string | yes | (existing) Trust Anchor entity identifier (URI). | | ||
| | `isLOTE` | boolean | no | (existing) Set `true` for ETSI List of Trusted Lists. Only applicable when `frameworkType` is `etsi_tl`. | | ||
| | `trustMarkId` | string | no | URI identifying a Trust Mark that the issuer MUST hold. Only applicable when `frameworkType` is `openid_federation`. | |
There was a problem hiding this comment.
Shouldn't we consider supporting more than one Trust Mark here? It would make it slightly more complex, but issuing a given credential may require the issuer to satisfy several criteria (not just credential‑type authorization but also, e.g., security/assurance conformance) each expressed as its own Trust Mark. That would mean trustMarkId becomes a list (all MUST hold) rather than a single value.
3 participants
Summary
Proposes extending the TS11
TrustAuthoritymodel with two optional fields for OpenID Federation trust framework entries:trustMarkId— URI identifying a Trust Mark the issuer must holdtrustMarkIssuers— accepted Trust Mark Issuers for the specified Trust MarkMotivation
ETSI Trusted Lists bind issuers to credential types through service type identifiers within the list itself. OpenID Federation has no equivalent built-in mechanism. Trust Marks fill this gap by providing a signed assertion that an issuer satisfies specific criteria (e.g., authorization to issue a particular credential type).
Key design points
frameworkTypeisopenid_federationTrustAuthorityentries across framework types use OR-semantics — verifiers satisfy at least one