On Mon, Jul 8, 2024 at 11:33 AM Emelia S. <eme...@brandedcode.com> wrote:
> I would suggest that if an AS were to implement to competing > specifications for what a client_id means, then it'd be up to the > implementor to decide what is used when. E.g., it'd be difficult to support > both OpenID Federation and this I-D simultaneously without some degree of > work on the implementors' behalf to try to decide which specification > should be used (both have client_id's as URIs, but operate very differently) > Why would there be any difference between the two? OpenID Connect does not dictate where the client metadata comes from. The only real mechanism for "claim" here would be through some sort of DNS > proof, but that requires either some sort of binding between the client > identifier metadata document and the DNS record, or some pre-existing > relationship with the AS where the AS provides the value for the proof. I'd > be inclined to consider this out of scope, and just allow AS's to provide > access to resources as they see fit (no different to dynamic client > registration) > Per my comments in GitHub, do we want to be able to treat developers of software that want localhost differently than people that deploy the software that are able to deploy without registration? If so, then standardizing how to claim your app may be useful. There may not be a requirement to actually claim the app though. The developer might be able to just enter a URI for the client and then have access to additional features for development. I've not thought through all the security implications of course! Sorry we won't see you in Vancouver! /Dick
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
