Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT)

I would advocate requesting early registration for urn:ietf:params:oauth:grant-type:token-exchange. -- Mike -Original Message- From: Benjamin Kaduk Sent: Friday, January 11, 2019 8:13 AM To: Brian Campbell Cc: The IESG ; oauth ; draft-ietf-oauth-token-

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

I also agree that “resource” should be a specific network-addressable URL whereas a separate audience parameter (like “aud” in JWTs) can refer to one or more logical resources. They are different, if related, things. Note that the ACE WG is proposing to register a logical audience parameter “r

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

o the developer community as it could be. On Sat, Jan 19, 2019 at 12:38 Phil Hunt mailto:phil.h...@oracle.com>> wrote: +1 to Mike and John’s comments. Phil On Jan 19, 2019, at 12:34 PM, Mike Jones mailto:Michael.Jones=40microsoft@dmarc.ietf.org>> wrote: I also agree that “resource

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

oing to create confusion and ultimately not be as useful to the developer community as it could be. On Sat, Jan 19, 2019 at 12:38 Phil Hunt mailto:phil.h...@oracle.com>> wrote: +1 to Mike and John’s comments. Phil On Jan 19, 2019, at 12:34 PM, Mike Jones mailto:Michael.Jones=40micro

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

: Rifaat Shekh-Yusef Sent: Thursday, January 24, 2019 12:46 PM To: George Fletcher Cc: Vittorio Bertocci ; Mike Jones ; oauth@ietf.org Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01 All, This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

019 at 5:13 PM Rifaat Shekh-Yusef mailto:rifaat.i...@gmail..com>> wrote: Hannes sent an update to this meeting here: https://mailarchive.ietf.org/arch/msg/oauth/v8sUMEBGMC24AdWLewAymP-X4kU Regards, Rifaat On Thu, Jan 24, 2019 at 6:20 PM Mike Jones mailto:michael.jo...@microsoft.com>>

Re: [OAUTH-WG] Fwd: AD Review of draft-ietf-oauth-jwt-bcp

Hi Eric, Replies are inline below, prefixed by “Mike>”. In summary, unless you want to see additional text added giving examples of substitution attacks, I believe that -04 addressed all of your review comments. Let us know, and if so, we’ll turn the crank and publish an -05 doing so.

[OAUTH-WG] OAuth Device Flow spec renamed to “OAuth 2.0 Device Authorization Grant”

I made a blog post about the renaming of the device spec and last-minute clarifications applied at http://self-issued.info/?p=1959 and @selfissued. Thanks again to William for doing the heavy lifting! Hopefully this is the version that gets sent to the RFC Edito

[OAUTH-WG] Review of draft-ietf-oauth-signed-http-request-03

There are some deployments that I'm aware of that are considering using draft-ietf-oauth-signed-http-request. Because of that, I've done a detailed review of https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03, which follows. Only substantive issues are discussed. If the draft

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

Good observation, Ludwig. We should do that. -- Mike -Original Message- From: OAuth On Behalf Of Ludwig Seitz Sent: Thursday, March 28, 2019 12:05 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00 On 28/03/2019 11:17, Daniel Fett wro

[OAUTH-WG] DPoP blog post

FYI, I posted about the new DPoP draft at http://self-issued.info/?p=1967 and as @selfissued, asking people to have a look and provide feedback. -- Mike ___ OAuth

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

I agree with George that the subject of a token must be the principal of that token. That what the JWT “sub” claim is for. Indeed, the first sentence of the “sub” definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 is: The "sub" (subject) claim identifies the principal that is the s

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

: Thursday, April 4, 2019 12:59 PM To: Mike Jones Cc: George Fletcher ; Vittorio Bertocci ; IETF oauth WG Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 the definition of RFC 7519 is actually "petitio principii" and a lot of deployments put claims about the Resource Ow

Re: [OAUTH-WG] IETF105 OAuth WG Draft Agenda

I’d be interested in hearing that presentation – particularly the “lessons” part. -- Mike From: OAuth On Behalf Of Richard Backman, Annabelle Sent: Wednesday, July 17, 2019 11:28 AM To: Dick Hardt ; Rifaat Shekh-Yusef Cc: oauth Subject:

[OAUTH-WG] OAuth 2.0 Token Exchange specification sent to the RFC Editor

I just made a blog post about the Token Exchange spec progressing to the RFC Editor queue. Congratulations all! See http://self-issued.info/?p=1992 and https://twitter.com/selfissued for the post. Cheers,

Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

