[OAUTH-WG] Re: Combining Step Up Auth mechanism with RAR

geo...@practicalidentity.com<mailto:geo...@practicalidentity.com> mailto:geo...@practicalidentity.com>> Date: Tuesday, 18 March 2025 at 12:17 To: Kai Lehmann mailto:kai.lehmann=401und1...@dmarc.ietf.org>> Cc: oauth@ietf.org<mailto:oauth@ietf.org> mailto:oauth@ietf.org>&g

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

Dear working group, we just released -10 for Token Status List to incorporate the latest changes as presented at IETF 122 and the feedback that we got from IANA review. Please review https://datatracker.ietf.org/doc/html/draft-ietf-oauth-status-list-10 for the 2. WGLC. Best regards, Paul

[OAUTH-WG] Re: Combining Step Up Auth mechanism with RAR

calidentity.com>> Date: Tuesday, 18 March 2025 at 12:17 To: Kai Lehmann mailto:kai.lehmann=401und1...@dmarc.ietf.org>> Cc: oauth@ietf.org<mailto:oauth@ietf.org> mailto:oauth@ietf.org>> Subject: [EXT][OAUTH-WG] Re: Combining Step Up Auth mechanism with RAR CAUTION: This message is fro

[OAUTH-WG] Re: Combining Step Up Auth mechanism with RAR

o:geo...@practicalidentity.com> mailto:geo...@practicalidentity.com>> Date: Tuesday, 18 March 2025 at 12:17 To: Kai Lehmann mailto:kai.lehmann=401und1...@dmarc.ietf.org>> Cc: oauth@ietf.org<mailto:oauth@ietf.org> mailto:oauth@ietf.org>> Subject: [EXT][OAUTH-WG] Re:

[OAUTH-WG] Re: Combining Step Up Auth mechanism with RAR

geo...@practicalidentity.com<mailto:geo...@practicalidentity.com> mailto:geo...@practicalidentity.com>> Date: Tuesday, 18 March 2025 at 12:17 To: Kai Lehmann mailto:kai.lehmann=401und1...@dmarc.ietf.org>> Cc: oauth@ietf.org<mailto:oauth@ietf.org> mailto:oauth@ietf.org>>

[OAUTH-WG] Re: Combining Step Up Auth mechanism with RAR

r_authentication error code, > it does not preclude future specifications or profiles from defining their > usage with other error codes." You could extend the specification with > custom error codes and parameters… > > > > Best regards. > > > > > >

[OAUTH-WG] Re: Combining Step Up Auth mechanism with RAR

or codes." You could extend the specification with custom error codes and parameters… Best regards. From: geo...@practicalidentity.com Date: Tuesday, 18 March 2025 at 12:17 To: Kai Lehmann Cc: oauth@ietf.org Subject: [EXT][OAUTH-WG] Re: Combining Step Up Auth mechanism with RAR CAUTION

[OAUTH-WG] Re: Combining Step Up Auth mechanism with RAR

Hi Kai, I recently saw a proposal to extend the Step-Up mechanism by returning a body with the WWW-Authenticate header. This could work for what you are looking to do in returning a RAR authorization_details JSON object that the client can then pass to the AS. My only concern with this is wheth

[OAUTH-WG] Re: [RFC7523] JWT-SVID as a client_assertion

Hi Dmitry Great question. The Transaction Token draft does allow for the use of SPIFFE SVIDs (section 7.6 of [1]) when authenticating clients, so this is definitely functionality we believe should be supported. JWT-SVID as Client Authentication --- The

[OAUTH-WG] Re: Httpdir last call review of draft-ietf-oauth-browser-based-apps-22

Hi Aaron, I've trimmed out the bits where your fixes look great. Overall, the draft is still in good shape. Just a few small follow-ups. On Sun, Mar 2, 2025, at 07:14, Aaron Parecki wrote: > We've added a variation of this paragraph: > https://www.ietf.org/archive/id/draft-ietf-oauth-browser-

