redirect_uri schema

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/2051

Original Reporter: alen_horvat

Current client_id_schema = redirect_uri relies on a prior knowledge about the client_id + TLS. (does not apply to other schemas)

TLS certificates contain only host names or they are wildcard certs.

1. Redirect URI will always contain an additional path
2. Redirect URI can be set dynamically or it can change over time (usually configuration is used to declare the endpoint)
3. In multi-tenant systems identity may be expressed in the sub-domain name or in the path of the redirect uri

For the first 2 points, would it make sense to set the client_id as the base URI, where the redirect_uri_path would only contain a path that must be append to the client_id?

3rd point is a bit more tricky when identity of the RP is expressed in the path or subdomain + wildcard certs are used.

Is it in interest of the WG to consider the improvements?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

How does redirect_uri rely on TLS? redirect uri just uses the redirect_uri as client id assuming the data is disclosed to this destination only, so noone can impersonate a verifier using a certain redirect uri.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: alen_horvat

When used with direct_post/direct_post.jwt

Even if there’s a redirect, the client id contains path elements. In OIDC all elements are configurable and a set of valid URIs are defined in the redirect_uris (if I remember correctly) claim in the oidc configuration. Hence, even if the implementation changes, client_id can remain the same (if defined as proposed above)

We ran into this issue since in one of the implementations where we versioned the endpoints, new version required to re-distribute the client_id info.

IMO, client_id should not change if a organisation replaces their implementation.

Or?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

client_id_schema = redirect_uri does not rely on a prior knowledge about the client_id. It is meant for the simplest PoC like implementations (which should be more explicit in the spec text probably).

when used with direct_post, client_id is expected to contain all path elements of redirect_uri

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

The client id scheme redirect_uri is not supposed to provide a stable client id for multiple or changing redirect uris. We have other client id schemes for that purpose. redirect uri is kind of the entry level, lightweight id scheme to have some identification of a client while ensuring existing consent cannot be utilized by an adversary.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: alen_horvat

Clear. Thank you. Should this be reflected in the description of the client_id_schema?

@{63696ff6c383ad8421462592} should this affect the mDL -7 redirect_uri client_id_schema?

Thank you!

Issue can be closed.