Re: [OAUTH-WG] [IANA #1270471] expert review for draft-ietf-oauth-dpop (jwt)

I likewise approve. -- Mike From: Brian Campbell Sent: Thursday, April 6, 2023 9:50 AM To: drafts-expert-review-comm...@iana.org Cc: ve7...@ve7jtb.com; Mike Jones ; charliemortim...@gmail.com; jwt-reg-rev...@ietf.org; oauth

Re: [OAUTH-WG] [IANA #1270370] Request to register OAuth Authorization Server Metadata: dpop_signing_alg_values_supported

I also approve this request. -- Mike From: John Bradley Sent: Wednesday, April 5, 2023 11:13 AM To: dick.ha...@gmail.com Cc: drafts-expert-review-comm...@iana.org; oauth-ext-rev...@ietf.org; Mike Jones ; n...@sakimura.org; oauth

Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields)

. -- Mike From: OAuth On Behalf Of Mike Jones Sent: Tuesday, March 7, 2023 8:58 PM To: Mark Nottingham Cc: Roy Fielding ; Amanda Baber via RT ; oauth@ietf.org Subject: Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields) Thanks - will do

[OAUTH-WG] Proposed OAuth Security BCP text on the use of CORS

I propose adding the following section to the OAuth Security BCP specification: Usage of CORS The Token Endpoint, Authorization Server Metadata Endpoint, jwks_uri Endpoint, Dynamic Client Registration Endpoint, and any other

Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields)

Thanks - will do. From: Mark Nottingham Sent: Tuesday, March 7, 2023 7:55:29 PM To: Mike Jones Cc: Brian Campbell ; Amanda Baber via RT ; oauth@ietf.org ; Roy Fielding Subject: Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http

Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields)

t and publish an updated draft incorporating your suggestions. Thanks, -- Mike -Original Message----- From: Mike Jones Sent: Monday, January 23, 2023 11:42 PM To: 'Mark Nottingham' ; Brian Campbell Cc: Amanda Baber via RT ; o

Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields)

; ryanridenou...@gmail.com ; neil.e.mad...@gmail.com ; Mike Jones ; Justin Richer ; Roy Fielding ; da...@alkaline-solutions.com ; bcampb...@pingidentity.com Subject: Re: [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields) Hi David, As far as I can tell, very little of our feedback

Re: [OAUTH-WG] OAuth 2.0 Protected Resource Metadata

Given that the draft is now being used, I support working group adoption. I’d also like to request time in Yokohama to talk about the draft. Thanks, -- Mike From: OAuth On Behalf Of

Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields)

Hi Mark, Like Brian, I appreciate your detailed review. My thoughts on the review points are interleaved with the discussion text below. > Keep in mind that HTTP header fields are basically sets of constrained octets > with weird combination rules; if you don't use SF, you should be

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

I support adoption of the cross-device flows document. -- Mike From: OAuth On Behalf Of Joseph Heenan Sent: Wednesday, November 16, 2022 4:34 AM To: oauth Subject: Re: [OAUTH-WG] Call for adoption: Cross-Device Flows Hi all I support

Re: [OAUTH-WG] DPoP - IPR Disclosure

I am not aware of any IPR pertaining to this specification. -- Mike From: OAuth On Behalf Of Rifaat Shekh-Yusef Sent: Wednesday, August 10, 2022 2:37 PM To: oauth Subject: [OAUTH-WG] DPoP - IPR Disclosure Daniel, Brian, John, Torsten,

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

Neil, you wrote: "SD-JWT is not simpler. Anyway, I think I have learnt enough from this thread, we don’t have to keep arguing the same points. I think the claims of combinatorial explosion are somewhat exaggerated and I don’t see compelling evidence of a real world need for selective disclosure

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

I support adoption. From: OAuth On Behalf Of Daniel Fett Sent: Friday, July 29, 2022 8:32 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Call for adoption - SD-JWT You don't often get email from mail=40danielfett...@dmarc.ietf.org. Learn why this is

Re: [OAUTH-WG] Feedback for draft-ietf-oauth-dpop-09

I concur with Brian's evaluation of these proposed changes. -- Mike From: OAuth on behalf of Brian Campbell Sent: Wednesday, July 6, 2022 1:53:17 PM To: Spencer Balogh Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Feedback for draft-ietf-oauth-dpop-09 Thanks

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

