Relying Party Instances and metadata in SIOP

[David Waite]

On the Connect/SIOP call today, the a good portion of discussion was centered on public (non-confidential) clients which were native apps or client-side web applications, which have similar limitations to SIOP:

1. Limitations on HTTP methods (e.g. native apps cannot receive form posts with POST, PWA form post with POST will send data to hosted infrastructure)
2. Lack of back-end API endpoints (can still have shared back-end infrastructure between one or more RPs, but not per-instance)
3. Inability to securely share secrets for e.g. signed requests
4. Reduced capacity to prevent malicious client impersonation

This appeared to be brought to a head by additional restriction on the “registration” parameter and other registration data to be authoritative for the RP. For example, one party indicated they were using the registration parameter to supply consistent public keys and were using that, rather than the client_id, to distinguish and secure individual RP “instances”. This also has been exasperated by the use of OpenID Federation’s automatic client registration, which requires a client public key to be known for signed communication.

This issue is meant to collect discussion topics on normative spec behavior around metadata. Separate issue(s) should be used for discussion of endpoints for large request/response messages and for cross-device communication.

[David Waite]

Since there are a lot of different approaches for solving this, I will try to kick discussion off by a high level distinction which serves to “bucket” proposals with respect to how we distinguish RP instances.

1. When public clients need to be uniquely identified (such as to do signed requests) they need to have different client_id values to correspond to the different credentials. This corresponds the the behavior you would get from dynamic client registration for individual installs of a mobile client with traditional OAuth/OpenID Connect.
2. A new class of client, a self-identifying relying party (SIRP) be created. Similar to SIOP, it is not identified uniquely by a relying party identifier but by the identifier plus its request signing keys.
3. Distinguishing individual RP instances is out of scope. We do not need a registration parameter and do not support techniques like signed requests. This may mean defining another “introduction” protocol for the RP/OP besides automatic client registration in OpenID Federation, which requires signed requests

‌

[David Waite]

From the SIOP call on 20211005, it appears there are four different approaches based on current protocol primitives which had traction:

1. client_id URI resolved to authoritative metadata including public keys
2. client_id URI resolved to authoritative keys but no metadata, registration in signed request
3. pre-negotiated client_id StringOrURI with pre-negotiated metadata with keys
4. pre-negotiated client_id StringOrURI with keys but no metadata, registration in signed request
5. client_id as redirect URI with no metadata or keys, so no registration parameter

(let me know if I’m missing one or mischaracterizing)

[Kristina Yasuda]

I think current SIOP spec aligns with what is described in this issue. I summarized the same topic in another issue as follows (mapping to your list above in italics)

1. [your 3 and 4] a pre-registered RP/Client - client_id is pre-registered [usual OIDC model]

2. Not pre-registered RP/Client - client_id is NOT pre-registered

   1. [your 2] DID that the Wallet/SIOP might be seeing for the first time; DID Doc used to obtain only the key to verify the signed request (if it is signed); rest of the registration metadata is included in the request itself [Microsoft model]
   2. [your 1] HTTPS URL that the Wallet/SIOP might be seeing for the first time; Entity statement used to obtain the registration metadata AND the key to verify the signed request [Ping preferred model]
   3. [your 5] redirect_uri = client_id; request is not signed

Please do a PR if you think overview in the Registration section in the SIOP spec can be made a little more high-level, closer to the language you use. Otherwise, I suggest we close this issue.

[David Waite]

Closing due to updated language in implementor's draft.