On Mon, Jul 8, 2024 at 12:38 PM Emelia Smith <eme...@brandedcode.com> wrote:
> > > On 8. Jul 2024, at 21:17, Dick Hardt <dick.ha...@gmail.com> wrote: > > > 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. > > > 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. > > > https://openid.net/specs/openid-federation-1_0.html#name-obtaining-federation-entity > > 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) > Silly me. I thought you had mistyped OpenID Connect as OpenID Federation and glossed over that. As the resolution will provide different data (and the URL to be resolved is different), an AS could act accordingly based on the result. I think all that is needed for the spec is calling out the potential conflicts and that the AS needs to be able to figure it out. > > 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. > I agree we don't want to support client_ids that resolve to non-public metadata. But the metadata could include localhost as a redirect_uri. That was what I thought we were discussing. What are valid redirect_uris, and are they restricted to being a URL containing the client_id. >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
