On 8. Jul 2024, at 21:17, Dick Hardt <dick.ha...@gmail.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.
This is in relation to OpenID Federation which also allows URIs as client_id's and has a process for resolving them based on a well-known URI.
So how it handles a URI as client_id is different to how our I-D handles things, you would likely pick one to implement based on your security requirements. (e.g., a bank or fintech service isn't likely to use client identifier metadata documents, because they need a much higher level of trust than something like social networking)
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!
I don't think we do want to support client_id's that resolve to non-public resources, as there is just too much risk of SSRF attacks and the AS cannot fetch the client metadata, which is the entire purpose of this I-D: allowing the AS to request the metadata rather than needing DCR.
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
