[OAUTH-WG] Re: WGLC for SD-JWT

Dick Hardt <dick.hardt@gmail.com> Sun, 15 September 2024 17:44 UTC

Return-Path: <dick.hardt@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 33F2DC14CE3B for <oauth@ietfa.amsl.com>; Sun, 15 Sep 2024 10:44:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 Ab5m8FI_Mvof for <oauth@ietfa.amsl.com>; Sun, 15 Sep 2024 10:44:30 -0700 (PDT)
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D170C14F748 for <oauth@ietf.org>; Sun, 15 Sep 2024 10:44:30 -0700 (PDT)
Received: by mail-yb1-xb2b.google.com with SMTP id 3f1490d57ef6-e04196b7603so3162965276.0 for <oauth@ietf.org>; Sun, 15 Sep 2024 10:44:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726422269; x=1727027069; darn=ietf.org; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WhypOxGBWRQUqfyJGf2yUA0earg1hzpXEDxchGwm8vY=; b=CYbgv0VHKjGLpRDikO2MWenXCKYZDpXvwLIuGA83xF1FX7ckI//zigX+r9p0gzcT4x QztDQ+l5c7N2qc8KzCD1sd5WqglID5GjSxyPNfa80LAjnxHJ1f+UMItVLqpBlfOzyYK1 u2iw8zGtUy5dCa3wDl3FKGL5PwJYr8Re7oZ/HazIF3oOTMUaloOOF099u6BAerjlNrrA sjIvJb0rRRnZgWAQeeIdJ1aZmPbx2Pr3u8RAWdtfU3naxq0ml9GKlTGJ0Lm+xnuDJvmB KwCQon7DNGEcTSK9aWOTduc1nCG5B3bZ9Qj21HXcsr9TsvUB0/QKmnWVykj/w1pjVzOu QjPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726422269; x=1727027069; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WhypOxGBWRQUqfyJGf2yUA0earg1hzpXEDxchGwm8vY=; b=GO4fPJesEjcbomyVUSp5H5s/KxB3o6gR3DgrJBG9WKRqBfppGHtR7YjhKY0nmyT5LG Da81dwtmGAIbntVlNslEzj2DDc3AnJw5uW3Ai6j6BxFXWve5N8cx5wQLIvuqVsYe/tUb brg8/uq2vSYBbKEIJw1vMyfjgiB46mCtXMso4sEkQv10qRnZgf2oXrnRwXO7DrlBwMHX N2UL5TtvHPAMOTUpmlxopO+y2k/XK78n0Jp8uH+3RvsFYwSRgBVHhgfK2YUYhg6r0uM3 zDpuf2lqsDixFOLOz/VVvbg/HOpFioxJv2493x0KaEFlFmOfbKSzGzvGloH9TSSWZWRs ISzw==
X-Forwarded-Encrypted: i=1; AJvYcCXG1ssV569NF3CISOWHxUwMBPrRwM6gIP1An8GH1BY1j+XWn/iAAYgwF6IjpSxfEoPnnBubfQ==@ietf.org
X-Gm-Message-State: AOJu0YyUB7hs/PbV3Wd6e5WQiD5kue8wT2cjxWPdfevZdS2UhIy7lV3D tzXjD5THOQfKEESO1xXpmpxXsf/flW8OpF828yXMZwqUHOi4yC4qhtecX/ACMo+LYsNbdedSQfl HMmylr3Om7KyXnYL7sEnvyFsvdGQ=
X-Google-Smtp-Source: AGHT+IEy/BNhkSd2fyDN0B9adQifM8wVDPFZ+oKOcxaxfPi34KV/frMTtp4bJuEEOkpUELSQ3YFxNdug41HfmzWhy3s=
X-Received: by 2002:a05:6902:2512:b0:e1a:a0c2:df2d with SMTP id 3f1490d57ef6-e1d9dba818amr8590673276.23.1726422268538; Sun, 15 Sep 2024 10:44:28 -0700 (PDT)
MIME-Version: 1.0
References: <CADNypP_BESkJTXfuv=G9HnLcGwhpSYRggYDZxzaq6-6AaARh0w@mail.gmail.com> <CA+k3eCQOofXBSFz_Ob6y1ZCWjnx4agvFuMOFc6vNWP4c93XTJw@mail.gmail.com> <CAD9ie-s4mhFkdTZ1G_+M4SNnTe14moiR-az+UE7JL5_dfQxYKg@mail.gmail.com> <CA+k3eCTM4W5SbnBANGNuhCVo_k2YkzsaTs-KDBTv9h84F16RgQ@mail.gmail.com>
In-Reply-To: <CA+k3eCTM4W5SbnBANGNuhCVo_k2YkzsaTs-KDBTv9h84F16RgQ@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Sun, 15 Sep 2024 18:43:51 +0100
Message-ID: <CAD9ie-soh-zNS=fx7ow7Je2L2+Vp6EkT7CmUvSGR1HQKAEP70w@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Content-Type: multipart/alternative; boundary="0000000000000c78d106222c0202"
Message-ID-Hash: KWXEJZFAOKSO7LUPILYERPF7LQRSWK37
X-Message-ID-Hash: KWXEJZFAOKSO7LUPILYERPF7LQRSWK37
X-MailFrom: dick.hardt@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: oauth <oauth@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Reply-To: Dick.Hardt@gmail.com
Subject: [OAUTH-WG] Re: WGLC for SD-JWT
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/BZBai3buSdkNCEWQo21KXobeVi0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>