[OAUTH-WG] Re: Transaction Token Implementations

tokenetes.io makes it easy for Kubernetes environments to adopt TraTs. On Mon, Mar 10, 2025 at 2:32 PM wrote: > Hi, > > The Transaction Token editors are looking for implementations of the OAuth > Transaction Tokens draft specification. If you have implemented the draft > spec, please respond to

[OAUTH-WG] Re: DPoP: which error code for ath or public key mismatch?

Hello Thomas, I believe Figure 16 (which is not normative) could be updated with an errata to use invalid_dpop_proof. S pozdravem, *Filip Skokan* On Sat, 8 Mar 2025 at 18:46, Thomas Broyer wrote: > Hi, > > I'm looking at DPoP (RFC9449) and wondering which error code should be > used by a reso

[OAUTH-WG] Re: Status List Feature Request

) needed, and issue occurs for AES/ASeal too. Best Steffen *Von:*Christian Bormann *Gesendet:* Donnerstag, 27. Februar 2025 16:41 *An:* Michael Jones ; Brian Campbell ; Filip Skokan *Cc:* oauth *Betreff:* [OAUTH-WG] Re: Status List Feature Request *Caution:* This email originated from

[OAUTH-WG] Re: Regarding issuing refresh tokens for PKCE based OAuth grant flow

Srinivas, I think what you're getting at is that you don't want to issue a refresh token to an unauthenticated client, for example a browser client where you can't protect the secret. As Aaron alluded, PKCE is like a state param--it's never a bad idea. Have you considered using DCR for the browse

[OAUTH-WG] Re: Regarding issuing refresh tokens for PKCE based OAuth grant flow

> how this works for mobile clients as it requires pre established trust) and > adoptions will not be an issue if enforced/required. > > > > Thanks, > > -Srinivas > > > > *From: *Thumilan > *Date: *Tuesday, March 4, 2025 at 8:48 AM > *To: *Srinivas Challa >

[OAUTH-WG] Re: Regarding issuing refresh tokens for PKCE based OAuth grant flow

established trust) and adoptions will not be an issue if enforced/required. Thanks, -Srinivas From: Thumilan Date: Tuesday, March 4, 2025 at 8:48 AM To: Srinivas Challa Cc: Aaron Parecki , oauth@ietf.org Subject: Re: [OAUTH-WG] Re: Regarding issuing refresh tokens for PKCE based OAuth grant flow

[OAUTH-WG] Re: Regarding issuing refresh tokens for PKCE based OAuth grant flow

Hi Srinivas, Using PKCE enhances security for public clients when acquiring tokens via authorization code grants. Regarding your question about using a refresh token (RT) to obtain an access token (AT), I believe you're asking about securing the token endpoint for public clients. To address this,

[OAUTH-WG] Re: Regarding issuing refresh tokens for PKCE based OAuth grant flow

Hi, Thanks for the responses. I agree on the recommendation that all clients should use PKCE. Let me clarify the question is about public clients that cannot have a client_secret getting refresh tokens without providing client credentials. Based on the response, looks like as long as we use one

[OAUTH-WG] Re: Regarding issuing refresh tokens for PKCE based OAuth grant flow

Hi Srinivas, There is no connection between PKCE and refresh tokens. All OAuth clients should be using PKCE. https://www.rfc-editor.org/rfc/rfc9700.html#section-2.1.1 If a client doesn't have client credentials, it can still use refresh tokens, but it is recommended that the AS issue one-time us

[OAUTH-WG] Re: Regarding issuing refresh tokens for PKCE based OAuth grant flow

Hi, You could perhaps use private_key_jwt from the OpenID specs: https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication Yours, Emelia > On 3 Mar 2025, at 20:06, Srinivas Challa > wrote: > > Hi, > I am from Workday working on the OAuth feature. We currently support PKCE >