I'm not aware of any conflicts for any of the three sets of dates. -- Mike -Original Message- From: OAuth On Behalf Of Aaron Parecki Sent: Thursday, July 25, 2019 4:07 PM To: Dick Hardt Cc: OAuth WG Subject: Re: [OAUTH-WG] Location and dates for next OAu

[OAUTH-WG] OAuth Device Flow is now RFC 8628

The OAuth Device Flow specification (recently renamed to be the OAuth 2.0 Device Authorization Grant specification) is now RFC 8628. The abstract describes the specification as: The OAuth 2.0 device authorization grant is designed for Internet-connec

Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

Sent: Monday, August 12, 2019 11:09 AM To: Steinar Noem ; Nat Sakimura Cc: Mike Jones ; OAuth WG Subject: RE: [OAUTH-WG] Location and dates for next OAuth Security Workshop I know you were too polite ! From: Steinar Noem mailto:stei...@udelt.no>> Sent: Saturday, August 10, 2019 11:04 AM To: N

Re: [OAUTH-WG] Virtual Interim Meeting - Nov. 4th

I would participate. From: OAuth On Behalf Of Vineet Banga Sent: Wednesday, October 16, 2019 7:19 AM To: Aaron Parecki Cc: oauth Subject: Re: [OAUTH-WG] Virtual Interim Meeting - Nov. 4th I would like to attend as well. Vineet On Wed, Oct 16, 2019 at 6:36 AM Aaron Parecki mailto:aa...@parec

[OAUTH-WG] JSON Web Token Best Current Practices sent to the RFC Editor

I'm pleased to report that the JSON Web Token (JWT) Best Current Practices (BCP) specification is now technically stable and will shortly be an RFC - an Internet standard. Specifically, it has now progressed to the RFC Editor queue, meaning that the only remaining step before finalization is ed

[OAUTH-WG] WGLC review of OAuth 2.0 Security Best Current Practice by Mike Jones

ations - The draft often uses the word "which" when you mean "that".. For instance, in 4.9.2, please change "which could" to "that could" and in 4.11 change "which are" to "that are". There's lots of places to look up the diffe

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

TLS on Web Servers is nearly ubiquitous now and works great. Trying to use mutual TLS on many platforms results in a nearly intractable user experience, where the end-users are asked to install certificates into certificate stores. Success rates for those UXs are very low. And it's even worse

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

I hear you about the difference between Web apps and native apps, Torsten. But using different mechanisms for different application types is a cost in and of itself. It's good to understand the tradeoffs. -- Mike From: OAuth on behalf of Torsten Lodderstedt

[OAUTH-WG] Additional WGLC review of OAuth 2.0 Security Best Current Practice by an AAD developer

oving from the implicit flow to RTs. The damage from exfiltrated RTs is much more severe, but the mitigations are less-specified by the BCPs, and thus seem less well-understood.. Frankly, I think each method of mitigation is worth of its own subsection with more discussion - 4.12.1, 4.12.2, etc.

Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode

I agree with Brian. Please update the text to describe this already safe usage. -- Mike From: OAuth on behalf of Brian Campbell Sent: Friday, December 27, 2019 11:03:30 AM To: oauth Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response types +

Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode

I agree with Brian's suggested text changes. -- Mike From: Brian Campbell Sent: Saturday, December 28, 2019 5:33:24 AM To: Torsten Lodderstedt Cc: Mike Jones ; oauth Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form

Re: [OAUTH-WG] Cryptographic hygiene and the limits of jwks_uri

This a good thing to think about. Thanks for bringing this up, Annabelle. One thing that partially mitigates this is that the “use” and/or “key_ops” attributes can be provided. This can allow signing keys to be differentiated from encryption keys, for instance. I’m not as worried about encryp

Re: [OAUTH-WG] -security-topics-13 and OIDC response types + form_post response mode

Connect. -- Mike From: Brian Campbell Sent: Thursday, January 9, 2020 2:37 PM To: Richard Backman, Annabelle Cc: Mike Jones ; Torsten Lodderstedt ; oauth Subject: Re: [OAUTH-WG] -security-topics-13 and OIDC response types + form_post response m

Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

The technique of replicating JWT claims that need to be publicly visible in an encrypted JWT in the header is defined at https://tools.ietf.org/html/rfc7519#section-5.3. (Thanks to Dick Hardt for bringing this need to my attention as we were finishing the JWT spec.)

Re: [OAUTH-WG] [EXTERNAL] RAR & multiple resources?

Please don’t use RAR as a pandora’s box to introduce unrelated new semantics, including issuing multiple access tokens. -- Mike From: OAuth On Behalf Of Dick Hardt Sent: Monday, January 13, 2020 5:32 PM To: Torsten Lodderstedt ; Brian Campb

Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

