[Openid-specs-ab] Issue #1289: SIOP and Entity Resolving Identifiers (openid/connect)

David Waite issues-reply at bitbucket.org
Mon Aug 16 22:36:01 UTC 2021


New issue 1289: SIOP and Entity Resolving Identifiers
https://bitbucket.org/openid/connect/issues/1289/siop-and-entity-resolving-identifiers

David Waite:

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 an OpenID Federation[ entity statement](https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.2.1) and associated key material \(JWKS\) 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:

```swift
func requestEntityMetadata(
  client_or_issuer: URI,
  authority_hints: Array<URI>) -> (entity_statement: JSON, jwks: JSON)
```

Specifically:

1. The format is always an entity statement, and not OpenID Server Metadata in the case of issuers. This is meant to allow for consistent rules for both RP and issuer roles, and to allow for future expansion of roles.
2. The entity statement is JSON and not a JWT, in anticipation of some resolution schemes providing a different integrity protection mechanism.
3. The federation resolution logic is behind the interface - any chaining up to authorities and combining metadata per policy is 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.
4. The JWKS is given a decrypted data rather than a signed JWT \(which is allowed by OIDC Federation\) to support the JWKS information _also_ coming from an alternative resolution scheme, such as the DID document itself.
5. 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\).




More information about the Openid-specs-ab mailing list