[OAUTH-WG] Re: Rtgdir last call review of draft-ietf-oauth-browser-based-apps-22

Thanks for your review, Matthew, we appreciate the time! On Tue, Feb 4, 2025 at 5:13 AM Matthew Bocci via Datatracker < nore...@ietf.org> wrote: > Reviewer: Matthew Bocci > Review result: Ready > > Hi, > > I am the designated Routing Area Directorate reviewer for this draft. The > draft > provid

[OAUTH-WG] Re: Artart last call review of draft-ietf-oauth-browser-based-apps-22

Thanks for your review, Marc, we've published a new version addressing your feedback. https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-23.html You can also see the more detailed commits and discussion on GitHub: https://github.com/oauth-wg/oauth-browser-based-apps/issues/72 Re

[OAUTH-WG] Re: Secdir last call review of draft-ietf-oauth-browser-based-apps-22

Thanks for your review, Watson. We've published a new version of the draft addressing your and others' feedback. https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-23.html You can also see the more detailed commits and discussion on GitHub: https://github.com/oauth-wg/oauth-brows

[OAUTH-WG] Re: Httpdir last call review of draft-ietf-oauth-browser-based-apps-22

Thanks for your thorough review Martin! We've published version 23 of the draft addressing your feedback. https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-23.html Notes on your feedback are inline. You can also see the specific feedback and commits by following this GitHub issu

[OAUTH-WG] Re: Status List Feature Request

I agree with Hannes that X.509 extensions need to be done in LAMPS, because that is where the expertise is. thanks, -rohan On Wed, Feb 26, 2025, 08:48 Hannes Tschofenig wrote: > (chair hat off) > > Hi Filip, Hi all, > > this sounds like feature creep to me. I brought this work on status > lists

[OAUTH-WG] Re: I-D Action: draft-ietf-oauth-selective-disclosure-jwt-17.txt

Below is my feedback about draft-ietf-oauth-selective-disclosure-jwt-17, grouped into four categories (A to D). Six issues have been opened about 3 weeks ago, but no reply has been posted on them on github. There are still open. A – *KB-JWT replay detection* a) About KB-JWT replay detectio

[OAUTH-WG] Re: Status List Feature Request

Ayabu-aE4ghyk/edit#slide=id.g33a15d709f8_0_331 Best Regards, Christian *From: *Michael Jones *Date: *Wednesday, 26. February 2025 at 18:05 *To: *Brian Campbell , Filip Skokan *Cc: *Christian Bormann , oauth *Subject: *RE: [OAUTH-WG] Re: Status List Feature Request X.509 already has it

[OAUTH-WG] Re: Status List Feature Request

=id.g33a15d709f8_0_331 Best Regards,Christian  From: Michael Jones Date: Wednesday, 26. February 2025 at 18:05To: Brian Campbell , Filip Skokan Cc: Christian Bormann , oauth Subject: RE: [OAUTH-WG] Re: Status List Feature RequestX.509 already has its own revocation infrastructure (in fact, more than one kind!).  We

[OAUTH-WG] Re: Status List Feature Request

Skokan Cc: Christian Bormann ; oauth Subject: [OAUTH-WG] Re: Status List Feature Request I concur with Filip's perspective. On Wed, Feb 26, 2025, 4:21 PM Filip Skokan mailto:panva...@gmail.com>> wrote: I believe it is inappropriate and wildly out of scope for an oauth document to d

[OAUTH-WG] Re: IETF122 Call for topics

uld be fine. > > > > Thanks, > > -- Mike > > > > *From:* Rifaat Shekh-Yusef > *Sent:* Sunday, February 16, 2025 6:51 AM > *To:* oauth > *Subject:* [OAUTH-WG] Re: IETF122 Call for topics > > > > A

[OAUTH-WG] Re: Status List Feature Request

