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

Warren Parad <wparad@rhosys.ch> Tue, 02 August 2022 11:56 UTC

Return-Path: <wparad@rhosys.ch>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A049C147920 for <oauth@ietfa.amsl.com>; Tue, 2 Aug 2022 04:56:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNq6cAhcYh6G for <oauth@ietfa.amsl.com>; Tue, 2 Aug 2022 04:56:20 -0700 (PDT)
Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A369C14CF06 for <oauth@ietf.org>; Tue, 2 Aug 2022 04:56:20 -0700 (PDT)
Received: by mail-yb1-xb33.google.com with SMTP id z5so21395841yba.3 for <oauth@ietf.org>; Tue, 02 Aug 2022 04:56:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=2nXrLratrOlTmpUlmcQ+P9v/5jWUmp5rxT/qE8vpWZQ=; b=OQd4y4q5dkSSxsyWavurwgQet/2J/m3GHgoCeXTSmEDWbNfqwmUyOb9/w4hNfDP99e 1OEhV99buDLgFO216YfT90TuAdtoJbx4JvCBRmJWCNULazqfz1vK0KuS7PZFkAD71VuI wobhS14Z2TiWZ7TeaVs1M2bhl2jhvtiJrH3zQdorcFSDouX3WOt/br0O2UbLjoaJf+go PBdJL+bcWlUR/cvR8ptVTsk2puVUqAglkBk/wgSfADoZUP+cC946YE9OeFYwLC44+Pkk z5BMHJ6K6zI8yP0WjTU+gE3aWkb5qUr3l+oNa1AlyFvL7e3UYMYvwjmIOLbzjBhe5C13 TFVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=2nXrLratrOlTmpUlmcQ+P9v/5jWUmp5rxT/qE8vpWZQ=; b=On29WJl5Y6KxnJdRUac/difhlsDpL3JT+fL/tJWt7svMynj6kY+zDcX5iKSB8Gvahv qVSgR+SoeUV56xYlw3deGgLcf7QBDJXvJdeTavLnRC8mzL2zTGfjeemLYRWC/C6BiTci r8TTnTl3edpMc8mSPnLjzX5zwtWlnV52S+LVUBfTpRiRJFzzOWRF7OcmmT2um0lCpUGo twYKfCuU5JHb4ycGb8lV/3kcxczEKG+JDKAms2r5F5yxgRzyf/7QnG4iBjrRNp9RPZI1 B3hFkBc7xK7itHM2e7oq/4aKn56NXo7bKBHTiAlcFUmzTl3dyR8J7o0SRIfj7nm1nY3c SSjA==
X-Gm-Message-State: ACgBeo3owm4CelupsVJn3XhkZgFGx0bZ2byZx/aPmEAddxJca81BkzBs 3nmWQX8HN+x+IbBVc3xJ4Q/H6cpQ4EoKdNCo9wA3
X-Google-Smtp-Source: AA6agR4W1Tp7ZMxWXDgkHPDI8RjOwZ0193mYCJ+jzsa81+KsRTfClmxF2B5+5Dxh8mAczti5+95pV+GvCAkhQn+N7j0=
X-Received: by 2002:a25:2e50:0:b0:669:9a76:beb with SMTP id b16-20020a252e50000000b006699a760bebmr15412546ybn.597.1659441379228; Tue, 02 Aug 2022 04:56:19 -0700 (PDT)
MIME-Version: 1.0
References: <CADNypP9xSXWKV=0nj803fW9xdqgguLWLOpMMQd0Uw3P16LQpfQ@mail.gmail.com> <CA+k3eCSCaSUUhbNe9G74a_g=ZnGFcz7iQHBGNMzWYFNmvskYPQ@mail.gmail.com> <CAODMz5F7wBwkemtRK71RBHG8-=D_ezjxSkECtYmMU0OSX5n4nw@mail.gmail.com> <75CB47D6-EB35-40EB-A3AE-0487C0405DC7@forgerock.com> <7acfa69a-f4a2-fbab-2868-6c68c2c970a4@verifiablecredentials.info> <CAJot-L0fxxo25bK1QK6Bqcg8WQ53P-tZgG2isFst072t1WrWbQ@mail.gmail.com> <d829ea91-f154-f186-3f23-9af98f4b0d61@verifiablecredentials.info> <CAP_qYynpRqm2AK4YJiebZGg=gitVd3d4DZ1-McMFVGnm0QuQVw@mail.gmail.com> <139668cc-1eaf-ac60-6a37-403ae6a3b294@verifiablecredentials.info> <CAGBSGjoAFr7E=m6i8qv8XWjkraApPxMsDxqWwyNRU5K51Gbq9Q@mail.gmail.com> <8e86d916-c0c4-1a63-14ef-45c9d566cde4@verifiablecredentials.info> <CAJot-L3dsKFFFPQ9PSysE0d__Qj+fAyy9Fj+VOXUY+mv9KML7A@mail.gmail.com> <75ad6245-f063-dc6d-1aa2-8b7594024907@verifiablecredentials.info>
In-Reply-To: <75ad6245-f063-dc6d-1aa2-8b7594024907@verifiablecredentials.info>
From: Warren Parad <wparad@rhosys.ch>
Date: Tue, 02 Aug 2022 13:56:08 +0200
Message-ID: <CAJot-L3zdYn4rEr0gpykqvO4PfvdZD=EWDN9WAQX1zp9Xeekqg@mail.gmail.com>
To: David Chadwick <d.w.chadwick@verifiablecredentials.info>
Cc: Aaron Parecki <aaron@parecki.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ef51f605e540cde2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/z-ovPBqFgBR2CkdwBND8kfStYo4>
Subject: Re: [OAUTH-WG] Call for adoption - SD-JWT
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2022 11:56:24 -0000

In the case we do that, this spec doesn't add value, right?

On Tue, Aug 2, 2022, 13:39 David Chadwick <
d.w.chadwick@verifiablecredentials.info> 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 <
> d.w.chadwick@verifiablecredentials.info> 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 <
>> d.w.chadwick@verifiablecredentials.info> 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 <
>>> d.w.chadwick@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.chadwick@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.in@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.com@dmarc.ietf.org> wrote:
>>>>>
>>>>>> I support adoption.
>>>>>>
>>>>>> On Thu, Jul 28, 2022, 8:17 PM Rifaat Shekh-Yusef <
>>>>>> rifaat.s.ietf@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
>>>
>> --
>> ---
>> Aaron Parecki
>> https://aaronparecki.com
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>