Relying Party Instances and metadata in SIOP
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:
- 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)
- Lack of back-end API endpoints (can still have shared back-end infrastructure between one or more RPs, but not per-instance)
- Inability to securely share secrets for e.g. signed requests
- 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.
Comments (4)
-
reporter -
reporter From the SIOP call on 20211005, it appears there are four different approaches based on current protocol primitives which had traction:
- client_id URI resolved to authoritative metadata including public keys
- client_id URI resolved to authoritative keys but no metadata, registration in signed request
- pre-negotiated client_id
StringOrURI
with pre-negotiated metadata with keys - pre-negotiated client_id
StringOrURI
with keys but no metadata, registration in signed request - client_id as redirect URI with no metadata or keys, so no registration parameter
(let me know if I’m missing one or mischaracterizing)
-
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)
- [your 3 and 4] a pre-registered RP/Client - client_id is pre-registered [usual OIDC model]
-
Not pre-registered RP/Client - client_id is NOT pre-registered
- [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]
- [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]
- [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.
-
reporter - changed status to resolved
Closing due to updated language in implementor's draft.
- Log in to comment
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.