I propose a simplification of SIOP and DID usage, where client_id and issuer are “entity resolving identifiers”, and subject is when it is a URI.
An “entity resolving identifier” uses a trusted process, to authoritatively resolve OpenID Federation entity statements into leaf entity metadata for an entity based on a given URI and scheme.
This definition is purposely meant to overlap DID resolution and the HTTPS-based resolution in the OpenID Federation drafts. It allows for DID resolution (and other potential future schemes) to be defined as an independent process.
If this resolution process is defined as an API, one would expect it to look similar to:
func requestEntityMetadata( client_or_issuer: URI, authority_hints: Array<URI>) -> (leaf_entity_metadata: JSON, jwks: JSON)
- Data is returned in the combined metadata format of an entity statement, and not just as OpenID Server Metadata. This is meant to allow for consistent rules for both RP and OP roles, and to allow for future expansion of roles.
- The entity statement is JSON and not a JWT, in anticipation of some resolution schemes providing a different integrity protection mechanism than signed/encrypted JWTs.
- The Federation resolution logic, e.g. chaining to an authority and combining metadata by policy, is encapsulated by the API. Note that this could conceivably be cross-scheme, e.g. a DID-identified client having a HTTPS-based authority.
- The JWKS is given as JSON data. OIDC Federation also allows the JWKS to be signed by the entity statement key. The process for resolving the key set may also come from an alternative resolution scheme and content format, such as verification methods on a DID document. For SIOP, #1291 may mean that there is no JWKS information provided here.
- Because data is not given in a way where authority and integrity can be independently confirmed, this is necessarily a trusted process/component.
The metadata for an RP or OP would be expected to include information on resolvable identifier schemes supported. The resolution schemes SHOULD have a prefix of the URI method, but may have further distinguishing data (such as a DID method, as these each require different resolution implementations).