. -- Mike From: Vladimir Dzhuvinov Sent: Wednesday, January 15, 2020 1:03 PM To: Takahiko Kawasaki Cc: John Bradley ; Mike Jones ; IETF oauth WG Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object On 14/01/2020 19:20, Takahiko

[OAUTH-WG] OAuth 2.0 Token Exchange is now RFC 8693

The OAuth 2.0 Token Exchange specification is now RFC 8693. The abstract of the specification is: This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens fr

Re: [OAUTH-WG] [EXTERNAL] Re: Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)

I also agree that we must allow client_id to be expressed outside of the signed request, as described by Nat. -- Mike -Original Message- From: OAuth On Behalf Of John Bradley Sent: Friday, January 31, 2020 6:25 AM To: Nat Sakimura ; Benjamin Kaduk Cc: oa

[OAUTH-WG] JWTs helping combat fraudulent and unwanted telephone calls

I wanted to bring two excellent articles by the IETF on work by the STIR working group to combat fraudulent and unwanted telephone calls to your attention: * STIR into Action, January 2020: Abstract: Provi

[OAUTH-WG] JSON Web Token Best Current Practices is now RFC 8725 and BCP 225

The OAuth 2.0 Token Exchange specification is now RFC 8725 and BCP 225. The abstract of the specification is: JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set o

Re: [OAUTH-WG] [EXTERNAL] Re: JSON Web Token Best Current Practices is now RFC 8725 and BCP 225

Oops – cut and paste error! I’ve fixed this in the blog post at https://self-issued.info/?p=2052. From: Dick Hardt Sent: Wednesday, February 19, 2020 4:43 PM To: Mike Jones Cc: oauth@ietf.org Subject: [EXTERNAL] Re: [OAUTH-WG] JSON Web Token Best Current Practices is now RFC 8725 and BCP 225

[OAUTH-WG] Review of OAuth 2.0 for Browser-Based Apps

