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

2019-01-11 Thread Mike Jones
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

2019-01-19 Thread Mike Jones
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

2019-01-22 Thread Mike Jones
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

2019-01-23 Thread Mike Jones
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

2019-01-24 Thread Mike Jones
: 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

2019-01-28 Thread Mike Jones
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

2019-02-22 Thread Mike Jones
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”

2019-03-11 Thread Mike Jones
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

2019-03-26 Thread Mike Jones
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

2019-03-28 Thread Mike Jones
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

2019-04-03 Thread Mike Jones
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

2019-04-04 Thread Mike Jones
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

2019-04-04 Thread Mike Jones
: 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

2019-07-17 Thread Mike Jones
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

2019-07-24 Thread Mike Jones
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

2019-07-25 Thread Mike Jones
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

2019-08-17 Thread Mike Jones
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

2019-09-16 Thread Mike Jones
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

2019-10-16 Thread Mike Jones
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

2019-10-22 Thread Mike Jones
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

2019-11-19 Thread 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

2019-11-22 Thread Mike Jones
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

2019-11-22 Thread Mike Jones
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

2019-11-27 Thread Mike Jones
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

2019-12-27 Thread Mike Jones
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

2019-12-28 Thread Mike Jones
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

2020-01-09 Thread Mike Jones
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

2020-01-09 Thread Mike Jones
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

2020-01-10 Thread Mike Jones
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?

2020-01-13 Thread Mike Jones
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

2020-01-15 Thread Mike Jones
. -- 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

2020-01-15 Thread Mike Jones
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)

2020-01-31 Thread Mike Jones
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

2020-02-12 Thread Mike Jones
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

2020-02-19 Thread Mike Jones
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

2020-02-19 Thread Mike Jones
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

2020-02-21 Thread Mike Jones
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

2020-02-21 Thread Mike Jones
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

2020-03-09 Thread Mike Jones
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

2020-03-10 Thread Mike Jones
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

2020-03-10 Thread Mike Jones
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

2020-03-10 Thread Mike Jones
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

2020-03-10 Thread Mike Jones
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

2020-03-12 Thread Mike Jones
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

2020-03-12 Thread Mike Jones
+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

2020-03-15 Thread Mike Jones
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

2020-03-15 Thread Mike Jones
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

2020-03-16 Thread Mike Jones
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

2020-03-16 Thread Mike Jones
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)

2020-03-16 Thread Mike Jones
+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

2020-03-17 Thread Mike Jones
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

2020-04-20 Thread Mike Jones
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"

2020-04-21 Thread Mike Jones
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

2020-04-23 Thread Mike Jones
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

2020-04-26 Thread Mike Jones
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

2020-04-28 Thread Mike Jones
. -- 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

2020-04-30 Thread Mike Jones
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?

2020-05-01 Thread Mike Jones
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

2020-05-01 Thread Mike Jones
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?

2020-05-06 Thread Mike Jones
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?

2020-05-06 Thread Mike Jones
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?

2020-05-06 Thread Mike Jones
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?

2020-05-06 Thread Mike Jones
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?

2020-05-06 Thread Mike Jones
. -- 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?

2020-05-06 Thread Mike Jones
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

2020-05-06 Thread Mike Jones
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?

2020-05-07 Thread Mike Jones
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?

2020-05-08 Thread Mike Jones
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?

2020-05-08 Thread Mike Jones
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?

2020-05-09 Thread Mike Jones
: 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?

2020-05-10 Thread Mike Jones
. -- 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?

2020-05-10 Thread Mike Jones
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?

2020-05-10 Thread Mike Jones
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?

2020-05-10 Thread Mike Jones
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?

2020-05-10 Thread Mike Jones
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

2020-05-11 Thread Mike Jones
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?

2020-05-12 Thread Mike Jones
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

2020-05-14 Thread Mike Jones
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

2020-05-19 Thread Mike Jones
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

2020-05-20 Thread Mike Jones
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

2020-06-01 Thread Mike Jones
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

2020-06-18 Thread Mike Jones
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

2020-06-22 Thread Mike Jones
+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

2020-07-23 Thread Mike Jones
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

2020-08-10 Thread Mike Jones
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)

2020-08-13 Thread Mike Jones
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)

2020-08-15 Thread Mike Jones
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

2020-08-26 Thread Mike Jones
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

2020-08-28 Thread Mike Jones
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

2020-10-20 Thread Mike Jones
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

2013-01-30 Thread Mike Jones
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

2013-01-30 Thread Mike Jones
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 )

2013-01-30 Thread Mike Jones
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?

2013-02-04 Thread Mike Jones
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?

2013-02-04 Thread Mike Jones
-- 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

2013-02-06 Thread Mike Jones
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

2013-02-11 Thread Mike Jones
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

2013-02-11 Thread Mike Jones
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)

2013-02-11 Thread Mike Jones
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

2013-02-11 Thread Mike Jones
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   >