Thanks for the further remarks, Hannes. I'll work with the authors on appropriately adding some additional background/context.
On Mon, Dec 5, 2022 at 3:39 AM Hannes Tschofenig <hannes.tschofe...@arm.com> wrote: > Thanks for the response, Brian. > > > > A few remarks below. > > > > *From:* Brian Campbell <bcampb...@pingidentity.com> > *Sent:* Tuesday, November 29, 2022 11:21 PM > *To:* Hannes Tschofenig <hannes.tschofe...@arm.com> > *Cc:* oauth <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> 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 profile > https://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. > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