Working on a PR ...

On Thu, Sep 12, 2024 at 11:37 PM Brian Campbell <bcampbell@pingidentity.com>
wrote:

> Thanks Dick,
>
> Some hopefully not-difficult-to-parse responses are inline below.
>
> On Wed, Sep 4, 2024 at 6:25 AM Dick Hardt <dick.hardt@gmail.com> wrote:
>
>> A while ago in an in-person meeting I provided feedback that the
>> introduction was difficult to parse. It still is. A few comments inserted
>> to illustrate.
>>
>> I'll raise my hand to provide alternative text if the authors are
>> interested.
>>
>
> Suggestions of alternative text would be very much appreciated.  Thank you
> for raising your hand! Please do try and be mindful of not altering the
> fundamental meaning of things, however. Along those lines are some comments
> in response to comments inline below. Pull requests, when doing so makes
> sense, are typically a good way of conveying suggestions.
>
>
>
>> /Dick
>>
>>
>>> 1.
>>> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1>
>>> Introduction
>>>
>>> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#name-introduction>This
>>> document specifies conventions for creating JSON Web Signature (JWS) [
>>> RFC7515
>>> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#RFC7515>
>>> ] structures with JSON [RFC8259
>>> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#RFC8259>
>>> ] objects as the payload while supporting selective disclosure of
>>> individual elements of that JSON. Because JSON Web Token (JWT) [RFC7519
>>> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#RFC7519>
>>> ] is a very prevalent application of JWS with a JSON payload, the
>>> selective disclosure of JWT claims receives primary treatment herein.
>>> However, that does not preclude the mechanism's applicability to other
>>> applications of JWS with JSON payloads.
>>>
>>
>> The last two sentences add alot of noise to the first paragraph of what
>> this document is all about
>>
>
> They might be somewhat prolix but I felt they were integral to what this
> document is all about when I wrote them. And still do.
>
>
>
>>
>>> The JSON-based representation of claims in a signed JWT is secured
>>> against modification using JWS digital signatures. A consumer of a signed
>>> JWT that has checked the signature can safely assume that the contents of
>>> the token have not been modified. However, anyone receiving an unencrypted
>>> JWT can read all the claims. Likewise, anyone with the decryption key
>>> receiving encrypted JWT can also read all the claims.
>>>
>>
>>
>>> One of the common use cases of a signed JWT is representing a user's
>>> identity. As long as the signed JWT is one-time use, it typically only
>>> contains those claims the user has consented to disclose to a specific
>>> Verifier. However, there is an increasing number of use cases where a
>>> signed JWT is created once and then used a number of times by the user (the
>>> "Holder" of the JWT). In such use cases, the signed JWT needs to contain
>>> the superset of all claims the user of the signed JWT might want to
>>> disclose to Verifiers at some point. The ability to selectively disclose a
>>> subset of these claims depending on the Verifier becomes crucial to ensure
>>> minimum disclosure and prevent Verifiers from obtaining claims irrelevant
>>> for the transaction at hand. SD-JWTs defined in this document enable such
>>> selective disclosure of JWT claims.
>>>
>>
>>
>>> One example of a multi-use JWT is an Issuer-signed credential that
>>> contains the claims about a subject, and whose authenticity can be
>>> cryptographically verified.
>>> Similar to the JWT specification on which it builds, this document is a
>>> product of the Web Authorization Protocol (OAuth) working group. However,
>>> while both JWT and SD-JWT have potential OAuth 2.0 applications, their
>>> utility and application is certainly not constrained to OAuth 2.0. JWT was
>>> developed as a general-purpose token format and has seen widespread usage
>>> in a variety of applications. SD-JWT is a selective disclosure mechanism
>>> for JWT and is similarly intended to be general-purpose specification.
>>> While JWTs with claims describing natural persons are a common use case,
>>> the mechanisms defined in this document are also applicable to other use
>>> cases.
>>>
>>
>> The above paragraphs are background on what problem is being solved --
>> but the writing is difficult to follow
>>
>
> Suggestions to make it less difficult to follow would be welcome. Ideally
> in the form of a PR, if you are so inclined.
>
>
>
>>
>>
>>> In an SD-JWT, claims can be hidden, but cryptographically protected
>>> against undetected modification. "Claims" here refers to both object
>>> properties (name/value pairs) as well as array elements. When issuing the
>>> SD-JWT to the Holder, the Issuer includes the cleartext counterparts of all
>>> hidden claims, the so-called Disclosures, outside the signed part of the
>>> SD-JWT.
>>>
>>
>>
>>
>>> The Holder decides which claims to disclose to a particular Verifier and
>>> includes the respective Disclosures in the SD-JWT to that Verifier. The
>>> Verifier has to verify that all disclosed claim values were part of the
>>> original Issuer-signed JWT. The Verifier will not, however, learn any claim
>>> values not disclosed in the Disclosures.
>>>
>>
>> The Holder and Verifier terms are being introduced here with no context.
>>
>
> There is a little bit more than "no context" but they do show up rather
> abruptly, don't they? They are also actually introduced in the Terms and
> Definitions section not much later in the document. Suggestions about how
> to provide the appropriate amount of context in the intro would be welcome.
>
>
> The key difference in an SD-JWT and a JWT that the claims are encrypted in
>> what is signed is not clearly obvious.
>>
>
> The meaning of that sentence is not clearly obvious to me. Some additional
> clarity would be needed before any related suggested changes could be
> considered.
>
>
>
>>
>>
>>> This document also defines a format for SD-JWTs with Key Binding
>>> (SD-JWT+KB). By optionally sending an SD-JWT+KB to a Verifier, the Holder
>>> can prove to the Verifier that they hold the private key associated to the
>>> SD-JWT (i.e., using the cnf claim [RFC7800
>>> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#RFC7800>
>>> ]). The strength of the binding is conditional upon the trust in the
>>> protection of the private key of the key pair an SD-JWT is bound to.
>>>
>>
>> This does not read as an introduction. Assumes significant knowledge of
>> why this is useful.
>>
>
> The last sentence feels out of place here and I think it should be
> removed. The overall concept is relevant, I think, even for an
> introduction. Do you have suggestions that could provide (some) readers
> with the knowledge to know why it's useful?
>
>
>
>>
>>
>>> SD-JWT can be used with any JSON-based representation of claims.
>>>
>>
>> repetitive from start of intro
>>
>
> Agree. That sentence should be removed.
>
>
>
>>
>>
>>> This specification aims to be easy to implement and to leverage
>>> established and widely used data formats and cryptographic algorithms
>>> wherever possible.
>>
>>
>> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-1>
>>
>>
>> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-2>
>>
>>
>> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-3>
>>
>>
>> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-4>
>>
>>
>> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-5>
>>
>>
>> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-6>
>>
>>
>> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-7>
>>
>>
>> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-8>
>>
>>
>> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-9>
>>
>>
>> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-10>
>>
>>
>> <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#section-1-11>
>> Fluff -- are there specifications that aim to be difficult to implement?
>>
>
> Well, I'd argue that the answer to the rhetorical question is in fact yes.
> You've been doing this longer than I, surely you've seen some of the same
> things I've seen. And I've seen some things. Perhaps it'd be more fair to
> say that there are lots of specifications that too quickly lose sight of
> that aim.
>
>
>
>
>>
>>
>> On Tue, Sep 3, 2024 at 4:06 PM Brian Campbell <bcampbell=
>> 40pingidentity.com@dmarc.ietf.org> wrote:
>>
>>> Thanks Rifaat & Hannes,
>>>
>>> In an effort to make the most up-to-date content available for the WGLC
>>> period, a -12 revision was just recently published, which contains a number
>>> of editorial improvements.
>>>
>>>
>>> https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html
>>>
>>> Respectfully,
>>>  Brian, Kristina, and Dr. Fett
>>>
>>>
>>>
>>> On Tue, Sep 3, 2024 at 4:40 AM Rifaat Shekh-Yusef <
>>> rifaat.s.ietf@gmail.com> wrote:
>>>
>>>> All,
>>>>
>>>> As per the discussion in Vancouver, this is a WG Last Call for the *SD-JWT
>>>> *document.
>>>>
>>>> https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-11.html
>>>>
>>>> Please, review this document and reply on the mailing list if you have
>>>> any comments or concerns, by *Sep 17th*.
>>>>
>>>> Regards,
>>>>   Rifaat & Hannes
>>>> _______________________________________________
>>>> OAuth mailing list -- oauth@ietf.org
>>>> To unsubscribe send an email to oauth-leave@ietf.org
>>>>
>>>
>>> *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
>>> To unsubscribe send an email to oauth-leave@ietf.org
>>>
>>
> *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.*