[OAUTH-WG] Re: new proposal on challenge endpoint for attestation-based client authentication

The proposed challenge fetching mechanism makes sense to me, also based on our experience and discussions in OpenID4VC work in OIDF DCP WG. Thank you for this work, Kristina On Tue, Jun 17, 2025 at 5:57 PM Paul Bastian wrote: > Dear OAuth WG, > > after discussions about the nonce fetching mech

[OAUTH-WG] Re: Second WGLC for Token Status List

I support moving this specification forward. It is a crucial building block for lifecycle management of different tokens/credentials. On Tue, Apr 1, 2025 at 9:42 PM ANTHONY NADALIN wrote: > support this moving forward as we need this in ISO > > Get Outlook for Android >

[OAUTH-WG] Re: IPR Disclosure - Selective Disclosure for JWTs (SD-JWT)

many times yes! Thank you, Hannes. On Mon, Feb 10, 2025 at 2:20 PM Brian Campbell wrote: > Yes, of course. > > On Mon, Feb 10, 2025 at 5:26 AM Daniel Fett 40danielfett...@dmarc.ietf.org> wrote: > >> Yes, of course :-) >> >> -Daniel >> Am 10.02.25 um 13:03 schrieb Hannes Tschofenig: >> >> Brian,

[OAUTH-WG] Re: IPR Disclosure - Selective Disclosure for JWTs (SD-JWT)

Thank you very much, Hannes! I am not aware of any IPR associated with the document. On Sun, Feb 9, 2025 at 4:03 PM Brian Campbell wrote: > Thanks Hannes, > > I am not aware of any IPR associated with the document. > > On Sun, Feb 9, 2025 at 6:59 AM Hannes Tschofenig < > hannes.tschofe...@h-brs

[OAUTH-WG] Re: SD-JWT and Unlinkability

on its own and not require > other documents to do something useful. > > On Tue, Sep 24, 2024 at 10:01 AM Kristina Yasuda > wrote: > >> And my point is that SD-JWT document is a wrong place to look for such >> actionable language. The intention is not and should not

[OAUTH-WG] Re: SD-JWT and Unlinkability

he reader is supposed to take guidance from other documents, then you > should refer to those other documents, but I would have that in addition to > specific guidance. > > On Mon, Sep 23, 2024 at 10:03 PM Kristina Yasuda > wrote: > >> > there is no guidance on how many to iss

[OAUTH-WG] Re: Explicit typing of SD-JWTs (was SD-JWT architecture feedback)

The reason why section 10.11 recommends JWT type to be defined by the use-case is because SD-JWT specification is not meant only for one kind of use-case/architecture. SD-JWT document does not define a stand alone credential format for issuer-holder-verifier model, SD-JWT VC document is intended to

[OAUTH-WG] Re: SD-JWT and Unlinkability

> there is no guidance on how many to issue, nor how a holder chooses when to reissue the same ones > the question about users randomly selecting some to store and some to reject. These are great points, however, just like JWT/JWS specifications do not define how to manage the lifecycle of those,

[OAUTH-WG] Re: Call for adoption - PIKA

I support adoption, too. Best, Kristina On Mon, Sep 9, 2024 at 4:55 PM Pieter Kasselman wrote: > I support adoption. > > > > *From:* Rifaat Shekh-Yusef > *Sent:* Tuesday 3 September 2024 11:47 > *To:* oauth > *Subject:* [OAUTH-WG] Call for adoption - PIKA > > > > All, > > > > As per the discus

[OAUTH-WG] Re: Review of draft-ietf-oauth-selective-disclosure-jwt-10

Thank you very much, Mike. Majority of your comments have been incorporated in this PR https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/452, which has been merged. Below, in bold, please find explanations for the points that have not been reflected. We appreciate your review. Best

[OAUTH-WG] Re: Call for adoption - PIKA

Sorry to chime in late as well… I support adoption of this draft. I have read the thread and to me it seems like there is a mechanism being proposed that solved a concrete problem in a simple manner. Some of the discussion can happen after the draft is adopted. Best, Kristina On Wed, Jun 26, 2024

Re: [OAUTH-WG] IETF119 - Call for topics

Hi, Editors would like to discuss SD-JWT progress. I would also like to discuss client attestation draft, it would be good to have more time than last time to be able to have substantial discussion because I feel like there are few issues that would benefit from that – mainly client authentica

Re: [OAUTH-WG] [media-types] A Discussion of Multiple Suffixes

Hi, To respond to one of the comments, registration of +sd-jwt is being requested in SD-JWT specification [1]. One comment, based on what I read above, I question the need for +ld and +ld+json, especially if +ld alone is not useful as Alexey pointed out. Instead, why registering one +ld-json m

Re: [OAUTH-WG] Call for adoption - Identity Chaining

I support adoption. Get Outlook for iOS From: OAuth on behalf of Pieter Kasselman Sent: Wednesday, November 15, 2023 8:41:28 AM To: rifaat.s.ietf ; oauth Subject: Re: [OAUTH-WG] Call for adoption - Identity Chaining I support adoption.

