On Wed, Dec 14, 2022 at 12:04 PM Dick Hardt <dick.ha...@gmail.com> wrote:
> > 1. I see the value of client discovery for registered clients as well as > for registering clients. For example, the client may be registered at a > number of ASes, and a discovery document lets the client update its > information once at its discovery endpoint rather than having to > manually update the information at each AS. A key example of this (pun > intended) is client key rotation. => I'd suggest updating the introduction > to not be focussed on registration, but as a way for the AS to learn about > a client. > > 2. I'm strongly opposed to JSON-LD as an optional format. Extra complexity > for an AS to support with no added value since JSON is already being > supported so would not be able to take advantage of any JSON-LD features. > > 3. I agree with using .well-known for discovery. It has become pretty > common now, and that pattern helps prevent there being a conflict with any > existing content / routes that are at the client endpoint. > > 4. This proposal presumes the client provides the same redirect_urs to > each AS. In the clients that I have deployed, I have unique redirect URIs > for each AS to assist in knowing which AS has sent back the redirect. For > example, I append an AS specific slug to the redirect URI. How would that > be handled in this proposal? One path would be for me to provide an AS > specific URI for the client to each AS. > > 5. In HellÅ -- we offer developers the option to include a logo to be used > for dark themed experiences in addition to the standard light themed > experience. > > 6. I did not see URIs for the standard terms (ToS) of service and privacy > policy (PP) URIs > Just in case it helps, FedCM makes IdPs expose a .well-known/web-identity file that, if you dereference all of the links, at some point gets to a configuration that points to the PP & TOS: https://fedidcg.github.io/FedCM/#idp-api-client-id-metadata-endpoint We use the PP & TOS to construct the browser UX. I'm not sure how FedCM's .well-known file relates to the .well-known file being discussed here, but it seemed worth bringing up since it shares some of the properties here. > 7. on the ToS and PP topics, we could include version info so that it is > easier for the AS to detect if the ToS and PP have been updated since the > last time the user provided consent > > 8. I prefer the other proposal I saw where 'client_uri` was used to signal > that client info was at a URI rather than using 'client_id', and client_id > and client_uri would be mutually exclusive. Doing this for both the > authorization and token endpoints would be what I would propose. Note that > we are deprecating the redirect_uri to be in the token request in OAuth 2.1. > > 9. With client discovery, we can more easily move to the client > authenticating with a signed request rather than a client secret, so a > jwks_uri would be a great addition > > 10. The string comparison in section (6) is confusing. My understanding is > that we have gone with byte comparisons with no transformations. What am I > missing? > > /Dick > > 10. > > > > On Wed, Dec 14, 2022 at 5:14 AM Dmitry Telegin <dmitryt= > 40backbase....@dmarc.ietf.org> wrote: > >> Hi Tobias, >> >> On Wed, Dec 14, 2022 at 2:49 AM Tobias Looker <tobias.looker= >> 40mattr.glo...@dmarc.ietf.org> wrote: >> >>> >>> There are certainly things we could explore here, one such option could >>> be to continue to only return application/json but for the document to >>> include an element like "@context" in the response if its desired that the >>> metadata be processable as a JSON-LD document. >>> >> >> I'd generally agree; my only concern about the Content-type is that it >> could be set by the web server rather than the developer, and developers >> might have no control over the web server configuration. If, for example, >> the metadata is deployed as a static JSON-LD file, and the web server uses >> MIME DB, then it will serve the resource as application/ld+json rather than >> application/json (unless reconfigured to do so). >> >> >>> >>> Yes I've had similar thoughts about this, I think RFC 9111 could be a >>> good basis. What remains a little unclear to me is what normative >>> requirements we might impose on implementers in regards to caching, for >>> instance I think requiring clients hosting their metadata to implement HTT >>> request caching would be too strict, but if they are to implement it, RFC >>> 9111 is recommended and if you do here is how it must be implemented? >>> >> >> I agree that requiring clients to implement caching (i.e. to guarantee >> Age and Cache-Control headers) might be excessively strict. But in the case >> where the headers are not present, I think we should recommend the ASes to >> implement some opinionated defaults (e.g., default TTL for client metadata >> = 1 hour etc.) >> >> Dmitry >> >> >>> >>> 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 <+64%2027%20378%200461> >>> 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:* Dmitry Telegin <dmitryt=40backbase....@dmarc.ietf.org> >>> *Sent:* 14 December 2022 06:30 >>> *To:* Tobias Looker <tobias.looker@mattr.global> >>> *Cc:* Ben Schwartz <bem...@google.com>; 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. >>> >>> 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 <+64%2027%20378%200461> >>> 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 >> > _______________________________________________ > 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