I concur with Filip's perspective. On Wed, Feb 26, 2025, 4:21 PM Filip Skokan wrote: > I believe it is inappropriate and wildly out of scope for an oauth > document to define X.509 extensions, which IIUC is needed in order to > define the Status Claim for X.509? The important thing to make sure

[OAUTH-WG] Re: Status List Feature Request

(chair hat off) Hi Filip, Hi all, this sounds like feature creep to me. I brought this work on status lists to the attention of the IETF LAMPS group, and there was zero interest from the PKI community in this type of solution. The PKIX community already has a wide range of established solutio

[OAUTH-WG] Re: Status List Feature Request

I believe it is inappropriate and wildly out of scope for an oauth document to define X.509 extensions, which IIUC is needed in order to define the Status Claim for X.509? The important thing to make sure is that the document does not preclude a future X.509 extension being drafted (wherever its ap

[OAUTH-WG] Re: OAuth Token Status List -08 and further discussions

Hi Russ and Tim, In your quality of co-chairs of the LAMPS WG, I forward you a message posted on the OAuth mailing list. Your opinion about it would be appreciated. On 20/02/2025 Paul Bastian wrote: We've also resolved several issues in Github, one remaining issue is on the question, whethe

[OAUTH-WG] Re: Question about size limits for the OAuth state parameter

Maybe we could add a "reminder" line like: The client SHOULD consider browser URL length limits when creating the state parameter and leave sufficient buffer for the AS to attach additional parameters to the redirect_uri. Emelia, another possibility for you is to recommend clients to use POST, and

[OAUTH-WG] Re: Question about size limits for the OAuth state parameter

There is AFAIK still no limit specified in HTTP itself on the maximum header length, but individual servers (e.g. nginx) usually set their own server-specific limits (8k seems common, and is what nginx does): http://nginx.org/en/docs/http/ngx_http_core_module.html#large_client_header_buffers T

[OAUTH-WG] Re: Question about size limits for the OAuth state parameter

> Is there anything I've missed here? No, there is no upper limit defined. You can generally expect random values as well as larger JSON objects, even JWTs (e.g. as per https://datatracker.ietf.org/doc/html/draft-bradley-oauth-jwt-encoded-state-09 ). S pozdravem, *Filip Skokan* On Mon, 24 Feb 2

[OAUTH-WG] Re: Implementation Status of SD-JWT

Keycloak uses its own implementation of SD-JWT, kindly contributed by Adorsys: https://github.com/keycloak/keycloak/tree/main/core/src/main/java/org/keycloak/sdjwt - Dmitry On Sun, Feb 9, 2025 at 2:01 PM Hannes Tschofenig wrote: > Hi all, > > as part of the shepherd write-up for the SD-JWT docu

[OAUTH-WG] Re: Implementation Status of SD-JWT

Here's another implementation that I just recently learned about: https://github.com/openwallet-foundation-labs/multiformat-vc-ios On Sun, Feb 9, 2025 at 8:16 AM Brian Campbell wrote: > There's this very lightly curated list of implementations in the > repository > https://github.com/oauth-wg/o

[OAUTH-WG] Re: IETF122 Call for topics

:51 AM To: oauth Subject: [OAUTH-WG] Re: IETF122 Call for topics As per the preliminary agenda, the two OAuth WG sessions: 1. Tuesday at 13:00 - 15:00 2. Friday at 09:30 - 11:30 Make sure to send us your topics as soon as possible. Regards, Rifaat & Hannes On Sun, Feb 9, 2025 at 2:1

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

All, Based on the feedback on the mailing list, we think that there is strong support to adopt this document as a WG document. We note that Brian raised a few concerns, and we hope that these will be discussed during the meeting in Bangkok. Authors, Feel free to submit a new WG draft version th

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

I support adoption. LJ On 19 Feb 2025, at 14:51, David Brossard wrote: I also support adoption. David. On Tue, Feb 18, 2025 at 11:22 AM Joe DeCock mailto:40duendesoftware@dmarc.ietf.org>> wrote: I also support adoption. Cheers, Joe On Mon, Feb 17, 2025 at 12:29 PM Chuck Mortimore mai

[OAUTH-WG] Re: IETF122 Call for topics

Friday slot is 3:30 am for Germany. Best Regards,Christian From: Rifaat Shekh-Yusef Date: Sunday, 16. February 2025 at 15:51To: oauth Subject: [OAUTH-WG] Re: IETF122 Call for topicsAs per the preliminary agenda, the two OAuth WG sessions:1. Tuesday at 13:00 - 15:00 2. Friday at 09:30 - 11:30 Make

[OAUTH-WG] Re: late review of draft-ietf-oauth-selective-disclosure-jwt-15

Thanks Rohan, I've gone through the comments and incorporated a bunch of the feedback into this https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/553 On Thu, Feb 13, 2025 at 12:33 PM Rohan Mahy wrote: > Hi, > I have a few comments on Section 10.1. > > However, when the user only d

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

I also support adoption. David. On Tue, Feb 18, 2025 at 11:22 AM Joe DeCock wrote: > I also support adoption. > > Cheers, > Joe > > On Mon, Feb 17, 2025 at 12:29 PM Chuck Mortimore < > charliemortim...@gmail.com> wrote: > >> I am in favor of / support adoption. >> >> thanks, >> >> Chuck Mortimo

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

I also support adoption. Cheers, Joe On Mon, Feb 17, 2025 at 12:29 PM Chuck Mortimore wrote: > I am in favor of / support adoption. > > thanks, > > Chuck Mortimore > > >> >> >> *From:* Rifaat Shekh-Yusef >> *Sent:* Thursday, February 6, 2025 8:37 AM >> *To:* oauth >> *Subject:* [OAUTH-WG] Cal

[OAUTH-WG] Re: Review comments for SD-JWT

On Wed, Feb 12, 2025 at 12:50 PM Brian Campbell wrote: > >> suggest removing the "fnord" from Richard "fnord" Barnes >> > > > treatment for Richard Barnes (whom I highly respect) in the > Acknowledgements section of this draft was absolutely intentional and > factually grounded in the actual cont

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

I am in favor of / support adoption. thanks, Chuck Mortimore > > > *From:* Rifaat Shekh-Yusef > *Sent:* Thursday, February 6, 2025 8:37 AM > *To:* oauth > *Subject:* [OAUTH-WG] Call for adoption - RFC7523bis > > > > All, > > This is a call for adoption for the *RFC7523bis* draft that was disc

[OAUTH-WG] Re: IETF122 Call for topics

Thanks Rifaat, On behalf of myself and the various co-conspirators I would like to formally request agenda time at IETF 122 for presentation and discussion of the following documents currently under the remit of the OAUTH WG: Selective Disclosure for JWTs (SD-JWT) https://datatracker.ietf.org/doc

[OAUTH-WG] Re: IETF122 Call for topics

As per the preliminary agenda, the two OAuth WG sessions: 1. Tuesday at 13:00 - 15:00 2. Friday at 09:30 - 11:30 Make sure to send us your topics as soon as possible. Regards, Rifaat & Hannes On Sun, Feb 9, 2025 at 2:10 PM Rifaat Shekh-Yusef wrote: > All, > > Let us know if you have any topi

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

I support the adoption of *RFC7523bis* draft. On Fri, Feb 7, 2025 at 3:38 AM 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/

[OAUTH-WG] Re: late review of draft-ietf-oauth-selective-disclosure-jwt-15

Hi, I have a few comments on Section 10.1. However, when the user only discloses a birthdate 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. Regarding presentation unlinkability and verifie

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

Hi, I support adoption Thanks, Michael Fraser ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org

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

I support adoption On Thu, Feb 13, 2025 at 9:28 AM Nat Sakimura wrote: > +1 > > On Thu, Feb 13, 2025 at 10:33 PM Dave Tonge > wrote: > >> Hi >> >> I support adoption >> >> Thanks >> >> Dave >> >> On Thu, 6 Feb 2025 at 17:37, Rifaat Shekh-Yusef >> wrote: >> >>> All, >>> >>> This is a call for a

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

+1 On Thu, Feb 13, 2025 at 10:33 PM Dave Tonge wrote: > Hi > > I support adoption > > Thanks > > Dave > > On Thu, 6 Feb 2025 at 17:37, Rifaat Shekh-Yusef > wrote: > >> All, >> >> This is a call for adoption for the *RFC7523bis* draft that was >> discussed recently during the last interim meetin

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

Hi I support adoption Thanks Dave On Thu, 6 Feb 2025 at 17:37, 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/ > > Rememb

[OAUTH-WG] Re: [RFC7523] JWT-SVID as a client_assertion

So I’ve been thinking of similar > On 13 Feb 2025, at 01:24, Dmitry Telegin wrote: > > (Background: exploring the possibility of using SPIFFE as client > authentication mechanism at the Transaction Token service.) > > JWT-SVIDs, defined in SPIFFE, are regular JWTs, though with some > peculiar

[OAUTH-WG] Re: [RFC7523] JWT-SVID as a client_assertion

It sounds like the SPIRE server is the AS. Which means that it must already have the clients registered and house their public keys or else the client signing doesn't work. Does SPIRE somehow not have this information already? On Thu, Feb 13, 2025, 01:25 Dmitry Telegin wrote: > (Background: exp

[OAUTH-WG] Re: Review comments for SD-JWT

Thanks Hannes, I really appreciate the feedback and work towards moving this one foreword in the process. I've prepared this pull request https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/552 with updates aimed at addressing the review comments. Please take a look and let us know if

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

;>> needing to be ignored. >>>>> >>>>> This is contrary to step 7 in section 7.2 of RFC 7519 which requires that >>>>> the processing rules of RFC 7515 should be followed if the JWT is a JWS, >>>>> or the rules of RFC7516 shoul

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

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: draft-jones-oauth-rfc7523bis published and questions to the

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

prior to last week’s interim meeting. I responded to Brian’s critiques in the thread “Re: [OAUTH-WG] Re: draft-jones-oauth-rfc7523bis published and questions to the working group”. -- Mike *From:* Brian Campbell *Sent:* Friday

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

>>>> RFC 7515 nor RFC 7516 include any special provisions for only ignoring >>>> header parameters if they are specified as being ignored, but instead >>>> requires all header parameters to be ignored if they are not understood, >>>> except if the

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

larifies that JOSE Header parameters should be verified >>> according to RFC7515 (JWS) or RFC7516 (JWE). >>> >>> >>> >>> >>> From: Brian Campbell >>> <<bcampbell=40pingidentity@dmarc.ietf.org>> >>> Sent: Monday 12 Aug

[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)

Yes, of course. On Mon, Feb 10, 2025 at 5:26 AM Daniel Fett wrote: > Yes, of course :-) > > -Daniel > Am 10.02.25 um 13:03 schrieb Hannes Tschofenig: > > Brian, Daniel, Kristina, > > is it correct that you are willing to be listed as a document author? > > Ciao > Hannes > > > Am 09.02.2025 um 16

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

