You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We recently ran into an situation where a client added some metadata to its Client ID Document, in particular a logo_uri. The value for this property was relative URL, which isn't something that is explicitly prevented by the specification, and can make sense in the context of a dereferencable Client ID.
The Client Metadata semantics in Solid-OIDC are aligned with the underlying OpenID Dynamic Client Registration specification, but in the context of that specification, relative URLs don't make sense, so this isn't called out.
In order to remain aligned with the underlying Client Metadata specification, the Solid-OIDC specification could add another requirement on the Client in its Client ID Document section, such as "URIs provided as values for parameters in the Client ID Document MUST be absolute".
The alternative would be to add a requirement on the OP conformance class to support relative URIs, but I think it moves away from the underlying specification and would potentially open up possibilities for more misalignments.
The text was updated successfully, but these errors were encountered:
I think this would be a necessary restriction at the Dynamic Client Registration level too, and could actually be a vector of attack for impersonation of a client (i.e., faking that your client is some other trusted client). Perhaps this is something more for the underlying security recommendations for OAuth?
We recently ran into an situation where a client added some metadata to its Client ID Document, in particular a
logo_uri
. The value for this property was relative URL, which isn't something that is explicitly prevented by the specification, and can make sense in the context of a dereferencable Client ID.The Client Metadata semantics in Solid-OIDC are aligned with the underlying OpenID Dynamic Client Registration specification, but in the context of that specification, relative URLs don't make sense, so this isn't called out.
In order to remain aligned with the underlying Client Metadata specification, the Solid-OIDC specification could add another requirement on the Client in its
Client ID Document
section, such as "URIs provided as values for parameters in the Client ID Document MUST be absolute".The alternative would be to add a requirement on the OP conformance class to support relative URIs, but I think it moves away from the underlying specification and would potentially open up possibilities for more misalignments.
The text was updated successfully, but these errors were encountered: