Re: [OAUTH-WG] Call for adoption - SD-JWT

[Warren Parad <[e-mail]>]

And in the situation they did, we would just use the existing scopes and
let the user approve the selected list. RS requests, AS redirects the user,
the user approves. (RS => AS => User)

The draft isn't trying to prevent needing to do that, it's trying to change
the order of the flow, first the AS, then the user, then the RS (AS => User
=> RS).

The only reason I can see doing this is if there are going to be guaranteed
offline interactions, either the AS is offline or the user is offline.

   - The AS offline is an interesting side journey. What if your country is
   taken over and the AS is really forever offline. This draft isn't going to
   fix that because the tokens expire. So unless the goal is to create never
   expiring tokens, it isn't a solution. And worse since we know attributes
   about a user do change over time, they'll have to be updatable. With the
   current draft we just update the AS and generate a new token, we can't do
   that if the AS is offline.


So the question is how many offline interactions are there, and what do
those look like? We know we are incorrectly over-engineering here if there
are only a small set of them. If there are many of these, then it makes
sense to continue down the path of "this is how we solve for the User
offline".

On Mon, Aug 1, 2022 at 7:26 PM Neil Madden <[e-mail]>
wrote:

>
> On 1 Aug 2022, at 17:34, Aaron Parecki <aaron=[e-mail]>
> 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 <
> [e-mail]> 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 <
>> [e-mail]> 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 <
>>> [e-mail]> 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=[e-mail]> 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=
>>>> [e-mail]> wrote:
>>>>
>>>>> I support adoption.
>>>>>
>>>>> On Thu, Jul 28, 2022, 8:17 PM Rifaat Shekh-Yusef <
>>>>> [e-mail]> 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
>>>>>> [e-mail]
>>>>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>> _______________________________________________
>>> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> --
> ---
> Aaron Parecki
> https://aaronparecki.com
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>