Yes, of course :-) -Daniel Am 10.02.25 um 13:03 schrieb Hannes Tschofenig: Brian, Daniel, Kristina, is it correct that you are willing to be listed as a document author? Ciao Hannes Am 09.02.2025 um 16:02 schrieb Brian Campbell: Thanks Hannes, I am not aware of any IPR associated with the

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

Brian, Daniel, Kristina, is it correct that you are willing to be listed as a document author? Ciao Hannes Am 09.02.2025 um 16:02 schrieb Brian Campbell: Thanks Hannes, I am not aware of any IPR associated with the document. On Sun, Feb 9, 2025 at 6:59 AM Hannes Tschofenig wrote: Hi

[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: IPR Disclosure - Selective Disclosure for JWTs (SD-JWT)

Hi Hannes, I am not aware of any IPR associated with the document. -Daniel Am 9. Februar 2025 16:02:43 MEZ schrieb Brian Campbell : >Thanks Hannes, > >I am not aware of any IPR associated with the document. > >On Sun, Feb 9, 2025 at 6:59 AM Hannes Tschofenig >wrote: > >> Hi Daniel, Kristina, B

[OAUTH-WG] Re: Implementation Status of SD-JWT

There's this very lightly curated list of implementations in the repository https://github.com/oauth-wg/oauth-selective-disclosure-jwt?tab=readme-ov-file#sd-jwt-implementations SD-JWT Implementations

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

Thanks Hannes, I am not aware of any IPR associated with the document. On Sun, Feb 9, 2025 at 6:59 AM Hannes Tschofenig wrote: > Hi Daniel, Kristina, Brian > > as part of the shepherd write-up, all authors of > > must confirm that any and all appropriate IPR disclosures required for full > con

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

ampbell=40pingidentity@dmarc.ietf.org>> >> Sent: Monday 12 August 2024 19:46 >> To: Pieter Kasselman >> <<pieter.kassel...@microsoft.com>> >> Cc: David Waite >> <<da...@alkaline-solutions.com>>; Paul Wouters >> <

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

, -- Mike From: Brian Campbell Sent: Friday, February 7, 2025 12:15 PM To: Michael Jones Cc: Filip Skokan ; oauth@ietf.org Subject: Re: [OAUTH-WG] Re: draft-jones-oauth-rfc7523bis published and questions to the working group On

[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

abilities in a timely manner with minimum disruption to deployments. > > > > -- Mike > > > > *From:* Brian Campbell > *Sent:* Friday, February 7, 2025 10:24 AM > *To:* Filip Skokan > *Cc:* Michael Jones

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

;pieter.kassel...@microsoft.com>> > Cc: David Waite > <<da...@alkaline-solutions.com>>; Paul Wouters > <<paul.wout...@aiven.io>>; RFC Errata System > <<rfc-edi...@rfc-editor.org>>; > prkassel...@gmail.com; oauth@ietf.org > Subject: Re: [OA

[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

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

h minimum disruption to deployments. -- Mike From: Brian Campbell Sent: Friday, February 7, 2025 10:24 AM To: Filip Skokan Cc: Michael Jones ; oauth@ietf.org Subject: Re: [OAUTH-WG] Re: draft-jones-oauth-rfc7523bis published and questions to the working

[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 <https://mailarchive.ietf.org/arch/msg/oauth/rZBbsr3TXkgK5bCrxRpdiRv2QVU/>" thread - I don't believe this draft is the right starting point. But if the WG decides otherw

[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

: Freitag, 7. Februar 2025 18:56 An: Steffen Schwalm Cc: oauth@ietf.org Betreff: Re: [OAUTH-WG] Re: Status List Feature Request Caution: This email originated from outside of the organization. Despite an upstream security check of attachments and links by Microsoft Defender for Office, a residual risk

[OAUTH-WG] Re: Status List Feature Request

list, this increase the effort for QTSP in eiDAS significantly) Means statulist would look a bit like a unfinished. But if somebody else would finish – also fine *Von:* Brian Campbell *Gesendet:* Freitag, 7. Februar 2025 16:19 *An:* Christian Bormann *Cc:* oauth *Betreff:* [OAUTH-WG] Re: S

[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

: Brian Campbell Gesendet: Freitag, 7. Februar 2025 16:19 An: Christian Bormann Cc: oauth Betreff: [OAUTH-WG] Re: Status List Feature Request Caution: This email originated from outside of the organization. Despite an upstream security check of attachments and links by Microsoft Defender for

[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] 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

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

I’m in favor of adoption. Thanks, -dhs -- Dean H. Saxe, CIDPRO (he/him) Principal Engineer Office of the CTO Beyond Identity dean.s...@beyondidentity.com On Feb 6, 2025 at 8:36:36 AM, Rifaat Shekh-Yusef wrote: > All, > > This is a call for adoption for the *RFC75

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

Hi Rohan, thanks for your feedback. Answers are inline: On 06.02.25 02:21, Rohan Mahy wrote: Hi, I support the overall goals of this document. I do *not* think the document was ready for WGLC; at minimum there are still plenty of TBDs and TODOs in the text. Below are some comments: We do not h

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

Hi, I support the overall goals of this document. I do *not* think the document was ready for WGLC; at minimum there are still plenty of TBDs and TODOs in the text. Below are some comments: 1. I would prefer we make the document standards track instead of informational. 2. You have to read throug

[OAUTH-WG] Re: Genart last call review of draft-ietf-oauth-browser-based-apps-22

Thanks for your edits Thomas! I've merged the PR. As for your BCP question, I am not totally certain about the implications of including it in BCP212, or whether it should be part of the new BCP240, or an entirely new BCP. I tried finding details about this in the various process RFCs/BCPs but I c

[OAUTH-WG] Re: I-D Action: draft-ietf-oauth-status-list-07.txt

Hi all, We are pleased to announce that draft -07 of Status List has been published. We have tried to incorporate the proposed changes as discussed in the interim meeting, the mailing list, and from discussions in github issues. Notable changes are:Section on prior workBe more explicit on the optio

[OAUTH-WG] Re: OAuth 2.1 ideas

Nick, As Dick indicated below, get a slide deck ready with your ideas, and Hannes and I will make sure to allocate some time during one the OAuth WG sessions to discuss this. Regards, Rifaat On Sat, Feb 1, 2025 at 6:11 AM Dick Hardt wrote: > Hey Nick, note that 2.1 does not introduce the man

[OAUTH-WG] Re: OAuth 2.1 ideas

Hey Nick, note that 2.1 does not introduce the mandate, it is in the OAuth Security BCP. While I agree that a refresh token expiry is handy, an AS can expire both a refresh token and an access token at any time. It is only an upper bound, just like the access token expiry. If you will be at IETF

[OAUTH-WG] Re: OAuth 2.1 ideas

Thanks for the context, Dick. Given that, I agree that the majority of my suggestions aren't in scope for 2.1. I do think that refresh_token_expires_in is worthy of continued discussion for 2.1, however, given that 2.1 introduces a mandate for either RT rotation or binding for public clients. refre

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

Hello Mike, thank you for a quick turnaround on these As far as questions 1-3 go: 1. I believe a precise incision in the form of a single "bis" document is fine but if these were individual documents it wouldn't hurt, whatever we can get out the door faster. 2. We have not done the

[OAUTH-WG] Re: -15 of SD-JWT

Wednesday, January 29, 2025 12:09 PM > > To: Brian Campbell > > Cc: oauth ; oauth-cha...@ietf.org > > Subject: [OAUTH-WG] Re: -15 of SD-JWT > > > > EXTERNAL EMAIL > > > > After discussion with the authors we've agreed that editorial improvements, &g

[OAUTH-WG] Re: -15 of SD-JWT

+1 (not confidential) Am 29.01.25 um 22:15 schrieb Pierce Gorman: +1 on advancing the draft. CONFIDENTIAL -Original Message- From: Watson Ladd Sent: Wednesday, January 29, 2025 12:09 PM To: Brian Campbell Cc: oauth;oauth-cha...@ietf.org Subject: [OAUTH-WG] Re: -15 of SD-JWT EXTERNAL

  1   2   3   4   5   6   7   8   >