Yes, we submitted both the .xml and .txt files. It does sound like a tooling issue. I'm sure the RFC Editor will sort it out before publication. Thanks again, -- Mike -Original Message- From: Lars Eggert Sent: Thursday,

Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-jwk-thumbprint-uri-03: (with COMMENT)

Hi Murray, I hear you about the BCP 14 usage, but at the same time, I think that the (single) use of MUST is appropriate. Furthermore, its usage there was suggested to us by Roman in his AD review. Therefore, I'm prone to leave it as is. All the best,

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

Hi Robert, Good question. Chasing the RFC reference chains, RFC 6920 says that algorithms have the syntax 1*unreserved where "unreserved" is from RFC 3986, Section 2.3. That section defines the unreserved character set as unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~".

[OAUTH-WG] Mike's review of draft-ietf-oauth-security-topics-29

Here's my cover-to-cover review of the OAuth Security BCP draft. The content of it is in GitHub, for the convenience of the editors. GitHub Issues: * https://github.com/oauthstuff/draft-ietf-oauth-security-topics/issues/27#issuecomment-1140173551 *

[OAUTH-WG] JWK Thumbprint URI Draft Addressing IETF Last Call Comments

Kristina Yasuda and I have published a new JWK Thumbprint URI draft that addresses the IETF Last Call comments received. Changes made were: *Clarified the requirement to use

Re: [OAUTH-WG] Last Call: (JWK Thumbprint URI) to Proposed Standard

. Best wishes, -- Mike From: Rifaat Shekh-Yusef Sent: Friday, May 6, 2022 2:28 PM To: Mike Jones Cc: Manger, James ; last-c...@ietf.org; draft-ietf-oauth-jwk-thumbprint-...@ietf.org; oauth-cha...@ietf.org; oauth@ietf.org Subject

Re: [OAUTH-WG] Last Call: (JWK Thumbprint URI) to Proposed Standard

Hi James. Thanks for your review. While ni: could have been used, ni: conveys nothing about the hash is of. Whereas urn:ietf:params:oauth:jwk-thumbprint says that the hash is a JWK thumbprint. At least for the use cases we anticipate, this additional specificity adds value.

Re: [OAUTH-WG] JWK Thumbprint URI - Implementations

https://mailarchive.ietf.org/arch/msg/oauth/h9IP7uSXWrv_u2nGdN_johEY9PM/ documents the Nimbus implementation. -- Mike From: OAuth On Behalf Of Rifaat Shekh-Yusef Sent: Friday, April 1, 2022 4:42 AM To: oauth Subject: [OAUTH-WG] JWK

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

I am not aware of any IPR that pertains to this specification. -- Mike From: OAuth On Behalf Of Rifaat Shekh-Yusef Sent: Friday, April 1, 2022 4:37 AM To: oauth Subject: [OAUTH-WG] JWK Thumbprint URI - IPR Disclosure Mike, Kristina, As

Re: [OAUTH-WG] WGLC for DPoP Document

I support publication of the specification. -- Mike From: OAuth On Behalf Of Rifaat Shekh-Yusef Sent: Monday, March 28, 2022 5:01 AM To: oauth Subject: [OAUTH-WG] WGLC for DPoP Document All, As discussed during the IETF meeting in Vienna

[OAUTH-WG] Registered the application/dpop+jwt media type

https://github.com/danielfett/draft-dpop/pull/126 Publishing a draft with this PR should get us to working group last call for DPoP, as discussed at IETF 113 on March 21, 2022. -- Mike ___ OAuth

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

FYI, I posted about this revision at https://self-issued.info/?p=2258 and https://twitter.com/selfissued/status/1499457532200308755. -- Mike From: OAuth On Behalf Of Brian Campbell Sent: Tuesday, March 1, 2022 1:14 PM To: oauth@ietf.org

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

Very cool! Thanks for updating us on your implementation. -- Mike From: OAuth On Behalf Of Vladimir Dzhuvinov Sent: Wednesday, February 23, 2022 12:59 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Second WGLC for JWK Thumbprint URI

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

Note that the current draft of this specification is https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-01.html (not -00). I support publication of this specification. -- Mike From: OAuth On Behalf Of Rifaat Shekh-Yusef

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