I did a cover-to-cover read of draft-ietf-oauth-browser-based-apps-04. My review comments follow in three sections: substantive comments on the text, substantive overall issues to consider (provided by Microsoft product engin

[OAUTH-WG] More product group review comments on the OAuth 2.0 for Browser-Based Apps spec

More comments hot off the presses from a Microsoft product architect... https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04#section-6.2

[OAUTH-WG] OAuth 2.0 DPoP for the Implicit Flow

As I previously described, members of the OAuth working group have developed a simplified approach to providing application-level proof-of-possession protections for OAuth 2.0 access tokens and refresh tokens. This approach is called OAuth 2.0 Demonstration of

Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.0 DPoP for the Implicit Flow

Parecki Sent: Tuesday, March 10, 2020 6:47 AM To: Justin Richer Cc: Mike Jones ; Rifaat Shekh-Yusef ; oauth@ietf.org Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.0 DPoP for the Implicit Flow This is my sentiment as well, I would not support this text being added to the DPoP draft. Aaron On Tue, Mar

Re: [OAUTH-WG] [EXTERNAL] Re: OAuth Topics for Vancouver

I’d like to request 10 minutes on the agenda after Brian to discuss DPoP support for the implicit flow, as described in https://tools.ietf.org/html/draft-jones-oauth-dpop-implicit-00. Thanks,

Re: [OAUTH-WG] [EXTERNAL] Re: OAuth 2.0 DPoP for the Implicit Flow

Sent: Tuesday, March 10, 2020 12:01 AM To: Mike Jones Cc: oauth@ietf.org Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.0 DPoP for the Implicit Flow Hi Mike, Thank you for the implicit dpop draft, quick questions - what htu and htm should be used when used with PAR? - is it fair to say that

Re: [OAUTH-WG] [EXTERNAL] Re: Corona Virus and Vancouver

I plan to be in Vancouver unless the meeting is cancelled. -- Mike From: OAuth On Behalf Of Justin Richer Sent: Tuesday, March 10, 2020 6:46 AM To: Daniel Fett Cc: oauth@ietf.org Subject: [EXTERNAL] Re: [OAUTH-WG] Corona Virus and Vancouver

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

I agree that we should restore the client_id functionality. Thanks for moving this forward! -- Mike From: OAuth On Behalf Of Nat Sakimura Sent: Monday, February 24, 2020 6:18 PM To: John Bradley Cc: oauth Subject: Re: [OAUTH-WG] Fwd: [EX

Re: [OAUTH-WG] [EXTERNAL] Re: First Draft of OAuth 2.1

+1 on sender constraints being RECOMMENDED but not REQUIRED. Different applications have different risk profiles. We should enable people to make reasonable choices for their use cases. Remember that OAuth 1.0 was rejected by the marketplace because implementing the sender-constraint mechanis

[OAUTH-WG] Clarifying the scope of the OAuth 2.1 spec

The abstract of draft-parecki-oauth-v2-1 concludes with this text: This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749. While accurate, I don't believe that this text captures the full intent of the OAuth 2

Re: [OAUTH-WG] [EXTERNAL] Re: Clarifying the scope of the OAuth 2.1 spec

Thanks, -- Mike From: Dick Hardt Sent: Sunday, March 15, 2020 6:50 PM To: Mike Jones Cc: aa...@parecki.com; tors...@lodderstedt.net; oauth@ietf.org Subject: [EXTERNAL] Re: Clarifying the scope of the OAuth 2.1 spec Hi Mike I like where you are going with this, bu

Re: [OAUTH-WG] Clarifying the scope of the OAuth 2.1 spec

ussion. -- Mike From: Dick Hardt Sent: Monday, March 16, 2020 8:36 AM To: Mike Jones Cc: aa...@parecki.com; tors...@lodderstedt.net; oauth@ietf.org Subject: Re: Clarifying the scope of the OAuth 2.1 spec Hi Mike I'm aligned on the overall messaging. Sorry I was not clear on my feedback

Re: [OAUTH-WG] [EXTERNAL] Re: Clarifying the scope of the OAuth 2.1 spec

Perfect – thanks for listening. -- Mike From: Dick Hardt Sent: Monday, March 16, 2020 12:32 PM To: Mike Jones Cc: aa...@parecki.com; tors...@lodderstedt.net; oauth@ietf.org Subject: [EXTERNAL] Re: Clarifying the scope of the OAuth 2.1 spec

Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (6017)

+1 From: OAuth On Behalf Of Brian Campbell Sent: Monday, March 16, 2020 3:05 PM To: RFC Errata System Cc: 1983-01...@gmx.net; oauth Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (6017) While the use of "application/x-www-form-urlencoded" on the username (client_id) and password

Re: [OAUTH-WG] Call for Adoption: DPoP

I am for adoption of DPoP. -- Mike From: OAuth On Behalf Of Rifaat Shekh-Yusef Sent: Tuesday, March 17, 2020 5:21 AM To: oauth Subject: [OAUTH-WG] Call for Adoption: DPoP All, As per the conclusion of the PoP interim meeting, this is a ca

[OAUTH-WG] Caution about open redirectors using the state parameter

I've seen several circumstances where "clever" clients implement an open redirector by encoding a URL to redirect to in the state parameter value. Attackers can then utilize this open redirector by choosing a state value. Can we please add an explicit prohibition of this practice in draft-ietf

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

This feedback is from a Microsoft engineer on the Azure Active Directory identity team: * 1 * Missing space at “Tokens(JWT)” * 2.1 * Use of “MUST” saying one form must be used, followed by “SHOULD” saying a different format should be used is a bit confusing. I get the poin

Re: [OAUTH-WG] OAuth GREASE

I will point out that OpenID Connect certification tests that the implementation ignores not-understood request parameters. So at least all the authorization servers that are also certified OpenID Connect implementations should be successfully ignoring not-understood parameters. I’d personally

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.txt

The next errata version of OpenID Connect Discovery will register the parameter request_object_signing_alg_values_supported and other parameters not previously registered. See https://openid.net/specs/openid-connect-discovery-1_0-29.html for the latest published errata draft. I can make a requ

Re: [OAUTH-WG] [EXTERNAL] Re: I-D Action: draft-ietf-oauth-jwsreq-21.txt

. -- Mike From: nat=sakimura@mg.sakimura.org On Behalf Of Nat Sakimura Sent: Sunday, April 26, 2020 10:29 AM To: Torsten Lodderstedt ; John Bradley ; Mike Jones Cc: oauth Subject: [EXTERNAL] Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.txt Thanks Mike. Right in as much as I never

[OAUTH-WG] Microsoft feedback on DPoP during April 2020 IIW session

ly more efficient than asymmetric keys. In discussions between John Bradley, Brian Campbell, and Mike Jones at IETF 106, John worked out how to deliver the symmetric key to the Token Endpoint without an extra round trip, however it would likely be more complicated to deliver it to the resource witho

Re: [OAUTH-WG] PAR - Can AS/client require request object?

Works for me. From: OAuth On Behalf Of Torsten Lodderstedt Sent: Friday, May 1, 2020 2:51 AM To: Brian Campbell Cc: oauth Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object? Filip´s proposal works for me. Are there any objections? Brian Campbell mailto:40pingidentity@dma

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.txt

I believe that Nat hasn’t yet published the JAR updates that Brian made. Do we want to add this text to the editor’s draft before publishing? -- Mike From: Torsten Lodderstedt Sent: Friday, May 1, 2020 2:37 AM To: Mike Jones Cc: John

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

The disadvantage of requiring PKCE for OpenID Connect implementations is that you’re trying to add a normative requirement that’s not required of OpenID Connect deployments today, which would bifurcate the ecosystem. There are hundreds of implementations (including the 141 certified ones at ht

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

ready working and secure clients. -- Mike From: Aaron Parecki Sent: Wednesday, May 6, 2020 11:56 AM To: Mike Jones Cc: Dick Hardt ; oauth@ietf.org Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE? > In particular, authorization servers sh

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

Wed, May 6, 2020 at 12:22 PM Mike Jones mailto:michael.jo...@microsoft.com>> wrote: Aaron, the section you cited at https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 makes it clear that clients can support EITHER PKCE or the OpenID Connect nonce. The text is:

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

stewards of the OAuth ecosystem. -- Mike From: Aaron Parecki Sent: Wednesday, May 6, 2020 12:29 PM To: Steinar Noem Cc: Phillip Hunt ; Mike Jones ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE? I should add that even some

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

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

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 to this

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

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

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 th

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?

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

n 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] 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?

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

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 a

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

zation response by attackers. 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 &g

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

ot switch 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

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

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] 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: 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 B

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 mailto:andreas.f...@novatec-gmbh.de

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 cha

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 als

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 https://bi

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

about the 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 secu

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 other

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

Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax

Let JSON do the parsing for you From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Wednesday, January 30, 2013 2:29 PM To: Todd W Lainhart Cc: IETF oauth WG Subject: Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax It's not meant to follo

Re: [OAUTH-WG] draft-richer-oauth-introspection-01 scope syntax

Having two ways to do something almost always hurts interop and always makes implementations bigger From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Craig McClanahan Sent: Wednesday, January 30, 2013 2:48 PM To: Justin Richer Cc: IETF oauth WG Subject: Re: [OAUTH-WG] dra

Re: [OAUTH-WG] Registration endpoints? (was: Re: Concerning OAuth )

OAuth *never* makes a distinction between what GET and POST do. (Yes, they pass the input parameters differently.) I *really* don’t think we should start doing this now for new operations. It will likely only confuse developers and make things harder for them - especially when using software

[OAUTH-WG] Should registration request be form-urlencoded or JSON?

Now that we're returning the registration state as JSON, it's pretty inconsistent for the registration request to instead be form-url-encoded. The case can be made for switching to JSON now - especially in light of possibly wanting to convey some structured information at registration time. I re

Re: [OAUTH-WG] Should registration request be form-urlencoded or JSON?

-- Mike From: Richer, Justin P. [mailto:jric...@mitre.org] Sent: Monday, February 04, 2013 1:34 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Should registration request be form-urlencoded or JSON? For history, the original UMA registration spec from whence

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

Hi Justin, Thanks for working to make progress on the OAuth Registration draft. Reading through the changes, it seems to me that a number of changes were made that there wasn't yet working consensus for - in fact, some of which I don't recall being discussed by the working group at all. These

Re: [OAUTH-WG] Registration: HAL _links structure and client self-URL

It seems like significant overkill, bordering on silliness, to use the syntax _links: { "self": { "href": "https://server.example.com/register/s6BhdRkqt3"; } } to represent a value that could be more straightforwardly represented as: "registration_access_url": "https

Re: [OAUTH-WG] Registration: Client secret rotation

The rotate_secret operation was added to OpenID Connect Registration as a workaround to the fact that registration updates used to be authenticated using the client secret, so it seemed overly dangerous to have an update operation potentially return an updated secret and have the secret be lost

Re: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)

At most, there should be two endpoints - creation and management - for a client, but the protocol should be structured such that they *can* be at the same URL, if the server so chooses. A simple way to accomplish this is to require that the client_id value be provided as an input parameter on u

Re: [OAUTH-WG] Registration: RESTful client lifecycle management

I'm fine with the use of the different verbs, provided that the client_id is present to distinguish between "register" and "update" operations for implementations that want to use it in that matter, as I'd previously written. (*Your* implementation is free to not use this value, if you so choos

  1   2   3   4   5   6   7   8   9   10   >