client_metadata_uri security considerations

[OIDF-automation]

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

Original Reporter: KristinaYasuda

Raised by George: “should we have some “security considerations” about following unknown URIs? For example, is there a requirement that the domain of the client_id be the same as the domain of the client_metadata_uri?” (original issue comment)

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

In OIDC Federation we have a .well-known webpath appended to the client_id url

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

I don’t know if this issue was already resolved by a PR

anyway, the client_metadata_uri should be built starting from the client_id if this is an https URL, and I would suggest a .well-known endpoint

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

that might be a good option. I am not sure if this will limit any DID based deployments - guess they just use client_metadata parameter if needed.

[peppelinux]

What about providing the client metadata from a trusted registry and therefore using and endpoint outside of the client's domain?

for some trust framework this would represent a crucial requirement.

[jogu]

What about providing the client metadata from a trusted registry and therefore using and endpoint outside of the client's domain?

Wouldn't that be better solved with OpenID Federation? 😁

[jogu]

As a way to try and make progress, I've opened a new issue, #202, that suggests completely removing the client_metadata_uri parameter. Comments on that issue would be most welcome.

[peppelinux]

What about providing the client metadata from a trusted registry and therefore using and endpoint outside of the client's domain?

Wouldn't that be better solved with OpenID Federation? 😁

The concept of registry can be abstract, where an openid federation api and a collected trust chain represent a distributed registry

Behind this there Is the third-party trust model, whatever it might be technically implemented