See my review comments in the thread “[OAUTH-WG] Comments on draft-chadwick-oauth-jwk-uri-00”. -- Mike From: David Chadwick Sent: Friday, February 18, 2022 3:52 AM To: Mike Jones ; Kristina Yasuda ; oauth@ietf.org Subject: Re: [OAUTH-WG

[OAUTH-WG] Comments on draft-chadwick-oauth-jwk-uri-00

Thanks for pointing the working group to this individual submission, David. Here's some initial comments on the document, as you requested. First, you specify base64 encoding of the JWK, rather than base64url encoding of it. This would result in non-URL-safe characters in the URI, such as /,

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

To: Kristina Yasuda ; Mike Jones ; oauth@ietf.org Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document On 07/02/2022 20:42, Kristina Yasuda wrote: 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

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

My traditional blog post describing the updated draft is at https://self-issued.info/?p=2251. I also tweeted about it at https://twitter.com/selfissued/status/1493778351919489037. -- Mike From: OAuth On Behalf Of Kristina Yasuda Sent:

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

Considerations text you may choose to supply. Thanks again, -- Mike From: Neil Madden Sent: Saturday, February 5, 2022 1:00 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG

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

David, I believe your objections below are actually about the JWK Thumbprint [RFC 7638] computation used by this specification, and not the operation defined by this specification. JWK Thumbprint became an RFC in 2015. This

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

, we’d consider using it. I looked for one and surprisingly didn’t find it. Or we could create one. Thanks all, -- Mike & Kristina From: OAuth On Behalf Of Mike Jones Sent: Fr

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

Neil, thanks for your review. First, you wrote: > Using a (hash of a) public key as an identifier is an idea that has > historically been subject to various attacks such as unknown key share > attacks, as well as issues due to malleable signature schemes or key exchange > schemes - where the

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

Thanks Rifaat, I support publication of the specification. -- Mike From: OAuth On Behalf Of Rifaat Shekh-Yusef Sent: Wednesday, February 2, 2022 4:19 AM To: oauth Subject: [OAUTH-WG] WGLC for JWK Thumbprint URI document All, The JWK

Re: [OAUTH-WG] dpop_jkt Authorization Request Parameter PR Updated

lcomed! -- Mike From: Brian Campbell Sent: Tuesday, January 25, 2022 9:13 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] dpop_jkt Authorization Request Parameter PR Updated The text that talks about matching the code challenge needs to be

[OAUTH-WG] Request for Working Group Last Call on the JWK Thumbprint URI Specification

int-uri-00. Thank you, -- Mike & Kristina From: OAuth On Behalf Of Mike Jones Sent: Saturday, January 29, 2022 3:41 PM To: oauth@ietf.org Subject: [EXTERNAL] [OAUTH-WG] Working Group Adopt

[OAUTH-WG] Working Group Adoption of the JWK Thumbprint URI Specification

The IETF OAuth working group has adopted the JWK Thumbprint URI specification. The abstract of the specification is: This specification registers a kind of URI that

[OAUTH-WG] dpop_jkt Authorization Request Parameter PR Updated

I've addressed the review comments on the dpop_jkt PR https://github.com/danielfett/draft-dpop/pull/89/ in commit https://github.com/danielfett/draft-dpop/pull/89/commits/6e0ff26e9aa2bf9bf1aacf9ba2ce29de0c032004. Specifically, the commit: * Specifies that SHA-256 is used for the JWK

Re: [OAUTH-WG] Call for adoption - JWK Thumbprint URI

I support adoption. This specification solves the need for having a key identifier that is also a URI. -- Mike From: OAuth On Behalf Of Rifaat Shekh-Yusef Sent: Thursday, January 13, 2022 6:27 AM To: oauth Subject: [EXTERNAL] [OAUTH-WG]

[OAUTH-WG] Described more of the motivations for the JWK Thumbprint URI specification

As requested by the chairs during today's OAuth Virtual Office Hours call, Kristina Yasuda and I have updated the JWK Thumbprint URI specification to enhance the description of the motivations for the specification. In particular, it now describes using JWK

Re: [OAUTH-WG] [oauth-ext-review] [IANA #1216704] Expert Review for draft-ietf-oauth-iss-auth-resp (oauth-parameters) (2)

Note that the requested OAuth parameter to be registered "iss" has already been registered by RFC 9101 (The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)) for Parameter Usage Location "authorization request". Fortunately, this use is compatible with that in

