- changed title to client identifier in SIOP when the DIDs are used
- edited description
client identifier in SIOP when the DIDs are used
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.
Comments (10)
-
reporter -
reporter - edited description
-
reporter - changed status to open
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.
-
Can we also support resolving the signing key via RP
/.well-known/openid-configuration
's jwks_uri, based on the domain in theclient_id
? -
reporter 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
ofclient_id
that equalsredirect_uri
like in the current SIOP? -
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 matchclient_id
, v2 would say thatredirect_uri
is mandatory and MUST NOT matchclient_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
andregistration_uri
request parameters from SIOP v2, which are IMHO strong candidate sources for security exploits (and just generally make things much more complex). -
reporter 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 metadataregistration_uri
is a URL where SIOP sends the response- remove
registration
andregistration_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?
-
reporter Issue
#1263is 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. -
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 -
reporter - changed status to resolved
PR #53 resolves this
- Log in to comment