[jose] Re: WGLC for draft-ietf-jose-fully-specified-algorithms

As a co-editor of FAPI2, yes this is a real problem. I think that having a spec like this would be beneficial and I support publication. I would, however, like to see the editorial points raised by Neil being addressed. -Daniel Am 06.05.24 um 19:11 schrieb Michael Jones: The draft is

[OAUTH-WG] Re: Mahesh Jethanandani's No Objection on draft-ietf-oauth-security-topics-27: (with COMMENT)

Thanks for the review, Mahesh! I fixed the usage of "man", "he", and "traditional" in this PR: https://github.com/oauthstuff/draft-ietf-oauth-security-topics/pull/99 The term "mastertheses" needs to remain as-is, as it appears only in a URL(!) The term "native" is commonly used to describe

Re: [OAUTH-WG] Parameter pollution with redirect_uri injection in Authorization step

Hi Mike, we require exact redirect URI matching, which should solve the problem; in PAR you can use a dynamic redirect_uri, but the PAR request must be authenticated by the client then, making this attack unlikely. -Daniel Am 02.05.24 um 17:08 schrieb Michael Jones: Hi Daniel and crew,

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-security-topics-26

Thank you for your review, Mike! I created a PR addressing your comments: https://github.com/oauthstuff/draft-ietf-oauth-security-topics/pull/91/files Please let me know if this looks good to you, I'll then release a new version with these changes. Am 29.04.24 um 03:40 schrieb Michael

Re: [OAUTH-WG] Artart last call review of draft-ietf-oauth-security-topics-25

Hi Russ, thank you for your feedback on the OAuth Security BCP draft! I incorporated most of the proposed changes into the latest version (-26). Some comments below: Am 18.02.24 um 22:27 schrieb Russ Housley via Datatracker: Reviewer: Russ Housley Review result: Almost Ready I am the

Re: [Gen-art] Genart last call review of draft-ietf-oauth-security-topics-25

Thank you Thomas for your feedback! I merged your PR and will release a new version soon. -Daniel Am 18.02.24 um 15:52 schrieb Thomas Fossati via Datatracker: Reviewer: Thomas Fossati Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team

Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-security-topics-25

Thank you Thomas for your feedback! I merged your PR and will release a new version soon. -Daniel Am 18.02.24 um 15:52 schrieb Thomas Fossati via Datatracker: Reviewer: Thomas Fossati Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team

[OAUTH-WG] Type Metadata for SD-JWT VC

Hi all, as discussed during IETF 119, we would like to introduce what we call Type Metadata to SD-JWT VC. For a bit of context, the intention is to provide a mechanism to provide information about credential types (e.g., a JSON schema, display/rendering information, a name and description

Re: [OAUTH-WG] OAuth Security Workshop 2024 | April 10-12 | Rome, Italy

This is just a reminder that the final deadline for submissions for OSW is coming up on March 10 (Sunday). https://oauth.secworkshop.events/osw2024 -Daniel Am 04.01.24 um 10:21 schrieb Daniel Fett: Hi all, This year's OAuth Security Workshop will be hosted by Fondazione Bruno Kessler

Re: [OAUTH-WG] AD Review of draft-ietf-oauth-security-topics-24

in github addresses almost all of my feedback.  A few minor things from the previous thread: *From:* OAuth *On Behalf Of * Daniel Fett *Sent:* Thursday, December 28, 2023 8:35 AM *To:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] AD Review of draft-ietf-oauth-security-topics-24 *Warning

Re: [OAUTH-WG] SD-JWT, use of JSON path in disclosure claim name

Hi Nikos, this question comes up from time to time, so I'll quote myself : "We thought a lot about pointer-based approaches like the one you propose in the beginning, but there are some drawbacks:  1. The Verifier can

[OAUTH-WG] OAuth Security Workshop 2024 | April 10-12 | Rome, Italy

