[OAUTH-WG] Re: draft-jones-oauth-rfc7523bis published and questions to the working group

This is a good discussion with multiple facets. It’s what WG discussions should be. In the JWT authorization grant case, I see our options as being to either definitively fixing the problem or having the authorization grant be a special case with different audience values than the cases we do

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

Hi Paul, Apparently my review (based on -06) and your publication of -07 happened at about the same time. I will reread -07 and provide my feedback soon. Regarding point 4, I wrote a quick test while having lunch that shows that a deflate (level=12) compressed bit-stream becomes much more efficie

[OAUTH-WG] Re: draft-jones-oauth-rfc7523bis published and questions to the working group

On Fri, Feb 7, 2025 at 7:37 PM Michael Jones wrote: > We agree on starting with a single document and on producing something > that addresses the issues in a timely and responsible manner. > > > > We disagree that the current document is correctly scoped to do so. > > > > As background, when aske

[OAUTH-WG] Re: [Technical Errata Reported] RFC7519 (8060)

Apologies Pieter, this fell "below the fold" in my inbox so to speak and I lost track of responding to it. Thanks for the proposed new "notes" for the errata, which I do think are sufficient now. In conjunction with that simple "corrected text" you had of "5. Verify the resulting JOSE Header accor

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

I obviously am in favor of adoption, as I believe we should do the work to close the identified security vulnerabilities in a timely manner. Thanks to all who worked on this doc with me prior to last week’s interim meeting. I responded to Brian’s critiques in the thread “Re: [OAUTH-WG] Re: dra

[OAUTH-WG] Re: draft-jones-oauth-rfc7523bis published and questions to the working group

We agree on starting with a single document and on producing something that addresses the issues in a timely and responsible manner. We disagree that the current document is correctly scoped to do so. As background, when asked, the Stuttgart security researchers who identified the vulnerability

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

As stated in the "[OAUTH-WG] Re: draft-jones-oauth-rfc7523bis published and questions to the working group " thread - I don't believe this draft is the right starting point. But if the WG decides otherwise, I sincerely hope

[OAUTH-WG] Re: draft-jones-oauth-rfc7523bis published and questions to the working group

Thanks for the work on this document Mike. Regarding the questions for the working group: 1. My preference is for a single document. 2. The scope of the changes should be constrained to only what is necessary to address the issue that brought us here, which is JWT Client Assertion Auth

[OAUTH-WG] Re: Status List Feature Request

„I have a preference for a single RFC covering all aspects related to Status List Tokens and hence covering end-entity X.509 PKCs, (in addition to SD-JWTs and SD-CWTs).” Fully agree The word attestation is meant in term of (Q)EAA and pubEAA – acc. Section 9 eIDAS. Von: Denis Gesendet: Freitag

[OAUTH-WG] Re: Status List Feature Request

Hi Steffen, In the sentences below, the use of the word "attestation" looks ambiguous, as it is commonly used in eIDAS 2.0 for EAAs. However, when considering eIDAS 2.0, PKCs used for electronic signatures purposes would be able to take advantage of Status List Tokens. I have a preference f

[OAUTH-WG] Re: Status List Feature Request

Hi Christian, My opinion has been posted yesterday at: https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/243 In a nutshell: Defining this extension in the current draft would be easier as the same document would be able to support "Referenced Tokens" encoded as JWT, CWT

[OAUTH-WG] Re: Status List Feature Request

As the Status List focus on revocation of attestations it directly affects the revocation of attestation signature. Means if OauthWG defines status list related to revocation of attestation but ignores the one on the signature of the attestions – this sounds a bit weird. Especially in case the s

[OAUTH-WG] Re: Status List Feature Request

That seems well beyond the scope of both the Status List draft and the OAuth WG in general. On Fri, Feb 7, 2025 at 2:57 PM Christian Bormann wrote: > Hi all, > > > > While going through the feedback and issues on github, there was one > bigger discussion point that we would like to bring to the

[OAUTH-WG] Status List Feature Request

Hi all, While going through the feedback and issues on github, there was one bigger discussion point that we would like to bring to the mailing list. Steffen Schwalm asked for support for X.509 Certificate revocation with the Status List - in that case the Status List describing the status of an X.

[OAUTH-WG] Re: Comments on two closed issues on github about draft-ietf-oauth-status-list

Hi Denis, towards point a) We think it makes sense to have this separation, we also make us of it in the privacy consideration Section 12.6 and implementation consideration Section 13.5. Furthermore we think it's not required to have multiple endpoints (status list language `uri`) as there ar

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

+1 for adoption On 06.02.2025 17:36, Rifaat Shekh-Yusef wrote: All, This is a call for adoption for the *RFC7523bis* draft that was discussed recently during the last interim meeting: https://datatracker.ietf.org/doc/draft-jones-oauth-rfc7523bis/ Remember that *adoption* does *not* mean a do

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

Hi, I fully support the adoption best, G Il giorno gio 6 feb 2025 alle ore 17:37 Rifaat Shekh-Yusef < rifaat.s.i...@gmail.com> ha scritto: > All, > > This is a call for adoption for the *RFC7523bis* draft that was discussed > recently during the last interim meeting: > https://datatracker.ietf.o