[OAUTH-WG] Re: Second WGLC for SD-JWT: 41 issues have been created on github
Tom Jones <thomasclinganjones@gmail.com> Wed, 13 November 2024 16:57 UTC
Return-Path: <thomasclinganjones@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 5BCFDC1ECA7B for <oauth@ietfa.amsl.com>; Wed, 13 Nov 2024 08:57:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.092
X-Spam-Level:
X-Spam-Status: No, score=-2.092 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_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 45rx6xLp0qIo for <oauth@ietfa.amsl.com>; Wed, 13 Nov 2024 08:57:28 -0800 (PST)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 55055C06EEF8 for <oauth@ietf.org>; Wed, 13 Nov 2024 08:57:04 -0800 (PST)
Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a9ec267b879so1261680266b.2 for <oauth@ietf.org>; Wed, 13 Nov 2024 08:57:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731517023; x=1732121823; 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=3Rx8TdKHNqAIizq6DR4ySbYC5DFwm967S3DqOl87Snc=; b=XEL/X+3Im65cjgkLYBdttyfVoMyJ3M4abKwHvDNxS5XxHnPWPWuF9CTHh03t2KKbF3 pjCW4IwmCcOU2vBNW9NGmctsUyYxs6txwRaqKlpQjKPZkTNbB3mtudR49dQNBvIYJun2 l1lVbtMbeEKnmFmDirPLwbx2u25xWMg2PrFJnoY9JEdUF/fIVxQgpaPFX1H5AasgWJKH nzQlVJBqsSmYVXVCxx8TW/dztyT4ahldi5HospRW56gKUUiqBc2+KbomCt/2L+yD5eQC qzrjret/bjf6/c2H91Ppb3peaSTnmJow5+ggqAtkButiTqdMYqiCGCCUgNyVpPzjsjeQ 9Jnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731517023; x=1732121823; 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=3Rx8TdKHNqAIizq6DR4ySbYC5DFwm967S3DqOl87Snc=; b=ddvJDPaAsms0oIX3Zg4bv5MhcL7jmwsgOsdPfG+OvkRw+I2PmrgWsppeOv0HnQvczj 1CiaE5KapFL0u37xtNIV9ZS1sKem9GkS7PP84a+cqE16LPrF3/wc2W0jcTf/Cr1oF7ix BLnbKFm1XSk+8ReaMHrYGQRZxUPTSjJ93KoOFeS3jKnRrvAhOQusNWhzncFO7jPGC1sd BvYLrvej5E+VcnN9Uu89r+gHGdx02rdWm60+4bXTQVq7yzXu1Tz4pGfX8GmL8qrL42+r i1ZGOsF01jw2yo0+ZPaCuuJEzanuVmL3pkf295ujbKcfX/wchCG+rbmZBG16M0/SyDF/ H0Gw==
X-Gm-Message-State: AOJu0Yy1G+cjr88Cz6Tx5hRt1ffED+UWg37liA1L9UQjqTQsziR8tkHa Qe+YRtyfi4k84wBUU7COe3uUgP5TGzTKQ985BnVDW439PLL5EKZ0wxD5zZwt0Wk3tgtldhF33D4 xmCusPrxAjQrMRXmVg1SClst7zAE=
X-Google-Smtp-Source: AGHT+IHadSKrGluzJfOTgc0OR//qyxdwT7LwJseFXj+eWmpL/lLc9TDFddgR2Dx/PACktPPkUUwVqGuCHdRdQpbYuq0=
X-Received: by 2002:a17:907:7f93:b0:aa1:dd58:aec6 with SMTP id a640c23a62f3a-aa1f8106392mr351528566b.48.1731517022330; Wed, 13 Nov 2024 08:57:02 -0800 (PST)
MIME-Version: 1.0
References: <CADNypP9aEU4Ka+0u8PQ3W+jmLN5c6NK77i25Wo9bxquML5Ky2w@mail.gmail.com> <24a7e74b-71a6-4b9c-9d84-d6a24981d3e6@free.fr> <97543c02-f793-4608-93b3-96e2c09fe2db@free.fr> <CA+k3eCQ8qq-YsgU6eHbLr5_adhpAT6xENpy5X3yWQQH_Fy732A@mail.gmail.com> <688d0659-a6d5-4297-a24f-e3b95c407bab@free.fr> <63ecb4ee-b298-49bb-8702-3e08f2739b1d@danielfett.de>
In-Reply-To: <63ecb4ee-b298-49bb-8702-3e08f2739b1d@danielfett.de>
From: Tom Jones <thomasclinganjones@gmail.com>
Date: Wed, 13 Nov 2024 08:56:50 -0800
Message-ID: <CAK2Cwb727M7NhtvmBiK5hN5N56fAzRp4SqKw94XRc1sgXEgDVw@mail.gmail.com>
To: Daniel Fett <mail=40danielfett.de@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000009e5980626ce39e3"
Message-ID-Hash: QDP3WS2R4MCOSWJZLTSFQMSASL3PKYQJ
X-Message-ID-Hash: QDP3WS2R4MCOSWJZLTSFQMSASL3PKYQJ
X-MailFrom: thomasclinganjones@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@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Reply-To: peace@acm.org
Subject: [OAUTH-WG] Re: Second WGLC for SD-JWT: 41 issues have been created on github
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Q68MuVKK51r_13_BQz0EaBEDGoY>
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>
The core problem here is that SD-JWT has been oversold and included in OID4VP for the EUDIW where it has no discernible value addressing issues of interest to a gov't issued cred, which, by definition, is not self-sovereign. The primary issue then is where the SD-JWT is used, which Fett makes clear, is not fixable. I presented a solution to the DID CCG nearly 5 years ago (2018-12-12) and was told by Chris Allen that they agreed not to address age verification "because it was too hard." Since the wallet must be trusted for the EUDIW, SD-JWT is of no value in that use case. Perhaps the security section could warn people that unlinkability is not possible in principle and remove SD from the OID4VP? Peace ..tom jones On Wed, Nov 13, 2024 at 8:33 AM Daniel Fett <mail= 40danielfett.de@dmarc.ietf.org> wrote: > > Am 11.11.24 um 15:58 schrieb Denis: > > This message is copied to Deb Cooley, our SEC Area Director. > > I see Hannes in the CC, but not Deb. Did you use BCC? > > > > By developing this draft in OAuth Working group, the major problem is that > the document focuses on a single protocol, > without having described the overall framework in which it will be used. > This draft is not targeted to be exclusively used > in the context of the OAuth Framework. It is well-known that one of the > targets is the EUDI wallet. > > This document, which does not mainly describe a protocol, but data > formats, is generic in nature and not limited to the EUDI wallet. In fact, > it is not even limited to wallet-based identity systems, as has been > discussed a number of times in this group. > > Many of your suggestions below and in your proposed changes seem to be > based on a misunderstanding about the scope of the work. Without protocols > for issuing and presenting credentials (like OpenID4VC), SD-JWT cannot be > used to built a wallet ecosystem. > > > > The basic protocol does not support the Verifier-Verifier unlinkability > property.The fact that the EUDI wallet, as described > in the ARF 1.4.1. does not support this property (despite the fact that > the EU Regulation mandates this principle in Article 5a (16) (b) > from REGULATION (EU) 2024/1183 of 11 April 2024) should not be taken as an > argument for not describing a variant of the protocol > using one-time use digital credentials. > > As above - SD-JWT is a data format. It can be used for one-time use > credentials, but the magic happens in a protocol. > > > > A threat analysis has not been carried out for > draft-ietf-oauth-selective-disclosure-jwt-13 (nor for the ARF 1.4.1). > > Any threats identified and considered relevant have been addressed in the > Security and Privacy Considerations sections. > > > The threat that apply to the "End-user, Holder, Issuer and Verifier" 4 > roles model (note that I didn't used the wording > "Holder, Issuer and Verifier" 3 roles model) are specific and, when > selective disclosure is used, the major threat is the > End-user collaborative attack against a Verifier. This threat is not > mentioned in the Security Considerations section. > > You keep bringing up End-user collaborative attacks since at least 2017 > and we have discussed them in the context of the OAuth Security BCP WGLC > and the DPoP WGLC. All I have to say on that topic has been said and I will > not engage in any further discussion on it, as it doesn't seem to be a good > use of my time. > > > > I am proposing a way forward to defeat the collaborative End-Users attack > by defining a new claim that I called "hcar"' > for "*h*older *char*acteristics". It should be defined as an array of > characteristics. Using this claim, the Verifier will be able > to know a set of characteristics of the Holder. > > Potentially originating in the misunderstanding mentioned above, this is > not for SD-JWT to solve. Please take a look at what OpenID4VC can do with > regards to guaranteeing properties of certain parties to other parties > (wallet/key attestations etc.). > > > In another area, I would like to mention an improvement that could be > addressed using the "hcar"' claim that would allow > to support both suspension and revocation checking, without using CRL-like > mechanisms or OCSP-like mechanisms. (...) > > This and all the parts I snipped out for brevity here depend on a number > of considerations that have to be made for specific deployments, each > having their own set of requirements and limitations. A mechanism like this > could, if deemed useful, be added by the concrete deployment. It exceeds > the scope of this basic data format to define such a mechanism. > > -Daniel > > > > Denis > > Hello Denis, > > Thank you for your continued interest in this work, > > One of the draft's co-editors has already reviewed the comments and worked > to identify appropriate and actionable items, incorporating these into a > pull request in the repository’s source document. This work is ongoing, but > we are hopeful to be in a position to publish the new draft -14 revision > soon. > > Then, as I proposed during the session last Thursday, I suggest the WG > proceed with submitting the draft to the IESG for publication while noting > in the Shepherd Write-Up that Denis Pinkas has around forty unresolved > comments. I believe it's completely reasonable at this point to declare the > majority of that feedback as being "in the rough" with respect to WG > consensus on the document content and desire to move it forward. > > Thanks, > Brian > > > On Wed, Nov 6, 2024 at 10:38 AM Denis <denis.ietf@free.fr> wrote: > >> >> As I got no response to my comments sent to the OAuth mailing during the >> first WG LC, as well as during the second WG LC, >> I have posted today 41 issues on github. They are numbered from #482 >> until #522. >> >> See: >> https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues?page=1&q=is%3Aissue+is%3Aopen >> >> To respond, please use the numbering #482 until #522 of the issues that >> have been posted on github. >> One major advantage is that every issue has now a header. Some text >> proposals have been slightly reworded. >> >> Denis >> >> *Daniel, Kristina and Brian,* >> >> >> * You will find below 42 comments. Most of them have been sent during the >> first Last Call, but none has been addressed. **Each text change >> proposal is numbered from 1 to 42.* >> >> * The main comments were sent on T**uesday, 17 September 2024 under the >> subject: "* >> >> >> *Re: WGLC for SD-JWT". See: >> https://mailarchive.ietf.org/arch/msg/oauth/sVks-Tf_XM6SLcdccIAX29n_Ui4/ >> <https://mailarchive.ietf.org/arch/msg/oauth/sVks-Tf_XM6SLcdccIAX29n_Ui4/> * >> >> *The introduction has been changed. My comments on the introduction have >> been revised and adapted to it. * >> * 1.** The second sentence of the second paragraph mentions:* >> >> * In this model, a JWT containing many claims is issued to an >> intermediate party, who holds the JWT (the Holder).* >> >> >> >> >> >> >> >> *COMMENT: In the introduction, it is important, to make the difference >> between the Holder, which is an *application*, and the individual (i.e. >> End-User) who is assumed to have the control of that application. The use >> of the word "entity" is to broad and does not capture this difference. An >> individual may consent to an operation that the Holder can perform. A >> Holder does not "consent". This difference is well noticed later on in >> clause 7.2: * >> >> *7.2. Processing by the Holder* >> * (...)* >> * For presentation to a Verifier, the Holder MUST perform the * >> * following (or equivalent) steps:* >> >> * 1. Decide which Disclosures to release to the Verifier,* >> * *obtaining proper End-User consent* if necessary.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * In the introduction, it is also important to mention that "claims" >> refers both to object properties name/value pairs) and to array elements. >> The current text does not mention it. Replace by: In this model, a JWT can >> contain both regular claims and selectively disclosable claims that are >> issued an End-User who is assumed to have the control of a Holder. When >> requesting a digital credential to an Issuer, the End-User using his Holder >> CAN ask the Issuer to include a set of claims while obfuscating other >> claims. "Claims" here refers both to object properties (name/value pairs) >> and to array elements. The Issuer then produces two elements: - a >> SD-JWT that contains both regular claims and digests of >> selectively-disclosable claims, - a set of regular claims for the >> selectively-disclosable claims. The resulting structure is called: SD-JWT + >> All.Claims **2.* >> >> >> >> >> >> >> * The third sentence of the second paragraph mentions: The Holder can >> then present the JWT to different verifying parties (Verifiers), that >> each may only require a subset of the claims in the JWT. Replace by: * >> >> >> *When talking to a Verifier, the Holder CAN choose to selectively >> disclose some obfuscated claims by sending a subset of the disclosed >> claims.* >> >> * The resulting structure is called: SD-JWT + Sel.Claims* >> >> *3.** The fifth paragraph mentions:* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * To prevent attacks in which an SD-JWT is presented to a Verifier >> without the Holder's consent, this specification additionally defines a >> mechanism for binding the SD-JWT to a key under the control of the >> Holder (Key Binding). When Key Binding is enforced, a Holder has to >> prove possession of a private key belonging to a public key contained in >> the SD-JWT itself. It usually does so by signing over a data structure >> containing transaction-specific data, herein defined as the Key Binding >> JWT. An SD-JWT with a Key Binding JWT is called SD- JWT+KB in this >> specification. COMMENT: Key Binding is not performed to prevent attacks >> without the "Holder's consent". In fact, key binding will be ineffective if >> the End-User consents to perform a collaborative attack against a Verifier >> for the profit of another individual ... unless the Holder supports >> specific characteristics that will be able to prevent such collaborative >> attacks. Once again, a Holder is an *application*, i.e., it is not a human >> being. Key Binding only demonstrates the knowledge a private key >> corresponding to a public key contained in a SD-JWT. It does not >> demonstrate the *possession* of a key. A key binding is performed: * >> >> *(a) when requesting a SD-JWT to an Issuer, while * >> *(b) the demonstration of that key binding is performed to a Verifier at >> the presentation time.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> *Replace by: When requesting a digital credential to an Issuer, the >> Holder CAN demonstrate to the Issuer that the request originates from an >> application that supports specific characteristics. In that case, the >> Holder CAN include in his request a public key and demonstrate to the >> Issuer the knowledge of the corresponding private key. When presenting a >> SD-JWT to a Verifier, the Holder CAN then add a key-binding JWT, called >> KB-JWT, that allows to integrity protect the "SD-JWT + Sel.Claims" >> structure. In this way, the Verifier will be able to verify that the >> "SD-JWT + Sel.Claims" structure and the KB-JWT " originate from a Holder >> that supports specific characteristics. The strength of the key >> binding is dependent upon the characteristics of the Holder. Such >> characteristics include the generation of key pairs, their protection as >> well as additional characteristics in particular to demonstrate its >> ability to counter collaborative or collusions attacks between >> End-Users. COMMENT: It is important to state upfront that key binding is >> not simply a cryptographic operation. That cryptographic operation will be >> ineffective if the Holder permits the legitimate End-User to use private >> keys contained in the Holder for the benefit of another individual. Unless >> the Verifier is able to know the characteristics of the Holder by using >> *information present in the SD-JWT*, the key binding mechanism can be >> easily defeated. The information that shall be placed in the SD-JWT is >> currently missing and should be added. See a later comment about a new >> claim called "hcahr" claim (i.e. holder characteristics). * >> *4.* >> * Last sentence from the fifth paragraph on page 5: * >> >> * An SD-JWT with a Key Binding JWT is called SD-JWT+KB in this >> specification.* >> >> * Since the end result is the concatenation of two JWTs, it would be more >> appropriate to call the structure SD-JWT+KB-JWT. * >> >> >> >> >> *This change should be done everywhere in the document. Change into: An >> SD-JWT with a Key Binding JWT is called SD-JWT + KB-JWT in this >> specification.* >> >> * However the description of the "* >> *SD-JWT+KB composite structure" is so unclear (so the next comments), >> that this change might be inappropriate. In any case, please clarify.* >> >> *5.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * Item 1 from Section 1.1. (Feature Summary) states: 1.1. Feature >> Summary This specification defines two primary data formats: 1. >> SD-JWT is a composite structure enabling selective disclosure of its >> contents. It comprises the following: * (...) * (...) >> * A format extending the JWS Compact Serialization, allowing for >> the combined transport of the Issuer-signed JSON data >> structure and the disclosable data items * An alternate format >> extending the JWS JSON Serialization, also allowing for transport >> of the Issuer-signed JSON data structure and disclosure data At >> the time of reading these two sentences, they are not understandable. These >> sentences should be rephrased so that that the motivations behind them can >> become understandable Please clarify.* >> >> * 6**.* >> >> >> >> >> >> * Item 2 from Section 1.1. (Feature Summary) states: 2. SD-JWT+KB is >> a composite structure enabling cryptographic key binding when >> presented to the Verifier. It comprises the following: * A >> facility for associating an SD-JWT with a key pair* >> >> * * A format for a Key Binding JWT (KB-JWT) that proves possession >> of the private key of the associated key pair* >> >> * * A format extending the SD-JWT format for the combined >> transport of the SD-JWT and the KB-JWT* >> >> * The whole description is not understandable.* >> >> *What is this "facility" ? See the comment 8 for a text change proposal.* >> >> *7.* >> >> >> >> >> >> >> >> >> >> * Item 2 from Section 1.1. (Feature Summary) states 2. SD-JWT+KB is a >> composite structure enabling cryptographic key binding when >> presented to the Verifier. It comprises the following: * >> (...) * A format for a Key Binding JWT (KB-JWT) that proves >> possession of the private key of the associated key pair There is >> no "proof of possession". What is a "***format for* a Key Binding JWT >> (KB-JWT)" ?* >> >> * This description is not understandable. **See the next comment for a >> text change proposal.* >> >> *8.* >> >> >> >> >> >> >> >> >> >> >> * Item 2 from Section 1.1. (Feature Summary) states 2. SD-JWT+KB is a >> composite structure enabling cryptographic key binding when >> presented to the Verifier. It comprises the following: * >> (...) * (...) * A format extending the SD-JWT format for >> the combined transport of the SD-JWT and the KB-JWT * >> *This description is not understandable. While reading it, it is not >> possible to understand where the **selective disclosures **have been >> placed.* >> >> *Section 4 provides more details. The wording * >> >> *"SD-JWT+KB" for the composite structure does look not to be adequate as >> in some cases the structure does not include the KB-JWT. Since this >> structure is presented to the Verifier, the wording "presentation >> structure" is proposed as it would be more neutral.* >> >> *It is thus proposed to replace the content of **the item 2 from Section >> 1.1. by:* >> >> >> * 2. a composite presentation structure enabling cryptographic key >> binding when presented to the Verifier. It * >> *is composed of the concatenation of* >> >> * the following: * >> >> >> * * an SD-JWT, * one or more selected Disclosures, >> and * a Key Binding JWT * >> >> >> *that allows to demonstrate to a Verifier that a >> cryptographic result computed over the two previous >> components using a private key corresponding to a public key >> present in a SD-JWT is correct**.* >> >> >> * See more details in section 4. * >> >> *Everywhere in the document change "SD-JWT+KB" into "presentation >> structure".* >> >> >> >> * 1.2. Conventions and Terminology **9.* >> >> >> >> >> >> >> >> * The current definition of Selectively Disclosable JWT (SD-JWT) is: >> Selectively Disclosable JWT (SD-JWT): A composite structure, >> consisting of an Issuer-signed JWT (JWS, [RFC7515]) and zero or more >> Disclosures, which supports selective disclosure as defined in this >> document. It can contain both regular claims and digests of >> selectively-disclosable claims. * >> >> >> >> >> >> >> >> >> >> >> >> >> >> *The "all Disclosures" are not part of the SD-JWT. It they were, they >> would be signed and removing one of them would break the signature of the >> Issuer. Change into: Selectively Disclosable JWT (SD-JWT): A composite >> structure, consisting of an Issuer-signed JWT (JWS, [RFC7515]) that >> contains both regular claims and one or more digests of selectively- >> disclosable claims. When a SD-JWT is sent back to a Holder, all >> the disclosures corresponding to the selectively-disclosable >> claims are also returned. When a SD-JWT is presented to a Verifier, >> all or only a subset of the disclosures previously obtained by the >> Holder are presented to the Verifier. **10.* >> >> >> >> >> >> >> >> >> >> >> >> * The current definition of key Binding is: Key Binding: Ability of >> the Holder to prove legitimate possession of an SD-JWT by proving >> control over a private key during the presentation. When utilizing >> Key Binding, an SD-JWT contains the public key corresponding to the >> private key controlled by the Holder (or a reference to this public >> key). COMMENT: Talking of a "legitimate possession" is an abuse of >> language. Who possesses the private key is unknown. Even when the key is >> controlled by a Holder, the End-User can decide to perform cryptographic >> computations with the private key for the benefit of one or more End-Users. >> If the set of claims does not allow to uniquely identify the End-User, the >> End-User cannot be caught. In that case, the End-User can even monetize his >> services for the benefit of **e.g., * >> >> >> >> >> >> >> >> >> *hundred or thousand of users. Replace this definition by: Key >> Binding: Ability to demonstrate to a Verifier that a cryptographic >> result computed over a data structure using a private key >> corresponding to a public key contained in a SD-JWT is correct. * >> *11.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * The current definition of Key Binding JWT is: Key Binding JWT >> (KB-JWT): A JWT for proving Key Binding as defined in Section 4.3. >> A Key Binding JWT is said to "be tied to" a particular SD-JWT when >> its payload includes a hash of the SD-JWT in its sd_hash claim. >> COMMENT: Referring to a subsequent Section is not adequate for a >> definition. The definition should be understandable without the need to >> look at another section. The KB-JWT does much more than the current >> description. Replace this definition by: Key Binding JWT (KB-JWT): A >> JWT that allows a Holder to disclose a set of claims that were >> obfuscated in a SD-JWT, to restrict the use of a SD-JWT to one or >> more designated Verifiers, to prevent the replay of a SD-JWT by a >> designated Verifier to non-designated Verifiers, to limit the use of >> the SD-JWT to a single exchange and that allows the Verifier to make >> sure that these limitations are enforced by a Holder that has the >> knowledge of a private key corresponding to a public key contained in >> the SD-JWT. * >> *12.* >> >> * The current definition of Issuer is: * >> >> >> >> >> >> * Issuer: An entity that creates SD-JWTs. Replace this definition by: >> Issuer: An entity that creates SD-JWTs and Disclosures. * >> *13.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * The current definition of Holder is: Holder: An entity that >> received SD-JWTs from the Issuer and has control over them. In the >> context of this document, the term may refer to the actual user, the >> supporting hardware and software in their possession, or both. >> COMMENT: It is important to make the difference between the (Holder) >> application supported by some hardware and the End-User that has the >> control of that (Holder) application. At a lower level of granularity, a >> (Holder) application can be composed of several hardware and software >> elements such as: TEE, Trusted OS, Trusted Applications, Rich OS, Untrusted >> Applications. These characteristics are fundamental to successfully achieve >> or not "key binding". Replace this definition by: Holder: An >> application supported by hardware that obtains SD-JWTs and >> Disclosures from an Issuer and is able to selectively disclose to a >> Verifier claims contained those SD-JWTs. In the context of this >> document, a Holder is placed under the control of an End-User. * >> *14.* >> >> >> >> >> >> >> >> >> >> >> * The current definition of Verifier is: Verifier: An entity that >> requests, checks, and extracts the claims from an SD-JWT with >> its respective Disclosures. Replace this definition by: Verifier: An >> entity that requests, receives a SD-JWT that contains selectively >> disclosable claims and uses Selective Disclosures to obtain one or >> more obfuscated claims. **15.* >> >> >> * Add a definition for the term End-Use End-User: an individual >> assumed to have the control of a Holder. * >> * 16.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * Correct Figure 1 as below: 3. Flow Diagram >> +------------+ | | | >> Issuer | | | +------------+ >> | Issues: SD-JWT + All Disclosures >> | v +------------+ >> | | | Holder | End-User >> | | +------------+ >> | Presents: SD-JWT + **Selected Disclosures + * >> *KB-JWT* >> >> >> >> >> >> >> >> >> >> >> * | v >> +-------------+ | |+ | Verifiers >> ||+ | ||| +-------------+|| >> +-------------+| +-------------+ >> Figure 1: SD-JWT Issuance and Presentation Flow* >> >> >> *17.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * Section 3.1. SD-JWT and Disclosures The third sentence of the second >> paragraph states: The Disclosures are sent to the Holder as part of the >> SD-JWT in the format defined in Section 4. The first sentence states: >> An SD-JWT, at its core, is a digitally signed JSON document containing >> digests over the selectively disclosable claims with the Disclosures >> outside the document. Hence, the Disclosures are NOT included in the >> Issuer-signed SD-JWT. Change the third sentence of the second paragraph >> into: The Disclosures are sent to the Holder in addition to the SD-JWT. >> COMMENT: The format used to carry both the SD-JWT and the Disclosures is >> unclear. * >> * 18.* >> >> >> >> >> >> >> >> >> >> >> >> >> * Section 3.2. 3.2. Disclosing to a Verifier To disclose to a >> Verifier a subset of the SD-JWT claim values, a Holder sends only the >> Disclosures of those selectively released claims to the Verifier as part >> of the SD-JWT. Change the third sentence of the second paragraph into: >> To disclose to a Verifier a subset of the SD-JWT claim values, in >> addition to the SD-JWT, a Holder sends only the Disclosures of those >> selectively released claims to the Verifier. * >> * 19.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * Section 3.3 When a Verifier requires Key Binding, the Holder >> presents an SD- JWT+KB, consisting of an SD-JWT as well as a Key Binding >> JWT tied to that SD-JWT. The Key Binding JWT encodes a signature by the >> Holder's private key over * a hash of the SD-JWT, * a nonce to >> ensure the freshness of the signature, and * an audience value to >> indicate the intended audience for the document. Change: * a >> nonce to ensure the freshness of the signature, and * an audience value >> to indicate the intended audience for the document. into: * a >> nonce previously received from the Verifier to ensure the freshness >> of the signature, and * an audience value to indicate the intended >> Verifier for the document. * >> * 20.* >> >> * Section 4 4. SD-JWT and SD-JWT+KB Data Formats* >> >> >> >> *Change the title into: * >> * 4. SD-JWT and presentation structure data formats* >> >> >> >> >> >> >> >> * An SD-JWT is composed of * an Issuer-signed JWT, and * zero >> or more Disclosures. No. The Disclosures, which are unsigned, are located >> outside the SD-JWT. * >> >> >> >> >> >> >> >> >> *Change into: A data structure for a SD-JWT with Disclosures is >> composed of: * an Issuer-signed JWT, and * one or more Disclosures. >> **21.* >> >> >> >> >> >> >> >> >> >> * Section 4: An SD-JWT+KB is composed of * an SD-JWT (i.e., an >> Issuer-signed JWT and zero or more Disclosures), and * a Key >> Binding JWT. Change into: A **presentation structure * >> >> >> >> >> >> >> *for a SD-JWT with Selected Disclosures and with key binding is >> composed of: * an SD-JWT * one or more Selected Disclosures, >> and * a Key Binding JWT. **22.* >> >> >> >> >> >> >> >> >> >> * Section 4.1: It is the Issuer who decides which claims are >> selectively disclosable and which are not. Change into: It is the >> Issuer which decides which claims can be selectively disclosed by the >> Holder and which claims are always disclosed. **23.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * Section 4.2.2. Disclosures for Array Elements This section contains an >> interesting example for the use case when an End-User has several >> nationalities. It is proposed to add another interesting example for the >> use case where an individual is willing to demonstrate that he is above >> or/and under an age threshold limit. Note: This topic has already been >> advertised to the OAuth mailing list on 20 September 2024 under the title: >> " Re: WGLC for SD-JWT" and the sub-title: *About disclosures for Array >> Elements versus disclosures of name/value pair*. See: >> https://mailarchive.ietf.org/arch/msg/oauth/EYlDtN8gg1--tsZ-AWolMjw4jAk/ >> <https://mailarchive.ietf.org/arch/msg/oauth/EYlDtN8gg1--tsZ-AWolMjw4jAk/> >> Draft of Annex - Ares(2024)5786783 "laying down rules for the application >> of Regulation (EU) No 910/2014 of the European Parliament and of the >> Council as regards person identification data and electronic attestations >> of attributes issued to European Digital Identity Wallets" identifies the >> following two optional attributes: "age_over_18" and "age_over_13" on page >> 3 in Table 2: Optional attributes. The threshold values depends upon the >> use case and vary country by country. Some examples are: over 13, over 15, >> over 18, over 21, over 60, over 65 but also under 25 (for social networks). >> Rather than defining more optional attributes, like "age_over_15", >> "age_over_21", "age_over_60", "age_over_65" or "age_under_25", each time >> there will be a new need, it is more adequate to define two array elements >> that will allow to support any age threshold value. This leads to define >> two arrays: * >> >> * - "age_over", and* >> * - "age_under".* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> *The Issuer may wish to make the whole "age_over" and/or "age_under" >> field selectively disclosable and allow the Holder to make the entries >> within the "age_over" and/or "age_under" array selectively disclosable. Add >> the following text: The disclosure of age threshold values is another >> example. Rather than defining attributes, like "age_over_15", >> "age_over_21", "age_over_60", "age_over_65" or "age_under_25", two array >> elements allow to support any age threshold value. Two examples are >> mentioned below : { "age_over": ["21", "13", "18", "15"] } A >> Disclosure for the second element of the "age_over" array in the following >> JWT Claims Set could be created. { "age_under": ["25", "18"] } A >> Disclosure for the first element of the "age_under" array in the following >> JWT Claims Set could be created. I let the co-editors of the document to >> complete this example. * >> *24.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * Section 5.1.2 It is out of the scope of this document to describe >> how the Holder key pair is established. For example, the Holder MAY >> create a key pair and provide a public key to the Issuer, the Issuer MAY >> create the key pair for the Holder, or Holder and Issuer MAY use pre- >> established key material. COMMENT: The strength of the key binding >> mechanism is dependent about the key generation process. For example, if >> the key pair can be freely exported or shared, then the strength of the key >> binding mechanism becomes close to zero. A first condition (which will not >> be the single one), shall be to use a secure cryptographic application >> which is part of the Holder application to generate the key pairs. In order >> to appreciate the strength key binding mechanism, the Verifier shall be >> made aware of the characteristics of the Holder. In order to avoid the use >> of a specific protocol between the Holder and the Verifier that could leak >> information that would be usable to link different accesses, a transitive >> trust scheme is preferred. At the moment where he Holder requests a SD-JWT >> to the Issuer, a specific protocol between the Holder and the Issuer is >> used that allows the Issuer to know some of the characteristics of the >> Holder. These characteristics can then be included in a specific claim of >> the SD-JWT (i.e., a "hchar" claim). Remove this paragraph and replace it >> with: The key pair SHALL be generated by a trusted part of the Holder where >> the characteristics of that application SHALL be included by the Issuer in >> SD-JWT using a specific claim (i.e., a "hchar" claim). See clause 4.3.2. * >> *25.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * Section 4.2.1 4.2.1. Disclosures for Object Properties Section 4.2.2 >> (Disclosures for Array Elements) contains a consideration that should also >> be applied to section 4.2.1 (Disclosures for Object Properties). Add the >> following text below the header of this section: The Issuer SHOULD hide >> the order of the obfuscated claims in the SD-JWT. To ensure this, it is >> RECOMMENDED to add decoy digests and to shuffle the digests included in >> the SD-JWT payload. See section 4.2.5 about Decoy Digests. It is also >> RECOMMENDED to use a fixed number of digests, so that the Verifier >> cannot deduce the value of an obfuscated claim name that won't be >> revealed. * >> * 26.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * Section 4.3 4.3. Key Binding JWT (...) The Key Binding JWT MUST be >> a JWT according to [RFC7519] and its payload MUST contain the following >> elements: * in the JOSE header, (...) * in the JWT payload, >> - iat: REQUIRED. The value of this claim MUST be the time at >> which the Key Binding JWT was issued using the syntax defined >> in [RFC7519]. - aud: REQUIRED. The intended receiver of >> the Key Binding JWT. How the value is represented is up to the >> protocol used and out of scope of this specification. - >> nonce: REQUIRED. Ensures the freshness of the signature. The >> value type of this claim MUST be a string. How this value is >> obtained is up to the protocol used and out of scope of this >> specification. - sd_hash: REQUIRED. The base64url-encoded hash >> value over the Issuer-signed JWT and the selected Disclosures as >> defined below. The time at which the Key Binding JWT was issued >> should not be REQUIRED. The use of the nonce is sufficient to prevent >> replay. Remove: - iat: REQUIRED. The value of this claim MUST be >> the time at which the Key Binding JWT was issued using the syntax >> defined in [RFC7519]. **27.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * Section 4.3.2 (Validating the Key Binding JWT) Some validation steps >> are missing. They should correspond in particular to the REQUIRED claims >> from clause 4.3: - aud: REQUIRED - nonce: REQUIRED - >> sd_hash: REQUIRED The presence of an additional claim which is currently >> not yet defined should be done. The claim allows to know characteristics of >> the Holder. It is proposed to name this claim "hchar" for "holder >> characteristics". Add the following text: The Verifier MUST verify that >> the Key Binding JWT is a JWT according to [RFC7519] and that its payload >> contains the following elements: - aud: REQUIRED. It MUST >> correspond to an identifier or a name of the intended Verifier. >> - nonce: REQUIRED. It MUST correspond to value of the nonce that >> was sent by the Verifier and received by the Holder when the >> Holder made an access request to the verifier. The value type >> of this claim MUST be a string. - sd_hash: REQUIRED. The >> base64url-encoded hash value over the Issuer-signed JWT and the >> selected Disclosures. If the Verifier is willing to know the strength of >> the key binding mechanism, the Verifier MUST verify that the payload of the >> Key Binding JWT contains the following element and that it understands its >> meaning: - hchar: REQUIRED. This claim allows the Verifier to know >> specific characteristics of the Holder (holder characteristics), >> in particular whether some of these characteristics are able to >> counter Holder collaborative attacks against a Verifier. **28.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * Section 7.1 (Verification of the SD-JWT) The text states: Upon >> receiving an SD-JWT, either directly or as a component of an SD- JWT+KB, >> a Holder or a Verifier needs to ensure that: * the Issuer-signed JWT is >> valid, i.e., it is signed by the Issuer and the signature is valid, >> and Change into: Upon receiving an SD-JWT, a Holder or a Verifier needs >> to ensure that: * the Issuer belongs to a set of Trusted Issuers using >> a certification path up to a trusted root, * the Issuer-signed >> JWT is valid, i.e., it is signed by a Trusted Issuer and the >> signature is valid, and * >> * 29.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * Section 7.1 (Verification of the SD-JWT) Some steps are missing. >> Section 4.1 in step 6 mentions: 6. The payload MAY contain further >> claims such as iss, iat, etc. as defined or required by the >> application using SD-JWTs. Corresponding verification steps should be added >> in section 7.1. After the following item: 3. Validate the Issuer >> and that the signing key belongs to this Issuer. Add the >> following item: 4. If required by the application using SD-JWTs, >> check that further claims such as iss, iat, nbf, exp, etc. are >> present and contain appropriate values. * >> * 30.* >> * Section 7.1 (Verification of the SD-JWT) * >> >> >> >> >> >> >> >> >> >> >> >> >> >> * Some other steps are missing. Add: 5. If required by the >> application using SD-JWTs and if the SD-JWT contains claims such >> as nbf or exp, verify that the current time lies between these >> two values. 6. If required by the application using SD-JWTs and if >> the previous verification succeeds, verify that the SD-JWT is >> not currently suspended, nor revoked. Note : The means to verify >> that the SD-JWT is not currently suspended, nor revoked, are not defined in >> this document. * >> *31.* >> * Section 7.2 * >> >> >> >> >> >> >> >> >> >> >> >> *7.2. Processing by the Holder The Issuer MUST provide the Holder an >> SD-JWT, not an SD-JWT+KB. If the Holder receives an SD-JWT+KB, it MUST >> be rejected. These sentences would mean that the Issuer would be in >> possession of the private key able to sign the KB-JWT. It is much better to >> construct an architecture where the Issuer CANNOT be in possession of the >> private key able to sign the KB-JWT. Remove these two sentences. * >> * 32.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> * Section 7.3 (Verification by the Verifier) Upon receiving a >> presentation from a Holder, in the form of either an SD-JWT or an >> SD-JWT+KB, in addition to the checks outlined in Section 8.1, Verifiers >> need to ensure that (...) The vocabulary should be aligned with the >> acronyms from Figure 1: SD-JWT Issuance and Presentation Flow. Change into: >> Upon receiving a presentation structure from a Holder, in the form of >> either an SD-JWT + sel.disclosures or an SD-JWT + sel.disclosures + SD-JKT, >> in addition to the checks outlined in Section 8.1, Verifiers need to >> ensure that (...) * >> * 33.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * Section 9.5 (Key Binding) Key Binding aims to ensure that the >> presenter of an SD-JWT credential is actually the legitimate Holder of >> the credential. An SD-JWT compatible with Key Binding contains a public >> key, or a reference to a public key, that corresponds to a private key >> possessed by the Holder. The Verifier requires that the Holder prove >> possession of that private key when presenting the SD-JWT credential. >> Without Key Binding, a Verifier only gets the proof that the credential >> was issued by a particular Issuer, but the credential itself can be >> replayed by anyone who gets access to it. This means that, for example, >> after a credential was leaked to an attacker, the attacker can present >> the credential to any verifier that does not require a binding. But >> also a malicious Verifier to which the Holder presented the credential >> can present the credential to another Verifier if that other Verifier >> does not require Key Binding. These two paragraphs are incorrect. Let us >> suppose that an End-User B connects to a Verifier in order to perform an >> operation. The Verifier then returns a selection of issuer names, claim >> names and a nonce. Let us now assume that an End-User A accepts to >> collaborate with the End-User B. The End-User B transmits the nonce to the >> End-User A. The End-User A then provides a "SD-JWT + **Selected >> Disclosures + * >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> *KB-JWT to the End-User B. In this way, the End-User B can take benefits >> of claims that belong to the End-User A. The Verifier is not in a position >> to know who is "the legitimate Holder of the credential" ... unless the set >> of disclosed claims allows to unambiguously identify the End-User. The >> collusion attack has been described on the OAuth mailing list on 07 >> November 2016. The ABC attack (the Alice and Bob Collusion attack). See: >> https://mailarchive.ietf.org/arch/msg/oauth/UIsbsVtINPifrCjG7GDZM7FOi2g/ >> <https://mailarchive.ietf.org/arch/msg/oauth/UIsbsVtINPifrCjG7GDZM7FOi2g/>. >> A few extracts: Whatever kind of cryptographic is being used, when two >> users collaborate, a software-only solution will be unable to prevent >> the transfer of an attribute of a user that possess it to another >> user that does not possess it . The use of a secure element or of a Trusted >> Application (TA) running in a TEE only protecting the confidentiality and >> the integrity of some secret key or private key will be ineffective to >> counter the Alice and Bob collusion attack. Additional properties will be >> required for the secure element or the Trusted Application (TA) running in >> a TEE. Change into: An SD-JWT compatible with Key Binding contains a >> public key, or a reference to a public key, that corresponds to a >> private key known by some entity. The Verifier requires that a Holder >> proves the knowledge of that private key when presenting an SD-JWT + * >> *Selected Disclosures + * >> >> *KB-JWT structure to a Verifier. Key Binding aims to ensure that the >> presenter of a * >> *SD-JWT + ** Selected Disclosures + **KB-JWT structure* >> >> >> * structure to a Verifier has either the knowledge of a private key >> corresponding to a public key contained in a SD-JWT or has had the >> ability to obtain a cryptographic result performed using that private >> key.* >> >> * Without Key Binding, a Verifier only gets the proof that the* >> * credential was issued by a particular Issuer, but the credential* >> * itself can be replayed by anyone who gets access to it. A * >> >> *malicious Verifier to which the Holder presented the credential can >> also present the credential to another Verifier* >> >> *if that other Verifier does not require Key Binding. * >> * With Key Binding, if two End-Users accept to collaborate, unless * >> * specific characteristics are supported by the Holder, an * >> *SD-JWT + ** Selected Disclosures + **KB-JWT structure* >> >> >> >> >> >> >> * structure can voluntarily be computed and then transmitted by the >> legitimate Holder of a private key with the consent of the End-User to >> another Holder. Using the "hchar" claim, the Verifier will be able to >> know whether some of these characteristics are able to counter Holder >> collaborative attacks against a Verifier. **34.* >> >> >> * New section 9.12. Presentation of claims issued by different Issuers >> The text below reuses text sent on 23 September 2024 to the OAUth mailing >> list under the topic: * >> >> >> *[OAUTH-WG] How to get the benefits of BBS+, without its drawbacks while >> using conventional cryptography ? (Was SD-JWT and Unlinkability)* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> *See: >> https://mailarchive.ietf.org/arch/msg/oauth/X4fZ-RMAfcC_5vAxl_qAnSBu8T0/ >> <https://mailarchive.ietf.org/arch/msg/oauth/X4fZ-RMAfcC_5vAxl_qAnSBu8T0/> >> Add the following text: 9.12. Presentation of claims issued by different >> Issuers There exist use cases where claims issued by different Issuers >> need to be presented to one Verifier. For example, an End-User would >> like to demonstrate to a Verifier that that he lives in California using >> a SD-JWT issued by a governmental organization and that he got a >> specific diploma using a SD-JWT issued by a University. When using the >> regular SD-JWT mechanism, the Holder generates one key pair for each >> Issuer. In this way, a SD-JWT issued by an Issuer A cannot be linked >> between collaborative Verifiers to a SD-JWT issued by an Issuer B. >> For that specific use case, the Holder can generate a one-time one key >> pair and use the same private key to request a SD-JWT from each Issuer. >> The two issued SD-JWTs will contain the same public key and, using >> the corresponding private key, the Holder will be able to demonstrate to >> one Verifier that the two presentations of the SD-JWT originate from the >> same Holder. This means that the key pairs MUST be generated by a >> trusted component from the Holder, e.g., running in a TEE. Both Issuers >> and Verifiers MUST be able to obtain the characteristics of the trusted >> component from Holder to be confident that Holder indeed supports >> this scheme. Since that key pair will only be used once towards a single >> Verifier, a linkage between different collaborative Verifiers using the >> framing of the SD-JWT will not be possible. **35.* >> >> >> >> >> >> * Section 10.1. (Unlinkability) 10.1. Unlinkability The word >> "unlinkability" is used with four different meanings or flavours. The last >> two properties are called: * >> >> * Issuer/Verifier Unlinkability (Honest Verifier), and* >> * Issuer/Verifier Unlinkability (Colluding/Compromised Verifier)* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * When reading these two long wordings, it is rather difficult to >> understand their meaning and their differences. The current text is using >> twice the word "track". * Cooperating Verifiers might want to *track* >> users across services to build advertising profiles. * Issuers >> might want to *track* where users present their credentials to enable >> surveillance. In order to make the text more understandable, it is proposed >> to use the terms "unlinkability" and "intrackability". Roughly speaking: * >> >> - * Verifiers may attempt to *link* accesses performed by the >> Holders.* >> - >> * Issuers may either be required by a national authority or be willing to >> *track* accesses performed by their Holders.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * This leads to consider one section dedicated to "unlinkability" and >> another section dedicated to "intrackability". Text change proposal: 10.1. >> Unlinkability Unlinkability is a property whereby one or more Verifiers >> are prevented from correlating SD-JWT presentations from the same >> Holder. Without unlinkability, a Verifier might be able to learn more >> about the End-User intended to disclose, for example: * A single >> Verifier might want to count the number of accesses made by one >> Holder. * Collaborative Verifiers might want to learn that the same >> End-User made an access to their services. In all cases, >> unlinkability is limited to cases where the disclosed claims do not >> contain information that directly or indirectly identifies the >> End-User. For example, when a taxpayer identification number is >> contained in the disclosed claims, the Issuer and Verifier can easily >> link the user's transactions. However, when the End-User only discloses >> a birth date to one Verifier and a postal code to another Verifier, the >> two Verifiers should not be able to determine that they were interacting >> with the same user. The following types of unlinkability are considered >> here: * Single Verifier Unlinkability: incapability of one Verifier to >> learn that it got two or more accesses using different sessions >> from the same End-User or the same Holder. * Verifier/Verifier >> Unlinkability: incapability of two or more collaborative Verifiers to >> learn that they got accesses from the same End-User or the same >> Holder. These collaborative Verifiers may wish to know whether they >> got an access from the same End-User, without necessarily being able >> to identify him. Independently from the set of disclosed >> claims, one or more fields from the SD-JWT or of the KB-JWT may >> reveal that they relate either to the same the End-User or to the >> same Holder, and hence to the same End-User. In that case, if a >> first Verifier is able to identify the End-User and collaborates with >> a second Verifier which was unable to identifier the End-User, then >> the second Verifier will be able to identify the End-User. Single >> Verifier Unlinkability and Verifier/Verifier unlinkability can be >> achieved using batch issuance: a batch of SD-JWTs based on the same set >> of claims is issued to the Holder instead of just a single SD-JWT. The >> Holder can then use a different SD-JWT for each Verifier or even for >> each different session with a Verifier. New key binding keys and salts >> MUST be used for each SD-JWT in the batch to ensure that the Verifiers >> cannot link the SD-JWTs using these values. Likewise, claims carrying >> time information, like iat, exp, and nbf, MUST either be randomized >> within a time period considered appropriate (e.g., randomize iat within >> the last 24 hours and calculate exp accordingly) or rounded (e.g., >> rounded down to the beginning of the day). **36.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * New Section 10.2 (Intrackability) Text addition proposal resulting from >> the split of section 10.1: 10.2. Intrackability Intrackability is a >> property whereby one or more Issuers are normally prevented to learn by >> which Verifier(s) a SD-JWT that they have issued has been consumed. The >> following types of intrackability are considered here: * Holder >> intrackability by one Issuer: incapability of an Issuer alone to >> learn to which Verifiers a SD-JWT that it has issued will be >> presented by a Holder. * Holder intrackability by both Issuers and >> Verifiers: incapability of one Issuer, with the help of one Verifier, >> to learn by which Verifier a SD-JWT that it has issued has been >> consumed. Holder intrackability by one Issuer is natively supported when >> using SD-JWTs since a SD-JWT does not contain an "aud" claim. Holder >> intrackability by both Issuers and Verifiers cannot be supported using >> SD-JWTs, as soon as a Verifier communicates the SD-JWT either to an >> authority upon its request that will then communicate it to the Issuer >> or deliberately communicates the SD-JWT to the Issuer. However, some >> mechanisms using zero-knowledge proofs (ZKP) may be able to support this >> property. It is important to note, for example, that a national >> authority can require to get an access to the audit logs from both a >> Verifier and an Issuer to know whether a same SD-JWT has been logged in >> both files. Since the Issuer "needs to know its customer" (KYC), >> national authorities may be able to identify an End-User who made an >> access to a Verifier. Section 10.X (Storage of User Data) RECOMMENDS >> that after verification, Verifiers SHOULD NOT store the SD-JWT. >> Depending upon the context of use, this recommendation should or should >> not be followed since there exist cases where such property will be non- >> desirable in particular to fight against crime or money laundering. * >> *37.* >> >> >> >> >> >> >> >> >> >> * Section 10.2 10.2. Storage of Signed User Data This section does not >> only consider the storage of *signed* user data, but also of user data that >> is *unsigned*. Change into: 10.2. Storage of User Data * >> * 38.* >> >> >> >> >> >> >> >> >> >> >> >> >> * Section 10.2 Holders SHOULD store SD-JWTs only in encrypted form, >> and, wherever possible, use hardware-backed encryption in particular for >> the private Key Binding key. When a smartphone is used, a TEE can be >> used and the SD-JWTs can be stored in it in clear text since the TEE is >> protected from the RichOS.Encrypted forms are not needed. Change into: >> Holders SHOULD store SD-JWTs and key pairs used for key binding only in >> a protected area such a Trusted Execution Environment (TEE) . * >> * 39.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * Section 10.2 After Verification, Verifiers SHOULD NOT store the >> Issuer-signed JWT or the respective Disclosures if they contain >> privacy-sensitive data. It may be sufficient to store the result of the >> verification and any End-User data that is needed for the application. >> In practice, a SD-JWT contains regular claims and selectively disclosable >> claims while Disclosures are sent separately. After verification, a >> Verifier needs to store any End-User data that is needed for the >> application. Change into: After Verification, Verifiers SHOULD NOT store >> the SD-JWT, nor the KB-JWT. However, it may be necessary to store >> End-User data as needed for the application including regular claims and >> Disclosures. **40.* >> >> >> >> >> >> >> >> >> >> * Section 10.3. (Confidentiality during Transport) Both confidentiality >> and integrity are important. Add integrity. Change into: 11.3. >> Confidentiality and integrity during Transport In the following text, >> change "confidentiality" into "integrity and confidentiality". **41.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * New Section 10.X (Issuer anonymity) This section should be placed >> before section 10.5 (Issuer Identifier) Add a new section: 10.X. Issuer >> anonymity Issuer anonymity: incapability of a Verifier, to learn from >> which Issuer a SD-JWT that has been presented by a Holder has been >> issued. Issuer anonymity cannot be supported using SD-JWTs, since a >> SD-JWT is signed by its Issuer using an asymmetric algorithm. However, >> some mechanisms using group signature or ring signatures may be able to >> support this property. * >> * 42.* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * Section 10.5 (Issuer Identifier) The last paragraph of this section >> states: To mitigate this issue, a group of issuers may elect to use a >> common Issuer identifier. A group signature scheme outside the scope of >> this specification may also be used, instead of an individual >> signature. Given the proposal to add a section dedicated to "Issuer >> anonymity" this paragraph can be removed. Remove this paragraph. END OF >> COMMENTS * >> >> * Denis* >> >> All, >> >> This is a *short second WG Last Call* for the *SD-JWT* document after >> the recent update based on the feedback provided during the first WGLC >> >> https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-13.txt >> >> Please, review this document and reply on the mailing list if you have >> any comments or concerns, by Oct 25th. >> >> Regards, >> Rifaat & Hannes >> >> _______________________________________________ OAuth mailing list -- >> oauth@ietf.org To unsubscribe send an email to oauth-leave@ietf.org >> >> >> >> _______________________________________________ >> 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 > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-leave@ietf.org >
- [OAUTH-WG] Second WGLC for SD-JWT Rifaat Shekh-Yusef
- [OAUTH-WG] Re: Second WGLC for SD-JWT Denis
- [OAUTH-WG] Re: Second WGLC for SD-JWT Watson Ladd
- [OAUTH-WG] Re: Second WGLC for SD-JWT: 41 issues … Denis
- [OAUTH-WG] Re: Second WGLC for SD-JWT Denis
- [OAUTH-WG] Re: Second WGLC for SD-JWT: 41 issues … Brian Campbell
- [OAUTH-WG] Re: Second WGLC for SD-JWT: 41 issues … Denis
- [OAUTH-WG] Re: Second WGLC for SD-JWT Watson Ladd
- [OAUTH-WG] Re: Second WGLC for SD-JWT Brian Campbell
- [OAUTH-WG] Re: Second WGLC for SD-JWT: 41 issues … Daniel Fett
- [OAUTH-WG] Re: Second WGLC for SD-JWT Daniel Fett
- [OAUTH-WG] Re: Second WGLC for SD-JWT: 41 issues … Tom Jones
- [OAUTH-WG] Re: Second WGLC for SD-JWT: 41 issues … Daniel Fett
- [OAUTH-WG] Re: Second WGLC for SD-JWT: 41 issues … Paul Bastian
- [OAUTH-WG] Re: Second WGLC for SD-JWT: 41 issues … Brian Campbell
- [OAUTH-WG] Re: Second WGLC for SD-JWT: 41 issues … Denis