Re: [OAUTH-WG] [External Sender] Call for adoption - Transaction Tokens

I support adoption too. From: OAuth On Behalf Of George Fletcher Sent: Tuesday, November 14, 2023 6:48 AM To: rifaat.s.ietf Cc: oauth Subject: Re: [OAUTH-WG] [External Sender] Call for adoption - Transaction Tokens You don't often get email from george.fletcher=40capitalone@dmarc.ietf.org

Re: [OAUTH-WG] Relationship between SPICE and OAuth

Moving a somewhat mature draft to another WG is highly likely slow down the progress on that document: there is no guarantee there will be an overlap in the WG members, there is a risk that discussions that were already resolved to be re-opened to be, etc. I consider SD-JWT closer to a finish l

Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List

> I find the new name "OAuth Status List" confusing. While I understand wanting > to remove "JWT" and "CWT" from the name, I was not aware of that discussion > during the call for adoption. I would suggest renaming this to "OAuth Token > Status List" instead. I would suggest removing “OAuth” fr

Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List

I support adoption, but we also implemented a similar spec and have similar observations/reservations as Orie. Really hope this draft can build up on the learnings to date and be a significant improvement.. From: OAuth On Behalf Of Orie Steele Sent: Saturday, September 30, 2023 6:10 AM To: rifa

Re: [OAUTH-WG] OAuth and JWT/VC documents

@dmarc.ietf.org; Kristina Yasuda ; oauth ; Paul Bastian ; Christian Bormann Subject: Re: [OAUTH-WG] OAuth and JWT/VC documents Inline: On Fri, Sep 29, 2023 at 12:05 PM Brian Campbell mailto:bcampb...@pingidentity.com>> wrote: If I might offer an observation... The draft-looker-oauth-jwt-cwt-statu

Re: [OAUTH-WG] SD-JWT does not meet standard security definitions

