Re: [OAUTH-WG] [SPICE] Regarding draft-ietf-oauth-status-list-00
Apologies, meant to link to the issue in case anyone would like to contribute to the discussion. https://github.com/vcstuff/draft-ietf-oauth-status-list/issues/93 Thanks, [MATTR website]<https://mattr.global/> Tobias Looker MATTR +64 273 780 461 tobias.looker@mattr.global<mailto:first.last@mattr.global> [MATTR website]<https://mattr.global/> [MATTR on LinkedIn]<https://www.linkedin.com/company/mattrglobal> [MATTR on Twitter]<https://twitter.com/mattrglobal> [MATTR on Github]<https://github.com/mattrglobal> 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: Tobias Looker Date: Monday, 15 January 2024 at 9:17 PM To: Orie Steele , oauth , sp...@ietf.org Subject: Re: [SPICE] Regarding draft-ietf-oauth-status-list-00 > Will there be a similar recommendation to use OHTTP with > draft-ietf-oauth-status-list ? I’ve opened an issue to track this but in general as editors we agree that adding an implementation consideration is likelyworthwhile. Thanks, [MATTR website]<https://mattr.global/> Tobias Looker MATTR +64 273 780 461 tobias.looker@mattr.global<mailto:first.last@mattr.global> [MATTR website]<https://mattr.global/> [MATTR on LinkedIn]<https://www.linkedin.com/company/mattrglobal> [MATTR on Twitter]<https://twitter.com/mattrglobal> [MATTR on Github]<https://github.com/mattrglobal> 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: SPICE on behalf of Orie Steele Date: Sunday, 14 January 2024 at 7:56 AM To: oauth , sp...@ietf.org Subject: [SPICE] Regarding draft-ietf-oauth-status-list-00 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 VC Enthusiasts, I wrote this draft today: https://datatracker.ietf.org/doc/draft-steele-spice-oblivious-credential-state/ It captures some of the discussion we have seen regarding OHTTP and Verifiable Credential Status Lists, that has happened at W3C. - https://github.com/w3c/vc-bitstring-status-list/issues/80 In particular, this paragraph was added as a result of privacy feedback: > Issuers SHOULD publish status list information using HTTPS URLs and in ways > that minimize possible correlation of usage patterns related to the list. > Verifiers SHOULD retrieve status list information using protocols that guard > against access pattern correlation, such as Oblivious HTTP [OHTTP]. > For example, a verifiable credential secured with Data Integrity Proofs might > have media type application/vc+ld+json, while a verifiable credential secured > with SD-JWT might have media type application/sd-jwt. - https://w3c.github.io/vc-bitstring-status-list/#media-types I note that the W3C draft for vc-bitstring-status-list is using the `application/sd-jwt` media type to refer to a specific JSON-LD payload being secured with sd-jwt, namely `application/vc+ld+json`... this seems to be in violation of the JWT BCP, which recommends using explicit types. It also makes me wonder how compatible these 2 drafts will end up being. I think it would be better to recommend a CWT based media type, instead of sd-jwt. Will there be a similar recommendation to use OHTTP with draft-ietf-oauth-status-list ? Regards, OS -- ORIE STEELE Chief Technology Officer www.transmute.industries [Image removed by sender.]<https://transmute.industries/> ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [SPICE] Regarding draft-ietf-oauth-status-list-00
> Will there be a similar recommendation to use OHTTP with > draft-ietf-oauth-status-list ? I’ve opened an issue to track this but in general as editors we agree that adding an implementation consideration is likelyworthwhile. Thanks, [MATTR website]<https://mattr.global/> Tobias Looker MATTR +64 273 780 461 tobias.looker@mattr.global<mailto:first.last@mattr.global> [MATTR website]<https://mattr.global/> [MATTR on LinkedIn]<https://www.linkedin.com/company/mattrglobal> [MATTR on Twitter]<https://twitter.com/mattrglobal> [MATTR on Github]<https://github.com/mattrglobal> 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: SPICE on behalf of Orie Steele Date: Sunday, 14 January 2024 at 7:56 AM To: oauth , sp...@ietf.org Subject: [SPICE] Regarding draft-ietf-oauth-status-list-00 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 VC Enthusiasts, I wrote this draft today: https://datatracker.ietf.org/doc/draft-steele-spice-oblivious-credential-state/ It captures some of the discussion we have seen regarding OHTTP and Verifiable Credential Status Lists, that has happened at W3C. - https://github.com/w3c/vc-bitstring-status-list/issues/80 In particular, this paragraph was added as a result of privacy feedback: > Issuers SHOULD publish status list information using HTTPS URLs and in ways > that minimize possible correlation of usage patterns related to the list. > Verifiers SHOULD retrieve status list information using protocols that guard > against access pattern correlation, such as Oblivious HTTP [OHTTP]. > For example, a verifiable credential secured with Data Integrity Proofs might > have media type application/vc+ld+json, while a verifiable credential secured > with SD-JWT might have media type application/sd-jwt. - https://w3c.github.io/vc-bitstring-status-list/#media-types I note that the W3C draft for vc-bitstring-status-list is using the `application/sd-jwt` media type to refer to a specific JSON-LD payload being secured with sd-jwt, namely `application/vc+ld+json`... this seems to be in violation of the JWT BCP, which recommends using explicit types. It also makes me wonder how compatible these 2 drafts will end up being. I think it would be better to recommend a CWT based media type, instead of sd-jwt. Will there be a similar recommendation to use OHTTP with draft-ietf-oauth-status-list ? Regards, OS -- ORIE STEELE Chief Technology Officer www.transmute.industries [Image removed by sender.]<https://transmute.industries/> ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List
As one of the authors of this draft I support adoption. Thanks, [MATTR website]<https://mattr.global/> Tobias Looker MATTR +64 273 780 461 tobias.looker@mattr.global<mailto:first.last@mattr.global> [MATTR website]<https://mattr.global/> [MATTR on LinkedIn]<https://www.linkedin.com/company/mattrglobal> [MATTR on Twitter]<https://twitter.com/mattrglobal> [MATTR on Github]<https://github.com/mattrglobal> 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: OAuth on behalf of Kristina Yasuda Date: Tuesday, 3 October 2023 at 2:41 AM To: Orie Steele , rifaat.s.ietf Cc: oauth Subject: Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List 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. I support adoption, but we also implemented a similar spec and have similar observations/reservations as Orie. Really hope this draft can build up on the learnings to date and be a significant improvement.. From: OAuth On Behalf Of Orie Steele Sent: Saturday, September 30, 2023 6:10 AM To: rifaat.s.ietf Cc: oauth Subject: Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List I support adoption. We have implementations of a similar spec and we don't think it would be good for vendors to have to support both, but that's not under control of OAuth... we hope there will be significant improvements made, after adoption to justify a separate spec, aside from CWT being generally better than JWT. Many of these improvements have already been discussed on the other spec, and with the authors. It's unfortunate that the spec does not cite previous work, which the authors and undoubtedly aware of, the same comment was made at the microphone at the last IETF. We look forward to reviewing drafts and implementing the spec to compare it's performance vs the existing W3C work item, which I mentioned on a previous thread. If the performance is not substantially better I don't think the draft should become an RFC, but I'm happy to help make it better if that's possible... and this working group has the expertise to improve this work, so I think transferring control to the working group makes sense. OS On Sat, Sep 30, 2023, 7:53 AM Rifaat Shekh-Yusef mailto:rifaat.s.i...@gmail.com>> wrote: All, This is an official call for adoption for the JWT and CWT Status List draft: https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/ Please, reply on the mailing list and let us know if you are in favor or against adopting this draft as WG document, by Oct 13th. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata
I support adoption of this draft. Thanks, [MATTR website]<https://mattr.global/> Tobias Looker MATTR +64 273 780 461 tobias.looker@mattr.global<mailto:first.last@mattr.global> [MATTR website]<https://mattr.global/> [MATTR on LinkedIn]<https://www.linkedin.com/company/mattrglobal> [MATTR on Twitter]<https://twitter.com/mattrglobal> [MATTR on Github]<https://github.com/mattrglobal> 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: OAuth on behalf of Heather Flanagan Date: Thursday, 24 August 2023 at 10:51 AM To: Steinar Noem , oauth Subject: Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata 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. Hi all, I have to chime in on this one. +1 to supporting it for adoption! -Heather On Aug 23, 2023, at 3:46 PM, Steinar Noem wrote: I support adoption ons. 23. aug. 2023 kl. 20:03 skrev Rifaat Shekh-Yusef mailto:rifaat.s.i...@gmail.com>>: All, This is an official call for adoption for the Protected Resource Metadata draft: https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/ Please, reply on the mailing list and let us know if you are in favor of adopting this draft as WG document, by Sep 6th. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth -- Vennlig hilsen Steinar Noem Partner Udelt AS Systemutvikler | stei...@udelt.no<mailto:stei...@udelt.no> | h...@udelt.no<mailto:h...@udelt.no> | +47 955 21 620 | www.udelt.no<http://www.udelt.no/> | ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Call for adoption - SD-JWT-based Verifiable Credentials
I support adoption of this draft. Thanks, [MATTR website]<https://mattr.global/> Tobias Looker MATTR +64 273 780 461 tobias.looker@mattr.global<mailto:first.last@mattr.global> [MATTR website]<https://mattr.global/> [MATTR on LinkedIn]<https://www.linkedin.com/company/mattrglobal> [MATTR on Twitter]<https://twitter.com/mattrglobal> [MATTR on Github]<https://github.com/mattrglobal> 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: OAuth on behalf of David Waite Date: Sunday, 30 July 2023 at 9:45 AM To: Rifaat Shekh-Yusef Cc: oauth Subject: Re: [OAUTH-WG] Call for adoption - SD-JWT-based Verifiable Credentials 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. I support adoption -DW On Jul 29, 2023, at 1:25 PM, Rifaat Shekh-Yusef wrote: All, This is an official call for adoption for the SD-JWT-based Verifiable Credentials draft discussed in SF. https://datatracker.ietf.org/doc/draft-terbu-oauth-sd-jwt-vc/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth 2.0 Attestation-Based Client Authentication
Thanks for the feedback. Generally any OAuth client could make use of this authentication method if they so wish, however the types of client this draft has initially been designed for are ones that don’t typically have good direct authentication options available today (e.g public clients). Thanks, [MATTR website]<https://mattr.global/> Tobias Looker MATTR +64 273 780 461 tobias.looker@mattr.global<mailto:first.last@mattr.global> [MATTR website]<https://mattr.global/> [MATTR on LinkedIn]<https://www.linkedin.com/company/mattrglobal> [MATTR on Twitter]<https://twitter.com/mattrglobal> [MATTR on Github]<https://github.com/mattrglobal> 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: Orie Steele Date: Friday, 21 July 2023 at 7:05 AM To: Tobias Looker Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Attestation-Based Client Authentication 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. Really excited for this, I'm especially interested in how this might apply to M2M flows, related to this part here: https://datatracker.ietf.org/doc/html/rfc7521#section-4.2 It seems very targeted towards mobile / desktop apps, would it work for servers / command line tools, etc? OS On Thu, Jul 20, 2023 at 1:57 PM Tobias Looker mailto:40mattr.glo...@dmarc.ietf.org>> wrote: Hi All, Paul and I would like to draw attention to a new draft we have submitted titled “OAuth 2.0 Attestation-Based Client Authentication” which will be presented at the up and coming IETF 117 meeting during the Friday meeting slot. This draft is related to the group of drafts on verifiable credentials that will be presented during this meeting slot. Specifically this draft is intended to address but not limited to eIDAS 2.0 usage of OpenID4VCI which requires wallet applications to be strongly authenticated via attestations. The current abstract of the draft is as follows: “This specification defines a new method of client authentication for OAuth 2.0 [RFC6749] by extending the approach defined in [RFC7521]. This new method enables client deployments that are traditionally viewed as public clients to be able to authenticate with the authorization server through an attestation based authentication scheme.” Link to the current editors copy => https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth/ Link to the specification repository => https://github.com/vcstuff/draft-looker-oauth-attestation-based-client-auth Thanks, [MATTR website]<https://mattr.global/> Tobias Looker MATTR +64 273 780 461 tobias.looker@mattr.global<mailto:first.last@mattr.global> [MATTR website]<https://mattr.global/> [MATTR on LinkedIn]<https://www.linkedin.com/company/mattrglobal> [MATTR on Twitter]<https://twitter.com/mattrglobal> [MATTR on Github]<https://github.com/mattrglobal> 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. ___ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth -- ORIE STEELE Chief Technology Officer www.transmute.industries [Image removed by sender.]<https://transmute.industries/> ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAuth 2.0 Attestation-Based Client Authentication
Hi All, Paul and I would like to draw attention to a new draft we have submitted titled “OAuth 2.0 Attestation-Based Client Authentication” which will be presented at the up and coming IETF 117 meeting during the Friday meeting slot. This draft is related to the group of drafts on verifiable credentials that will be presented during this meeting slot. Specifically this draft is intended to address but not limited to eIDAS 2.0 usage of OpenID4VCI which requires wallet applications to be strongly authenticated via attestations. The current abstract of the draft is as follows: “This specification defines a new method of client authentication for OAuth 2.0 [RFC6749] by extending the approach defined in [RFC7521]. This new method enables client deployments that are traditionally viewed as public clients to be able to authenticate with the authorization server through an attestation based authentication scheme.” Link to the current editors copy => https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth/ Link to the specification repository => https://github.com/vcstuff/draft-looker-oauth-attestation-based-client-auth Thanks, [MATTR website]<https://mattr.global/> Tobias Looker MATTR +64 273 780 461 tobias.looker@mattr.global<mailto:first.last@mattr.global> [MATTR website]<https://mattr.global/> [MATTR on LinkedIn]<https://www.linkedin.com/company/mattrglobal> [MATTR on Twitter]<https://twitter.com/mattrglobal> [MATTR on Github]<https://github.com/mattrglobal> 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. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth2 Client Discovery
> Don't you think the AS should state what it requires in a client discovery > call as well? I guess I'm trying to understand what exactly this would be and where one would draw the line, for example would the AS simply publish a list of required client metadata properties OR a list of metadata properties and the valid enumeration for each property? The whole purpose of the AS metadata document in the first place is for the AS to publish what it supports, so I'm trying to drill into what is missing. > Why not? Because RFC 6749 > I also prioritize developers using libraries of client library developers. If > I as a consumer of a library am wanting to use client discovery and I happen > to be using a library that does not support it -- it will give me an error > right away because I did not get a client_id. I think the point I was trying to make is that if we re-use client_id then there won't be any need to update client libraries to support client discovery and I think that resolves a significant adoption challenge. > You view client discovery as incremental -- I consider it to be a significant > shift. For example, clients are going to authenticate (if needed) with a > signed request vs using a secret. Understood I think that's correct. Thanks, [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D=0> Tobias Looker MATTR CTO +64 (0) 27 378 0461 tobias.looker@mattr.global<mailto:tobias.looker@mattr.global> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D=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: Dick Hardt Sent: 16 December 2022 09:52 To: Tobias Looker Cc: 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. On Thu, Dec 15, 2022 at 12:39 PM Tobias Looker wrote: > Would be good to see tos_uri and policy_uri (personally, I'm disappointed in > the name policy_uri as policy is a much broader context than privacy -- bu
Re: [OAUTH-WG] OAuth2 Client Discovery
Hi Vladimir, > OAuth 2.0 and OIDC originally have a model where the client metadata is made > to match the server's requirements and supported algorithms. Agreed. > For a client to publish metadata tailored to one particular OP / AS server > doesn't appear to be much of a problem. How do you envision a scenario when > the client developer wants to enable different OP / AS servers, where the > supported algs and other capabilities may differ? Here one strategy could be > to make the metadata as general as possible, but then this may lead to > registration errors due to incomplete metadata. Incomplete metadata can also > cause the server to pick a default value that suits its capabilities, but > because there is no explicit client registration response the client has no > way to find out how it got registered, which may then lead to errors in the > OAuth flow. One option is for the client to publish everything it supports in its metadata document(s) that different AS's can use to assess compatible and pick which various features to use. I agree incomplete metadata could cause incompatibility issues and depending on how strong we want to be in defining this mechanism we could opt for a larger set of metadata being required by a client to lessen the risk of these sorts of incompatibilities arising. IMO just like the incentives at play for an AS to publish a well defined metadata document that reduces the potential for incompatibilities, a client developer using this mechanism will be in a similar boat, more metadata published about the client will mean less potential for bad assumptions being made by the AS. > My second question - if basic auth is regarded as possible with static client > metadata discovery, how can the client and server establish a secret between > them? This is a good catch, w.r.t client authentication I suspect signed requests where the client uses a private key, who's public keys are fetchable from its JWK's endpoint is going to be a better pattern then a shared secret with the AS, will update this section. Thanks, [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D=0> Tobias Looker MATTR CTO +64 (0) 27 378 0461 tobias.looker@mattr.global<mailto:tobias.looker@mattr.global> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D=0> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read
Re: [OAUTH-WG] OAuth2 Client Discovery
ing. My understanding is > that we have gone with byte comparisons with no transformations. What am I > missing? This language was lifted directly from RFC 8414 (https://www.rfc-editor.org/rfc/rfc8414#section-4) it is primarily there to ensure complete definition around how an implementation should check the client_uri value returned in the resolved JSON metadata document matches the client_id/client_uri used to perform the resolution. This check is conceptually the same to what we require implementations to do when performing authorization server (openid provider) discovery in checking the issuer field. Thanks, [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D=0> Tobias Looker MATTR CTO +64 (0) 27 378 0461 tobias.looker@mattr.global<mailto:tobias.looker@mattr.global> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D=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: Dick Hardt Sent: 15 December 2022 09:03 To: Dmitry Telegin Cc: Tobias Looker ; 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. 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 exist
Re: [OAUTH-WG] OAuth2 Client Discovery
> While we're talking about prior art, I should also mention that the IndieAuth > extension of OAuth 2 has been using URLs as client IDs since about 2012. > (Disclosure: I am the editor of the spec) > Since 2012, the spec has matured and was published as a W3C Note in 2018 > while the W3C Social Web Working Group was active. > (https://www.w3.org/TR/indieauth/) Currently, the spec is maintained in the > IndieWeb community, the latest update was in February 2022: > https://indieauth.spec.indieweb.org/20220212/ Is there an accepted way to reference prior art in an I-D I'd like to be able to highlight IndieAuth, Solid and OpenID Federation all as examples of slightly different ways this problem is being solved in the wild today. > For this reason, the IndieAuth spec has put far less emphasis on client > metadata discovery vs making the rest of the OAuth flow work by having the > client_id be a URL. There is a method of client metadata discovery defined, > but it's always secondary to making sure the user can see the redirect URL > (or the client identifier if it has the same hostname as the redirect URL), > since ultimately that is where the authorization code will be sent. In general I agree, one thing I would note is does the user need to see the redirect URL? In the client discovery model I would assume the identifier surfaced by the AS to the user, to establish trust in the client, is the client_id (which is taking the form of a URL). Because if you are resolving the clients metadata using this + a well-known path, and you receive a list of permitted redirect_uri's for that client that you can validate the authorization request against? Take the example client_id => https://client.example.com metadata resolved from => https://client.example.com/.well-known/oauth-client supported redirect uri listed in client metadata => https://another-domain.com I would assume the only identifier that is important to surface to the user about the client is https://client.example.com, the redirect uri the client is less of a concern, provided it is validated against the redirect uri's permitted by the client which is listed in its metadata. Thanks, [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D=0> Tobias Looker MATTR CTO +64 (0) 27 378 0461 tobias.looker@mattr.global<mailto:tobias.looker@mattr.global> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D=0> This communication, includi
Re: [OAUTH-WG] OAuth2 Client Discovery
Hi Dmitry, Thanks for the feedback, it appears there is a lot of conceptual alignment with Solids approach. > 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) 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. > any unknown fields (like JSON-LD "@context") must be ignored? Yeah this aligns with the data extensibility model anyway e.g "ignore what you don't understand" so I don't see any issue with this. > 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? 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? Thanks, [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D=0> Tobias Looker MATTR CTO +64 (0) 27 378 0461 tobias.looker@mattr.global<mailto:tobias.looker@mattr.global> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D=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 Sent: 14 December 2022 06:30 To: Tobias Looker Cc: Ben Schwartz ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth2 Client Discovery EXTERNAL EMAIL: This email originated outside of our organisation. Do not c
Re: [OAUTH-WG] Call for adoption: Cross-Device Flows
+1 I support adoption of this draft. Thanks, [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D=0> Tobias Looker MATTR CTO +64 (0) 27 378 0461 tobias.looker@mattr.global<mailto:tobias.looker@mattr.global> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D=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: OAuth on behalf of Torsten Lodderstedt Sent: 23 November 2022 00:28 To: Justin Richer Cc: oauth Subject: Re: [OAUTH-WG] Call for adoption: Cross-Device Flows 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. +1 I support adoption of this draft. Am 22.11.2022 um 01:44 schrieb Justin Richer mailto:jric...@mit.edu>>: I support adoption of this draft. It’s important work that affects a number of areas in and around OAuth. — Justin On Nov 15, 2022, at 6:43 AM, Rifaat Shekh-Yusef mailto:rifaat.s.i...@gmail.com>> wrote: All, During the IETF meeting last week, there was a strong support for the adoption of the following document as a WG document: https://datatracker.ietf.org/doc/draft-kasselman-cross-device-security/ This is to start a call for adoption for this document. Please, provide your feedback on the mailing list on whether you support the adoption of this document as a WG or not, by Nov 29th. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth2 Client Discovery
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, [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D=0> Tobias Looker MATTR CTO +64 (0) 27 378 0461 tobias.looker@mattr.global<mailto:tobias.looker@mattr.global> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D=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 purpose
[OAUTH-WG] OAuth2 Client Discovery
Hi All, I would like to draw attention to a new I-D we've recently updated called "OAuth2 Client Discovery". https://datatracker.ietf.org/doc/draft-looker-oauth-client-discovery/01/ Below is the drafts current abstract for context: "This specification defines a mechanism for an authorization server to obtain the metadata of a client, including its endpoint locations and capabilities without the need for a registration process." Further motivation can be found in the drafts introduction. We believe the draft is relevant to the presentation Kristina will be making tomorrow on "client_id" as a URI, hence the email promoting awareness of it. There is also important discussion in the current open issues for the I-D, including those discussing its compatibility with other specifications that overlap. https://github.com/mattrglobal/draft-looker-oauth-client-discovery/issues Thanks, [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D=0> Tobias Looker MATTR CTO +64 (0) 27 378 0461 tobias.looker@mattr.global<mailto:tobias.looker@mattr.global> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D=0> [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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D=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. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