Re: [OAUTH-WG] [IANA #1216703] Expert Review for draft-ietf-oauth-iss-auth-resp (oauth-parameters)

I also approve of the registration of this parameter. -- Mike From: Dick Hardt Sent: Thursday, January 6, 2022 6:05 PM To: drafts-expert-review-comm...@iana.org Cc: Mike Jones ; n...@sakimura.org; oauth@ietf.org; oauth-ext-rev...@ietf.org

[OAUTH-WG] Virtual office hours

Are the OAuth virtual hours happening 11 hours from now? Inquiring minds want to know. ;-) -- Mike ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter

sufficiently long to be exploited by these sophisticated attackers. Cheers Pieter From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf Of Warren Parad Sent: Wednesday 1 December 2021 15:29 To: Pieter Kasselman mailto:40microsoft@dmarc.ietf.org>> Cc: Mike Jones mailto:40microsoft@dmarc.iet

[OAUTH-WG] dpop_jkt Authorization Request Parameter

As described during the OAuth Security Workshop session on DPoP, I created a pull request adding the dpop_jkt authorization request parameter to use for binding the authorization code to the client's DPoP key. See https://github.com/danielfett/draft-dpop/pull/89. This is an alternative to

Re: [OAUTH-WG] JWK Thumbprint URI Specification

, -- Mike From: David Waite Sent: Wednesday, November 24, 2021 2:42 PM To: Mike Jones Cc: David Chadwick ; oauth@ietf.org Subject: Re: [OAUTH-WG] JWK Thumbprint URI Specification I would investigate whether there are advantages of having this be a URN vs a URI in a new base scheme (e.g

Re: [OAUTH-WG] JWK Thumbprint URI Specification

Subject: Re: [OAUTH-WG] JWK Thumbprint URI Specification On 24/11/2021 20:07, Mike Jones wrote: The JSON Web Key (JWK) Thumbprint specification [RFC 7638<https://www.rfc-editor.org/rfc/rfc7638.html>] defines a method for computing a hash value over a JSON Web Key (JWK) [RFC 7517<https:

[OAUTH-WG] JWK Thumbprint URI Specification

The JSON Web Key (JWK) Thumbprint specification [RFC 7638] defines a method for computing a hash value over a JSON Web Key (JWK) [RFC 7517] and encoding that hash in a URL-safe manner. Kristina

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

attacks. The prohibition on clients reusing an authorization code needs to remain. -- Mike From: Vittorio Bertocci Sent: Friday, October 15, 2021 4:19 PM To: Richard Backman, Annabelle Cc: Mike Jones ; oauth@ietf.org Subject: [EXTERNAL

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

f the one time use requirement is removed. Is there another countermeasure in PKCE that would prevent it? For example, an attacker may obtain the Authorization Code and the Code Verifier from a log and replay it. Cheers Pieter From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf Of Aa

[OAUTH-WG] Authorization code reuse and OAuth 2.1

During today's call, it was asked whether we should drop the OAuth 2.0 language that: The client MUST NOT use the authorization code more than once. If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

PM To: Mike Jones Cc: rifaat.s.i...@gmail.com; oauth@ietf.org Subject: Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature Hi Mike, One of the major benefits of this proposed draft is that it does not try to solve the problem of HTTP message signing

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

I do not support adoption of this draft. OAuth 1 failed because of the complexity of HTTP Signing and the resulting difficulty of achieving interop. draft-ietf-oauth-signed-http-request was abandoned by the working group recognizing that it was resurrecting equivalent complexity to OAuth 1.

Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-04.txt

FYI, I wrote about the nonce support at https://self-issued.info/?p=2194 and https://twitter.com/selfissued/status/1445789505902899206. -- Mike From: OAuth On Behalf Of Brian Campbell Sent: Monday, October 4, 2021 3:11 PM To: oauth

[OAUTH-WG] Opportunity to Join the OpenID Foundation Certification Team

The OpenID Foundation is looking to add a part-time member to the OpenID Certification program team. I'm posting this here since a number of OAuth invariants are validated by the certification tests, and indeed, I know that a number of you have participated in the certification program. See

[OAUTH-WG] Adding the option to use server-supplied nonces to DPoP

We all know that using proof-of-possession with issued tokens is a means of rendering exfiltrated tokens useless to attackers. The DPoP was created as one of the tools to prevent this. There's a huge amount of evidence of successful token exfiltration attacks in the wild, some of which is

Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-03.txt

I had expected that we would use the existing member name “at_hash” for the access token hash value, rather than the new name “ath”, since there’s already precedent for using it. Could we change to the standard name for this when we publish the next version?

Re: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT)

https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-34 incorporates the fixes you suggested. Thanks again, -- Mike -Original Message- From: Mike Jones Sent: Thursday, April 8, 2021 6:49 AM To: Francesca Palombini ; i

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

https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-34 incorporates the fixes you suggested. Thanks again! -- Mike -Original Message- From: Mike Jones Sent: Thursday, April 8, 2021 6:46 AM To: Murray Kucherawy ; The IESG

Re: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT)

-Original Message- From: Francesca Palombini Sent: Thursday, April 8, 2021 2:47 AM To: Mike Jones ; i...@ietf.org Cc: draft-ietf-oauth-jws...@ietf.org; oauth-cha...@ietf.org; oauth@ietf.org; hannes.tschofe...@gmx.net Subject: Re: Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32

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

Thanks for your review, Murray. My replies are inline, prefixed by "Mike>". -Original Message- From: Murray Kucherawy via Datatracker Sent: Wednesday, April 7, 2021 11:43 PM To: The IESG Cc: draft-ietf-oauth-jws...@ietf.org; oauth-cha...@ietf.org; oauth@ietf.org;

Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT)

