Other client id values than redirect URI

[Torsten Lodderstedt]

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.

[Tom Jones]

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.

[Michael Jones]

In some cases, the OpenID Connect Federation spec uses the Entity Statement as the Client ID.

[Torsten Lodderstedt]

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.

[David Waite]

I filed a separate proposal, #1289, on replacing the redirect_uri behavior with a feature on federation entity statements.

[Torsten Lodderstedt]

thanks Dave. Please note: this issue asks for advanced option. I don’t propose to remove the redirect_uri as client_id.

[Oliver Terbu]

Is #1290 related or even superseding this issue?

[Kristina Yasuda]

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.

‌

[Kristina Yasuda]

Resolved after 2021-11-17 SIOP call