First of all, BBS and SD-JWT are not comparable apple to apple. BBS is a signature scheme and it needs to be combined with few other things like JWP or BBS data integrity proof type (https://www.w3.org/TR/vc-di-bbs/) with JSON-LD payload. While SD-JWT is a mechanism that can be used with any cry

Re: [OAUTH-WG] Call for adoption - Attestation-Based Client Authentication

I support adoption. From: OAuth on behalf of Rifaat Shekh-Yusef Sent: Saturday, July 29, 2023 12:27:14 PM To: oauth Subject: [OAUTH-WG] Call for adoption - Attestation-Based Client Authentication All, This is an official call for adoption for the Attestation-

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

I support adoption. From: OAuth on behalf of Rifaat Shekh-Yusef Sent: Saturday, July 29, 2023 12:25:16 PM To: oauth Subject: [OAUTH-WG] Call for adoption - SD-JWT-based Verifiable Credentials All, This is an official call for adoption for the SD-JWT-based Ver

Re: [OAUTH-WG] [GNAP] Publication has been requested for draft-ietf-gnap-core-protocol-15

I would like to get some context too. After WGLC that started on Jan-07, I could only find one email on the mailing list.

Re: [OAUTH-WG] Request for Feedback on "SD-JWT VC" Draft Specification

+1 to work on this draft. It would drive interoperability and bring clarity to a very important topic - how to use SD-JWT in a three party model (issuer-wallet-verifier), because SD-JWT is designed to be used with various applications not limited to three party model. Best, Kristina From: OAut

Re: [OAUTH-WG] Call for adoption: Cross-Device Flows

I support adoption of this document too. Kristina From: OAuth On Behalf Of Aaron Parecki Sent: Wednesday, November 16, 2022 5:16 PM To: OAuth WG Subject: Re: [OAUTH-WG] Call for adoption: Cross-Device Flows I support adoption of this document. Aaron On Wed, Nov 16, 2022 at 7:52 AM Mike Jones

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

Thank you very much, everyone, for the feedback! Really looking forward to keep working on the document. Kindest Regards, Kristina & Daniel From: OAuth On Behalf Of Jaimandeep Singh Sent: Friday, August 12, 2022 5:44 AM To: Rifaat Shekh-Yusef Cc: oauth Subject: Re: [OAUTH-WG] Call for adoption

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

issuer issuing usbsets of JWTs vs SD-JWT approach in a decoupled flow. https://mailarchive.ietf.org/arch/msg/oauth/_nf1_4GOefLtjMz2uvzdd0E3D_0/ From: Warren Parad Sent: Friday, August 5, 2022 1:41 PM To: Kristina Yasuda Cc: Warren Parad ; Daniel Fett ; oauth@ietf.org Subject: Re: [OAUTH-WG]

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

Yes, SD-JWT is not complete and that’s exactly why we are asking for a WG adoption. The questions you are asking are better answered in the WG, post-adoption. Thank you, Kristina PS. Offline claim transmission is not the only “feature” of SD-JWT for all of the reasons that have been previously

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

Maybe - If we want to force a Client to make a network call every time it receives a request to present a credential, while there is an alternative approach that allows the Client to generate on its own a presentation response with a required subset of claims. But why would we want to do that?

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

I support adoption. To add some color. One of the use-cases is a flow where issuance of a user credential (collection of user claims) is decoupled from presentation (where both issuance and presentation of a user credential are done using extensions of OAuth flows). The goal of this decoupling

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

Hi Nikos, Regarding the example 4, the way vc-data-model v1.1 has defined mapping of a data-model into a JWT (https://www.w3.org/TR/vc-data-model/#json-web-token), there are (roughly) three types of claims in a JWT-VC. 1) newly defined `vc` claim that includes all properties of the vc-data-mode

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

ot;, while optional claims are hashed and included in "sd_digests". Best, Kristina From: David Chadwick Sent: Friday, June 24, 2022 2:16 AM To: Kristina Yasuda ; oauth@ietf.org Subject: Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT) Hi Kristina Yes I realise that if the RP k

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

Hi David, Thank you for the feedback. Blinding claim names has been considered. Here is the issue: https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/3 We made a choice not to hash claim names because SD-JWT already reveals information about the issuer and the schema, and reveali

Re: [OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-jwk-thumbprint-uri-02: (with COMMENT)

Hi Lars, https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-03.html addressing your comment regarding inclusivity has been published. Thank you! Kristina -Original Message- From: Kristina Yasuda Sent: Wednesday, June 1, 2022 10:22 PM To: 'Lars Eggert' ; Th

Re: [OAUTH-WG] Warren Kumari's No Objection on draft-ietf-oauth-jwk-thumbprint-uri-02: (with COMMENT)

Hi Warren, Thank you for your feedback. Appreciate it! Best, Kristina -Original Message- From: Warren Kumari via Datatracker Sent: Wednesday, June 1, 2022 10:13 PM To: The IESG Cc: draft-ietf-oauth-jwk-thumbprint-...@ietf.org; oauth-cha...@ietf.org; oauth@ietf.org; rifaat.s.i...@gmai

Re: [OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-jwk-thumbprint-uri-02: (with COMMENT)

Hi Lars, Thank you for the review. We will change "considered invalid" to "not considered valid" when we publish the next draft. Regarding your reference to the Simplified BSD License, could you please clarify what you meant since https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprin

Re: [OAUTH-WG] Call for adoption - Step-up Authentication

I support adoption. Kristina From: OAuth On Behalf Of Vladimir Dzhuvinov Sent: Monday, May 2, 2022 5:30 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Call for adoption - Step-up Authentication +1 for adoption Vladimir Dzhuvinov On 26/04/2022 13:46, Rifaat Shekh-Yusef wrote: This is a call for

Re: [OAUTH-WG] AD Review of draft-ietf-oauth-jwk-thumbprint-uri-01

Hi Roman, Thank you very much for the comments. We will incorporate them in the next revision. Best, Kristina -Original Message- From: OAuth On Behalf Of Roman Danyliw Sent: Monday, April 25, 2022 1:08 PM To: oauth@ietf.org Subject: [OAUTH-WG] AD Review of draft-ietf-oauth-jwk-thumbprint

Re: [OAUTH-WG] JWK Thumbprint URI - IPR Disclosure

Hi, I am also not aware of any IPR that pertains to this specification. Best, Kristina From: OAuth on behalf of Mike Jones Sent: Friday, April 1, 2022 8:13 AM To: Rifaat Shekh-Yusef; oauth Subject: Re: [OAUTH-WG] JWK Thumbprint URI - IPR Disclosure I am not awa

Re: [OAUTH-WG] Second WGLC for JWK Thumbprint URI document

Thank you for the great comments received during the first WGLC. They significantly improved this simple document - especially the Security Considerations section. I support the publication, and looking forward to addressing the comments received during the second WGLC, if any. Kristina From

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

Hi All, Thank you very much for the constructive feedback. We have tried to address the WGLC comments received to date with the latest draft published at https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwk-thumbprint-uri-01. Following are updates made to the document: - Added security co

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

Thank you, Brian, DW and Aaron for the references. Mike and I discussed this and we would like to - Make SHA-256 the mandatory to implement algorithm, to guarantee interoperability (as suggested by DW). - Use the "Named Information Hash Algorithm Registry" as the source of a string hash algorit

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

Hi David, I think your comments below apply to the choices made in another specification (SIOP v2 in OIDF), rather than this IETF draft we are discussing. I've seen you opened an issue in the OpenID Connect WG Bitbucket. Let's discuss there whether SIOP v2 should use JWK Thumbprint URI. Best, K

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

I support publication of JWK Thumbprint URI specification. Kristina From: OAuth On Behalf Of Vladimir Dzhuvinov Sent: Wednesday, February 2, 2022 7:20 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document +1 in support for a jkt URI RFC Vladimir Dzhuvinov On 02/02