Thanks for your review, Ben. We've published https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-33 to address your and other IESG comments. Responses are inline below, prefixed by "Mike>". -Original Message- From: OAuth On Behalf Of Benjamin Kaduk via Datatracker Sent: Tuesday,

Re: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT)

Thanks for your review, Francesca. We've published https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-33 to address your and other IESG comments. Responses are inline below, prefixed by "Mike>". -Original Message- From: Francesca Palombini via Datatracker Sent: Wednesday, April 7,

Re: [OAUTH-WG] Martin Duke's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT)

Thanks for your review, Martin. We've published https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-33 to address your and other IESG comments. Responses are inline below, prefixed by "Mike>". -Original Message- From: Martin Duke via Datatracker Sent: Tuesday, April 6, 2021 12:13 PM

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

Thanks for your review, Éric. We've published https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-33 to address your and other IESG comments. Responses are inline below, prefixed by "Mike>". -Original Message- From: Éric Vyncke via Datatracker Sent: Tuesday, April 6, 2021 7:49 AM

Re: [OAUTH-WG] Lars Eggert's No Objection on draft-ietf-oauth-jwsreq-32: (with COMMENT)

Thanks for your review, Lars. We've published https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-33 to address your and other IESG comments. Responses are inline below, prefixed by "Mike>". -Original Message- From: Lars Eggert via Datatracker Sent: Tuesday, April 6, 2021 5:19 AM

[OAUTH-WG] OAuth 2.0 JWT Secured Authorization Request (JAR) updates addressing remaining review comments

After the OAuth 2.0 JWT Secured Authorization Request (JAR) specification was sent to the RFC Editor, the IESG requested an additional round of IETF feedback. We've published an updated draft addressing the remaining review comments, specifically, SecDir

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-jwsreq-30

Thanks, Watson. We've published https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-31 with these changes. -- Mike -Original Message- From: Watson Ladd Sent: Wednesday, March 17, 2021 6:21 PM To: Mike Jones Cc: nat ; r...@cert.org; sec...@ietf.org

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-jwsreq-30

. -- Mike From: Mike Jones Sent: Friday, February 26, 2021 12:55 PM To: 'Watson Ladd' ; Nat Sakimura ; Roman Danyliw Cc: secdir ; IETF oauth WG ; last-c...@ietf.org; draft-ietf-oauth-jwsreq@ietf.org Subject: Re: Secdir last call review of draft-ietf-oauth-jwsreq-30 Thanks again

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-jwsreq-30

Thanks again for your review, Watson. My replies to your comments below are prefixed by "Mike>". -Original Message- From: Watson Ladd Sent: Tuesday, December 15, 2020 9:01 PM To: Nat Sakimura Cc: secdir ; IETF oauth WG ; last-c...@ietf.org; draft-ietf-oauth-jwsreq@ietf.org

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR): IPR Confirmation

