Hi David, This issue was already raised. Below the proposal for both draft and python code
https://github.com/oauthstuff/draft-selective-disclosure-jwt/pull/124 Regarding the privacy I'd like to have a combined presentation format that makes the PID/QEAA (VC) untraceable (jwe, with variable iat claim value). You find some open issues for joining in the discussion Best Il lun 1 ago 2022, 14:50 David Chadwick < d.w.chadw...@verifiablecredentials.info> ha scritto: > I would like to add a few further points. > > The age-over property is more complex than your example, because a driving > license only contains the date of birth. The issuing authority decides > which age-over properties to statically provide in the mDL and the ISO > standard provides an algorithm of how the wallet should respond if the > age-over being requested is not present in the mDL. So different mDLs may > contain different age-over properties and respond differently to requests > for age-over from two people of the same age. > > The ISO mDL selective disclosure is more privacy protecting than the > proposed SD-JWT because it also blinds the property names as well as the > values. > > The examples below do not say why the use cases cannot work if the wallet > has a set of conventional JWTs containing different commonly requested > subsets of claims, such as age or address or classes of vehicle one can > drive. > > Kind regards > > David > On 01/08/2022 13:24, Warren Parad wrote: > > This is done because network availability and privacy concerns may >> separate the act of acquiring the SD-JWT of a license from the issuing >> authority, and presenting it (such as days later during a traffic stop on a >> mountain road). > > > I think we keep pointing to "offline drivers license" as the only reason > we have this draft. But we still haven't made clear why the "offline > drivers license" actually needs this. I spent some real time thinking about > and came up with two hypotheticals that helped me. > > *Hypothetical 1:* > You are on a mountain road and a police officer pulls you over, it's late > at night, you have no internet, and your driver license is 100% digital. > > The officer wants to know if you live in the area, or if you are from out > of state. You don't want to tell the police officer your name, you click > some magic buttons on your device, and a QR code pops up. This QR code > contains only: > > - "id_token" with salted fields > - selective disclosure for: *address city + state* > > > The police officer's magic new special SD-JWT device tells them you have a > valid driver's license and that you live in the area. The officer is either: > > - Okay with that > - Asks for further disclosure, which you can agree to or risk being > arrested and brought in for questioning. > > > *Hypothetical 2:* > You live in the US and going out to a bar. Bars in the US are infamous for > carding people. You want to tell them that you are over 21, but don't want > to tell them anything else. So you take out your digital wallet and show > them a QR code that only contains: > > - "id_token" with salted fields > - selective disclosure for: *over 21* > > The bouncer uses their magic new SD-JWT device to verify that information, > and can either say: > > - That's sufficient, come on in > - I don't believe that is yours, I need to see your picture (including > details), your name as well as another form of identification. > > > *Problem from 2:* > The bouncer says, I need to know you have been vaccinated against covid in > the last 6 months. Here's where things start to get challenging, did the > issuer have this information available to create a claim that could be > selectively disclosed? > > Do we need to maintain a registry of all the allowed claims, or are > countries some how going to be on top of this? > > What happens when different countries have different "standard claims"? > > > On Mon, Aug 1, 2022 at 1:29 PM David Chadwick < > d.w.chadw...@verifiablecredentials.info> wrote: > >> >> On 01/08/2022 11:55, Neil Madden wrote: >> >> I agree with many of these points that Jaimandeep Singh raises. >> >> It would be good to know exactly what the intended use-cases within OAuth >> are. In particular, in OAuth it’s normally the case that the client is >> relatively untrusted and a privacy goal is to avoid revealing >> information/PII to the client unnecessarily. In SD-JWT it seems that this >> is turned on its head somewhat and we trust the client (holder) with >> everything and instead want to keep some information private from the >> resource servers? >> >> I think there are also some questions about exactly which claims can be >> selectively disclosed - e.g., it would be a very bad idea to allow security >> constraints like “exp”, “aud” or “cnf” to be selectively (not) disclosed. >> But the problem is that the set of security constraints is not fixed in any >> way, and new ones may be added by future specs or application-specific >> ones. So the issuer will need to be careful not to allow such constraints >> to be selectively disclosed. >> >> Ultimately, I just don’t find this idea of fine-grained pick ’n’ mix >> selective disclosure of individual claims to be very compelling compared to >> the much simpler solution of just issuing multiple JWTs in the first place >> (with appropriate subsets of claims in them). >> >> +1. This is exactly what we do >> >> David >> >> >> — Neil >> >> On 29 Jul 2022, at 03:15, Jaimandeep Singh < >> jaimandeep.phdcs21=40nfsu.ac...@dmarc.ietf.org> wrote: >> >> Dear All, >> 1. At the outset I must compliment Daniel Fett and Kristina Yasudafor >> and all the contributors for the wonderful work done on SD-JWT. >> 2. However, in my opinion there is no clear motivation for using SD-JWT >> in the present oAuth 2.0/2.1 ecosystem. We already have JWS and JWE which >> more or less satisfy the requirements. >> 3. The focus and time of the WG-OAUTH should be more aligned to the work >> directly impacting the improvements or BCP in the oAuth 2.0/2.1 specs. >> 4. WG-JWP (JSON Web Proofs) may be a more suitable place for the adoption >> of SD-JWT as they are working on a similar set of problems. They are >> actively seeking participation in the area of SD-JWT. >> 5. In view of above I am presently not in favour of its adoption in >> WG-OAUTH. >> >> Regards >> Jaimandeep Singh >> >> On Fri, Jul 29, 2022 at 6:43 AM Brian Campbell <bcampbell= >> 40pingidentity....@dmarc.ietf.org> wrote: >> >>> I support adoption. >>> >>> On Thu, Jul 28, 2022, 8:17 PM Rifaat Shekh-Yusef < >>> rifaat.s.i...@gmail.com> wrote: >>> >>>> All, >>>> >>>> This is a call for adoption for the *SD-JWT* document >>>> >>>> https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/ >>>> >>>> Please, provide your feedback on the mailing list by *August 12th*. >>>> >>>> Regards, >>>> Rifaat & Hannes >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> *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 >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://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
