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 >> >
- [OAUTH-WG] Call for adoption - SD-JWT Rifaat Shekh-Yusef
- Re: [OAUTH-WG] Call for adoption - SD-JWT Dick Hardt
- Re: [OAUTH-WG] Call for adoption - SD-JWT Brian Campbell
- Re: [OAUTH-WG] Call for adoption - SD-JWT Jaimandeep Singh
- Re: [OAUTH-WG] Call for adoption - SD-JWT Warren Parad
- Re: [OAUTH-WG] Call for adoption - SD-JWT Torsten Lodderstedt
- Re: [OAUTH-WG] Call for adoption - SD-JWT Daniel Fett
- Re: [OAUTH-WG] Call for adoption - SD-JWT Steinar Noem
- Re: [OAUTH-WG] Call for adoption - SD-JWT Leif Johansson
- Re: [OAUTH-WG] Call for adoption - SD-JWT Jaromir Talir
- Re: [OAUTH-WG] Call for adoption - SD-JWT David Waite
- Re: [OAUTH-WG] Call for adoption - SD-JWT Mike Jones
- Re: [OAUTH-WG] Call for adoption - SD-JWT Giuseppe De Marco
- Re: [OAUTH-WG] Call for adoption - SD-JWT Wayne Chang
- Re: [OAUTH-WG] Call for adoption - SD-JWT Joseph Heenan
- Re: [OAUTH-WG] Call for adoption - SD-JWT Neil Madden
- Re: [OAUTH-WG] Call for adoption - SD-JWT David Chadwick
- Re: [OAUTH-WG] Call for adoption - SD-JWT Warren Parad
- Re: [OAUTH-WG] Call for adoption - SD-JWT David Chadwick
- Re: [OAUTH-WG] Call for adoption - SD-JWT Giuseppe De Marco
- Re: [OAUTH-WG] Call for adoption - SD-JWT David Chadwick
- Re: [OAUTH-WG] Call for adoption - SD-JWT Aaron Parecki
- Re: [OAUTH-WG] Call for adoption - SD-JWT David Chadwick
- Re: [OAUTH-WG] Call for adoption - SD-JWT Warren Parad
- Re: [OAUTH-WG] Call for adoption - SD-JWT Neil Madden
- Re: [OAUTH-WG] Call for adoption - SD-JWT Warren Parad
- Re: [OAUTH-WG] Call for adoption - SD-JWT Vittorio Bertocci
- Re: [OAUTH-WG] Call for adoption - SD-JWT Kristina Yasuda
- Re: [OAUTH-WG] Call for adoption - SD-JWT Warren Parad
- Re: [OAUTH-WG] Call for adoption - SD-JWT Torsten Lodderstedt
- Re: [OAUTH-WG] Call for adoption - SD-JWT Warren Parad
- Re: [OAUTH-WG] Call for adoption - SD-JWT Torsten Lodderstedt
- Re: [OAUTH-WG] Call for adoption - SD-JWT Torsten Lodderstedt
- Re: [OAUTH-WG] Call for adoption - SD-JWT Warren Parad
- Re: [OAUTH-WG] Call for adoption - SD-JWT Torsten Lodderstedt
- Re: [OAUTH-WG] Call for adoption - SD-JWT Warren Parad
- Re: [OAUTH-WG] Call for adoption - SD-JWT Neil Madden
- Re: [OAUTH-WG] Call for adoption - SD-JWT David Chadwick
- Re: [OAUTH-WG] Call for adoption - SD-JWT Torsten Lodderstedt
- Re: [OAUTH-WG] Call for adoption - SD-JWT Warren Parad
- Re: [OAUTH-WG] Call for adoption - SD-JWT Torsten Lodderstedt
- Re: [OAUTH-WG] Call for adoption - SD-JWT Pieter Kasselman
- Re: [OAUTH-WG] Call for adoption - SD-JWT Jaromir Talir
- Re: [OAUTH-WG] Call for adoption - SD-JWT David Chadwick
- Re: [OAUTH-WG] Call for adoption - SD-JWT Warren Parad
- Re: [OAUTH-WG] Call for adoption - SD-JWT Kristina Yasuda
- Re: [OAUTH-WG] Call for adoption - SD-JWT David Chadwick
- Re: [OAUTH-WG] Call for adoption - SD-JWT David Chadwick
- Re: [OAUTH-WG] Call for adoption - SD-JWT David Chadwick
- Re: [OAUTH-WG] Call for adoption - SD-JWT Mike Jones
- Re: [OAUTH-WG] Call for adoption - SD-JWT Neil Madden
- Re: [OAUTH-WG] Call for adoption - SD-JWT Giuseppe De Marco
- Re: [OAUTH-WG] Call for adoption - SD-JWT David Chadwick
- Re: [OAUTH-WG] Call for adoption - SD-JWT Torsten Lodderstedt
- Re: [OAUTH-WG] Call for adoption - SD-JWT David Chadwick
- Re: [OAUTH-WG] Call for adoption - SD-JWT Jaimandeep Singh
- Re: [OAUTH-WG] Call for adoption - SD-JWT Daniel Fett
- Re: [OAUTH-WG] Call for adoption - SD-JWT Warren Parad
- Re: [OAUTH-WG] Call for adoption - SD-JWT Daniel Fett
- Re: [OAUTH-WG] Call for adoption - SD-JWT Warren Parad
- Re: [OAUTH-WG] Call for adoption - SD-JWT Daniel Fett
- Re: [OAUTH-WG] Call for adoption - SD-JWT Warren Parad
- Re: [OAUTH-WG] Call for adoption - SD-JWT Kristina Yasuda
- Re: [OAUTH-WG] Call for adoption - SD-JWT David Waite
- Re: [OAUTH-WG] Call for adoption - SD-JWT Warren Parad
- Re: [OAUTH-WG] Call for adoption - SD-JWT Warren Parad
- Re: [OAUTH-WG] Call for adoption - SD-JWT Kristina Yasuda
- Re: [OAUTH-WG] Call for adoption - SD-JWT Kushal Das
- Re: [OAUTH-WG] Call for adoption - SD-JWT Nat Sakimura
- Re: [OAUTH-WG] Call for adoption - SD-JWT Christian Paquin
- Re: [OAUTH-WG] Call for adoption - SD-JWT Brian Campbell
- Re: [OAUTH-WG] Call for adoption - SD-JWT Rifaat Shekh-Yusef
- Re: [OAUTH-WG] Call for adoption - SD-JWT Jaimandeep Singh
- Re: [OAUTH-WG] Call for adoption - SD-JWT Kristina Yasuda