redirect_uri, claims_supported, scopes_supported in SIOP registration?

[Torsten Lodderstedt]

It’s not clear to me whether a RP is supposed to register redirect_uri, claims_supported, or scopes_supported with a SIOP. I don’t think it makes sense and would ask the WG for clarification.

[Kristina Yasuda]

redirect_uri has been included for backward compatibility reasons with OIDC.CORE, even though in SIOP redirect_uri = client_id. Since RPs supporting SIOP would probably need to use new libraries that support SIOP, it might make sense to rethink where backward compatibility does not have to be prioritized.

For scopes_supported, do you mean that in SIOP scope will be set to openid, and address , email etc. will not be used since Access Token is not involved?

Could you please elaborate on claims_supported ? SIOP might want to tell RP which claims it holds - or do you imagine this to be replaced by PE syntax in OIDC4VP?

‌

[Torsten Lodderstedt]

This ticket is about registration only. I don’t think it makes any sense the SIOP RP registers redirect_uri, claims_supported or scopes_supported given this registration takes place along with the request and is one time only.

[Michael Jones]

claims_supported and scopes_supported are Discovery parameters (from the list in https://openid.net/specs/openid-connect-discovery-1_0.html) - not Registration parameters.

[Torsten Lodderstedt]

thanks Mike. Seems I was temporarily confused. This means my question relates to redirect_uris only.

[Michael Jones]

Unless we remove the redirect_uri entirely (which I’m not advocating), it would seem to me that it’s logical to include it in the client registration metadata. Torsten, can you elaborate on your statement that you don’t think it makes sense?

[Torsten Lodderstedt]

The redirect URI of a particular RP is already passed as client id value and is the only legit redirect URI value. This is a security/privacy measure since it ensures another RP cannot “utilize” a legit RP’s consents and PPIDs/sub values just by using the same client id but another redirect_uri.

I therefore think passing a different redirect URI as registration metadata is dangerous.

[Kristina Yasuda]

at Sept-21-2021 call this was discussed. It was suggested that it is ok to include redirect_uris in the registration block in the req if the req is signed by the client you already have a relationship with. and add a text saying not to include redirect_uris in registration block in other cases.

[Torsten Lodderstedt]

What are the underlying assumptions re key exchange and trust management between RP and SIOP?

[Kristina Yasuda]

PR #53 introduced the following language in Relying Party Registration section:

`registration` parameters **MUST NOT** include `redirect_uris` to prevent attackers from inserting malicious Redirection URI. If `registration` parameter includes `redirect_uris`, Self-Issued OP **MUST** ignore it and only use `redirect_uri` directly supplied in the Self-Issued OP request.

I think we can close this issue.

[Kristina Yasuda]

Resolved after 2021-11-17 SIOP call