> oauth-requ...@ietf.org şunları yazdı (5 Ara 2022 13:39): > > Send OAuth mailing list submissions to > oauth@ietf.org <mailto:oauth@ietf.org> > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-requ...@ietf.org <mailto:oauth-requ...@ietf.org> > > You can reach the person managing the list at > oauth-ow...@ietf.org <mailto:oauth-ow...@ietf.org> > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > Today's Topics: > > 1. Re: draft-ietf-oauth-selective-disclosure-jwt (Hannes Tschofenig) > > Kimden: Hannes Tschofenig <hannes.tschofe...@arm.com > <mailto:hannes.tschofe...@arm.com>> > Konu: Ynt: [OAUTH-WG] draft-ietf-oauth-selective-disclosure-jwt > Tarih: 5 Aralık 2022 13:39:48 GMT+3 > Kime: Brian Campbell <bcampb...@pingidentity.com > <mailto:bcampb...@pingidentity.com>> > Bilgi: oauth <oauth@ietf.org <mailto:oauth@ietf.org>> > > > Thanks for the response, Brian. > > A few remarks below. > > From: Brian Campbell <bcampb...@pingidentity.com > <mailto:bcampb...@pingidentity.com>> > Sent: Tuesday, November 29, 2022 11:21 PM > To: Hannes Tschofenig <hannes.tschofe...@arm.com > <mailto:hannes.tschofe...@arm.com>> > Cc: oauth <oauth@ietf.org <mailto:oauth@ietf.org>> > Subject: Re: [OAUTH-WG] draft-ietf-oauth-selective-disclosure-jwt > > Hi Hannes, > > Though I am yet to officially have my name on the document as a co-author, > you did mention me directly :) And so I'll attempt to answer or respond to > your questions/statements below. > > > On Mon, Nov 28, 2022 at 7:24 AM Hannes Tschofenig <hannes.tschofe...@arm.com > <mailto:hannes.tschofe...@arm.com>> wrote: > Hi Daniel, Hi Kristina, Hi Brian, > Hi all, > > Reading through draft-ietf-oauth-selective-disclosure-jwt I was wondering why > the document defines new terminology for roles that already exist in OAuth. > For example: > > Issuer = AS > Holder = Client > Verifier = RS > > I assume that was done intentionally. What was the rational was. > > JWT itself <https://datatracker.ietf.org/doc/rfc7519/> is a product of this > WG (as I'm sure you remember).. While JWT had important applications in > OAuth, it was developed as a more general purpose token format and has seen > widespread usage both in OAuth and beyond. Similarly, SD-JWT is meant to be a > general purpose selective disclosure mechanism for JWT, which can have > applications in OAuth but is certainly not constrained to OAuth. As such, the > terminology in the draft aims to be generally applicable/meaningful. This is > similar/consistent with JWT/RFC7519, which also does not use terms like AS, > RS, or client. > > > [Hannes] I think the draft should provide that background. > > > You write: > > “ > One of the common use cases of a signed JWT is representing a user's identity. > “ > > In classical OAuth this use case should not be common. We bragged about the > fact that you could to delegated authorization without having to rely on > identity information. I think it would help to expand this statement a bit > and explain what the use case is. > > A signed JWT representing a user's identity is, in fact, exceedingly common. > Even in classical OAuth the access tokens almost always convey something > about an identity - the resource owner in OAuth parlance. The sub in > introspection https://www.rfc-editor.org/rfc/rfc7662#section-2.2 and the JWT > AT profilehttps://datatracker.ietf.org/doc/html/rfc9068#section-2.2 show this > in specs, for example. Of course the AT format and content aren't defined by > OAuth itself and are left up to the implementation/deployment so those > optional specs don't tell the whole story. But every single deployment I've > seen has some identity info in the AT for delegation. > > > [Hannes] This paragraph would be a good addition to the draft providing a bit > of background. > > You write: > “ As long as the signed JWT is one-time use, it typically only contains those > claims the user has consented to disclose to a specific Verifier. However, > there is an increasing number of use cases where a signed JWT is created once > and then used a number of times by the user (the "Holder" of the JWT). In > such cases, the signed JWT needs to contain the superset of all claims the > user of the signed JWT might want to disclose to Verifiers at some point. The > ability to selectively disclose a subset of these claims depending on the > Verifier becomes crucial to ensure minimum disclosure and prevent Verifiers > from obtaining claims irrelevant for the transaction at hand. > “ > > Using the same access token with multiple resource servers is not good > security practice not only from a privacy point of view but also from a > security point of view. > > From reading the introduction I get the impression that you create your own > problem that is subsequently solved in the document. Since I believe you are > too clever to do this, I believe the document needs to provide more text to > explain how this use case emerged. You mention “verifiable credential” as the > “use case” but it is a technology rather than a use case. > > I've reread the introduction (which, in full disclosure, I did not write) and > honestly feel like it does a pretty decent job of describing the emerging > problem space and what the draft aims to provide. We certainly don't want to > leave you or any reader with the impression that the document invents a > not-real problem only to subsequently solve it. But I'm not getting that > impression from reading it. And I am honestly not sure how to better avoid > giving that impression (other than writing this email, I guess). > > > [Hannes] The obvious solution to only disclose information relevant for a > recipient is to provide that information. Now, you introduce a new > requirement, namely that you want to obtain the token once and then share it > with many recipients. > > It would be good to motivate this new requirement since the solution comes > with a certain cost. > > > Ciao > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > _______________________________________________ > 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
