> On 1 Aug 2022, at 17:34, Aaron Parecki <[email protected]> > wrote: > David, > > Creating "A conventional JWT with a subset of claims" is exactly the thing > this draft sets out to prevent needing to do. The problem with that approach > is the AS would have to create a new JWT with only the claims needed for the > particular presentation, so the AS would need to be both accessible (online) > by the client as well as aware of the request. These are both properties > avoided by the SD-JWT draft, perhaps these can be clarified in the > introduction.
But this isn’t true. As I said on the other thread on the JOSE list, the client doesn’t need to go back to the AS to get a new token with JWTs anymore than they do with SD-JWT. In the limit the AS could issue a separate JWT for each claim and then the client can choose which ones to send to the RS. Now of course if the AS actually issued a JWT for each claim that would be very inefficient. But in reality the client is not going to want a totally unique combination of claims for each presentation. There are likely just a small handful of sets of claims that actually make sense to disclose together in any scenario, so the AS could issue a small number of JWTs that cover those scenarios. Indeed, if the client is producing unique combinations of claims for a presentation then that provides a way to fingerprint that client/user! So far I’ve failed to see any convincing scenario where a client would really need such fine-grained control over selective disclosure. — Neil > >> On Mon, Aug 1, 2022 at 9:22 AM David Chadwick >> <[email protected]> wrote: >> thanks Guiseppe. Glad to hear that blinding claim names is now on the cards. >> >> This does not answer the question about why conventional JWTs with a subset >> of the claims cannot also be used >> >> Kind regards >> >> David >> >> On 01/08/2022 17:04, Giuseppe De Marco wrote: >>> 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 >>> <[email protected]> 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 >>>>> <[email protected]> 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 >>>>>>>> <[email protected]> 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 >>>>>>>> <[email protected]> wrote: >>>>>>>>> I support adoption. >>>>>>>>> >>>>>>>>> On Thu, Jul 28, 2022, 8:17 PM Rifaat Shekh-Yusef >>>>>>>>> <[email protected]> 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 >>>>>>>>>> [email protected] >>>>>>>>>> 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 >>>>>>>>> [email protected] >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> [email protected] >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > -- > --- > Aaron Parecki > https://aaronparecki.com > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
