Other client id values than redirect URI
Have there been discussions before to utilize other values than the redirect uri as client id value for SIOP RP?
Redirect URIs are not the most stable data on earth and loosing the client id means loosing the connection between the RP and the respective key pair used to authenticate with the RP.
I think public keys, DIDs or OIDC federation could be more advanced options.
Comments (10)
-
-
reporter - changed title to Other client id values than redirect URI
- edited description
-
In some cases, the OpenID Connect Federation spec uses the Entity Statement as the Client ID.
-
reporter Should that be listed as an option in SIOP v2? I guess OIDC federation would also provide means to establish trust in the client id via signature and/or redirect_uris in the confirmed entity statements.
-
I filed a separate proposal,
#1289, on replacing the redirect_uri behavior with a feature on federation entity statements. -
- changed status to open
-
reporter thanks Dave. Please note: this issue asks for advanced option. I don’t propose to remove the redirect_uri as client_id.
-
Is
#1290related or even superseding this issue? -
This has been addressed in PR #53
- when request is not sighed, redirect_uri=client_id
-
when request is signed,
- client_id can be a DID and DID resolution is used and
- client_id can be an HTTP URL and OpenID Federation Entity Statements in Automatic Registration is used
I think we can close this issue.
-
- changed status to resolved
Resolved after 2021-11-17 SIOP call
- Log in to comment
I agree with the statements. Not sure if we are ready yet to pick an alternate. This goes to the core of identifying the client to the user (who is also the OP). We may need more than an issue to resolve this.