El jue., 1 dic. 2022 9:19 a. m., <oauth-requ...@ietf.org> escribió:
> Send OAuth mailing list submissions to > 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 > > You can reach the person managing the list at > 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. Question regarding RFC 7636 (KAMPANAT THUMWONG) > 2. Re: mails (KAMPANAT THUMWONG) > 3. Re: draft-ietf-oauth-selective-disclosure-jwt (Denis) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 1 Dec 2022 15:15:51 +0700 > From: KAMPANAT THUMWONG <1992kongpc....@gmail.com> > To: oauth@ietf.org > Subject: [OAUTH-WG] Question regarding RFC 7636 > Message-ID: > < > caff0tnhkhsp3xuqy57k_pt-4axkd9m86p6ad_y9n5lwmfzs...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 1992kongpc....@gmail.com > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20221201/9c9c6417/attachment.htm > > > > ------------------------------ > > Message: 2 > Date: Thu, 1 Dec 2022 15:31:52 +0700 > From: KAMPANAT THUMWONG <1992kongpc....@gmail.com> > To: OAuth@ietf.org > Subject: Re: [OAUTH-WG] mails > Message-ID: > <CAFF0TNHN70Dr8jZ= > isqgyr8fw26db7yksa3aveg409civyx...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20221201/b2072ad9/attachment.htm > > > > ------------------------------ > > Message: 3 > Date: Thu, 1 Dec 2022 15:18:52 +0100 > From: Denis <denis.i...@free.fr> > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] draft-ietf-oauth-selective-disclosure-jwt > Message-ID: <bb01ca46-c82b-fd4e-e04d-ddddcbc31...@free.fr> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hi Brian, > > My two cents. > > 1) This draft is about selective-disclosure. The draft should be > balanced between enclosure and disclosure. > The topic of selective-enclosure should also be addressed. > > In particular in OAuth, the claims to be incorporated are usually only > selected with a coarse granularity > and the end-user (as well as the holder) has no clue about which claims > will or will not be incorporated. > > 2) The draft states: > > ???????????? However, anyone receiving an unencrypted JWT can read all > of the claims. > > In OAuth, the claims are considered to be opaque and SHALL not be read > by the holder. Their semantics or content of a JWT can change at any time. > This should be mentioned in the draft. > > In the privacy considerations section, another sub-section should be > included about OAuth, i.e. a section "8.3? OAuth". > > OAuth considers that the claims included into the JWT are opaque to the > holder (i.e. the Client) when a JWT is used in the context of OAuth. > This means that the holder is unable to verify that the claims that have > been incorporated in the JWT correspond to those that have been requested. > > The Issuer is a position to include more claims or different claims from > those that should have been incorporated. This may be a concern for some > end users. > > 3) About section 8.2 Unlinkability > > The text states: > > ?????????? More advanced cryptographic schemes, outside the scope of > this specification, can be used to prevent this type of linkability. > > The draft by itself creates the problem since a single JWT is intended > for multiple verifiers. > The linkability problem arises because in particular when the same "sub" > claim is used for two different Verifiers. > > The use of the following claims should be avoided (I reuse one of the > examples): > > ???? "given_name": "John", > "family_name": "Doe", > "email": "john...@example.com", > "phone_number": "+1-202-555-0101", > "address": { > "street_address": "123 Main St", > "locality": "Anytown", > "region": "Anystate", > "country": "US" > }, > "birthdate": "1940-01-01 > > In order to solve the problem, the use of previous claims should be > avoided and a specific "sub" claim should be used for each verifier. > > Hence, the concern could be solved using no " advanced cryptographic > schemes " but by defining a new structure in the JWT that would allow > to associate a "sub" claim (as well as other claims) with a specific > Verifier. A change of the SD-JWT Releases structure should be considered. > > The use of this draft for end users concerned with some forms of > linkages between verifiers should be deprecated > and this should be mentioned in the Introduction: a single JWT targeted > to a single Verifier solves this concern. > > Denis > > > > 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. > > > > ?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. > > > > 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). > > > > > > /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 > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20221201/4b7e4925/attachment.htm > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 170, Issue 1 > ************************************* >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
