client identifier in SIOP when the DIDs are used

[Kristina Yasuda]

Currently, SIOP assumes that client_id = redirect_uri because without pre-registration of the client_id SIOP cannot trust it, and redirect_uri is the only way for SIOP to identify the RP. However that became possible with DIDs that introduced indirection.

Suggestion to add a parameter in a SIOP request when RP can be identified by a DID - something like rp_did. (hope someone can help with a better name)

When SIOP request is signed, SIOP will check the signature using a public key from a DID Document obtained by resolving a DID in rp_did, identified by kid of the header.

[Kristina Yasuda]

On 2021-07-21 call, John agreed using DIDs would allow SIOP to identify RP in a way that was not possible in the original SIOP text.

[Jeremie Miller]

Can we also support resolving the signing key via RP /.well-known/openid-configuration's jwks_uri, based on the domain in the client_id?

[Kristina Yasuda]

That should make client_id trustable even without pre-established trust and without using DIDs.

Would it make sense to “revive“ client_id in SIOP, but limit it to DID or a URL with particular requirements? If it is a DID, SIOP MUST perform a DID Resolution, if it is a URL, SIOP MUST resolve /.well-known/openid-configuration to obtain jwks_uri?

or were imagining resolving /.well-known/openid-configuration of client_id that equals redirect_uri like in the current SIOP?

[David Waite]

I’ve been thinking of this some lately, along the lines of how to differentiate a SIOPv1 request from a SIOPv2 request and specifically if there is a way we can do a clean break - change a normative rule such that an implementation that only knows SIOP v1 will reject v2 messages.

So, if v1 says that the redirect_uri is optional and if specified must match client_id, v2 would say that redirect_uri is mandatory and MUST NOT match client_id.

At that point, we can define `client_id` to be a resolvable URI - you can use any URI scheme that the Self-Issued OP understands how to resolve into client metadata. For HTTPS scheme that process could be OpenID Federation, for a DID that might use a DID resolver.

Ideally, we can use such a scheme to remove registration and registration_uri request parameters from SIOP v2, which are IMHO strong candidate sources for security exploits (and just generally make things much more complex).

[Kristina Yasuda]

So, if I understand correctly, the proposal is to

• client_id is a URI that can be resolved to a a document that includes registration metadata
• registration_uri is a URL where SIOP sends the response
• remove registration and registration_uri

with a purpose of

• prevent a potential security attack where malicious RP can use a client_id of a good RP and add a bad redirect_uri by passing it in a registration parameter?
• differentiating siop v1 from siop v2 implementations

I think this makes sense.

Would this also solve an security issues in cross-device SIOP if SIOP would have to check if redirect_uri in the metadata resolved from client_id matches redirect_uri in the request? because SIOP will be able to verify where it is redirecting - prevents open redirect/SSRF in the response, and SIOP will be able to trust the source of the request based on the combination of both redirect_uri and client_id in the request?

‌

[Kristina Yasuda]

Issue #1263 is related. we could keep client_id=registration_url, with the above mechanism, but than the question is how does OP differentiates, if client_id is simply a registration_url, or a resolvable URL/DID.

[Giuseppe De Marco]

What about resolving the signing key via RP /.well-known/openid-federation and consider adopting oidc federation 1.0?

see
https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.6.1

[Kristina Yasuda]

PR #53 resolves this