Hello Tobias, thanks for the draft! In regards to prior art, I'd like to mention Solid Project and their OIDC flavor, Solid-OIDC: https://solid.github.io/solid-oidc/#clientids-document
They're using a similar approach (and have been for years), though with some differences: - client_id points to a URL that must resolve to the client metadata document directly (no .well-known/* used); - the document's format is JSON-LD, a superset of JSON. In order to maintain compatibility with Solid and similar existing technologies, would it make sense to mention that: - while retrieving client metadata, AS should recognize not only application/json, but application/ld+json (or maybe even application/*+json, as per https://datatracker.ietf.org/doc/html/rfc6839#section-3-1)? - any unknown fields (like JSON-LD "@context") must be ignored? On an unrelated note, it would be nice to cover the issue of caching the client metadata on the AS side. Obviously, we wouldn't want to re-request the metadata upon every request to the authorization endpoint. Would RFC 9111 suffice here? If so, which subset should be guaranteed to be supported by the AS? Thanks, Dmitry On Wed, Nov 9, 2022 at 8:36 PM Tobias Looker <tobias.looker= 40mattr.glo...@dmarc.ietf.org> wrote: > Hi Ben, > > See below for some thoughts. > > > I'm having trouble understanding the precise URL structures that are > used here. Can client_uri include a nontrivial path? Why is it necessary > to repeat client_uri in the response JSON? > > The intent here is to follow how "OAuth 2.0 authorization metadata" works > (RFC 8414) which requires the client resolving the authorization server > metadata to check that the issuer in the resolved document matches the > issuer URL they started the resolution with, see below for the relevant > extract from RFC 8414. > > " > > The "issuer" value returned MUST be identical to the authorization > server's issuer identifier value into which the well-known URI string > was inserted to create the URL used to retrieve the metadata. If > these values are not identical, the data contained in the response > MUST NOT be used. > > > " > > So the equivalent with our draft is to require the authorization server to > validate that the client_uri returned in the clients metadata response > matches the URL that was used to retrieve the metadata. > > > The use of .well-known is a bit unusual. Why not just host the JSON at > the client_uri? > > Just to clarify it is, just under a well-known path? e.g if the client uri > is https://client.example.com then the metadata would be published at > https://client.example.com/.well-known/oauth-client > > > Finally, I note that the section on Impersonation Attacks doesn't > mention the client_name or logo_uri. If these are to be shown to the user, > they present a very serious impersonation risk that ought to be discussed. > (The client_name also might need to be localized, which could be done by > fetching the JSON document with an appropriate Accept-Language request > header.) > > Yes absolutely agree this is an important security consideration to > highlight, I will capture an issue. > > > Thanks, > > [image: Mattr website] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0> > > > > *Tobias Looker* > > MATTR > CTO > > +64 (0) 27 378 0461 > tobias.looker@mattr.global > > [image: Mattr website] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0> > > [image: Mattr on LinkedIn] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1SbN9fvNg%26u%3Dhttps%253a%252f%252fwww.linkedin.com%252fcompany%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D&reserved=0> > > [image: Mattr on Twitter] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WdMte6ZA%26u%3Dhttps%253a%252f%252ftwitter.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D&reserved=0> > > [image: Mattr on Github] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiWwGdMoDtMw%26u%3Dhttps%253a%252f%252fgithub.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D&reserved=0> > > > This communication, including any attachments, is confidential. If you are > not the intended recipient, you should not read it - please contact me > immediately, destroy it, and do not copy or use any part of this > communication or disclose anything about it. Thank you. Please note that > this communication does not designate an information system for the > purposes of the Electronic Transactions Act 2002. > > ------------------------------ > *From:* Ben Schwartz <bemasc=40google....@dmarc.ietf.org> > *Sent:* 10 November 2022 07:04 > *To:* Tobias Looker <tobias.looker@mattr.global> > *Cc:* oauth@ietf.org <oauth@ietf.org> > *Subject:* Re: [OAUTH-WG] OAuth2 Client Discovery > > EXTERNAL EMAIL: This email originated outside of our organisation. Do not > click links or open attachments unless you recognise the sender and know > the content is safe. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
