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

Giuseppe De Marco <demarcog83@gmail.com> Mon, 01 August 2022 16:04 UTC

Return-Path: <demarcog83@gmail.com>
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 D1206C14F73D for <oauth@ietfa.amsl.com>; Mon, 1 Aug 2022 09:04:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 P8ig5KiSPxUK for <oauth@ietfa.amsl.com>; Mon, 1 Aug 2022 09:04:56 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 C3130C14F730 for <oauth@ietf.org>; Mon, 1 Aug 2022 09:04:56 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id gk3so9050224ejb.8 for <oauth@ietf.org>; Mon, 01 Aug 2022 09:04:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=mOouONUuom7zxRRDY3GfDiShZcCm9IZa/SoSzRDnkG4=; b=kYvKxKYCH4BxYmVh4QGA4JrJpDIMilwXvVL1TGsS5GV8+3TN910zXqfNtCsiVeBl3d ThNBiuaepIBoW19jZuD41CDlCs6HdVEajapgdLSLse8l4utxjAHqiW5Z91Q8uM96Omh4 U8734uzTwIHXVGVB4pjF+dw4YRNfSuqSbbwUt+AnIhT4BN319zO8rgqzwNw6/kyKgfhW R0uVIhR+yqqkayn1jvM/7cwPdkSOJmuYKpSEDlA/G+3nADzj7paMPBr6x02Uia5RmrQ8 UuIkGYPfWZh+Y/FCiutXDZyeil6UCwlOu85LBsoUFMhsXD6Sc1pOAu47xv83uhKAcXMY q6VQ==
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=mOouONUuom7zxRRDY3GfDiShZcCm9IZa/SoSzRDnkG4=; b=L+uGJeapbws/Mg9JYy5UaJOD9EiMivRV19PRljVVjFie95fHBqQpgXDiKWMxdsDjdz AH1DS8oDl9EZx/0S1wKt/DlMWeibXvcYQxWESLiIm5ZgUn8L8UHhPNseGbsl5VhURu3q Hr1R++PVKY8P/2N7BMkwMcA8ks3qpwo45h4YM5ksLgvmb7MZUA1kdlsG187U2avbFxKc Kzb7CdOInW5lr013SZZ92bP5gEyZPn0b7RBv0wkFS9l2/SDB/yym6Mgsjkdn5cAiVJX/ +S+qYLb7vDHVODs2NhU+wdXiZQdR4lWwmK6H6o1/zYNOjkvIvS3J5dQvWJm7MZFjHZ+U vsmg==
X-Gm-Message-State: AJIora8XxvQ2YjViovFq1gvE0YygZcg7+nW89PELO7+heT9wtcPnQ/te dcLNEz7QNMJTChs0kWx1v/tck8362jndKHjRUJA=
X-Google-Smtp-Source: AGRyM1teBj7sCgaG6YP4kaljPUwrLTrTz5I4PZ7f/5a/3+bQzbcYFDWeoXMelvwWXUUViL6eVwgZKJSru2jh5rptDgM=
X-Received: by 2002:a17:907:7f1a:b0:72e:f9c9:dfe2 with SMTP id qf26-20020a1709077f1a00b0072ef9c9dfe2mr12987542ejc.84.1659369895115; Mon, 01 Aug 2022 09:04:55 -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>
In-Reply-To: <d829ea91-f154-f186-3f23-9af98f4b0d61@verifiablecredentials.info>
From: Giuseppe De Marco <demarcog83@gmail.com>
Date: Mon, 01 Aug 2022 18:04:42 +0200
Message-ID: <CAP_qYynpRqm2AK4YJiebZGg=gitVd3d4DZ1-McMFVGnm0QuQVw@mail.gmail.com>
To: David Chadwick <d.w.chadwick@verifiablecredentials.info>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000263fc105e5302960"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/nS8sm4zQiussE__HmWmoxT2rPJk>
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: Mon, 01 Aug 2022 16:04:57 -0000

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
>