Hi all, This year's OAuth Security Workshop will be hosted by Fondazione Bruno Kessler and will take place in Rome/Italy, April 10-12. Like last year, there are two deadlines for the Call for Sessions, February 11 and March 10, in order to provide early feedback for those that need

Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-security-topics-23

E? //Axel *From: *OAuth on behalf of Daniel Fett *Date: *Wednesday, 3. January 2024 at 14:01 *To: *oauth@ietf.org *Subject: *Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-security-topics-23 Hi Axel, I would be happy to see OAuth move away from state as a CSRF protection mechanism in the fu

Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-security-topics-23

e Exchange (PKCE, [RFC7636 <https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.html#RFC7636>]), it is RECOMMENDED the clientrelies on the CSRF protection provided by PKCE." Kind regards Axel *From: *OAuth on behalf of Daniel F

Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-security-topics-23

Hi Hannes, thanks again for your feedback! It is incorporated in the editor's copy now. - https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.html - Diff to published version:

Re: [OAUTH-WG] AD Review of draft-ietf-oauth-security-topics-24

Hi Roman, thanks again for your feedback! I have a few open questions below, but already incorporated most of your (and Hannes) feedback in the editor's copy: - https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.html - Diff to published version:

Re: [OAUTH-WG] AD Review of draft-ietf-oauth-security-topics-24

Hi Roman, thanks for the detailed review and your valuable feedback! I think you raise one important point in particular that I'd like to discuss on the list: Am 19.12.23 um 00:08 schrieb Roman Danyliw: ** I struggled to understand what was mandatory in the mix of RFC2119 keywords. (a)

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

I support adoption. Am 14.11.23 um 13:57 schrieb Rifaat Shekh-Yusef: All, This is an *official *call for adoption for the *Transaction Tokens *draft: https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/ Please, reply on the mailing list and let us know if you are

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

I support adoption. Am 14.11.23 um 13:58 schrieb Rifaat Shekh-Yusef: All, This is an *official* call for adoption for the *Identity Chaining *draft: https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-identity-chaining/ Please, reply on the mailing list and let us know if you are in

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

I agree with Aaron! Also we should be very careful about any additions to the Security BCP at this point. It is very easy to re-start the "one more thing" loop we've been stuck in for the last years. There may be more useful things to say, but we should put them on the list for a future

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt: Collaborative attacks against a Verifier

ion Protocol (OAUTH) WG of the IETF. Title: Selective Disclosure for JWTs (SD-JWT) Authors: Daniel Fett Kristina Yasuda Brian Campbell Name:draft-ietf-oauth-selective-disclosure-jwt-06.txt Pages: 90 Dates: 2023-10-23 Abstract: Thi

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

t; for IoT devices and networks. As a result, everything was re-defined in CBOR/COSE. CWT was one of the outcome of that work. The idea was nice but the success was below my expectations. Am 02.11.2023 um 13:23 schrieb Daniel Fett: Hi Hannes, Am 02.11.23 um 12:46 schrieb Hannes Tschofenig: Th

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

ocre formats. In that sense, I also don't see that SD-JWT should wait for a CBOR-based draft to start or even longer. -Daniel Ciao Hannes Am 02.11.2023 um 08:41 schrieb Daniel Fett: I second what my co-authors Kristina and Brian said. It is a risk, and there are a lot of unknowns here.

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

I second what my co-authors Kristina and Brian said. It is a risk, and there are a lot of unknowns here. I have a similar feeling regarding SD-JWT VC, even though that is farther away from the finish line. And as an attempt to explain some of the responses: I think the communication here

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt: Collaborative attacks against a Verifier

JSON serialized SD-JWTs Am 23.10.23 um 18:17 schrieb internet-dra...@ietf.org: Internet-Draft draft-ietf-oauth-selective-disclosure-jwt-06.txt is now available. It is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF. Title: Selective Disclosure for JWTs (SD-JWT)

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-24.txt

Daniel Fett Name:draft-ietf-oauth-security-topics-24.txt Pages: 62 Dates: 2023-10-23 Abstract: This document describes best current security practice for OAuth 2.0. It updates and extends the OAuth 2.0 Security Threat Model to incorporate practical

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

internet-dra...@ietf.org: Internet-Draft draft-ietf-oauth-selective-disclosure-jwt-06.txt is now available. It is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF. Title: Selective Disclosure for JWTs (SD-JWT) Authors: Daniel Fett Kristina Yasuda

Re: [OAUTH-WG] SD-JWT Redaction Reasons

The Holder can put such information into the KB-JWT, if required. -Daniel Am 20.10.23 um 16:28 schrieb Orie Steele: In some ways this is related to the question about disclosures. On Fri, Oct 20, 2023 at 9:03 AM Daniel Fett wrote: At least at the moment I don't think

Re: [OAUTH-WG] Clarification on SD-JWT verification

Hi Jacob, the intention was to cover the first case you listed. We should clarify this. -Daniel Am 20.10.23 um 15:02 schrieb Jacob Ward: Hello again, On a similar note to my previous email, could I get some clarity on a step in the SD-JWT verification process? /4. If any digests were

Re: [OAUTH-WG] SD-JWT Verification strictness

Hi Jacob, this check is mainly important for the Holder to ensure the integrity of the received SD-JWT. For the Verifier, there is not much to gain by checking this (but it also doesn't hurt either). However, we intended to keep the algorithms for the Holder and Verifier similar and

Re: [OAUTH-WG] SD-JWT Redaction Reasons

At least at the moment I don't think that there is a huge need for such a feature. I don't think that we should clutter the existing SD-JWT data structures with such information. If required, it could go into a separate data structure in the SD-JWT, for example a list of JSON pointers with a

Re: [OAUTH-WG] IPR Disclosure - OAuth 2.0 Security Best Current Practice

I am not aware of any IPR associated with this document. -Daniel Am 04.10.23 um 17:10 schrieb Tschofenig, Hannes: In my earlier email I forgot to include John. John, I also need your confirmation! *Von:*OAuth *Im Auftrag von *Tschofenig, Hannes *Gesendet:* Mittwoch, 4. Oktober 2023 15:41

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

I support adoption. Am 30.09.23 um 14:52 schrieb Rifaat Shekh-Yusef: All, This is an official call for adoption for the *JWT and CWT Status List* draft: https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/ Please, reply *on the mailing list *and let us know if you are in

Re: [OAUTH-WG] [Editorial Errata Reported] RFC9449 (7646)

The erratum looks correct to me. -Daniel Am 18.09.23 um 08:57 schrieb RFC Errata System: The following errata report has been submitted for RFC9449, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)". -- You may review the report below and at:

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

+1 Am 28.08.23 um 10:33 schrieb Joseph Heenan: I support adoption. Joseph On 23 Aug 2023, at 20:01, Rifaat Shekh-Yusef wrote: All, This is an official call for adoption for the *Protected Resource Metadata* draft: https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/

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

Thanks, Hannes. The fact that technologies like AnonCreds are based on such old principles, yet they are not uniformly standardized, often times limited to a few implementations that may or may not be secure, are full of security footguns, lack hardware support, and are just extremely hard or

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

Hi Watson, can you please be specific about the "standard, 22 year old security definitions" and "schemes of this type"? Not having to make assumptions would certainly help to have a useful discussion. -Daniel Am 23.08.23 um 07:32 schrieb Watson Ladd: Dear all, I read with alarm that

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

I support adoption. Am 29.07.23 um 21:27 schrieb Rifaat Shekh-Yusef: All, This is an official call for adoption for the *Attestation-Based Client Authentication *draft discussed in SF. https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth/ Please, reply on the

Re: [OAUTH-WG] OAuth Security Workshop 2023

to our conference venue. -Daniel Am 19.05.23 um 16:15 schrieb Daniel Fett: All, we are very happy to announce that the Call for Sessions for the OAuth Security Workshop 2023 in London is now open! We have two deadlines this time, June 4th and July 2nd, in order to provide early feedback

Re: [OAUTH-WG] BCP: Mix-Up Attacks, Implicit Grant Variant

Hi Alexander, Am 14.06.23 um 15:19 schrieb Alexander Rademann: ** Hello, everyone! Section 4.4.1 of the BCP draft lists several variants of mix-up attacks; the description of the Implicit grant variant

Re: [OAUTH-WG] Simplification and consolidation of SD-JWT terminology and format

Hi Hannes, maybe it was a bit implicit, but the point of Brian's email was to specifically do what you said - discuss this normative change here first. Although this is an extremely small change, we are conscious about not introducing breaking changes unless there is a tangible, practical

[OAUTH-WG] OAuth Security Workshop 2023

All, we are very happy to announce that the Call for Sessions for the OAuth Security Workshop 2023 in London is now open! We have two deadlines this time, June 4th and July 2nd, in order to provide early feedback for those that need confirmed talks (e.g., for company sponsorship). Please

Re: [OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-step-up-authn-challenge-14: (with COMMENT)

Hi Lars, we addressed your comments in -15 which we just uploaded: https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-15.html -Daniel Am 12.04.23 um 17:07 schrieb Brian Campbell: Thank you, Lars, for the review and ballot. I put together this small PR with updates for the comments/nits

Re: [OAUTH-WG] Warren Kumari's No Objection on draft-ietf-oauth-dpop-14: (with COMMENT)

Hi Warren, we addressed your comments in -15 which we just uploaded: https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-15.html -Daniel Am 12.04.23 um 01:18 schrieb Warren Kumari: On Tue, Apr 11, 2023 at 4:10 PM, Brian Campbell wrote: Thank you, Warren, for the review and

Re: [OAUTH-WG] Éric Vyncke's No Objection on draft-ietf-oauth-dpop-14: (with COMMENT)

Hi Eric, we addressed your comments in -15 which we just uploaded: https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-15.html -Daniel Am 11.04.23 um 17:05 schrieb Eric Vyncke (evyncke): Thank you, Brian, for your prompt reply and the PR. Your point about the tags around "none" is well

Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-dpop-14: (with COMMENT)

Thanks for your comments, Murray! Replies below. Am 13.04.23 um 07:45 schrieb Murray Kucherawy via Datatracker: Murray Kucherawy has entered the following ballot position for draft-ietf-oauth-dpop-14: No Objection When responding, please keep the subject line intact and reply to all email

Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-step-up-authn-challenge-14: (with COMMENT)

Am 13.04.23 um 08:11 schrieb Vittorio Bertocci: On the SHOULD on top of S4. There are pretty common situations in which failing to get a response from an API is an acceptable outcome, and presenting an interactive prompt isn't. A classic example is a background update that the client can use

Re: [OAUTH-WG] OAuth 2.0 Proof-of-Possession (PoP) Security Architecture

Hi Nat, after reading through the PoP architecture document again, my impression is that this document had a lot of value before MTLS and DPoP came along. But when thinking about what an updated version could look like, and considering that it is unlikely for the moment that many other PoP

Re: [OAUTH-WG] OAuth WG Agenda @ IETF116

Thank you, Rifaat! I see the side meetings listed at https://wiki.ietf.org/meeting/116/sidemeetings for Wednesday and Thursday, 10-11:30. Is that final? -Daniel Am 21.03.23 um 13:35 schrieb Rifaat Shekh-Yusef: *Tuesday * Chairs update – Rifaat/Hannes (10 min)

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

I support adoption of this document. -Daniel Am 15.11.22 um 15:43 schrieb Rifaat Shekh-Yusef: All, During the IETF meeting last week, there was a strong support for the adoption of the following document as a WG document:

[OAUTH-WG] Alternative social event today

Hi all, for those at IETF115 that don't have a social event ticket, let's meet at 6pm at the IETF registration desk and find a nice place for dinner. -Daniel ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Security Topics | Incorporate in-browser communication security considerations | PR53

Hi Christian, thanks for bringing this to our attention! I think the recommendations in the PR are very helpful and we will consider adding the text to the document. -Daniel Am 25.10.22 um 15:37 schrieb Christian Mainka: Hi, we would like to request the inclusion of _in-browser

Re: [OAUTH-WG] DPoP - IPR Disclosure

I am not aware of any IPR relating to this document. -Daniel Am 10. August 2022 23:37:20 MESZ schrieb Rifaat Shekh-Yusef : >Daniel, Brian, John, Torsten, Mike, and David, > >As part of the shepherd write-up for the *DPoP* document, there is a need >for an IPR disclosure from the authors.

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

from that group, I >would love to hear them. > >On Fri, Aug 5, 2022 at 10:26 AM Daniel Fett 40danielfett...@dmarc.ietf.org> wrote: > >> Am 05.08.22 um 10:22 schrieb Warren Parad: >> >> > and nobody involved in the JWP effort thinks that SD-JWT should be in >

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

Am 05.08.22 um 10:22 schrieb Warren Parad: > and nobody involved in the JWP effort thinks that SD-JWT should be in that WG once created Why? For the reasons listed, I guess? Also, mind the "As far as I am aware" part, but I don't remember any discussions in that direction at IETF114.

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

Hi Jaimandeep, Am 04.08.22 um 20:39 schrieb Jaimandeep Singh: Dear All, My compliments to all the collaborators including David for making efforts in answering the queries. However, I am of the opinion that we need to answer some of the more fundamental questions before arriving at any

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

+1 for obvious reasons. Am 28. Juli 2022 21:12:49 GMT-04:00 schrieb Brian Campbell : >I support adoption. > >On Thu, Jul 28, 2022, 8:17 PM Rifaat Shekh-Yusef >wrote: > >> All, >> >> This is a call for adoption for the *SD-JWT* document >>

Re: [OAUTH-WG] DPoP - Document Shepherd Review

Apologies accepted! :-) Am 28.07.22 um 01:11 schrieb Brian Campbell: I need to make one more apology - this time for the incorrect spelling of Dr. Fett's name (should be Daniel not Danial). My apologies. On Wed, Jul 27, 2022 at 6:43 PM Brian Campbell wrote: Thanks Rifaat and others

[OAUTH-WG] SD-JWT - New version - Call for adoption?

Hi all, Kristina and I have just uploaded the latest version of draft-fett-oauth-selective-disclosure-jwt. In this version, we address issues raised both in this working group and by other interested parties. Other issues are still under discussion in the

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

Hi Nikos, Am 28.06.22 um 13:22 schrieb Nikos Fotiou: Hi Daniel, I just want to reverse your arguments and I will stop spamming. I will focus on your “sub” example. When a VC is encoded as a JWT, and according to specs (https://www.w3.org/TR/vc-data-model/#proof-formats) “sub MUST

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

Zd6AuLmPraGhPJ0zF5r_JhxCVZs", "family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw", "email": "fPZ92dtYMCN2Nb-2ac_zSH19p4yakUXrZl_-wSgaazA", "phone_number": "QdSffzNzzd0n60MsSmuiKj6Y6Enk2b-BS-KtEePde5M", "address": "JFu99NUXPq55f6DFBZ22rMk

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

Hi Neil, thanks for your feedback! The security considerations are certainly far from complete in this first draft (and didn't intend to be). Your comments will help us to improve this part of the draft. Am 23.06.22 um 20:52 schrieb Neil Madden: I’m not entirely sure the OAuth WG is a

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

losure-jwt/issues/79 Thanks, Daniel Best, Nikos -- Nikos Fotiou -http://pages.cs.aueb.gr/~fotiou Researcher - Mobile Multimedia Laboratory Athens University of Economics and Business https://mm.aueb.gr On 23 Jun 2022, at 7:32 PM, Daniel Fett wrote: All, Kristina and I would like to bring to

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

All, Kristina and I would like to bring to your attention a new draft that we have been working on with many others over the past weeks. "Selective Disclosure JWT (SD-JWT)" describes a format for signed JWTs that support selective disclosure (SD-JWT), enabling sharing only a subset of the

Re: [OAUTH-WG] Security BCP Review

Hi Rifaat, Am 14.02.22 um 22:26 schrieb Rifaat Shekh-Yusef: As part of the preparation for the shepherd write-up, I reviewed the document and have the following comments: https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-19.html

Re: [OAUTH-WG] WGLC for DPoP Document

I also support publication. -Daniel Am 29.03.22 um 23:20 schrieb David Waite: I also support publication of this specification -DW On Mar 29, 2022, at 3:12 PM, Mike Jones wrote: I support publication of the specification. -- Mike *From:*OAuth *On Behalf Of*Rifaat Shekh-Yusef

Re: [OAUTH-WG] WGLC for DPoP Document

+1 Am 29.03.22 um 15:10 schrieb Justin Richer: And this is exactly the problem with the “collaborating clients” attack, as has been pointed out any number of times it’s been brought up before. If two clients are willingly collaborating in this way, they do not need to share any cryptographic

[OAUTH-WG] OAuth Security BCP Github

Since this was asked at the meeting, the OAuth Security BCP lives here: https://github.com/oauthstuff/draft-ietf-oauth-security-topics -Daniel -- https://danielfett.de ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Security Workshop 2022 - Tickets now available

Hi everyone, as a quick reminder, there's less than a week left to book early bird tickets. If you want to submit a session proposal, please do so until March 23. Thanks, Daniel Am 11.02.22 um 22:27 schrieb Daniel Fett: Hi everyone, I'm pleased to announce that the website for the OAuth

Re: [OAUTH-WG] proof of access token possession using client secret

What exactly is the attack that you're trying to prevent? If the clients share the access tokens, they might as well share access to the resource server (forwarding requests and responses). You can't really prevent that. DPoP or MTLS, potentially with non-exportable keys, might be a better

Re: [OAUTH-WG] OAuth: The frustrating lack of good libraries

lp address your concerns. Please have a look here: https://loginbuddy.net I just updated the web site. Or visit the GitHub project: https://github.com/SaschaZeGerman/loginbuddy In any case, that is my current contribution to the developer community.

[OAUTH-WG] OAuth: The frustrating lack of good libraries

** *Hi all,* * While helping clients to onboard into the yes ecosystem, in my consulting work, and in discussions with developers implementing OAuth 2.0, one topic comes up increasingly often: The (somewhat frustrating) lack of good, modern, and universal OAuth libraries. Many of the

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dpop-05.txt

of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) Authors : Daniel Fett Brian Campbell John Bradley

Re: [OAUTH-WG] DPoP proof and the public key

Hi George, the main reason for this is to facilitate a client implementation that always sends the same kind of proof. For the client, there's no need to distinguish between token request, resource request, or even PAR request. Even though the key would only be needed once, of course.

[OAUTH-WG] OAuth Security Workshop 2022 - Tickets now available

Hi everyone, I'm pleased to announce that the website for the OAuth Security Workshop 2022 is now up: https://oauth.secworkshop.events/osw2022 The three-day event takes place in Trondheim, Norway, from May 4 to May 6, 2022. This workshop will *not* be a hybrid event. We might provide

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

0kmFmzW75uIfaSBtXQrRmwuk71WWO6ryCzahTcxBPYX > > As a result, an access token was issued although the code_verifier > provided in the token request did not match the code_challenge and > code_challenge_method in the authorization request. > >   > > Many applications consider t

Re: [OAUTH-WG] Francesca Palombini's Discuss on draft-ietf-oauth-iss-auth-resp-03: (with DISCUSS)

Hi Francesca, Warren, Brian, we have modified the IANA Considerations section in the just uploaded version -04 according to your feedback. -Daniel Am 30.11.21 um 19:42 schrieb Francesca Palombini: > > Hi Warren, Brian, > >   > > Thanks for your feedback, and for confirming that the semantics of

Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-iss-auth-resp-03: (with COMMENT)

Hi Murray, thanks for your review and feedback. We have just uploaded version -04 which includes a fix for the missing quotation marks (which were not added by xml2rfc automatically for an unknown reason). -Daniel Am 02.12.21 um 07:01 schrieb Murray Kucherawy via Datatracker: > Murray

Re: [OAUTH-WG] dpop_jkt Authorization Request Parameter

+1 to what Neil and Aaron said. dpop_jkt effectively creates a client authentication mechanism with an ad-hoc identifier for the client. I'm wondering if dynamic registration plus an asymmetric client authentication scheme doesn't already solve the problem. -Daniel Am 01.12.21 um 01:05 schrieb

Re: [OAUTH-WG] Invitation: OAuth Security Workshop 2021

Hi all, this is just a reminder that the OAuth Security Workshop 2021 takes place in a little more than two weeks. You can still register for the event and propose sessions at https://barcamps.eu/osw2021 <https://barcamps.eu/osw2021>. -Daniel Am 23.08.21 um 10:46 schrieb Daniel Fett: >

Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

Am 16.10.21 um 01:41 schrieb Mike Jones: > > As I see it, the retry in case of network failures should happen by > performing a new authorization request – not by trying to reuse an > authorization code – which is indistinguishable from an attack. > It only looks like an attack when the code has

Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

I don't think that a MAY is appropriate here. I wasn't in the call yesterday, so I hope I don't miss anything here, but... Even with PKCE, the one-time use requirement of the code is still important. First and foremost, if we allow unlimited re-use of the same code, even just as an option, we

Re: [OAUTH-WG] Shepherd writeup for draft-ietf-oauth-iss-auth-resp

Hi Rifaat, looks good to me! -Daniel Am 08.10.21 um 15:13 schrieb Rifaat Shekh-Yusef: > All, > > The following is the first version of the shepherd writeup for > the draft-ietf-oauth-iss-auth-resp document. > https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/shepherdwriteup/ >

Re: [OAUTH-WG] self-issued access tokens

That very much sounds like a static string as the access token plus DPoP. -Daniel Am 29.09.21 um 03:54 schrieb toshio9@toshiba.co.jp: > Hi OAuth folks, > > I have a question. Is there (or was there) any standardizing effort for > "self-issued access tokens"? > > Self-issued access tokens are

Re: [OAUTH-WG] IPR Disclosures - OAuth 2.0 Authorization Server Issuer Identification

Hi Rifaat, not sure why, but I totally missed that first email. Thanks for the reminder! I am not aware of any IPR related to the OAuth 2.0 Authorization Server Issuer Identification draft. -Daniel Am 08.09.21 um 18:44 schrieb Rifaat Shekh-Yusef: > Karsten, Daniel, > > Any update on this? > >

[OAUTH-WG] Invitation: OAuth Security Workshop 2021

Hi all, I would like to invite you to the OAuth Security Workshop 2021, a fully-virtual, two-day event on  *November 30 and December 1, 2021 (UTC).* The OAuth Security Workshop (OSW) aims to improve the security of OAuth, OpenID Connect, GNAP and related Internet protocols by facilitating

[OAUTH-WG] High-quality OAuth client libraries

Hi all, I'd like to draw your attention to a discussion that came up in the OpenID Foundation's FAPI working group. As you know, FAPI mostly builds upon standardized OAuth and OIDC features. Nonetheless, it is hard to find client libraries that can be used "out of the box" with a FAPI. Many

Re: [OAUTH-WG] Call for Feedback on draft-ietf-oauth-iss-auth-resp-00

Hi Neil, I'm not sure - maybe others can chime in here as well - if a discussion relating to an expired previous draft is something one would expect in the spec. For the record, the client_id does not provide any additional security. The key to mitigating Mix-Up is that the "honest AS" ensures

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-18.txt

Andrey Labunets > Daniel Fett > Filename: draft-ietf-oauth-security-topics-18.txt > Pages : 53 > Date: 2021-04-13 > > Abstract: >This document describes best current security practice for OAuth 2.0. >

Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP

Am 12.04.21 um 16:56 schrieb Denis: > Hi  Daniel, > >> (...) As I'm sure you have noticed, we have updated Section 3 following your last input. It now explicitly says:     Attackers can collaborate to reach a common goal. It also says    Note that in

Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP

Hi Denis, Am 12.04.21 um 14:57 schrieb Denis: >> >>> The first sentence of section 3 (The Updated OAuth 2.0 Attacker >>> Model) clearly states: >>> >>>     " In the following, this attacker model is updated (...) to >>> include new types of attackers and to define the attacker model more >>>

Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP

Denis, I was awaiting your mail and I admire your perseverence with bringing this topic to our attention. To your points: Am 12.04.21 um 13:36 schrieb Denis: > The case where two clients collude to mount an attack against a RS is > not addressed. It now needs to be addressed. > > > This should

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-17.txt

easy especially if the only > mechanism available for the callback is a custom scheme URL. > > Thoughts? > > On 4/6/21 9:15 AM, Daniel Fett wrote: >> Hi all, >> >> this version most importantly updates the recommendations for Mix-Up >> mitigation, building

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-17.txt

Andrey Labunets > Daniel Fett > Filename: draft-ietf-oauth-security-topics-17.txt > Pages : 52 > Date: 2021-04-06 > > Abstract: >This document describes best current security practice for OAuth 2.0. >It u

Re: [OAUTH-WG] OAuth 2.0 Pushed Authorization Requests: Implementation Status

Hi Hannes, as mentioned by Brian, the yes Signing Flow is based on PAR and therefore implemented by our banks (> 1000). A python client for the yes signing flow is publicly available that uses PAR: https://github.com/yescom/pyyes -Daniel Am 24.03.21 um 20:53 schrieb Hannes Tschofenig: > > Hi

Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response

Hi Warren, Am 08.12.20 um 20:15 schrieb Warren Parad: > As an implementer on both sides of the issue I'm struggling to > understand how this problem would occur. I'm finding issues with the > proposed problems: > > 1. Honest AS is compromised, assuming this does happen details on why >

Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response

Obviously, +1. Am 08.12.20 um 13:50 schrieb Rifaat Shekh-Yusef: > All, > > This is a call for adoption for the following AS Issuer Identifier in > Authorization Response as a WG document: > https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/ > > Please, provide your

Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

So what you are proposing is that the time window in which an RS accepts the DPoP proof is defined by the expiration time of the access token? DPoP proofs are intended to be generally be short-lived and fresh for each request in order to provide some level of replay protection. There is no point

Re: [OAUTH-WG] Token substitution in DPoP

Thanks Justin for bringing this to our attention. Right now, I don't think that this is a big problem and I wasn't able to come up with a way to improve the attack. I hope that it doesn't come back to haunt us when somebody does a more in-depth analysis... That said, the lack of binding to the

Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

A small feedback for the 3rd paragraph in Section 4: >>>>> s/identifes/identifies/ >>>>> >>>>> Best Regards, >>>>> Taka >>>>>   >>>>> >>>>> On Tue, Nov 3,

  1   2   3   >