I'm not aware of any IPR that pertains to this specification. -- Mike -Original Message- From: Hannes Tschofenig Sent: Monday, September 21, 2020 12:22 PM To: John Bradley ; nat@nat.consulting; Mike Jones Cc: oauth@ietf.org Subject: JWT Secured

Re: [OAUTH-WG] WGLC Review of PAR

I agree with Dick that it would be a mistake to make the URL one-time use. It’s unenforceable and unnecessarily gets in the way of valuable deployment patterns. From: OAuth On Behalf Of Dick Hardt Sent: Thursday, August 27, 2020 9:12 AM To: Justin Richer Cc: Brian Campbell ; oauth Subject:

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

I agree with Dick’s observation about the privacy implications of using an Introspection Endpoint. That’s why it’s preferable to not use one at all and instead directly have the Resource understand the Access Token. One way of doing this is the JWT Access Token spec. There are plenty of

Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)

claims they may or may not contain. Or is that breaking? S pozdravem, Filip Skokan On Fri, 14 Aug 2020 at 00:59, Mike Jones mailto:40microsoft@dmarc.ietf.org>> wrote: At Nat's request, I've created a pull request addressing Cross-JWT Confusion security considerations.

Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)

At Nat's request, I've created a pull request addressing Cross-JWT Confusion security considerations. It addresses both Brian's comment and the IESG comments about explicit typing. See the full PR at https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10. See the source diffs at

Re: [OAUTH-WG] ECDH-1PU encryption algorithm

I’m likewise supportive of the work. Note that COSE working group is currently open whereas JOSE is closed, so if you want working group review, I’d submit specs to COSE soon. As background, I worked the spec https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-08 in COSE which

Re: [OAUTH-WG] swapping a jwsreq/JAR JWT for a client authentication JWT

The “Use Explicit Typing” section of the JWT BCP explicitly says: “Explicit typing is RECOMMENDED for new uses of JWTs.” It does not recommend trying to retrofit “typ” values for existing JWT uses, as that would often cause breaking

Re: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in place of IETF108

+1 from me too From: OAuth On Behalf Of Torsten Lodderstedt Sent: Sunday, June 21, 2020 2:42 PM To: Falk Andreas Cc: oauth Subject: Re: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in place of IETF108 +1 Am 21.06.2020 um 22:39 schrieb Falk Andreas

Re: [OAUTH-WG] [EXTERNAL] Re: Mix-Up Revisited

I support documenting the use of the issuer to mitigate mix-up attacks. Note that while issuer was first defined by OpenID Connect, it became art of OAuth 2.0 in RFC 8414 - OAuth 2.0 Authorization Server Metadata. -- Mike From: OAuth On

Re: [OAUTH-WG] Downgrade attacks on PKCE

Hardt Sent: Monday, June 1, 2020 10:54 AM To: Neil Madden Cc: Daniel Fett ; oauth@ietf.org; Mike Jones Subject: Re: [OAUTH-WG] Downgrade attacks on PKCE Mike: what are your thoughts on the options? ᐧ On Sat, May 30, 2020 at 4:39 AM Neil Madden mailto:neil.mad...@forgerock.com>> wro

Re: [OAUTH-WG] [EXTERNAL] Re: proposed resolution for PKCE in OAuth 2.1

(or corresponding static registration). Otherwise, it should be up to the client which of the mechanisms to use. -- Mike From: Aaron Parecki Sent: Wednesday, May 20, 2020 3:48 PM To: Nov Matake Cc: Mike Jones ; oauth@ietf.org Subject

Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

between `code_challenge` and `nonce`. For example, the presence of a `nonce` parameter in the authorization request is not sufficient to determine that the `code_verifier` check can be skipped. Of course, we need to adapt the wording in the Security BCP accordingly. -Daniel Am 15.05.20 um 01:01 s

Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

ers. Public clients MUST use the >>> "code_challenge” with a transaction-specific value that is securely >>> bound to the client and the user agent in which the transaction was >>> started. Confidential clients MUST use the “code_challenge” in the >>> same way or ot

Re: [OAUTH-WG] Incorporate or Reference RFC8628 Device Authorization Grant?

