In the case we do that, this spec doesn't add value, right? On Tue, Aug 2, 2022, 13:39 David Chadwick < [email protected]> wrote:
> Hi Warren > > I am speaking about the verifiable credential issuing process where the > user/wallet is the client and the credential issuing system is the > authoriser and operates the AS and RS. (This is the model describes in the > OIDC4VCI spec.) > > So the AS issues the access token to the user/wallet. This is then sent to > the RS to obtain the verifiable credential. So I was asserting that if the > user/wallet has an access token for a complete verifiable credential, then > it should be able to ask for a set of subset credentials either > concurrently or sequentially, dependent upon the policy of the RS. > > Does this make sense to you now? > > Kind regards > > David > On 01/08/2022 18:24, Warren Parad wrote: > > Hey David, would you be able to go back and reread what you wrote? I'm > trying to parse it and it seems what you are calling different things don't > align to the common understanding of what AS/RS/client mean. > > For instance: > > - the user, not the AS, authorizes a client to attain credentials > - the client doesn't ask the RS for anything other than the managed > resources using the credentials > - the client in this case is likely a hardware device that runs the > user-agent so in practice it will have and know 100% of the user's data > - AS issues credentials, that is its job, saying "it shouldn't be > involved" is the same as saying "I don't want to use OAuth for this" (which > is fine, but likely that's the important part) > - RS doesn't decide HOW it decides IF, the HOW is decided by the RS' > api documentation and published expectations > > To avoid potential miscommunication, about what these are and how they > work, can I suggest first outlining a concrete situation, and then > identifying how you would expect the agents would interact with each other. > We can do the messy part of assigning "which is the AS" and "which is the > RS or the client" afterwards. But having the hypothetical model would go a > long way. > > On Mon, Aug 1, 2022 at 6:56 PM David Chadwick < > [email protected]> wrote: > >> Hi Aaron >> >> I think we have different mental models for this. In my opinion, if the >> AS authorises the client to obtain a complete credential with all the >> properties, then the client should be able to ask the RS for a set of >> subsets of the credential, since the client is not obtaining more than what >> has been authorised. I do not think that the AS should be involved in the >> credential issuing process. It is for the RS to decide how to honour the >> client's request. >> >> Kind regards >> >> David >> On 01/08/2022 17:34, Aaron Parecki 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. >> >> Aaron Parecki >> >> >> >> >> 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 <bcampbell= >>>>> [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 >>>>> [email protected]https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing [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