Works for me From: OAuth On Behalf Of Aaron Parecki Sent: Tuesday, May 12, 2020 2:44 PM To: Phillip Hunt Cc: OAuth WG Subject: Re: [OAUTH-WG] Incorporate or Reference RFC8628 Device Authorization Grant? I have a draft I'm about to publish after our recent discussions. One of the changes is

Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

From: Aaron Parecki Sent: Monday, May 11, 2020 4:55 PM To: OAuth WG Cc: Neil Madden ; Mike Jones Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1 Thank you Neil. To address Mike's concerns in the previous threads, I would like to also update section 9.7 with the following

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

The difference is that OAuth 2.1 is supposed to compatible with OAuth 2.0 (which is my whole goal here), whereas OAuth 2.0 was incompatible with OAuth 1.0 by design. From: Dick Hardt Sent: Sunday, May 10, 2020 12:58 PM To: Mike Jones Cc: Torsten Lodderstedt ; oauth@ietf.org Subject: Re

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

Exactly! I believe that this also the same point that Brian Campbell was making earlier about interoperability implications. -- Mike From: Neil Madden Sent: Sunday, May 10, 2020 1:06 PM To: Dick Hardt Cc: Mike Jones ; oauth@ietf.org

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

the draft, then there would be no perception problem, as it would be clear that adoption of 2.1 would be voluntary, just like the other extension specs. From: Dick Hardt Sent: Sunday, May 10, 2020 12:38 PM To: Mike Jones Cc: Torsten Lodderstedt ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.1

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

s take on this. -- Mike From: Torsten Lodderstedt Sent: Sunday, May 10, 2020 3:17 AM To: Mike Jones Cc: Aaron Parecki ; Dick Hardt ; OAuth WG Subject: Re: OAuth 2.1 - require PKCE? Mike Jones mailto:michael.jo...@microsoft.com>> schrieb am Sa. 9. Mai 2020 um 20:46: There’s a huge ecosystem of succes

Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.1 - require PKCE?

. -- Mike From: Torsten Lodderstedt Sent: Sunday, May 10, 2020 3:15 AM To: Mike Jones Cc: Daniel Fett ; oauth@ietf.org Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE? Hi Mike, Mike Jones mailto:40microsoft@dmarc.ietf.org>> schrieb am Fr. 8. Mai 2020 um 18:55: OAu

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

: Aaron Parecki Sent: Friday, May 8, 2020 8:34 PM To: OAuth WG Cc: Dick Hardt ; Torsten Lodderstedt ; Mike Jones Subject: Re: OAuth 2.1 - require PKCE? Aaron, I believe you’re trying to optimize the wrong thing. You’re concerned about “the amount of explanation this will take”. That’s optimizing

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

of approval by the OAuth working group. -- Mike From: Phillip Hunt Sent: Friday, May 8, 2020 12:45 PM To: Dick Hardt Cc: Philippe De Ryck ; Mike Jones ; OAuth WG Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE? We are not discussing

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

Daniel, you wrote: > We would then have: > - use PKCE, except if you use OIDC with a nonce, then you don't need PKCE, > except if you are a public client, then you still need PKCE. > - use state, except if you use PKCE, then you don't need state. I believe that this is an accurate statement of

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

result. Let me know when you’re ready to incorporate them into the spec text. -- Mike From: Aaron Parecki Sent: Thursday, May 7, 2020 4:39 PM To: Dick Hardt Cc: OAuth WG ; Torsten Lodderstedt ; Mike Jones Subject: Re: OAuth 2.1 - require

[OAUTH-WG] Aligning PKCE requirements within the OAuth Security BCP

As is being discussed in the thread "[OAUTH-WG] OAuth 2.1 - require PKCE?", https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 has inconsistent requirements for PKCE support between clients and servers. Per the first paragraph, clients must either use PKCE or use the

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

for the change to the Security BCP to make it self-consistent. -- Mike From: Aaron Parecki Sent: Wednesday, May 6, 2020 1:43 PM To: Mike Jones Cc: Dick Hardt ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE? Going back

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

. -- Mike From: Phillip Hunt Sent: Wednesday, May 6, 2020 1:16 PM To: Mike Jones Cc: Aaron Parecki ; Steinar Noem ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE? Why couldn’t OIDC evolve as a spec to conform and match FAPI and 2.1? Phil On May 6, 2020, at 12:34

  1   2   3   4   5   6   7   8   9   10   >