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

[Mike Jones]

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@ietf.org
Subject: Re: [IANA #1270471] expert review for draft-ietf-oauth-dpop (jwt)

Thanks David, I approve the JWT claims registrations.

On Thu, Apr 6, 2023 at 9:39 AM David Dong via RT 
mailto:drafts-expert-review-comm...@iana.org>>
 wrote:
Dear John, Brian, Michael and Chuck (cc: oauth WG),

As the designated experts for the JSON Web Token Claims registry, can you 
review the proposed registration in draft-ietf-oauth-dpop for us? Please see:

https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

The due date is Wednesday April 12th, 2023. This document is on next week's 
IESG telechat agenda.

-
Seventh, in the JSON Web Token Claims also on the JSON Web Token (JWT) registry 
page located at:

https://www.iana.org/assignments/jwt/

three new web token claims will be registered as follows:

Claim Name: htm
Claim Description: The HTTP method of the request
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 4.2 ]

Claim Name: htu
Claim Description: The HTTP URI of the request (without query and fragment 
parts)
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 4.2 ]

Claim Name: ath
Claim Description: The base64url encoded SHA-256 hash of the ASCII encoding of 
the associated access token's value
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 4.2 ]

As this section of the draft also requests registrations in a Specification 
Required (see RFC 8126) registry, the IESG-designated experts for the JSON Web 
Token Claims registry have asked that you send a review request to the mailing 
list specified in RFC7519. This review must be completed before the document's 
IANA state can be changed to "IANA OK."
-

If this registration is OK, when the IESG approves the document for 
publication, we'll make the registration at:

https://www.iana.org/assignments/jwt/

With thanks,

David Dong
IANA Services Specialist

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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@ietf.org
Subject: Re: [IANA #1270370] Request to register OAuth Authorization Server 
Metadata: dpop_signing_alg_values_supported

I approve the request.
Sent from my iPhone


On Apr 5, 2023, at 1:59 PM, Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:

I approve this request.

On Wed, Apr 5, 2023 at 8:47 AM David Dong via RT 
mailto:drafts-expert-review-comm...@iana.org>>
 wrote:
Dear Michael, Nat, John and Dick (cc: oauth WG / review mailing list),

As the designated experts for the OAuth Authorization Server Metadata registry, 
can you review the proposed registration in draft-ietf-oauth-dpop for us? 
Please see:

https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

-
Tenth, in the OAuth Authorization Server Metadata also on the OAuth Parameters 
registry page located at:

https://www.iana.org/assignments/oauth-parameters/

a single, new parameter is to be registered as follows:

Metadata Name: dpop_signing_alg_values_supported
Metadata Description: JSON array containing a list of the JWS algorithms 
supported for DPoP proof JWTs
Change Controller: IETF
Specification Document(s): [ RFC-to-be; Section 5.1 ]
-

The due date is Wednesday April 12th, 2023. This document is on next week's 
IESG telechat agenda.

If this registration is OK, when the IESG approves the document for 
publication, we'll make the registration at:

https://www.iana.org/assignments/oauth-parameters/

Unless you ask us to wait for the other reviewers, we’ll act on the first 
response we receive.

With thanks,

David Dong
IANA Services Specialist
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

Hi Mark,

We've published https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-14.html, 
which incorporates the PR.  Could you please approve IANA registration of the 
HTTP fields on that basis?

Thanks again for your help with the draft.

   -- 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.


From: Mark Nottingham 
mailto:mnot=40mnot@dmarc.ietf.org>>
Sent: Tuesday, March 7, 2023 7:55:29 PM
To: Mike Jones mailto:michael.jo...@microsoft.com>>
Cc: Brian Campbell 
mailto:bcampb...@pingidentity.com>>; Amanda Baber 
via RT 
mailto:drafts-expert-review-comm...@iana.org>>;
 oauth@ietf.org<mailto:oauth@ietf.org> mailto:oauth@ietf.org>>; 
Roy Fielding mailto:field...@gbiv.com>>
Subject: Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop 
(http-fields)

Hi Mike,

Thanks. I left a comment on the PR, suggesting two small tweaks.

Cheers,


> On 8 Mar 2023, at 2:33 pm, Mike Jones 
> mailto:Michael.Jones=40microsoft@dmarc.ietf.org>>
>  wrote:
>
> Hi Mark,
>
> I've created the pull request 
> https://github.com/danielfett/draft-dpop/pull/180 to incorporate your 
> suggestions.  Please also see some additional replies below, which are 
> prefixed by "Mike>".
>
> Please let us know if you'd like to see any changes to the PR before we merge 
> it 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' 
> mailto:mnot=40mnot@dmarc.ietf.org>>; 
> Brian Campbell 
> mailto:bcampbell=40pingidentity@dmarc.ietf.org>>
> Cc: Amanda Baber via RT 
> mailto:drafts-expert-review-comm...@iana.org>>;
>  oauth@ietf.org<mailto:oauth@ietf.org>; Roy Fielding 
> mailto:field...@gbiv.com>>
> Subject: 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 
>> specifying (for example) what happens when two header values (and/or fields) 
>> are present (as per below). SF does a lot of the legwork here, even if from 
>> a type system standpoint it's not a perfect fit.
>
> I agree that we should specify these things - probably using language 
> parallel to that in the SF draft, where appropriate.  I also share your 
> assessment that, unfortunately, the SF type system is not an ideal fit for 
> the DPoP headers.
>
> Mike> 
> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-13.html#name-checking-dpop-proofs
>  does include the validation check "there is not more than one DPoP HTTP 
> request header field".  In the PR, I also explicitly added that the there is 
> a single field value.
>
>> That said, personally I'd deconstruct the JWT and convey it as separate 
>> binary values, so that if binary structured headers ever does catch on, it 
>> can get the perf/compactness advantages of that.
>
> Deconstructing the JWT would entail defining a new JWT serialization 
> (representation).  Currently there is exactly one JWT serialization and this 
> specification uses it.  I suspect developers would like us to keep it that 
> way.
>
> Only one of the fields of a signed JWT is actually binary (the signature); 
> the header and payload are JSON.  All are encoded using the base64 URL-safe 
> character set (letters, numbers, -, and _ with no trailing =s) for safe 
> transmission with encoded fields separated by the also URL-safe character 
> period.  Furthermore, the signature is computed over the base64url-encoded 
> values of the first two fields with a period between them.  The base64url 
> encoding and concatenation is integral to the computation of the signature.  
> Any different serialization would still have to perform these computations.
>
> (Note also that some JWTs have three base64url-encoded fields separated by 
> period characters and some have five, depending upon whether they are signed 
> (three) or encrypted (five); deconstructing a value with a variable number of 
> non-independent fields seems like significant unnecessary complexity.)
>
&

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

[Mike Jones]

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 endpoints directly accessed by Clients
  SHOULD support the use of
  Cross-Origin Resource Sharing (CORS)
  to enable JavaScript Clients and other browser-based Clients to 
access them.
  CORS MUST NOT be used at the Authorization Endpoint
  as it is redirected to by the client and not directly accessed.


Relevant background information can be found at 
https://bitbucket.org/openid/connect/issues/980 and 
https://bitbucket.org/openid/connect/pull-requests/338/errata-specified-the-use-of-cors-at.

   -- Mike

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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

Hi Mike,

Thanks. I left a comment on the PR, suggesting two small tweaks.

Cheers,


> On 8 Mar 2023, at 2:33 pm, Mike Jones 
>  wrote:
>
> Hi Mark,
>
> I've created the pull request 
> https://github.com/danielfett/draft-dpop/pull/180 to incorporate your 
> suggestions.  Please also see some additional replies below, which are 
> prefixed by "Mike>".
>
> Please let us know if you'd like to see any changes to the PR before we merge 
> it 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 ; 
> oauth@ietf.org; Roy Fielding 
> Subject: 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 
>> specifying (for example) what happens when two header values (and/or fields) 
>> are present (as per below). SF does a lot of the legwork here, even if from 
>> a type system standpoint it's not a perfect fit.
>
> I agree that we should specify these things - probably using language 
> parallel to that in the SF draft, where appropriate.  I also share your 
> assessment that, unfortunately, the SF type system is not an ideal fit for 
> the DPoP headers.
>
> Mike> 
> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-13.html#name-checking-dpop-proofs
>  does include the validation check "there is not more than one DPoP HTTP 
> request header field".  In the PR, I also explicitly added that the there is 
> a single field value.
>
>> That said, personally I'd deconstruct the JWT and convey it as separate 
>> binary values, so that if binary structured headers ever does catch on, it 
>> can get the perf/compactness advantages of that.
>
> Deconstructing the JWT would entail defining a new JWT serialization 
> (representation).  Currently there is exactly one JWT serialization and this 
> specification uses it.  I suspect developers would like us to keep it that 
> way.
>
> Only one of the fields of a signed JWT is actually binary (the signature); 
> the header and payload are JSON.  All are encoded using the base64 URL-safe 
> character set (letters, numbers, -, and _ with no trailing =s) for safe 
> transmission with encoded fields separated by the also URL-safe character 
> period.  Furthermore, the signature is computed over the base64url-encoded 
> values of the first two fields with a period between them.  The base64url 
> encoding and concatenation is integral to the computation of the signature.  
> Any different serialization would still have to perform these computations.
>
> (Note also that some JWTs have three base64url-encoded fields separated by 
> period characters and some have five, depending upon whether they are signed 
> (three) or encrypted (five); deconstructing a value with a variable number of 
> non-independent fields seems like significant unnecessary complexity.)
>
>>> ABNF syntax for the nonce value is provided at 
>>> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-12.html#section-8-9 
>>> along with the description of its use in the DPoP exchange.
>
>> I see. It'd be better if it were explicitly called out as the syntax for the 
>> field (ideally with a section title that makes this clear), rather than 
>> making the reader do that work.
>
> Mike> The nonce syntax ABNF now has its own section title in the PR.
>
> I'm fine with us making the editorial improvement that you suggest.
>
>>> I believe that the SF String type would accommodate the content we intended 
>>> to allow servers to use for the nonce (it's basically a server chosen value 
>>> that the client treats as opaque and sends back in subsequent DPoP proof 
>>> JWTs). However, that would be a breaking change, which shouldn't be 
>>> undertaken lightly.
>
>> Right. It really depends on how advanced deployment of this is; if there's 
>> only modest production use, it ma

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

[Mike Jones]

Hi Mark,

I've created the pull request https://github.com/danielfett/draft-dpop/pull/180 
to incorporate your suggestions.  Please also see some additional replies 
below, which are prefixed by "Mike>".

Please let us know if you'd like to see any changes to the PR before we merge 
it 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 ; 
oauth@ietf.org; Roy Fielding 
Subject: 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 specifying 
> (for example) what happens when two header values (and/or fields) are present 
> (as per below). SF does a lot of the legwork here, even if from a type system 
> standpoint it's not a perfect fit.

I agree that we should specify these things - probably using language parallel 
to that in the SF draft, where appropriate.  I also share your assessment that, 
unfortunately, the SF type system is not an ideal fit for the DPoP headers.

Mike> 
https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-13.html#name-checking-dpop-proofs
 does include the validation check "there is not more than one DPoP HTTP 
request header field".  In the PR, I also explicitly added that the there is a 
single field value.

> That said, personally I'd deconstruct the JWT and convey it as separate 
> binary values, so that if binary structured headers ever does catch on, it 
> can get the perf/compactness advantages of that.

Deconstructing the JWT would entail defining a new JWT serialization 
(representation).  Currently there is exactly one JWT serialization and this 
specification uses it.  I suspect developers would like us to keep it that way.

Only one of the fields of a signed JWT is actually binary (the signature); the 
header and payload are JSON.  All are encoded using the base64 URL-safe 
character set (letters, numbers, -, and _ with no trailing =s) for safe 
transmission with encoded fields separated by the also URL-safe character 
period.  Furthermore, the signature is computed over the base64url-encoded 
values of the first two fields with a period between them.  The base64url 
encoding and concatenation is integral to the computation of the signature.  
Any different serialization would still have to perform these computations.

(Note also that some JWTs have three base64url-encoded fields separated by 
period characters and some have five, depending upon whether they are signed 
(three) or encrypted (five); deconstructing a value with a variable number of 
non-independent fields seems like significant unnecessary complexity.)

>> ABNF syntax for the nonce value is provided at 
>> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-12.html#section-8-9 
>> along with the description of its use in the DPoP exchange.

> I see. It'd be better if it were explicitly called out as the syntax for the 
> field (ideally with a section title that makes this clear), rather than 
> making the reader do that work.

Mike> The nonce syntax ABNF now has its own section title in the PR.

I'm fine with us making the editorial improvement that you suggest.

>> I believe that the SF String type would accommodate the content we intended 
>> to allow servers to use for the nonce (it's basically a server chosen value 
>> that the client treats as opaque and sends back in subsequent DPoP proof 
>> JWTs). However, that would be a breaking change, which shouldn't be 
>> undertaken lightly.

> Right. It really depends on how advanced deployment of this is; if there's 
> only modest production use, it may still be reasonable to make such a change 
> (especially keeping in mind that people who adopt drafts need to bear the 
> consequences of doing so).

I'm with Brian here.  I don't believe that the cost/benefit tradeoff of the 
breaking change versus using the SF String type is a good one.

> To be concrete -- what should an implementation do when it receives two DPoP 
> header fields, both with valid values? When it receives one with two 
> comma-separated values?

These are great questions.  I'll commit to us answering them in the next draft.

Mike> Per my earlier comment about the validation rules, these issues are both 
addressed in the rules.

>>> - The long line-wrapped example in Section 4.1 would benefit from RFC8792 
>>

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

[Mike Jones]

Per my reply on your review thread, Mark, I plan to make those updates shortly. 
Thanks again for your useful review.

Best wishes,
-- Mike


From: Mark Nottingham 
Sent: Thursday, February 9, 2023 11:42:34 AM
To: Amanda Baber via RT 
Cc: oauth@ietf.org ; 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 was addressed in the latest 
draft.

Much of it was general review, not about the header registration; from that 
perspective, I note that the DPoP-Nonce header field syntax still isn't 
explicitly defined.

Cheers,



> On 8 Feb 2023, at 6:12 am, David Dong via RT 
>  wrote:
>
> Dear Mark / Roy,
>
> We see that this document has been updated; could you please let us know if 
> this is OK or if you have further comments?
>
> Thank you.
>
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
>
> Best regards,
>
> David Dong
> IANA Services Specialist
>
> On Tue Jan 24 07:42:49 2023, michael.jo...@microsoft.com wrote:
>> 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 specifying (for example) what happens when two header
>>> values (and/or fields) are present (as per below). SF does a lot of
>>> the legwork here, even if from a type system standpoint it's not a
>>> perfect fit.
>>
>> I agree that we should specify these things - probably using language
>> parallel to that in the SF draft, where appropriate.  I also share
>> your assessment that, unfortunately, the SF type system is not an
>> ideal fit for the DPoP headers.
>>
>>> That said, personally I'd deconstruct the JWT and convey it as
>>> separate binary values, so that if binary structured headers ever
>>> does catch on, it can get the perf/compactness advantages of that.
>>
>> Deconstructing the JWT would entail defining a new JWT serialization
>> (representation).  Currently there is exactly one JWT serialization
>> and this specification uses it.  I suspect developers would like us to
>> keep it that way.
>>
>> Only one of the fields of a signed JWT is actually binary (the
>> signature); the header and payload are JSON.  All are encoded using
>> the base64 URL-safe character set (letters, numbers, -, and _ with no
>> trailing =s) for safe transmission with encoded fields separated by
>> the also URL-safe character period.  Furthermore, the signature is
>> computed over the base64url-encoded values of the first two fields
>> with a period between them.  The base64url encoding and concatenation
>> is integral to the computation of the signature.  Any different
>> serialization would still have to perform these computations.
>>
>> (Note also that some JWTs have three base64url-encoded fields
>> separated by period characters and some have five, depending upon
>> whether they are signed (three) or encrypted (five); deconstructing a
>> value with a variable number of non-independent fields seems like
>> significant unnecessary complexity.)
>>
>>>> ABNF syntax for the nonce value is provided at
>>>> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-
>>>> 12.html#section-8-9 along with the description of its use in the
>>>> DPoP exchange.
>>
>>> I see. It'd be better if it were explicitly called out as the syntax
>>> for the field (ideally with a section title that makes this clear),
>>> rather than making the reader do that work.
>>
>> I'm fine with us making the editorial improvement that you suggest.
>>
>>>> I believe that the SF String type would accommodate the content we
>>>> intended to allow servers to use for the nonce (it's basically a
>>>> server chosen value that the client treats as opaque and sends back
>>>> in subsequent DPoP proof JWTs). However, that would be a breaking
>>>> change, which shouldn't be undertaken lightly.
>>
>>> Right. It really depends on how advanced deployment of this is; if
>>> there's only modest production use, it may still be reasonable to
>>> make such a change (especially keeping in mind that people who a

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

[Mike Jones]

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 Giuseppe De Marco
Sent: Tuesday, January 24, 2023 1:38 AM
To: oauth 
Cc: flo...@agid.gov.it; michele.dam...@agid.gov.it; cole...@agid.gov.it; 
nunzio.napolit...@agid.gov.it; fa.mar...@ipzs.it; 
michela.c...@teamdigitale.governo.it
Subject: [OAUTH-WG] OAuth 2.0 Protected Resource Metadata

Hello everybody,

I would like to bring to your attention this expired draft: 
https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/

I propose the take up this individual draft for its adoption as an official 
internet draft.
The reason I ask this is that there are implementations of this draft born with 
the need to have metadata for entities of type RS.

The implementation of which I am aware concerns the Italian "Attribute 
Authorities" [0]. OpenID Federation draft also defines the metadata of the 
oauth_resource type [1], taking up the elements defined in the draft in 
question. Recently, an interesting reflection seems to have arisen also in 
OpenID4VCI/OpenID4VP [2].

Thank you for your attention, I hope to read your valuable feedback soon,
best

[0] https://italia.github.io/spid-cie-oidc-docs/en/metadata_aa.html
[1] https://openid.net/specs/openid-connect-federation-1_0.html#section-4.7
[2] 
https://bitbucket.org/openid/connect/issues/1781/do-new-entity-types-required-for-oid4vp
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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 specifying 
> (for example) what happens when two header values (and/or fields) are present 
> (as per below). SF does a lot of the legwork here, even if from a type system 
> standpoint it's not a perfect fit.

I agree that we should specify these things - probably using language parallel 
to that in the SF draft, where appropriate.  I also share your assessment that, 
unfortunately, the SF type system is not an ideal fit for the DPoP headers.

> That said, personally I'd deconstruct the JWT and convey it as separate 
> binary values, so that if binary structured headers ever does catch on, it 
> can get the perf/compactness advantages of that.

Deconstructing the JWT would entail defining a new JWT serialization 
(representation).  Currently there is exactly one JWT serialization and this 
specification uses it.  I suspect developers would like us to keep it that way.

Only one of the fields of a signed JWT is actually binary (the signature); the 
header and payload are JSON.  All are encoded using the base64 URL-safe 
character set (letters, numbers, -, and _ with no trailing =s) for safe 
transmission with encoded fields separated by the also URL-safe character 
period.  Furthermore, the signature is computed over the base64url-encoded 
values of the first two fields with a period between them.  The base64url 
encoding and concatenation is integral to the computation of the signature.  
Any different serialization would still have to perform these computations.

(Note also that some JWTs have three base64url-encoded fields separated by 
period characters and some have five, depending upon whether they are signed 
(three) or encrypted (five); deconstructing a value with a variable number of 
non-independent fields seems like significant unnecessary complexity.)

>> ABNF syntax for the nonce value is provided at 
>> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-12.html#section-8-9 
>> along with the description of its use in the DPoP exchange.

> I see. It'd be better if it were explicitly called out as the syntax for the 
> field (ideally with a section title that makes this clear), rather than 
> making the reader do that work.

I'm fine with us making the editorial improvement that you suggest.

>> I believe that the SF String type would accommodate the content we intended 
>> to allow servers to use for the nonce (it's basically a server chosen value 
>> that the client treats as opaque and sends back in subsequent DPoP proof 
>> JWTs). However, that would be a breaking change, which shouldn't be 
>> undertaken lightly.

> Right. It really depends on how advanced deployment of this is; if there's 
> only modest production use, it may still be reasonable to make such a change 
> (especially keeping in mind that people who adopt drafts need to bear the 
> consequences of doing so).

I'm with Brian here.  I don't believe that the cost/benefit tradeoff of the 
breaking change versus using the SF String type is a good one.

> To be concrete -- what should an implementation do when it receives two DPoP 
> header fields, both with valid values? When it receives one with two 
> comma-separated values?

These are great questions.  I'll commit to us answering them in the next draft.

>>> - The long line-wrapped example in Section 4.1 would benefit from RFC8792 
>>> encoding. In HTTP, a line-wrapped field like the one shown has whitespace 
>>> inserted between each line, which is problematic here.
> 
>> This is a bit of a stylistic preference thing. That example and others in 
>> the draft are intentionally similar (with a note about line breaks and extra 
>> space being for display purposes) to closely related and referenced 
>> documents like RFC7515, RFC7519, and RFC6749. The examples from these RFCs 
>> seem to have worked well for readers/implementers in practice, and so we'd 
>> prefer to keep the formatting conventions in this draft the same as in those.
>
> Consistency between documents that specify HTTP protocol elements is 
> important, so I'd ask you to reconsider; while the community that has been 
> developing and implementing the specification may already be familiar with 
> it, aligning with other documents makes it easier for a broader audience. 
> See, for example, the Signatures specification: 
> https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html#name-request-response-signature-

I'm fine with us making this editorial change to the examples, since you feel 
that this would help some readers of the specification.

In closing, I'll say that I appreciate that the SF spec has done heavy lifting 
that we would do well to take advantage of.  I appreciate you bringing it to 
our att

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

[Mike Jones]

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 adoption of this document.

Thanks

Joseph



On 15 Nov 2022, at 14:43, Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:

All,

During the IETF meeting last week, there was a strong support for the adoption 
of the following document as a WG document:
https://datatracker.ietf.org/doc/draft-kasselman-cross-device-security/

This is to start a call for adoption for this document.
Please, provide your feedback on the mailing list on whether you support the 
adoption of this document as a WG or not, by Nov 29th.

Regards,
 Rifaat & Hannes


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] DPoP - IPR Disclosure

[Mike Jones]

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, Mike, and David,

As part of the shepherd write-up for the DPoP document, there is a need for an 
IPR disclosure from the authors.
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

Are you aware of any IPRs associated with this document?

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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 in OAuth, so I don’t 
support this draft."

Speculatively issuing JWTs with combinations of claims because they might be 
used in the future might be a fine strawman proposal to score debating points 
but is hardly a practical engineering solution.  Whereas SD-JWT meets the needs 
of JSON-based use cases for selective disclosure using the 
issuer/holder/verifier pattern, including those for ISO Mobile Driver's 
Licenses.

That's why I support adoption.

   -- Mike

From: OAuth  On Behalf Of Neil Madden
Sent: Tuesday, August 2, 2022 2:16 AM
To: Kristina Yasuda 
Cc: oauth 
Subject: Re: [OAUTH-WG] Call for adoption - SD-JWT


On 2 Aug 2022, at 03:20, Kristina Yasuda 
mailto:Kristina.Yasuda=40microsoft@dmarc.ietf.org>>
 wrote:

I support adoption.

To add some color.

One of the use-cases is a flow where issuance of a user credential (collection 
of user claims) is decoupled from presentation (where both issuance and 
presentation of a user credential are done using extensions of OAuth flows). 
The goal of this decoupling is to avoid “issuer call home”, where the user can 
send a user credential directly to the RP, without RP needing to contact the 
Issuer directly.

So what’s the plan for revocation in this scenario? Something like OCSP 
Stapling? Short-lived tokens? Either way, the client will need to go back to 
the issuer regularly.


So the motivations are not limited to offline scenarios, but are applicable to 
the scenarios that want to recreate in the online environment, the user 
experience of presenting credentials in-person.

I’m not sure why this would be a goal. Presenting credentials in person is 
subject to many constraints that just don’t apply in the digital world.



Driver’s Licence just happens to be an example familiar to many, and there is 
no reason it cannot be a diploma, or an employee card, or a training 
certificate, etc. But it is worth highlighting that SD-JWT work becomes 
critical if we are to enable ISO-compliant mobile Driver Licences expressed in 
JSON to enable online scenarios and make life of the Web developers easier (as 
opposed processing data encoded as CBOR and signed as a COSE message). 
Selective disclosure is a requirement in many government issued credentials, 
while the usage of advanced cryptography is not always encouraged by the 
national cybersecurity agencies.

I’m not sure what any of this has to do with OAuth?


Regarding an approach where issuer issues multiple JWTs of a same type but with 
different subset of claims, it is not an ideal way to do selective disclosure 
with JWTs (type as a way to differentiate credential with one data 
structure/syntax from another). It complicates implementations that try to 
provide RP-U unlinkability (RPs cannot collude to track the user). The simplest 
way to achieve unlinkability with JWTs without using advanced cryptography is 
to issue multiple credentials of the same type but with varying use identifiers 
and enable pairwise identifiers per RP. Now there are multiple copies of each 
JWT with subset of claims of the same type. This greatly complicates 
presentation of these credentials too – since credentials are of the same type, 
now wallet needs to manage the combination of a subset of claims + pairwise 
identifier…

The same is needed in SD-JWT - the wallet needs to manage pairwise identifiers 
and which subset of claims to disclose.



What if the implementation also wants predicates property, where age_over_XX 
boolean is sent instead of a birthdate string? The simplest way to do 
predicates with JWTs without using advanced cryptography is to have issuers to 
issue multiple age_over_xx booleans so that an appropriate one can be 
selectively disclosed to the RP. How many “JWTs with subset of claims” does the 
issuer needs to issue to account for all possible age requirements? Note that 
it’s not just age_over_21 to start gambling, it’s also age_over_65 to get 
pension benefits.

Being over 65 also proves that you are over 21.


Managing the combinatorial explosion of sets of claims in speculatively issued 
JWTs, many of which will never be used, seems unwieldy, to say the least. "A 
conventional JWT with a subset of claims" approach could be taken in some 
implementations, but it should not prevent a simpler, extensible alternative of 
SD-JWT.

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 in OAuth, so I don’t 
support this draft.

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

[Mike Jones]

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 important
+1 for obvious reasons.
Am 28. Juli 2022 21:12:49 GMT-04:00 schrieb Brian Campbell 
mailto:bcampbell=40pingidentity@dmarc.ietf.org>>:
I support adoption.
On Thu, Jul 28, 2022, 8:17 PM Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:
All,

This is a call for adoption for the SD-JWT document
https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/

Please, provide your feedback on the mailing list by August 12th.

Regards,
 Rifaat & Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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 Spencer,

As you've likely surmised by now, my appetite for changes is fairly small at 
this point. But I can see the value in adding the corresponding decoded content 
in those spots for readability. So would definitely welcome a PR that is scoped 
to just that.

On Sun, Jul 3, 2022 at 7:27 PM Spencer Balogh 
mailto:spbal...@gmail.com>> wrote:
Hi Brian,

I'd definitely be happy to get the nonce and client considerations changes in, 
and I'm happy to propose more text tweaks if there's still any ambiguity there. 
Those were some of my largest concerns as a potential server or client 
implementer of this spec.

With respect to # PR Fully specified 
examples, I can definitely 
understand the concerns around the private key and , and I was 
feeling mixed on that in the first place. Would there be more appetite for this 
with the private keys and signatures removed, or at least adding a 
corresponding decoded content figure to `Figure 4: Token Request for a DPoP 
sender-constrained token using an authorization code`, and `Figure 6: Token 
Request for a DPoP-bound Token using a Refresh Token`, similar to `Figure 12: 
DPoP Protected Resource Request`'s corresponding `Figure 13: Decoded Content of 
the DPoP Proof JWT in Figure 12`. I think the decoded messages in particular 
help readability a good bit. I suppose this is getting into my preferences as 
well though. :)

Also understood on the layer violation for `dpop_signing_alg_values_supported` 
in validation. I'll go ahead and close that one.

Let me know what you think.

Thanks,
Spencer Balogh


On Fri, Jul 1, 2022 at 3:26 PM Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
Hi Spencer,

Thanks for the interest and feedback, even if it's a little late in the game.

I think the proposed changes in # PR Nonce clarifications, more complete 
documentation, and guidance 
are a nice improvement that closes the disconnect you pointed out. We'll need 
to produce a new -10 draft revision with updates from the Shepherd Review and 
I'd like to incorporate the content of this PR in that as well. Unless there 
are meaningful objections from the WG. I don't think that's overstepping things 
too much process-wise and I assume the Chairs will speak up if it is.

The new subsection in # PR Proposal Section 7.2 Client 
Considerations seems 
reasonable. Barring any objections from the WG, this can probably be 
incorporated as well.

The changes in # PR Fully specified 
examples are too much at 
this stage. Some of the JSON is invalid. There are stylistic and aesthetic 
differences and then inconsistencies. I think the private key does hurt in this 
context because it's a potential distraction and might lead to readers trying 
to reproduce the proofs (which won't work b/c ES256 isn't deterministic). There 
may be other objections but even this has involved a not insignificant amount 
of time.  Admittedly some of this is subjective or preference based but 
hopefully you can understand that there's risk and cost involved. And it's late 
in the process.

The  # PR Checking DPoP Proofs 
tweaks change is not 
workable because it pulls an authorization server specific construct as a 
normative requirement into a section that applies to both authorization server 
and resource server. It's kind of like a compile time error for a spec, if 
there was such a thing. The note about order not being implied could be added 
tho. Or the list could be changed to use bullets and not have numbering. I 
don't recall there being any real reason for the numbering.





On Thu, Jun 30, 2022 at 10:12 AM Spencer Balogh 
mailto:spbal...@gmail.com>> wrote:
Hi all,

I'm new to all of this, please forgive me if I'm missing any expectations or 
conventions here.

I have a bit of feedback for OAuth 2.0 Demonstrating Proof-of-Possession at the 
Application Layer
(DPoP) draft-ietf-oauth-dpop-09 
(https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop). I'm aware that 
you're already after the Working Group Last Call, so I'm trying to come in with 
mostly non-normative changes, and with draft suggestions rather than just open 
questions. I've opened several pull requests against the RFC repo so that 
needed changes can be easily incorporated, and not get blocked by changes that 
are more my preference.

I also wanted to follow up here to provide a little bit more context on the 
change proposals.

# PR Nonce clarifications, more complete documentation, and g

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

[Mike Jones]

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, June 2, 2022 12:09 AM
To: Kristina Yasuda 
Cc: The IESG ; draft-ietf-oauth-jwk-thumbprint-...@ietf.org; 
oauth-cha...@ietf.org; oauth@ietf.org; rifaat.s.i...@gmail.com
Subject: Re: Lars Eggert's No Objection on 
draft-ietf-oauth-jwk-thumbprint-uri-02: (with COMMENT)

Hi,

On 2022-6-2, at 5:22, Kristina Yasuda  wrote:
> Regarding your reference to the Simplified BSD License, could you please 
> clarify what you meant since 
> https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-02.html 
> does refer to the Revised BSD License? There doesn't seem to be a problem in 
> that regard.

I reviewed the text version at 
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-02.txt and 
that does refer to the simplified BSD license. (Same for -03.)

This looks like a tooling issue. Did you submit XML (only) to the datatracker 
when you submitted -03?

Thanks,
Lars

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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,
-- Mike

-Original Message-
From: Murray Kucherawy via Datatracker  
Sent: Wednesday, June 1, 2022 11:07 PM
To: The IESG 
Cc: draft-ietf-oauth-jwk-thumbprint-...@ietf.org; oauth-cha...@ietf.org; 
oauth@ietf.org; rifaat.s.i...@gmail.com
Subject: Murray Kucherawy's No Objection on 
draft-ietf-oauth-jwk-thumbprint-uri-03: (with COMMENT)

Murray Kucherawy has entered the following ballot position for
draft-ietf-oauth-jwk-thumbprint-uri-03: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwk-thumbprint-uri/



--
COMMENT:
--

One suggestion: This document cites BCP 14, and then barely uses it (there's
just one "MUST", and nothing else).  In my view, you could replace "MUST be"
with "are" and then drop all the BCP 14 boilerplate, with the same effect.



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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 / "-" / "." / "_" / "~".

These are all characters that do not require encoding.

So I think we're good to go.

Thanks again,
-- Mike

-Original Message-
From: Robert Wilton via Datatracker  
Sent: Friday, May 27, 2022 2:57 AM
To: The IESG 
Cc: draft-ietf-oauth-jwk-thumbprint-...@ietf.org; oauth-cha...@ietf.org; 
oauth@ietf.org; rifaat.s.i...@gmail.com; rifaat.s.i...@gmail.com
Subject: Robert Wilton's No Objection on 
draft-ietf-oauth-jwk-thumbprint-uri-02: (with COMMENT)

Robert Wilton has entered the following ballot position for
draft-ietf-oauth-jwk-thumbprint-uri-02: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwk-thumbprint-uri/



--
COMMENT:
--

Hi,

I just wanted to confirm that the names of "Hash Name String" in the IANA
registry are always such that they can be directly used in URLs without
encoding.  RFC 6920, section 9.4, didn't seem to specify any restriction, but
text if the rest of that RFC (that I'm not really familiar with) seems to
suggest/indicate that they use a restricted character set and hence are safe to
directly embed.

Thanks,
Rob



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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
  *   
https://github.com/oauthstuff/draft-ietf-oauth-security-topics/issues/26#issuecomment-1140176847
  *   https://github.com/oauthstuff/draft-ietf-oauth-security-topics/issues/30
  *   https://github.com/oauthstuff/draft-ietf-oauth-security-topics/issues/31
  *   https://github.com/oauthstuff/draft-ietf-oauth-security-topics/issues/32
  *   https://github.com/oauthstuff/draft-ietf-oauth-security-topics/issues/33
  *   https://github.com/oauthstuff/draft-ietf-oauth-security-topics/issues/34
  *   https://github.com/oauthstuff/draft-ietf-oauth-security-topics/issues/35
  *   https://github.com/oauthstuff/draft-ietf-oauth-security-topics/issues/36
  *   https://github.com/oauthstuff/draft-ietf-oauth-security-topics/issues/37
  *   https://github.com/oauthstuff/draft-ietf-oauth-security-topics/issues/38
  *   https://github.com/oauthstuff/draft-ietf-oauth-security-topics/issues/39
  *   https://github.com/oauthstuff/draft-ietf-oauth-security-topics/issues/40
  *   https://github.com/oauthstuff/draft-ietf-oauth-security-topics/issues/41
  *   https://github.com/oauthstuff/draft-ietf-oauth-security-topics/issues/42
  *   https://github.com/oauthstuff/draft-ietf-oauth-security-topics/issues/43
  *   https://github.com/oauthstuff/draft-ietf-oauth-security-topics/issues/44
  *   https://github.com/oauthstuff/draft-ietf-oauth-security-topics/issues/45

GitHub PR (addressing only obvious wording and grammatical issues):

  *   https://github.com/oauthstuff/draft-ietf-oauth-security-topics/pull/46

Thanks again for writing the draft!

   Best wishes,
   -- Mike

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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 registered hash algorithm identifiers.
*Acknowledged IETF Last Call reviewers.

The specification is available at:
*https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-02.html

   -- Mike

P.S.  This notice was also published at https://self-issued.info/?p=2275 and 
https://twitter.com/selfissued/status/1526310481920524293.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

I’m queasy about the interop implications of using a query parameter.  
Questions then arise like “What if I receive an ni: URI without the query 
parameter.  Should I accept it as valid or reject it?” and “What if the query 
parameter is different than the one I expected?  Should I accept it or reject 
it?”

Finally, I believe that defining a particular query parameter would violate the 
“Get off my lawn” provisions of https://datatracker.ietf.org/doc/html/rfc7320.

For several reasons, I believe we’re better off staying with the syntax we have.

   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

Mike,

RFC6920 defines an optional query parameter, in section 3:
https://www.rfc-editor.org/rfc/rfc6920.html#section-3

I guess you could have added a query parameter to add that specificity.

Regards,
 Rifaat


On Tue, May 3, 2022 at 10:04 AM Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
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.

   -- Mike

From: last-call mailto:last-call-boun...@ietf.org>> 
On Behalf Of Manger, James
Sent: Tuesday, April 26, 2022 9:26 AM
To: last-c...@ietf.org<mailto:last-c...@ietf.org>
Cc: 
draft-ietf-oauth-jwk-thumbprint-...@ietf.org<mailto:draft-ietf-oauth-jwk-thumbprint-...@ietf.org>;
 oauth-cha...@ietf.org<mailto:oauth-cha...@ietf.org>; 
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [Last-Call] [OAUTH-WG] Last Call: 
 (JWK Thumbprint URI) to Proposed 
Standard

draft-ietf-oauth-jwk-thumbprint-uri-01 uses labels from the Named Information 
IANA 
registry<https://www.iana.org/assignments/named-information/named-information.xhtml>
 to create URIs from hashes, but then why doesn’t it just use the RFC that 
created that registry and already defines a way to format hashes as URIs [RFC 
6920 Naming Things with Hashes<https://www.rfc-editor.org/rfc/rfc6920.html>]?

For a JSON object representing a JWK whose SHA-256 hash (base64url-encoded) is 
NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs:

  *   RFC6920 defines the URI:
ni:///sha-256;NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
  *   draft-ietf-oauth-jwk-thumbprint-uri-01 defines the URI:
urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs

--
James Manger


From: OAuth mailto:oauth-boun...@ietf.org>> on behalf 
of The IESG mailto:iesg-secret...@ietf.org>>
Date: Tuesday, 26 April 2022 at 7:17 am
To: IETF-Announce mailto:ietf-annou...@ietf.org>>
Cc: 
draft-ietf-oauth-jwk-thumbprint-...@ietf.org<mailto:draft-ietf-oauth-jwk-thumbprint-...@ietf.org>
 
mailto:draft-ietf-oauth-jwk-thumbprint-...@ietf.org>>,
 oauth-cha...@ietf.org<mailto:oauth-cha...@ietf.org> 
mailto:oauth-cha...@ietf.org>>, 
oauth@ietf.org<mailto:oauth@ietf.org> mailto:oauth@ietf.org>>
Subject: [OAUTH-WG] Last Call:  
(JWK Thumbprint URI) to Proposed Standard
[External Email] This email was sent from outside the organisation – be 
cautious, particularly with links and attachments.

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'JWK Thumbprint URI'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org<mailto:last-c...@ietf.org> mailing lists by 2022-05-09. 
Exceptionally, comments may
be sent to i...@ietf.org<mailto:i...@ietf.org> instead. In either case, please 
retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This specification registers a kind of URI that represents a JSON Web
   Key (JWK) Thumbprint value.  JWK Thumbprints are defined in RFC 7638.
   This enables JWK Thumbprints to be used, for instance, as key
   identifiers in contexts requiring URIs.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwk-thumbprint-uri/



No IPR declarations have been submitted directly on this I-D.





___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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.

   -- Mike

From: last-call  On Behalf Of Manger, James
Sent: Tuesday, April 26, 2022 9:26 AM
To: last-c...@ietf.org
Cc: draft-ietf-oauth-jwk-thumbprint-...@ietf.org; oauth-cha...@ietf.org; 
oauth@ietf.org
Subject: Re: [Last-Call] [OAUTH-WG] Last Call: 
 (JWK Thumbprint URI) to Proposed 
Standard

draft-ietf-oauth-jwk-thumbprint-uri-01 uses labels from the Named Information 
IANA 
registry
 to create URIs from hashes, but then why doesn't it just use the RFC that 
created that registry and already defines a way to format hashes as URIs [RFC 
6920 Naming Things with Hashes]?

For a JSON object representing a JWK whose SHA-256 hash (base64url-encoded) is 
NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs:

  *   RFC6920 defines the URI:
ni:///sha-256;NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
  *   draft-ietf-oauth-jwk-thumbprint-uri-01 defines the URI:
urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs

--
James Manger


From: OAuth mailto:oauth-boun...@ietf.org>> on behalf 
of The IESG mailto:iesg-secret...@ietf.org>>
Date: Tuesday, 26 April 2022 at 7:17 am
To: IETF-Announce mailto:ietf-annou...@ietf.org>>
Cc: 
draft-ietf-oauth-jwk-thumbprint-...@ietf.org
 
mailto:draft-ietf-oauth-jwk-thumbprint-...@ietf.org>>,
 oauth-cha...@ietf.org 
mailto:oauth-cha...@ietf.org>>, 
oauth@ietf.org mailto:oauth@ietf.org>>
Subject: [OAUTH-WG] Last Call:  
(JWK Thumbprint URI) to Proposed Standard
[External Email] This email was sent from outside the organisation - be 
cautious, particularly with links and attachments.

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'JWK Thumbprint URI'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2022-05-09. 
Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please 
retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This specification registers a kind of URI that represents a JSON Web
   Key (JWK) Thumbprint value.  JWK Thumbprints are defined in RFC 7638.
   This enables JWK Thumbprints to be used, for instance, as key
   identifiers in contexts requiring URIs.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwk-thumbprint-uri/



No IPR declarations have been submitted directly on this I-D.





___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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 Thumbprint URI - Implementations

All,

As part of the shepherd write-up for the JWK Thumbprint URI document, we are 
looking for information about implementations of this draft.
Please, reply to this email on the mailing list with any implementations that 
you are aware of to support this document.

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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 part of the shepherd write-up for the JWK Thumbprint URI document, there is 
a need for an IPR disclosure from the authors.
Are you aware of any IPRs associated with this document?

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC for DPoP Document

[Mike Jones]

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 last week, this is a WG Last 
Call for the DPoP document:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

Please, provide your feedback on the mailing list by April 11th.

Regards,
 Rifaat & Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dpop-06.txt

This -06 revisoun has a relatively small set of mostly editorial changes and a 
(hopefully) better name for the client metadata that was introduced in -05.


On Tue, Mar 1, 2022 at 1:38 PM 
mailto:internet-dra...@ietf.org>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : OAuth 2.0 Demonstrating Proof-of-Possession at the 
Application Layer (DPoP)
Authors : Daniel Fett
  Brian Campbell
  John Bradley
  Torsten Lodderstedt
  Michael Jones
  David Waite
Filename: draft-ietf-oauth-dpop-06.txt
Pages   : 42
Date: 2022-03-01

Abstract:
   This document describes a mechanism for sender-constraining OAuth 2.0
   tokens via a proof-of-possession mechanism on the application level.
   This mechanism allows for the detection of replay attacks with access
   and refresh tokens.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-06.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-06


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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 document


+1 in support for publication.

The Nimbus JWT lib was recently updated to match the 01 spec with the hash alg 
in the URN.

Vladimir Dzhuvinov
On 21/02/2022 15:12, Rifaat Shekh-Yusef wrote:
All,

Mike and Kristina made the necessary changes to address all the great comments 
received during the initial WGLC.

This is a second WG Last Call for this document to make sure that the WG has a 
chance to review these changes:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

Please, provide your feedback on the mailing list by March 7th.

Regards,
 Rifaat & Hannes



___

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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
Sent: Monday, February 21, 2022 5:12 AM
To: oauth 
Subject: [OAUTH-WG] Second WGLC for JWK Thumbprint URI document

All,

Mike and Kristina made the necessary changes to address all the great comments 
received during the initial WGLC.

This is a second WG Last Call for this document to make sure that the WG has a 
chance to review these changes:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

Please, provide your feedback on the mailing list by March 7th.

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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] WGLC for JWK Thumbprint URI document

Hi Mike

The additional mechanism was published as an I-D last week.


draft-chadwick-oauth-jwk-uri-00.txt

I thought this list had been notified, but my-bad, I see it was not.  So I have 
just sent out the notification now.

So can we get some feedback from this group as well as the OIDC one, before 
progressing either?

Kind regards

David

On 17/02/2022 22:23, Mike Jones wrote:
Hi David,

Rifaat reminded me that yours is the only WGLC comment that has not been 
resolved by publication of -01.  As noted earlier, the substantive differences 
between this draft and the JWK URI draft that you’re proposing are being 
primarily discussed in the OpenID Connect working group, where the JWK 
Thumbprint URI mechanism is used.

In that discussion, you made this issue comment 
https://bitbucket.org/openid/connect/issues/1429/replace-jwk-thumbprint-uri-with-jwk-uri#comment-61838115:

“I agree that adding JWK URI should not exclude JWK Thumbprint URIs. Similarly 
JWK Thumbprint URIs should not exclude JWK URIs.”

That seems to me to indicate that you’re OK with this specification being 
published, while also wanting both working groups to consider your additional 
mechanism when a draft is submitted?  Am I hearing you correctly on that?

At least in my mind, the fact that you might publish another not-equivalent 
mechanism shouldn’t hold up publication of this mechanism.

   Thanks again,
   -- Mike

From: David Chadwick 
<mailto:d.w.chadw...@verifiablecredentials.info>
Sent: Monday, February 7, 2022 12:54 PM
To: Kristina Yasuda 
<mailto:kristina.yas...@microsoft.com>; Mike 
Jones <mailto:michael.jo...@microsoft.com>; 
oauth@ietf.org<mailto: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 are discussing.

Hi Kristina

Yes and no.

No, in that the registration of either of the I-Ds as an RFC is a matter for 
this list, and should answer this question, "what is the best way (or ways) of 
creating a URI from a public key."

Yes, in that the SIOPv2 specification requires at least one way of specifying a 
public key as a URI and therefore needs some other standard or standards to 
refer to.
I’ve seen you opened an issue in the OpenID Connect WG Bitbucket. Let’s discuss 
there whether SIOP v2 should use JWK Thumbprint URI.

Yes we can certainly discuss the latter issue in OIDF

Kind regards

David

Best,
Kristina

From: OAuth <mailto:oauth-boun...@ietf.org> On Behalf 
Of David Chadwick
Sent: Sunday, February 6, 2022 2:40 AM
To: Mike Jones 
<mailto:michael.jo...@microsoft.com>; 
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

On 05/02/2022 17:46, Mike Jones wrote:
David, I believe your objections below are actually about the JWK Thumbprint 
[RFC 
7638<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7638.html&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Ca3ed141a4e8d44a502ac08d9e95d13c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637797408920851038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YsMfndDhygG7AkSPK9NeYrKhDwFkd5P%2FSAgZsrXH%2F6Q%3D&reserved=0>]
 computation used by this specification, and not the operation defined by this 
specification.  JWK Thumbprint became an RFC in 2015.

Hi Mike

no, my objection is to the JWK Thumbprint URI document. I accept that the JWK 
Thumbprint RFC already exists.

The aim of the SIOPv2 group is to transfer a public key as a URI, so it 
leverages the JWK Thumbprint RFC to do this. As I point out in my I-D, SIOPv2 
transfers the public key and the public key thumbprint. My I-D suggests that we 
simply transfer the public key as a URI then no thumbprint computation is 
necessary by the SIOPv2. The recipient can compute its own thumbprint if it 
needs to by utilising the JWK Thumprint RFC and in this case no hashing 
algorithm needs to be jointly agreed upon.

Kind regards

David

This 
specification<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-jwk-thumbprint-uri-00.html&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Ca3ed141a4e8d44a502ac08d9e95d13c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637797408920851038%7CUnknown%7CTWFpbGZsb3d8ey

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

[Mike Jones]

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 /, +, 
and =.  If you're going to encode things, I suggest using the URL-safe 
base64url encoding.

But secondly, I would not re-encode the JWK fields at all.  I know that David 
Waite had an idea for a representation of JWK URIs where the JSON fields are 
represented as colon-separated pairs in the URI.  So for instance, the example 
JWK at https://datatracker.ietf.org/doc/html/rfc7517#section-3 would be instead 
represented as:

urn:ietf:params:oauth:jwk:kty:EC:crv:P-256:x:f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU:y:x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0:kid:Public%20key%20used%20in%20JWS%20spec%20Appendix%20A.3%20example

This would avoid double base64url-encoding fields, which would prevent 
unnecessary size expansion.

I suggest you work with David if you want to further pursue the idea of a JWK 
URI specification.

   Best wishes,
   -- Mike

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

Hi David,

Rifaat reminded me that yours is the only WGLC comment that has not been 
resolved by publication of -01.  As noted earlier, the substantive differences 
between this draft and the JWK URI draft that you’re proposing are being 
primarily discussed in the OpenID Connect working group, where the JWK 
Thumbprint URI mechanism is used.

In that discussion, you made this issue comment 
https://bitbucket.org/openid/connect/issues/1429/replace-jwk-thumbprint-uri-with-jwk-uri#comment-61838115:

“I agree that adding JWK URI should not exclude JWK Thumbprint URIs. Similarly 
JWK Thumbprint URIs should not exclude JWK URIs.”

That seems to me to indicate that you’re OK with this specification being 
published, while also wanting both working groups to consider your additional 
mechanism when a draft is submitted?  Am I hearing you correctly on that?

At least in my mind, the fact that you might publish another not-equivalent 
mechanism shouldn’t hold up publication of this mechanism.

   Thanks again,
   -- Mike

From: David Chadwick 
Sent: Monday, February 7, 2022 12:54 PM
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 are discussing.

Hi Kristina

Yes and no.

No, in that the registration of either of the I-Ds as an RFC is a matter for 
this list, and should answer this question, "what is the best way (or ways) of 
creating a URI from a public key."

Yes, in that the SIOPv2 specification requires at least one way of specifying a 
public key as a URI and therefore needs some other standard or standards to 
refer to.
I’ve seen you opened an issue in the OpenID Connect WG Bitbucket. Let’s discuss 
there whether SIOP v2 should use JWK Thumbprint URI.

Yes we can certainly discuss the latter issue in OIDF

Kind regards

David

Best,
Kristina

From: OAuth <mailto:oauth-boun...@ietf.org> On Behalf 
Of David Chadwick
Sent: Sunday, February 6, 2022 2:40 AM
To: Mike Jones 
<mailto:michael.jo...@microsoft.com>; 
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

On 05/02/2022 17:46, Mike Jones wrote:
David, I believe your objections below are actually about the JWK Thumbprint 
[RFC 
7638<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7638.html&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Ca3ed141a4e8d44a502ac08d9e95d13c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637797408920851038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YsMfndDhygG7AkSPK9NeYrKhDwFkd5P%2FSAgZsrXH%2F6Q%3D&reserved=0>]
 computation used by this specification, and not the operation defined by this 
specification.  JWK Thumbprint became an RFC in 2015.

Hi Mike

no, my objection is to the JWK Thumbprint URI document. I accept that the JWK 
Thumbprint RFC already exists.

The aim of the SIOPv2 group is to transfer a public key as a URI, so it 
leverages the JWK Thumbprint RFC to do this. As I point out in my I-D, SIOPv2 
transfers the public key and the public key thumbprint. My I-D suggests that we 
simply transfer the public key as a URI then no thumbprint computation is 
necessary by the SIOPv2. The recipient can compute its own thumbprint if it 
needs to by utilising the JWK Thumprint RFC and in this case no hashing 
algorithm needs to be jointly agreed upon.

Kind regards

David

This 
specification<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-jwk-thumbprint-uri-00.html&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7Ca3ed141a4e8d44a502ac08d9e95d13c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637797408920851038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8Vt%2BwrhXuAC3CjvGzaQtmYv4%2BIV3ElozbVGED4FLUvQ%3D&reserved=0>
 defines how to create a JWK Thumbprint URI by concatenating the URI prefix 
“urn:ietf:params:oauth:jwk-thumbprint” to an RFC 7638 JWK Thumbprint.  That’s 
all it does.  That’s why Rifaat’s statement “The JWK Thumbprint URI document is 
a simple and straightforward specification” is indeed correct.

   Best wishes,
   -- Mike

From: OAuth <mailto:oauth-boun...@ietf.org> On Behalf 
Of David Chadwick
Sent: Friday, February 4, 2022 9:55 AM
To: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

On 02/02/2022 12:18, Rifaat Shekh-Yusef wrote:
All,

The JWK Thumbprint URI

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

[Mike Jones]

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: Monday, February 14, 2022 4:34 PM
To: oauth 
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

Hi All,

Thank you very much for the constructive feedback.
We have tried to address the WGLC comments received to date with the latest 
draft published at 
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwk-thumbprint-uri-01.

Following are updates made to the document:
- Added security considerations about multiple public keys coresponding to the 
same private key.
- Added hash algorithm identifier after the JWK thumbprint URI prefix to make 
it explicit in a URI which hash algorithm is used.
- Added reference to a registry for hash algorithm identifiers.
- Added SHA-256 as a mandatory to implement hash algorithm to promote 
interoperability.

Kindest Regards,
Kristina

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Rifaat Shekh-Yusef
Sent: Wednesday, February 2, 2022 4:19 AM
To: oauth mailto:oauth@ietf.org>>
Subject: [OAUTH-WG] WGLC for JWK Thumbprint URI document

All,

The JWK Thumbprint URI document is a simple and straightforward specification.

This is a WG Last Call for this document:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

Please, provide your feedback on the mailing list by Feb 16th.

Regards,
 Rifaat & Hannes


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

Thanks for the useful information, Neil!  I learned things I didn't know from 
reading your remarks, which is always good. :-)

The good news is that in the application that motivated writing this 
specification (OpenID Connect Self-Issued OpenID Provider v2) the mitigation 
you described is already in place; the key is used to sign a JWT that includes 
both the key thumbprint and the key itself.  But it will be great to describe 
these attacks and how they relate to using key thumbprints as identifiers 
generally, so others are aware of them.

We also look forward to any additional Security 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: WGLC for JWK Thumbprint URI document

Hi Mike,


On 4 Feb 2022, at 15:30, Mike Jones 
mailto:Michael.Jones=40microsoft@dmarc.ietf.org>>
 wrote:

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 same proof of identity is valid under many public keys. 
> The security considerations should mention these issues, and potential 
> suggest countermeasures (eg including the full public key JWK in the input to 
> be signed etc).

I’m not all that familiar with the attacks you’re referencing.  Is there I 
write-up on them that you could refer me and the other working group members to 
so we can better understand them?  And ideally, could you write up a paragraph 
or two on them that you’d like us to include in the Security Considerations?

I’ll have a look and see if there is a concise write up somewhere. To give you 
an idea, here are some potential attacks:

Firstly, in ECDSA for example each signature is typically valid for at least 
two public keys, and these keys can be easily recovered from the signature 
itself [1]. So if Alice is using an ECDSA signature as proof of her identity, 
and her identity is a (hash of a) public key, then it is also a valid proof of 
identity for a different identity (different JWK thumbprint). This makes an 
authentication scheme based on this ambiguous, which is not usually a good 
thing.

A similar thing can happen with ECDH-based key exchanges or authenticated 
encryption schemes (like my own ECDH-1PU) with certain elliptic curves. In this 
case you can add “points of small order” to a public key to derive a new public 
key that will produce the same ECDH shared secrets (or even simpler change the 
PK point (x,y) to (x,-y)). The attacker in this case can’t decrypt or tamper 
with a message but they can claim that it came from their public key instead of 
the real originator. Again, this can make the same proof of identity valid for 
two or more identities if you use public keys as identities.

In both cases these “attacks” can be avoided by including the identities/public 
keys in the input to the signature (or KDF for ECDH). For example, EdDSA 
already does this, and this is a recommended best practice for ECDH (sadly 
missing from JWE). An alternative is to define a canonical public key for each 
given signature and reject non-canonical keys.

Whether these “attacks” actually lead to a vulnerability or not depends on 
exactly what you are doing. But it is a surprising property that can lead to 
subtle issues as the security considerations of RFC 7748 note [2]:

“ Designers using these curves should be aware that for each public

   key, there are several publicly computable public keys that are

   equivalent to it, i.e., they produce the same shared secrets.  Thus

   using a public key as an identifier and knowledge of a shared secret

   as proof of ownership (without including the public keys in the key

   derivation) might lead to subtle vulnerabilities.”


Adding wording along those lines (generalised to mention signatures too) would 
be good. I’ll come up with some wording.

Other security issues can arise when a public key hash is informally associated 
with some other kind of identifier without a strong binding between the two. 
For example, the unknown key share attacks described in RFC 8844 [3].

[1]: https://crypto.stackexchange.com/a/60219
[2]: https://datatracker.ietf.org/doc/html/rfc7748#section-7
[3]: https://www.rfc-editor.org/rfc/rfc8844.html

— Neil



Second, you asked that the hash algorithm be made explicit, as did Vladimir.  
I’ll consult with Kristina on that today and respond to that suggestion in a 
subsequent message.

   Thanks again,
   -- Mike

From: OAuth mailto:oauth-

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

[Mike Jones]

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 
specification
 defines how to create a JWK Thumbprint URI by concatenating the URI prefix 
“urn:ietf:params:oauth:jwk-thumbprint” to an RFC 7638 JWK Thumbprint.  That’s 
all it does.  That’s why Rifaat’s statement “The JWK Thumbprint URI document is 
a simple and straightforward specification” is indeed correct.

   Best wishes,
   -- Mike

From: OAuth  On Behalf Of David Chadwick
Sent: Friday, February 4, 2022 9:55 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

On 02/02/2022 12:18, Rifaat Shekh-Yusef wrote:
All,

The JWK Thumbprint URI document is a simple and straightforward specification.

Actually this is a complex and inefficient specification compared to other 
possibilities.

I have written an Internet-Draft outlining an alternative scheme, the JWK URI, 
which provides OIDC SIOPv2 with all the requirements that it needs with much 
less effort than implementing JWK Thumbprint URIs. I am currently formatting 
this I-D correctly to submit to the IETF. The rationale for this new Internet 
Draft is as follows.

To produce or validate a JWK Thumbprint, both the sender and the receiver have 
to have the JWK available to them. Then they have to canonicalise the JWK as 
described in [RFC7638], and finally hash the octets of the UTF-8 representation 
of this JSON object with a pre-agreed algorithm in order to both obtain the 
same hash value. The way that the JWK Thumbprint URI is used in SIOPv2 [SIOPv2] 
is as follows:

  1.  the SIOP creates an asymmetric key pair and encodes the public key as a 
JWK
  2.  the SIOP creates the JWK Thumbprint as described in [RFC7638] and 
converts it to a URI as described in [JONES],
  3.  the SIOP passes both the JWK and JWK Thumbprint URI to the RP in the JWT,
  4.  the RP extracts the JWK and JWK Thumbprint from the JWT
  5.  the RP re-computes the JWK Thumbprint from the JWK
  6.  the RP compares the computed JWK Thumbprint with the received JWK 
Thumbprint to confirm that they are equal.

One can see that the use of JWK Thumbprint URIs is both inefficient (in all 
cases) and a significant disadvantage (in some cases). If the JWK URI is 
transferred instead of the JWK and JWK Thumbprint URI then:

a) The SIOP will never need to create the JWK Thumbprint URI. The RP may only 
need to create the JWK Thumbprint if it needs this, for example, as a unique 
subject identifier. Even in this case, there is still an advantage to the RP in 
receiving the JWK URI instead of the JWK Thumprint URI, in that the RP no 
longer needs to pre-agree a hashing algorithm with the SIOP. Thus the RP can 
independently determine which hashing algorithm to use when creating its own 
JWK Thumbprint. (Note. If the SIOP were able to canonicalise the same public 
key in a JWK in different ways and produce different thumbprints from the same 
public key, then the canonicalisation algorithm is broken, and the RP would 
never to able to deterministically produce the same thumbprints each time.)

b) In those cases where the SIOP uses ephemeral key pairs and a different 
public key each time it communicates with an RP, then neither party needs to 
produce the JWK Thumbprint as it will never be seen again. It is a significant 
disadvantage to have to use JWK Thumbprints in this case.

I therefore kindly request that the JWK Thumbprint URI document does not 
progress until the WG has had chance to compare and contrast the two methods.

Kind regards

David



This is a WG Last Call for this document:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

Please, provide your feedback on the mailing list by Feb 16th.

Regards,
 Rifaat & Hannes





___

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

Kristina and I spoke about it today and we agreed that it makes sense to make 
the hash algorithm explicit.  So for instance, we’d propose that the example
urn:ietf:params:oauth:jwk-thumbprint:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
become
urn:ietf:params:oauth:jwk-thumbprint:S256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
when using the SHA-256 hash function.

Similarly, we’d propose to also define S384, S512, and possibly also S3-256, 
S3-384, and S3-512 (for the SHA-3 hash functions).

For extra credit, if there’s already an IANA registry with string names for 
these hash functions, 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: Friday, February 4, 2022 7:30 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] 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 same proof of identity is valid under many public keys. 
> The security considerations should mention these issues, and potential 
> suggest countermeasures (eg including the full public key JWK in the input to 
> be signed etc).

I’m not all that familiar with the attacks you’re referencing.  Is there I 
write-up on them that you could refer me and the other working group members to 
so we can better understand them?  And ideally, could you write up a paragraph 
or two on them that you’d like us to include in the Security Considerations?

Second, you asked that the hash algorithm be made explicit, as did Vladimir.  
I’ll consult with Kristina on that today and respond to that suggestion in a 
subsequent message.

   Thanks again,
   -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Vladimir Dzhuvinov
Sent: Thursday, February 3, 2022 11:00 PM
To: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: [EXTERNAL] Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document


The original JWK thumbprint RFC 7638 essentially describes the method for 
composing the hash input from a JWK and that the output is base64url encoded. 
SHA-256 is mentioned, but there is no default implied hash function. This 
leaves it to applications / other specs to determine.

https://www.rfc-editor.org/rfc/rfc7638.html#section-3.4

The URN gives us now a natural possibility to encode the hash function 
alongside the fact that it's a JWK thumbprint, so let's include it. This will 
make things more explicit and self-contained.

What do the authors think about this possibility?

~Vladimir

Vladimir Dzhuvinov
On 04/02/2022 01:47, Neil Madden wrote:
The draft doesn’t specify which hash function is being used. I assume it is 
SHA-256, but it should either say that is the only algorithm allowed or perhaps 
encode the hash algorithm into the URI. Otherwise the value is ambiguous.

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 same proof of identity is valid under many public keys. The security 
considerations should mention these issues, and potential suggest 
countermeasures (eg including the full public key JWK in the input to be signed 
etc).

— Neil

On 2 Feb 2022, at 12:19, Rifaat Shekh-Yusef 
<mailto:rifaat.s.i...@gmail.com> wrote:

All,

The JWK Thumbprint URI document is a simple and straightforward specification.

This is a WG Last Call for this document:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

Please, provide your feedback on the mailing list by Feb 16th.

Regards,
 Rifaat & Hannes


___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


___

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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 same proof of identity is valid under many public keys. 
> The security considerations should mention these issues, and potential 
> suggest countermeasures (eg including the full public key JWK in the input to 
> be signed etc).

I’m not all that familiar with the attacks you’re referencing.  Is there I 
write-up on them that you could refer me and the other working group members to 
so we can better understand them?  And ideally, could you write up a paragraph 
or two on them that you’d like us to include in the Security Considerations?

Second, you asked that the hash algorithm be made explicit, as did Vladimir.  
I’ll consult with Kristina on that today and respond to that suggestion in a 
subsequent message.

   Thanks again,
   -- Mike

From: OAuth  On Behalf Of Vladimir Dzhuvinov
Sent: Thursday, February 3, 2022 11:00 PM
To: oauth@ietf.org
Subject: [EXTERNAL] Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document


The original JWK thumbprint RFC 7638 essentially describes the method for 
composing the hash input from a JWK and that the output is base64url encoded. 
SHA-256 is mentioned, but there is no default implied hash function. This 
leaves it to applications / other specs to determine.

https://www.rfc-editor.org/rfc/rfc7638.html#section-3.4

The URN gives us now a natural possibility to encode the hash function 
alongside the fact that it's a JWK thumbprint, so let's include it. This will 
make things more explicit and self-contained.

What do the authors think about this possibility?

~Vladimir

Vladimir Dzhuvinov
On 04/02/2022 01:47, Neil Madden wrote:
The draft doesn’t specify which hash function is being used. I assume it is 
SHA-256, but it should either say that is the only algorithm allowed or perhaps 
encode the hash algorithm into the URI. Otherwise the value is ambiguous.

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 same proof of identity is valid under many public keys. The security 
considerations should mention these issues, and potential suggest 
countermeasures (eg including the full public key JWK in the input to be signed 
etc).

— Neil


On 2 Feb 2022, at 12:19, Rifaat Shekh-Yusef 
 wrote:

All,

The JWK Thumbprint URI document is a simple and straightforward specification.

This is a WG Last Call for this document:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

Please, provide your feedback on the mailing list by Feb 16th.

Regards,
 Rifaat & Hannes


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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 Thumbprint URI document is a simple and straightforward specification.

This is a WG Last Call for this document:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

Please, provide your feedback on the mailing list by Feb 16th.

Regards,
 Rifaat & Hannes


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

Thanks for the help, Brian.  I’ve updated the PR 
https://github.com/danielfett/draft-dpop/pull/89/ in the third 
commit<https://github.com/danielfett/draft-dpop/pull/89/commits/66b1e679376509ca38862dcbce2635ee307309b4>
 to address your comments.

Further reviews and feedback welcomed!

   -- 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 fixed too.

https://github.com/danielfett/draft-dpop/pull/89/files#diff-cbb16c6731a89f7daa2f8f1963f5c005633f4273846af12926d187292cb3a66bR996

On Tue, Jan 25, 2022 at 7:37 AM Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
The changes to the example to add PKCE aren't valid PKCE. The appendix from the 
original https://datatracker.ietf.org/doc/html/rfc7636#appendix-B might be a 
better place to borrow example content from.

I believe also that review comments had requested some treatment of the 
optionality/requiredness of the new dpop_jkt parameter.



On Mon, Jan 24, 2022 at 8:41 PM Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
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 Thumbprint
  *   Adds PKCE to the example
  *   Describes how the attacks mitigated by DPoP binding of the authorization 
code can arise

   -- Mike

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

As described below, "Given that the specification does only one simple thing in 
a straightforward manner, we believe that it is ready for working group last 
call."  The editors therefore request that the chairs initiate working group 
last call for draft-ietf-oauth-jwk-thumbprint-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 Adoption of the JWK Thumbprint URI 
Specification


The IETF OAuth working group<https://datatracker.ietf.org/wg/oauth/about/> has 
adopted the JWK Thumbprint 
URI<https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html>
 specification. The abstract of the specification is:

This specification registers a kind of URI that represents a JSON Web Key (JWK) 
Thumbprint value. JWK Thumbprints are defined in RFC 7638. This enables JWK 
Thumbprints to be used, for instance, as key identifiers in contexts requiring 
URIs.



The need for this arose during specification work in the OpenID Connect working 
group<https://openid.net/wg/connect/>. In particular, JWK Thumbprint URIs are 
used as key identifiers that can be syntactically distinguished from other 
kinds of identifiers also expressed as URIs in the Self-Issued OpenID Provider 
v2<https://openid.net/specs/openid-connect-self-issued-v2-1_0.html> 
specification.



Given that the specification does only one simple thing in a straightforward 
manner, we believe that it is ready for working group last call.



The specification is available at:
*https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

   -- Mike

P.S.  This note was also posted at https://self-issued.info/?p=2242 and as 
@selfissued<https://twitter.com/selfissued/>.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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 represents a JSON Web Key (JWK) 
Thumbprint value. JWK Thumbprints are defined in RFC 7638. This enables JWK 
Thumbprints to be used, for instance, as key identifiers in contexts requiring 
URIs.



The need for this arose during specification work in the OpenID Connect working 
group. In particular, JWK Thumbprint URIs are 
used as key identifiers that can be syntactically distinguished from other 
kinds of identifiers also expressed as URIs in the Self-Issued OpenID Provider 
v2 
specification.



Given that the specification does only one simple thing in a straightforward 
manner, we believe that it is ready for working group last call.



The specification is available at:
*https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

   -- Mike

P.S.  This note was also posted at https://self-issued.info/?p=2242 and as 
@selfissued.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] dpop_jkt Authorization Request Parameter PR Updated

[Mike Jones]

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 Thumbprint
  *   Adds PKCE to the example
  *   Describes how the attacks mitigated by DPoP binding of the authorization 
code can arise

   -- Mike

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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] Call for adoption - JWK Thumbprint URI

All,

This is a call for adoption for the JWK Thumbprint URI draft:
https://datatracker.ietf.org/doc/draft-jones-oauth-jwk-thumbprint-uri/

Please, provide your feedback on the mailing list by Jan 27th.

Regards,
 Rifaat & Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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 Thumbprint URIs 
as key identifiers that can be syntactically distinguished from other kinds of 
identifiers also expressed as URIs.  It is used this way in the Self-Issued 
OpenID Provider 
v2 
specification, for instance.  No normative changes were made.

As discussed on the call, we are requesting that that the chairs use this new 
draft as the basis for a call for working group adoption.

The specification is available at:

  *   
https://www.ietf.org/archive/id/draft-jones-oauth-jwk-thumbprint-uri-01.html

   -- Mike

P.S.  This note was also published at https://self-issued.info/?p=2237 and as 
@selfissued.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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 
draft-ietf-oauth-iss-auth-resp.

I would be OK with draft-ietf-oauth-iss-auth-resp also registering it for usage 
"authorization response", as proposed in the draft, but the original 
registration for use "authorization request" by RFC 9191 should remain.

-- Mike

P.S.  No, I'm not a designated expert for this registry.  Hannes is the only DE 
currently appointed by the IESG.

-Original Message-
From: oauth-ext-review  On Behalf Of Amanda 
Baber via RT
Sent: Thursday, January 6, 2022 4:50 PM
Cc: oauth-ext-rev...@ietf.org; Hannes Tschofenig ; 
oauth@ietf.org
Subject: [oauth-ext-review] [IANA #1216704] Expert Review for 
draft-ietf-oauth-iss-auth-resp (oauth-parameters) (2)

Hi Hannes,

Although the IESG has approved the document, we need expert approval in order 
to move forward with the registration, unless the ADs specifically tell us to 
move ahead without it. Can you approve the OAuth Parameter registration in this 
document?

https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/

thanks,
Amanda

On Tue Jan 04 13:21:14 2022, rifaat.s.i...@gmail.com wrote:
> Hannes,
> 
> Can you please take a look at this request to allow us to make 
> progress with this document?
> 
> Thanks,
>  Rifaat
> 
> 
> On Mon, Jan 3, 2022 at 8:58 PM Amanda Baber via RT < 
> drafts-expert-review-comm...@iana.org> wrote:
> 
> > Hi Hannes,
> >
> > Have you had a chance to review the OAuth Parameters request in this 
> > document?
> >
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/
> >
> > thanks,
> >
> > Amanda Baber
> > IANA Operations Manager
> >
> > On Wed Nov 24 21:28:18 2021, amanda.baber wrote:
> > > Attn: Hannes (OAuth Parameters registry expert)
> > >
> > > I'm resending a review request for a document that's listed on the 
> > > next IESG telechat. Can you get to this before 12/2?
> > >
> > > thanks,
> > >
> > > Amanda Baber
> > > IANA Operations Manager
> > >
> > > On Tue Nov 16 21:17:59 2021, michelle.cotton wrote:
> > > > Mailing List/Expert Review requested
> > > >
> > > > Attn: Hannes (OAuth Parameters registry expert)
> > > >
> > > > As the designated expert for the OAuth Parameters registry, can 
> > > > you review the proposed registration in draft-oauth-iss-auth-resp for 
> > > > us?
> > > > Please see:
> > > >
> > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/
> > > >
> > > > A single, new registration is being requested:
> > > >
> > > > Name: iss
> > > > Parameter Usage Location: authorization response Change 
> > > > Controller: IESG
> > > > Reference: [ RFC-to-be; Section 2 ]
> > > >
> > > > If this is request is OK, when the IESG approves the document 
> > > > for publication, we'll make the registration at
> > > >
> > > > https://www.iana.org/assignments/oauth-parameters/
> > > >
> > > > The IESG has asked us to set a two-week deadline for 
> > > > registration reviews. The due date for this request is 2021-11-30.
> > > >
> > > > Thank you,
> > > >
> > > > Michelle Cotton
> > > > IANA Services
> >
> > ___
> > oauth-ext-review mailing list
> > oauth-ext-rev...@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth-ext-review
> >

___
oauth-ext-review mailing list
oauth-ext-rev...@ietf.org
https://www.ietf.org/mailman/listinfo/oauth-ext-review

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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; ve7...@ve7jtb.com
Subject: Re: [IANA #1216703] Expert Review for draft-ietf-oauth-iss-auth-resp 
(oauth-parameters)

Given you sent the initial review a few months ago, let’s not hold up the 
process and move forward.

On Thu, Jan 6, 2022 at 7:23 PM Amanda Baber via RT 
mailto:drafts-expert-review-comm...@iana.org>>
 wrote:
Hi,

On Fri Jan 07 01:12:36 2022, dick.ha...@gmail.com<mailto:dick.ha...@gmail.com> 
wrote:
> Unfortunately I don’t know what the approval process is — I don’t feel
> I
> need to discuss or review with the others — the IANA registration is
> pretty
> straightforward and I have not heard any controversy about it
>
> I recall at least 2 of the other experts are aligned on the underlying
> spec.

It's up to the experts: some groups prefer explicit unanimous or majority 
approval, while others are OK with a single approval (sometimes depending on 
what's being registered). One group rotates approval duties on a monthly basis.

We can move forward with this if you're OK with giving us the go-ahead. For 
what it's worth, the initial approval request was sent in mid-November, and we 
haven't seen any other responses.

Should we make the registration now or wait for Michael, Nat, and John?

thanks,
Amanda

> On Thu, Jan 6, 2022 at 6:46 PM Amanda Baber via RT <
> drafts-expert-review-comm...@iana.org<mailto:drafts-expert-review-comm...@iana.org>>
>  wrote:
>
> > Hi Dick,
> >
> > Should we wait for further approvals or proceed with the
> > registration? The
> > document has been approved by the IESG, so we can move ahead now once
> > one
> > or more experts instruct us to do so.
> >
> > thanks,
> > Amanda
> >
> > On Wed Jan 05 16:14:21 2022, 
> > dick.ha...@gmail.com<mailto:dick.ha...@gmail.com> wrote:
> > > I'm fine with the IANA registry update.
> > > ᐧ
> > >
> > > On Tue, Jan 4, 2022 at 7:19 AM Rifaat Shekh-Yusef <
> > rifaat.s.i...@gmail.com<mailto:rifaat.s.i...@gmail.com>>
> > > wrote:
> > >
> > > > Mike, Nat, John, Dick,
> > > >
> > > > Can you please take a look at this to allow us to make progress
> > > > with
> > this
> > > > document?
> > > >
> > > > Thanks,
> > > >  Rifaat
> > > >
> > > >
> > > > On Mon, Jan 3, 2022 at 8:57 PM Amanda Baber via RT <
> > > > drafts-expert-review-comm...@iana.org<mailto:drafts-expert-review-comm...@iana.org>>
> > > >  wrote:
> > > >
> > > >> Attn: Michael, Nat, John and Dick (OAuth Authorization Server
> > > >> Metadata
> > > >> registry experts)
> > > >>
> > > >> Have you had a chance to review the request in this document?
> > > >>
> > > >> https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/
> > > >>
> > > >> Is approval from all four experts required?
> > > >>
> > > >> thanks,
> > > >>
> > > >> Amanda Baber
> > > >> IANA Operations Manager
> > > >>
> > > >> On Wed Nov 24 21:27:25 2021, amanda.baber wrote:
> > > >> > Attn: Michael, Nat, John and Dick (OAuth Authorization Server
> > Metadata
> > > >> > registry experts)
> > > >> >
> > > >> > I'm resending a review request for a document that's listed on
> > > >> > the
> > > >> > next IESG telechat. Can you get to this before 12/2?
> > > >> >
> > > >> > Please let us know if approval from all four experts is
> > > >> > required.
> > > >> >
> > > >> > thanks,
> > > >> >
> > > >> > Amanda Baber
> > > >> > IANA Operations Manager
> > > >> >
> > > >> > On Tue Nov 16 21:09:23 2021, michelle.cotton wrote:
> > > >> > > Mailing List/Expert Review requested
> > > >> > >
> > > >> > > Attn: Michael, Nat, John and Dick (OAuth Authorization
> > > >> > > Server
> > > >> > > Metadata
> > > >> > > registry experts)
> > > &g

[OAUTH-WG] Virtual office hours

[Mike Jones]

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

[Mike Jones]

th. If we don't like the client auth 
mechanisms to the AS, we should directly provide an auth RFC recommending 
better alternatives than sending a symmetric client_secret back to the AS.


[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement 
Authress<https://authress.io/>.


On Thu, Dec 2, 2021 at 4:42 PM Pieter Kasselman 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
Thanks for the comments and engagement Warren.

The attacks we described and the ideas on mitigations are born out of attack 
vectors we are observing in the wild. They are not negligible. We are seeing a 
new class of very sophisticated attackers, and if you’re interested, this 
article provides good context on capability and sophistication of the attackers 
Brad Smith: Inside Microsoft during the SolarWinds hack 
(fastcompany.com)<https://www.fastcompany.com/90672384/microsoft-president-brad-smith-solarwinds-exclusive>.
 We are sharing this with the hope that the industry will benefit from our 
experiences and incorporate it into standards and products. Attacks that seemed 
impossibly complex are not only possible, but have become probable.

The proposed changes for DPoP are not meant to replace the need for one-time 
use tokens (single use tokens are preferable and we should continue to expect 
them), but instead address the limitations around implementing one-time use, 
especially at scale. The 60s window you mention below is 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.ietf.org>>;
 oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter

(e.g. one-time use in a certain timeframe etc).

Sure but couldn't we just reduce the lifetime? Even if the token isn't one time 
use, surely the reuse time is trivially short which would prevent against 
exfiltration of the necessary security tokens to issue the attack?

I feel like the simpler solution will always win, which in this case is 
one-time use tokens, then the problem is moot, right? So this only comes into 
play if you want to allow token reuse in a time window. The previously 
suggested max allowed time window from OAuth 2.1 was 60s for auth codes. So we 
are saying that the attack surface is still too large, for the .01% of 
implementations that have multi-use tokens, and the .01% of implementations 
that use the maximum 60s reuse, and then the subset of those that aren't 
correctly scrubing their logs, and then the subset of those that have a 
vulnerability which allows for exfiltration of both those logged tokens and the 
logged PKCE verifier?

Why are we making this more complicated for a majority of cases, which:

  *   Only have single use tokens
  *   Or Only have a very short lifetime
  *   Or Are already correctly sanitizing their logs
  *   Or Have defense in depth for their deployments.
If the implementation is so insecure that none of those are happening, wouldn't 
the implementation for this functionality also be suspect for an opportunity 
for attack?

I feel like we are justifying here that multi-use tokens are wrong, but still 
want a solution to use them. Once we've proven that an deployment is not okay 
with using multi-use tokens, then the conclusion should be "don't have 
multi-use tokens", not: "let's still have multi-use tokens, but come up with a 
complex way to prevent their multi-use from accidentally being abused".

Or am I missing something that would actually make this a non-negligible attack 
vector?

- Warren


[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement 
Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cb5c71bfcbfbb48fd641508d9b4df5fcf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739693847580905%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FBkvuWZ3FVTcdTtfe%2FoLurIGxcsJHCz6zXmW1PROTSc%3D&reserved=0>.


On Wed, Dec 1, 2021 at 4:14 PM Pieter Kasselman 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
Hi Aaron, Neil

Thanks for the questions.

We agree that ideally authorization codes and PKCE proofs would never end up in 
log files and 

[OAUTH-WG] dpop_jkt Authorization Request Parameter

[Mike Jones]

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 https://github.com/danielfett/draft-dpop/pull/86, 
which achieved this binding using a new DPoP PKCE method.  Using this 
alternative allows PKCE implementations to be unmodified, while adding DPoP in 
new code, which may be an advantage in some deployments.

Please review and comment.  Note that I plan to add more of the attack 
description written by Pieter Kasselman to the security considerations in a 
future commit.  This attack description was sent by Pieter yesterday in a 
message with the subject "Authorization Code Log File Attack (was DPoP Interim 
Meeting Minutes)".

   -- Mike

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWK Thumbprint URI Specification

[Mike Jones]

Hi DW,

Having the OAuth WG to add a new registration to a registry that it controls is 
fairly easy.  Our success in motivating and accomplishing registering a new URI 
scheme may vary.

You can read about how the JWK Thumbprint RFC handles choice of hash functions 
in the Selection of Hash Function section 
https://datatracker.ietf.org/doc/html/rfc7638#section-3.4.  I would propose 
that we do the same.  I can plan on adding text to that effect in the next 
published draft.

   Thanks,
   -- 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. jkt:bTz_1…). I haven’t seen much URN namespacing 
of dynamic values (e.g. values not being maintained by the entity responsible 
for the namespace or sub-spaces), and a new scheme is a terser form.

Also, do you foresee any reason to support other hashing algorithms, since 
thumbprints themselves do not dictate a hashing algorithm? An optional hashing 
seems simple enough to add, except I don’t know of a hash algorithm registry to 
reference

-DW

Sent from my iPhone


On Nov 24, 2021, at 4:18 PM, Mike Jones 
mailto:Michael.Jones=40microsoft@dmarc.ietf.org>>
 wrote:

The JWK Thumbprint is typically used as a key identifier. Yes, the key needs to 
be known by other means if you’re going to use it.  Some protocols work that 
way, which is what this spec is intended to enable.  For instance, the 
Self-Issued OpenID Provider (SIOP) v1 and v2 protocols send the public key 
separately in a “sub_jwk” claim.  In other use cases, it may already be known 
to the receiving party – for instance, from a prior discovery step.

It would be fine to separately also define a URI representation communicating 
an entire JWK, but that would be for different use cases, and not the goal of 
this (intentionally narrowly scoped) specification.

   Cheers,
   -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of David Chadwick
Sent: Wednesday, November 24, 2021 12:36 PM
To: oauth@ietf.org<mailto:oauth@ietf.org>
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://www.rfc-editor.org/rfc/rfc7517.html>] and encoding that hash in a 
URL-safe manner. Kristina Yasuda<https://twitter.com/kristinayasuda> and I have 
just created the JWK Thumbprint 
URI<https://www.ietf.org/archive/id/draft-jones-oauth-jwk-thumbprint-uri-00.html>
 specification, which defines how to represent JWK Thumbprints as URIs. This 
enables JWK Thumbprints to be communicated in contexts requiring URIs, 
including in specific JSON Web Token (JWT) [RFC 
7519<https://www.rfc-editor.org/rfc/rfc7519.html>] claims.



My immediate observation is why are you sending the thumbprint of the JSON Web 
Key and not sending the actual key value in the URI?

Sending the thumbprint means the recipient still has to have some other way of 
obtaining the actual public key, whereas sending the public key as a URI means 
that no other way is needed.

Kind regards

David



Use cases for this specification were developed in the OpenID Connect Working 
Group<https://openid.net/wg/connect/> of the OpenID Foundation. Specifically, 
its use is planned in future versions of the Self-Issued OpenID Provider 
v2<https://openid.net/specs/openid-connect-self-issued-v2-1_0.html> 
specification.



The specification is available at:
1.   
https://www.ietf.org/archive/id/draft-jones-oauth-jwk-thumbprint-uri-00.html

   -- Mike

P.S.  This note was also published at https://self-issued.info/?p=2211 and as 
@selfissued<https://twitter.com/selfissued/>.





___

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWK Thumbprint URI Specification

[Mike Jones]

The JWK Thumbprint is typically used as a key identifier. Yes, the key needs to 
be known by other means if you’re going to use it.  Some protocols work that 
way, which is what this spec is intended to enable.  For instance, the 
Self-Issued OpenID Provider (SIOP) v1 and v2 protocols send the public key 
separately in a “sub_jwk” claim.  In other use cases, it may already be known 
to the receiving party – for instance, from a prior discovery step.

It would be fine to separately also define a URI representation communicating 
an entire JWK, but that would be for different use cases, and not the goal of 
this (intentionally narrowly scoped) specification.

   Cheers,
   -- Mike

From: OAuth  On Behalf Of David Chadwick
Sent: Wednesday, November 24, 2021 12:36 PM
To: oauth@ietf.org
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://www.rfc-editor.org/rfc/rfc7517.html>] and encoding that hash in a 
URL-safe manner. Kristina Yasuda<https://twitter.com/kristinayasuda> and I have 
just created the JWK Thumbprint 
URI<https://www.ietf.org/archive/id/draft-jones-oauth-jwk-thumbprint-uri-00.html>
 specification, which defines how to represent JWK Thumbprints as URIs. This 
enables JWK Thumbprints to be communicated in contexts requiring URIs, 
including in specific JSON Web Token (JWT) [RFC 
7519<https://www.rfc-editor.org/rfc/rfc7519.html>] claims.



My immediate observation is why are you sending the thumbprint of the JSON Web 
Key and not sending the actual key value in the URI?

Sending the thumbprint means the recipient still has to have some other way of 
obtaining the actual public key, whereas sending the public key as a URI means 
that no other way is needed.

Kind regards

David



Use cases for this specification were developed in the OpenID Connect Working 
Group<https://openid.net/wg/connect/> of the OpenID Foundation. Specifically, 
its use is planned in future versions of the Self-Issued OpenID Provider 
v2<https://openid.net/specs/openid-connect-self-issued-v2-1_0.html> 
specification.



The specification is available at:
1.   
https://www.ietf.org/archive/id/draft-jones-oauth-jwk-thumbprint-uri-00.html

   -- Mike

P.S.  This note was also published at https://self-issued.info/?p=2211 and as 
@selfissued<https://twitter.com/selfissued/>.




___

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] JWK Thumbprint URI Specification

[Mike Jones]

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 Yasuda and I have 
just created the JWK Thumbprint 
URI
 specification, which defines how to represent JWK Thumbprints as URIs. This 
enables JWK Thumbprints to be communicated in contexts requiring URIs, 
including in specific JSON Web Token (JWT) [RFC 
7519] claims.



Use cases for this specification were developed in the OpenID Connect Working 
Group of the OpenID Foundation. Specifically, 
its use is planned in future versions of the Self-Issued OpenID Provider 
v2 
specification.



The specification is available at:
*
https://www.ietf.org/archive/id/draft-jones-oauth-jwk-thumbprint-uri-00.html

   -- Mike

P.S.  This note was also published at https://self-issued.info/?p=2211 and as 
@selfissued.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

As I see it, the retry in case of network failures should happen by performing 
a new authorization request – not by trying to reuse an authorization code – 
which is indistinguishable from an attack.

Let’s not use OAuth 2.1 as an opportunity to sanction behaviors that we can’t 
distinguish from 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

I am a fan of this approach. It feels pretty empty to cast people out of 
compliance just because they are handling a realistic circumstance, such as 
network failures, that we know about beforehand.
In addition, this gives us a chance to provide guidance on how to handle the 
situation, instead of leaving AS implementers to their own device.

On Fri, Oct 15, 2021 at 11:32 AM Richard Backman, Annabelle 
mailto:40amazon@dmarc.ietf.org>> 
wrote:
The client MUST NOT use the authorization code more than once.

This language makes it impossible to build a fault tolerant, spec compliant 
client, as it prohibits retries. We could discuss whether a retry really 
constitutes a separate "use", but ultimately it doesn't matter; multiple 
presentations of the same code look the same to the AS, whether they are the 
result of retries, the client attempting to get multiple sets of tokens, or an 
unauthorized party trying to replay the code.

I think we can have a fault tolerant, replay-proof implementation, but it takes 
some effort:


  1.  The AS can prevent the authorized client from using one code to get a 
bunch of independent refresh and access token pairs by either re-issuing the 
same token (effectively making the token request idempotent) or invalidating 
previously issued tokens for that code. (Almost but not quite 
idempotent…idempotent-adjacent?)
  2.  The AS can prevent unauthorized parties from replaying snooped codes+PKCE 
by requiring stronger client authentication: implement dynamic client 
registration and require a replay-resistant client authentication method like 
`jwt-bearer`. The AS can enforce one-time use of the client credential token 
without breaking fault tolerance, as the client can easily mint a new one for 
each retry to the token endpoint.

Yes, I know, this is way more complex than just a credential-less public client 
doing PKCE. Perhaps we can have our cake and eat it too with language like:

The client MUST NOT use the authorization code more than once, unless retrying 
a token request that failed for reasons beyond the scope of this protocol. 
(e.g., network interruption, server outage) Refer to [Fault Tolerant Replay 
Prevention] for guidance.

…where Fault Tolerant Replay Prevention is a subsection under Security 
Considerations. I don't think this wording is quite right, as the guidance is 
really going to be for the AS, not the client, but hopefully it's enough to get 
the idea across.

—
Annabelle Backman (she/her)
richa...@amazon.com<mailto:richa...@amazon.com>




On Oct 15, 2021, at 8:27 AM, Mike Jones 
mailto:Michael.Jones=40microsoft@dmarc.ietf.org>>
 wrote:


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.

I agree with Daniel.

Also, while we’ve talked about server requirements, I think it’s equally 
important that we retain this client requirement:

The client MUST NOT use the authorization code more than once.

  -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Daniel Fett
Sent: Friday, October 15, 2021 8:13 AM
To: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Re: Authorization code reuse and OAuth 2.1

I don't think that a MAY is appropriate here.

I wasn't in the call yesterday, so I hope I don't miss anything here, but...

Even with PKCE, the one-time use requirement of the code is still important. 
First and foremost, if we allow unlimited re-use of the same code, even just as 
an option, we change the semantics of this artifact. I guess there are many 
examples where this causes issues, but one would be DPoP. It assumes that there 
is only one (successful) token request and in that request, the token is bound 
to a specific key. If there can be more than one successful token request, all 
it takes is code_challenge and the code sitting around somewhere in accessible 
memory and an XSS attacker can exfiltrate them and use them on his own device, 
binding the resulting token to an attacker-controlled key. This is the attack 
outcome against which we introduced the nonce in DPoP. (Probably we should add 
this thought as a security 

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

[Mike Jones]

itself leaks it. If you have things leaking from the 
authorization server log, you likely have much bigger problems than 
authorization code replays.

Keep in mind that even with the proposed change to drop the requirement of 
authorization codes being one time use, authorization servers are free to 
enforce this still if they want. Authorization code lifetimes are still 
expected to be short lived as well.

Aaron


On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman 
mailto:pieter.kassel...@microsoft.com>> wrote:
Aaron, I was curious what prevents an attacker from presenting an Authorization 
Code and a PKCE Code Verifier for a second time if 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 Aaron Parecki
Sent: Wednesday 13 October 2021 18:40
To: Warren Parad 
mailto:40rhosys...@dmarc.ietf.org>>
Cc: Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>;
 oauth@ietf.org<mailto:oauth@ietf.org>
Subject: [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

Warren, I didn't see you on the interim call, so you might be missing some 
context.

The issue that was discussed is that using PKCE already provides all the 
security benefit that is gained by enforcing single-use authorization codes. 
Therefore, requiring that they are single-use isn't necessary as it doesn't 
provide any additional benefit.

If anyone can think of a possible attack by allowing authorization codes to be 
reused *even with a valid PKCE code verifier* then that would warrant keeping 
this requirement.

---
Aaron Parecki


On Wed, Oct 13, 2021 at 10:27 AM Warren Parad 
mailto:40rhosys...@dmarc.ietf.org>> wrote:
Isn't it better for it to be worded as we want it to be, with the implication 
being that of course it might be difficult to do that, but that AS devs will 
think long and hard about sometimes not denying the request? Even with MUST, 
some AS will still allow reuse of auth codes. Isn't that better than flat out 
saying: sure, there's a valid reason

In other words, how do we think about RFCs? Do they exist to be followed to the 
letter or not at all? Or do they exist to stipulate this is the way, but 
acknowledge that not everyone will build a solution that holds them as law.

Let's look at SHOULD
This word, or the adjective "RECOMMENDED", mean that there may exist valid 
reasons in particular circumstances to ignore a particular item, but the full 
implications must be understood and carefully weighed before choosing a 
different course.

I think recommended here is not sufficient nor are there valid reasons. "It's 
too hard" isn't really a valid reason. Isn't it better in this case for an AS 
to not be compliant with the RFC, than it is to relax this to SHOULD and have 
lots of AS thinking reusing auth codes is a viable solution, "because they are 
a special snowflake where SHOULD should apply".

Are we setting the standard or instead attempting to sustain a number of "AS 
that are in compliance with the RFC"?


[Image removed by
sender.]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement 
Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154760332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lbb9cJl0VUcfBD9IwzKF4BeB5nnggZxLB1TwlZYdNK4%3D&reserved=0>.


On Wed, Oct 13, 2021 at 7:17 PM Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
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
 revoke (when possible) all tokens previously issued based on
 that authorization code."

The rationale given was that enforcing one-time use is impractical in 
distributed authorization server deployments.

Thinking about this some more, at most, we should relax this to:
 The client MUST NOT use the authorization code
 more than once.  If an authorization code is used more than
 once, the authorization server SHOULD deny the request and SHOULD
 revoke (when possible) all tokens previously issued based on
 that authorization code."

In short, it should remain illegal for the client to try to reuse the 
authoriza

[OAUTH-WG] Authorization code reuse and OAuth 2.1

[Mike Jones]

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
 revoke (when possible) all tokens previously issued based on
 that authorization code."

The rationale given was that enforcing one-time use is impractical in 
distributed authorization server deployments.

Thinking about this some more, at most, we should relax this to:
 The client MUST NOT use the authorization code
 more than once.  If an authorization code is used more than
 once, the authorization server SHOULD deny the request and SHOULD
 revoke (when possible) all tokens previously issued based on
 that authorization code."

In short, it should remain illegal for the client to try to reuse the 
authorization code.  We can relax the MUST to SHOULD in the server requirements 
in recognition of the difficulty of enforcing the MUST.

Code reuse is part of some attack scenarios.  We must not sanction it.

  -- Mike

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

I understand the layering that you’re describing, Justin.  That said, all the 
complexity of OAuth 1 and draft-ietf-oauth-signed-http-request are still there 
*and more*.  The complexity is just moved to a different draft in the HTTP 
working group that the proposed OAuth draft in question has taken a dependency 
upon.  The HTTP working group draft is a fully general, all-singing, 
all-dancing HTTP signing draft that will be even more difficult to obtain 
interop on than OAuth 1 or draft-ietf-oauth-signed-http-request were.

Just like canonicalization schemes inhibit interoperation due to their sheer 
complexity, HTTP signing schemes do the same.  We should discourage realistic 
systems from taking dependencies on them.  Therefore, we should not adopt this 
draft.

   -- Mike

From: Justin Richer 
Sent: Friday, October 8, 2021 12:23 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 — which is a huge problem unto 
itself. When I wrote the original draft-ietf-oauth-signed-http-request, I 
wasn’t able to write it to depend on a general-purpose HTTP signing spec and so 
it had to invent a mechanism. OAuth 1 worked on signing just query parameters 
and lots of things in the front-channel, and so invented its own mechanism.

Now that the HTTP working group is well on the way to standardizing the HTTP 
Message Signatures draft as a general-purpose RFC, the OAuth working group 
doesn’t need to solve that problem anymore, and that’s a really, really good 
thing. We aren’t the right community to get that right, and the two previous 
failed attempts you point to prove that better than anything. That’s exactly 
why this draft is NOT going to do that, at all. HTTP Message Signing exists, 
people are implementing it and using it. It makes sense for the OAuth working 
group to define a way to use that work in an OAuth context. We are not and 
should not try again to define a way to sign HTTP messages.

That said, we know that DPoP invents its own way to sign an HTTP message, in a 
limited fashion. It has clear limitations — it doesn’t sign query parameters 
(which are likely to be important to many API types), it doesn’t sign headers, 
it doesn’t sign the body, etc. Even with these limitations, DPoP is useful, and 
I still argue that instead of trying to extend DPoP with a bunch of other 
things, we should let it exist as the clean point solution that it is.

This draft is actually significantly simpler than DPoP precisely because it is 
not defining an HTTP signing mechanism.

 — Justin


On Oct 8, 2021, at 2:24 PM, Mike Jones 
mailto:Michael.Jones=40microsoft@dmarc.ietf.org>>
 wrote:

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.  The 
proposed new draft is a third crack at the same thing that’s not sufficiently 
differentiated from the previous failed efforts in my mind to warrant us 
spending time on it.

Also, note we do have draft-ietf-oauth-dpop, which solves the actual 
proof-of-possession problem for OAuth in a narrowly targeted, focused manner.  
That draft is active and in good shape.  We don’t need a more general, more 
complicated draft solving the same problem.

   -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Rifaat Shekh-Yusef
Sent: Wednesday, October 6, 2021 2:02 PM
To: oauth mailto:oauth@ietf.org>>
Subject: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with 
HTTP Message Signature

All,

As a followup on the interim meeting today, this is a call for adoption for the 
OAuth Proof of Possession Tokens with HTTP Message Signature draft as a WG 
document:
https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/

Please, provide your feedback on the mailing list by October 20th.

Regards,
 Rifaat & Hannes

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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.  The 
proposed new draft is a third crack at the same thing that’s not sufficiently 
differentiated from the previous failed efforts in my mind to warrant us 
spending time on it.

Also, note we do have draft-ietf-oauth-dpop, which solves the actual 
proof-of-possession problem for OAuth in a narrowly targeted, focused manner.  
That draft is active and in good shape.  We don’t need a more general, more 
complicated draft solving the same problem.

   -- Mike

From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Wednesday, October 6, 2021 2:02 PM
To: oauth 
Subject: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with 
HTTP Message Signature

All,

As a followup on the interim meeting today, this is a call for adoption for the 
OAuth Proof of Possession Tokens with HTTP Message Signature draft as a WG 
document:
https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/

Please, provide your feedback on the mailing list by October 20th.

Regards,
 Rifaat & Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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 
Subject: [OAUTH-WG] Fwd: New Version Notification for 
draft-ietf-oauth-dpop-04.txt


WG,

The collective DPoP co-authors are pleased to announce that a new -04 revision 
of DPoP has been published. The doc history snippet is copied below for 
quick/easy reference. The main change here is the addition of an option for a 
server-provided nonce in the DPoP proof.

   -04
   *  Added the option for a server-provided nonce in the DPoP proof.
   *  Registered the invalid_dpop_proof and use_dpop_nonce error codes.
   *  Removed fictitious uses of realm from the examples, as they added
  no value.
   *  State that if the introspection response has a token_type, it has
  to be DPoP.
   *  Mention that RFC7235 allows multiple authentication schemes in
  WWW-Authenticate with a 401.
   *  Editorial fixes.

-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Mon, Oct 4, 2021 at 4:05 PM
Subject: New Version Notification for draft-ietf-oauth-dpop-04.txt
To: ...



A new version of I-D, draft-ietf-oauth-dpop-04.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:   draft-ietf-oauth-dpop
Revision:   04
Title:  OAuth 2.0 Demonstrating Proof-of-Possession at the Application 
Layer (DPoP)
Document date:  2021-10-04
Group:  oauth
Pages:  37
URL:https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-04.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
Html:   https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-04.html
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-04

Abstract:
   This document describes a mechanism for sender-constraining OAuth 2.0
   tokens via a proof-of-possession mechanism on the application level.
   This mechanism allows for the detection of replay attacks with access
   and refresh tokens.




The IETF Secretariat


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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 
https://openid.net/2021/10/01/opportunity-to-join-the-openid-foundation-certification-team/.

   -- Mike

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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 referenced at the end 
of this message.  For instance, sometimes the legitimate user of a client is 
the attacker.  Once instance of this is that some banks have cited employees 
stealing legitimate tokens issued on bank computers and taking them to non-bank 
computers, thereby bypassing audit controls.

When reviewing DPoP with Microsoft's identity architects, they pointed out that 
DPoP as written today can still enable exfiltrated DPoP tokens to be used by 
some kinds of attackers; doing so also requires that the attackers exfiltrate 
DPoP proofs.  This is possible when the legitimate user of a client is the 
attacker.

Preventing exfiltrated pre-generated DPoP proofs from being used in the future 
requires the server being able to limit their lifetime.  An effective means of 
doing this is to include a server-provided nonce in the DPoP proof.  That puts 
the lifetime of DPoP proofs in control of the server, because when a new nonce 
value is provided, older, possibly pre-generated DPoP proofs become invalid at 
the server.

The Microsoft identity server team is already internally using this technique 
with the stale OAuth HTTP Signing draft.  They want to be able to use it with 
DPoP for the same reasons.  DPoP without this won't mitigate the real security 
attacks that our systems are encountering.  Note that unless a server-provided 
nonce is used, what is actually being proved is possession of a DPoP proof - 
not possession of the proof-of-possession key.

Having discussed this with some of the editors, I have created a pull request 
adding the optional use of server-provided nonces to DPoP.  This will break no 
existing deployments.  But it will enable new deployments to choose to use 
server-contributed nonces to limit DPoP proof lifetimes, both for authorization 
servers and resource servers.  The pull request is at 
https://github.com/danielfett/draft-dpop/pull/81/.  Reviews of the PR are 
welcomed.  I propose that we merge it and publish draft -04 sometime next week, 
pending review feedback.



My colleague Pieter Kasselman assembled some examples of successful token 
exfiltration attacks in the public domain (and helped review the PR).  Those 
follow, for your reading pleasure.

  1.  Introducing a new phishing technique for compromising Office 365 accounts 
(o365blog.com)
 *   It describes a phishing attack that allows the attacker to obtain an 
Access Token and a Refresh Token (which is then used to obtain additional 
Access Tokens).
 *   Operationalised with the AADInternals Tool
  2.  The Art of the Device Code Phish - Boku 
(0xboku.com)

 *   It extends the above attack and shows step-by-step how to exfiltrate a 
Access Token and a Refresh Token with a similar phishing attack and then obtain 
additional tokens.
 *   Operationalised with AADInternals and TokenTactics
  1.  DEF CON 29 - Jenko Hwong - New Phishing Attacks Exploiting OAuth 
Authentication Flows - 
YouTube

 *   It shows another attack to exfiltrate tokens using phishing techniques 
that exploit Device Code Flow.
 *   It includes a demo of the attack that shows how it bypasses MFA and 
anti-Phishing controls and then uses the PRT to get tokens and pivot to other 
services.
 *   Tools available as open source.
  1.  Requesting Azure AD Request Tokens on Azure-AD-joined Machines for 
Browser SSO | by Lee Christensen | Posts By SpecterOps Team 
Members

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

[Mike Jones]

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?

  Thanks,
  -- Mike

From: OAuth  On Behalf Of Brian Campbell
Sent: Wednesday, April 7, 2021 1:30 PM
To: oauth 
Subject: [OAUTH-WG] Fwd: New Version Notification for 
draft-ietf-oauth-dpop-03.txt

A new revision of DPoP has been published. The doc history snippet is copied 
below. The main change here is the addition of an access token hash claim.

   -03

   *  Add an access token hash ("ath") claim to the DPoP proof when used
  in conjunction with the presentation of an access token for
  protected resource access

   *  add Untrusted Code in the Client Context section to security
  considerations

   *  Editorial updates and fixes

-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Wed, Apr 7, 2021 at 2:16 PM
Subject: New Version Notification for draft-ietf-oauth-dpop-03.txt


A new version of I-D, draft-ietf-oauth-dpop-03.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:   draft-ietf-oauth-dpop
Revision:   03
Title:  OAuth 2.0 Demonstrating Proof-of-Possession at the Application 
Layer (DPoP)
Document date:  2021-04-07
Group:  oauth
Pages:  32
URL:https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
Html:   https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html
Htmlized:   https://tools.ietf.org/html/draft-ietf-oauth-dpop-03
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-03

Abstract:
   This document describes a mechanism for sender-constraining OAuth 2.0
   tokens via a proof-of-possession mechanism on the application level.
   This mechanism allows for the detection of replay attacks with access
   and refresh tokens.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org.

The IETF Secretariat


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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...@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: 
(with COMMENT)

Thanks for sweating the details, Francesca.  I'll plan to publish an updated 
draft after the telechat making the error handling for the case when the key 
isn't associated with the client clearer.

Thanks again,
-- Mike

-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: 
(with COMMENT)

Hi Mike!

Thanks for the quick reply. It looks good to me, just one answer to point 4. :

4. -

   specified in the "alg" Header Parameter.  If a "kid" Header Parameter
   is present, the key identified MUST be the key used, and MUST be a
   key associated with the client.  Algorithm verification MUST be

...

   same parameter is provided in the query parameter.  The Client ID
   values in the "client_id" request parameter and in the Request Object
   "client_id" claim MUST be identical.  The Authorization Server then

FP: "MUST be a key associated with the client" - what if it is not? does 
the AS return an error to the client then? Same comment "... MUST be identical" 
- is any error returned if it's not?

Mike> I believe that the responses to these validation errors are already 
described in the following paragraph, which says "If signature validation 
fails, the Authorization Server MUST return an 'invalid_request_object' error 
to the client in response to the authorization request."

FP: As I read it, the first paragraph says: 

   The Authorization Server MUST validate the signature of the JSON Web
   Signature [RFC7515] signed Request Object.  If a "kid" Header

Then follows up with a number of other checks that need to be done (the text I 
quoted in my original comment). And then ends with the sentence you quoted:

   If signature validation fails, the Authorization Server MUST return
   an "invalid_request_object" error to the client in response to the
   authorization request.

Same for the second - the text I reported is followed by:

  The Authorization Server then
   validates the request as specified in OAuth 2.0 [RFC6749].

And then again from the text you quoted:

   If the validation fails, then the Authorization Server MUST return an
   error to the client in response to the authorization request, as
   specified in Section 5.2 of OAuth 2.0 [RFC6749].

So while reading I considered that the validation (either of the signature for 
par 1 or of the request for par 2) is separate from the additional checks. The 
intent of it could be made clear by a minor addition in each par:

1st paragraph:

OLD:

   If signature validation fails, the Authorization Server MUST return
   an "invalid_request_object" error to the client in response to the
   authorization request.

NEW:

   If signature validation fials, or if the key identified is not associated 
with the client, the Authorization Server MUST return
   an "invalid_request_object" error to the client in response to the
   authorization request.

2nd paragraph:

OLD:

   If the validation fails, then the Authorization Server MUST return an
   error to the client in response to the authorization request, as
   specified in Section 5.2 of OAuth 2.0 [RFC6749].

NEW:

   If the validation of the request or the Client ID check fails, then the 
Authorization Server MUST return an
   error to the client in response to the authorization request, as
   specified in Section 5.2 of OAuth 2.0 [RFC6749].


I think this would clarify the text, but I'll leave it up to you to decide if 
it's worth adding.
Thanks,
Francesca

On 08/04/2021, 06:45, "Mike Jones"  wrote:

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, 2021 3:29 AM
To: The IESG 
Cc: draft-ietf-oauth-jws...@ietf.org; oauth-cha...@ietf.org; 
oauth@ietf.org; hannes.tschofe...@gmx.net
Subject: F

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

[Mike Jones]

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 
Cc: draft-ietf-oauth-jws...@ietf.org; oauth-cha...@ietf.org; oauth@ietf.org; 
hannes.tschofe...@gmx.net
Subject: RE: 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; 
hannes.tschofe...@gmx.net
Subject: Murray Kucherawy's No Objection on draft-ietf-oauth-jwsreq-33: (with 
COMMENT)

Murray Kucherawy has entered the following ballot position for
draft-ietf-oauth-jwsreq-33: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/



--
COMMENT:
--

Ah, jwsreq.  We meet again.  Fortunately, looking only at the diff from my last 
ballot comments to this one, I only have a couple of minor things this time:

Sections 9.2 and 9.3 each say they are registering "values", but each registers 
only one.

Mike> Thanks.  I correct this in an updated draft after the telechat.

"+1" to Francesca's points #1 and #5.

Mike> We addressed those points in draft 33 (published last night, my time).

Thanks for changing the media type name to use hyphens instead of dots.  That 
avoided a big mess.

Mike> You're welcome!

-- Mike

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

Thanks for sweating the details, Francesca.  I'll plan to publish an updated 
draft after the telechat making the error handling for the case when the key 
isn't associated with the client clearer.

Thanks again,
-- Mike

-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: 
(with COMMENT)

Hi Mike!

Thanks for the quick reply. It looks good to me, just one answer to point 4. :

4. -

   specified in the "alg" Header Parameter.  If a "kid" Header Parameter
   is present, the key identified MUST be the key used, and MUST be a
   key associated with the client.  Algorithm verification MUST be

...

   same parameter is provided in the query parameter.  The Client ID
   values in the "client_id" request parameter and in the Request Object
   "client_id" claim MUST be identical.  The Authorization Server then

FP: "MUST be a key associated with the client" - what if it is not? does 
the AS return an error to the client then? Same comment "... MUST be identical" 
- is any error returned if it's not?

Mike> I believe that the responses to these validation errors are already 
described in the following paragraph, which says "If signature validation 
fails, the Authorization Server MUST return an 'invalid_request_object' error 
to the client in response to the authorization request."

FP: As I read it, the first paragraph says: 

   The Authorization Server MUST validate the signature of the JSON Web
   Signature [RFC7515] signed Request Object.  If a "kid" Header

Then follows up with a number of other checks that need to be done (the text I 
quoted in my original comment). And then ends with the sentence you quoted:

   If signature validation fails, the Authorization Server MUST return
   an "invalid_request_object" error to the client in response to the
   authorization request.

Same for the second - the text I reported is followed by:

  The Authorization Server then
   validates the request as specified in OAuth 2.0 [RFC6749].

And then again from the text you quoted:

   If the validation fails, then the Authorization Server MUST return an
   error to the client in response to the authorization request, as
   specified in Section 5.2 of OAuth 2.0 [RFC6749].

So while reading I considered that the validation (either of the signature for 
par 1 or of the request for par 2) is separate from the additional checks. The 
intent of it could be made clear by a minor addition in each par:

1st paragraph:

OLD:

   If signature validation fails, the Authorization Server MUST return
   an "invalid_request_object" error to the client in response to the
   authorization request.

NEW:

   If signature validation fials, or if the key identified is not associated 
with the client, the Authorization Server MUST return
   an "invalid_request_object" error to the client in response to the
   authorization request.

2nd paragraph:

OLD:

   If the validation fails, then the Authorization Server MUST return an
   error to the client in response to the authorization request, as
   specified in Section 5.2 of OAuth 2.0 [RFC6749].

NEW:

   If the validation of the request or the Client ID check fails, then the 
Authorization Server MUST return an
   error to the client in response to the authorization request, as
   specified in Section 5.2 of OAuth 2.0 [RFC6749].


I think this would clarify the text, but I'll leave it up to you to decide if 
it's worth adding.
Thanks,
Francesca

On 08/04/2021, 06:45, "Mike Jones"  wrote:

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, 2021 3:29 AM
To: The IESG 
Cc: draft-ietf-oauth-jws...@ietf.org; oauth-cha...@ietf.org; 
oauth@ietf.org; hannes.tschofe...@gmx.net
Subject: Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: 
(with COMMENT)

Francesca Palombini has entered the following ballot position for
draft-ietf-oauth-jwsreq-32: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more in

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

[Mike Jones]

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; 
hannes.tschofe...@gmx.net
Subject: Murray Kucherawy's No Objection on draft-ietf-oauth-jwsreq-33: (with 
COMMENT)

Murray Kucherawy has entered the following ballot position for
draft-ietf-oauth-jwsreq-33: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/



--
COMMENT:
--

Ah, jwsreq.  We meet again.  Fortunately, looking only at the diff from my last 
ballot comments to this one, I only have a couple of minor things this time:

Sections 9.2 and 9.3 each say they are registering "values", but each registers 
only one.

Mike> Thanks.  I correct this in an updated draft after the telechat.

"+1" to Francesca's points #1 and #5.

Mike> We addressed those points in draft 33 (published last night, my time).

Thanks for changing the media type name to use hyphens instead of dots.  That 
avoided a big mess.

Mike> You're welcome!

-- Mike

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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, April 6, 2021 11:39 AM
To: The IESG 
Cc: oauth@ietf.org; oauth-cha...@ietf.org; draft-ietf-oauth-jws...@ietf.org
Subject: Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-32: (with 
COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwsreq-32: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/



--
COMMENT:
--

Thank you for the new security considerations text in Sections 10.7 and
10.8 since I last reviewed; it does a great job capturing my comments (and the 
current deployed reality).

Thanks also to Watson Ladd for the latest secdir review and the authors for 
their responses to it.

Mike> Glad to hear it!

Section 6.2

   The Authorization Server MUST validate the signature of the JSON Web
   Signature [RFC7515] signed Request Object.  The signature MUST be
   validated using a key associated with the client and the algorithm
   specified in the "alg" Header Parameter.  [...]

The last version I reviewed had some language tying the algorithm used for 
verification back to a registration (and I commented that perhaps a 
registration might not always exist).  This language seems to set the recipient 
up to blindly use the "alg" header parameter, even if it's "none", and we 
should probably have some hedging language here (I see we do have language 
elsewhere that bans "none" specifically)...

 If a "kid" Header Parameter
   is present, the key identified MUST be the key used, and MUST be a
   key associated with the client.  Algorithm verification MUST be
   performed, as specified in Sections 3.1 and 3.2 of [RFC8725].

... and maybe that would just take the form of swapping the order of these two 
sentences, now that I keep reading.

Mike> Order swapped, per your suggestion.

Section 10.2

Do any of the procedures listed for steps (c) and/or (d) need to be performed 
in step (e) as well?  (In particular, the requirements on the returned URI seem 
like they would still apply, and possibly the need for client authentication.

Mike> Having re-read (c), (d), and (e), I don't think so.  The returned URI in 
(e) can be an opaque identifier that is not a URL, so the URL checking logic 
wouldn't apply.

Section 10.3

Nat's response at
https://mailarchive.ietf.org/arch/msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/ to my 
previous review suggested that there might be value in future work that 
specifies the linkage across these endpoints to try to address the cross-phase 
attacks discussed in [FETT].  However, the paragraph that I had commented on 
(that mentions "an extension specification") has since been removed, and I 
failed to track down why just from a quick mailarchive search.  There may well 
have been a good reason for removing it (and the reference to [FETT]), so 
please help refresh my memory if that's the case.

Mike> It was removed as suggested by Watson Ladd in the discussion that 
resulted from his SecDir review.

Section 10.4

   The introduction of "request_uri" introduces several attack
   possibilities.  Consult the security considerations in Section 7 of
   RFC3986 [RFC3986] for more information regarding risks associated
   with URIs.

My previous comments had mentioned that because of time skew the dereferenced 
request URI might actually have the contents of a different request than the 
one intended, and Nat's response at 
https://mailarchive.ietf.org/arch/msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/
pointed out that OIDC actually does use a nonce that would prevent such an 
occurrence.  Hopefully Nat did get a chance to think about whether there was 
anything else that we should mention in this document, on this topic.  ("There 
isn't anything else to mention here" is a fine answer; I just wanted to close 
the loop on that thread, since I didn't find one in the mail archive.)

Mike> OpenID Connect requests using some response_type values include a nonce 
and those using others don't.  Thinking about it some more, I don't think 
there's any particular risks about using these URLs that are sufficiently 
different than those of other URLs that they're worth mentioning here.

Section 11.1

nit:

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

[Mike Jones]

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, 2021 3:29 AM
To: The IESG 
Cc: draft-ietf-oauth-jws...@ietf.org; oauth-cha...@ietf.org; oauth@ietf.org; 
hannes.tschofe...@gmx.net
Subject: Francesca Palombini's No Objection on draft-ietf-oauth-jwsreq-32: 
(with COMMENT)

Francesca Palombini has entered the following ballot position for
draft-ietf-oauth-jwsreq-32: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/



--
COMMENT:
--

Thank you for the work on this document. I only have minor comments, the most 
interesting is probably 4. about if additional failure behavior should be 
defined at the AS.

Francesca

1. -

   A Request Object (Section 2.1) has the "mime-type" "application/

FP: Please use "media type" instead of "mime-type" and reference
https://tools.ietf.org/html/rfc6838

Mike> Thanks, updated, although referencing RFC 2046 for the term "media type" 
(which is not superseded by RFC 6838).

2. -

   The following is an example of the Claims in a Request Object before
   base64url encoding and signing.  Note that it includes the extension

FP: This example is the first time "base64url" appears in the document. I think 
it would make sense to mention that base64url is used when JWT is introduced, 
for example in the first paragraph of section 4.

Mike> Reference added.

3. -

   If decryption fails, the Authorization Server MUST return an
   "invalid_request_object" error.

...

   If signature validation fails, the Authorization Server MUST return
   an "invalid_request_object" error.

...

   If the validation fails, then the Authorization Server MUST return an
   error as specified in OAuth 2.0 [RFC6749].

FP: very minor, but I suggests you add "to the client, in response to the 
request defined in 5.2.2. of this specification". The reason is that the doc 
specifies that the AS might be having other exchanges (to fetch the Request
Object) at the same time, and it can't hurt to be precise. Also regarding the 
reference to RFC 6749 - can you add a specific section to reference?

Mike> Done

4. -

   specified in the "alg" Header Parameter.  If a "kid" Header Parameter
   is present, the key identified MUST be the key used, and MUST be a
   key associated with the client.  Algorithm verification MUST be

...

   same parameter is provided in the query parameter.  The Client ID
   values in the "client_id" request parameter and in the Request Object
   "client_id" claim MUST be identical.  The Authorization Server then

FP: "MUST be a key associated with the client" - what if it is not? does the AS 
return an error to the client then? Same comment "... MUST be identical" - is 
any error returned if it's not?

Mike> I believe that the responses to these validation errors are already 
described in the following paragraph, which says "If signature validation 
fails, the Authorization Server MUST return an 'invalid_request_object' error 
to the client in response to the authorization request."

5. -

   location, (b) check the content type of the response is "application/

FP: For consistency, please change "content type" to "media type".

Mike> Done

Thanks again,
-- Mike


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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
To: The IESG 
Cc: draft-ietf-oauth-jws...@ietf.org; oauth-cha...@ietf.org; oauth@ietf.org; 
hannes.tschofe...@gmx.net
Subject: Martin Duke's No Objection on draft-ietf-oauth-jwsreq-32: (with 
COMMENT)

Martin Duke has entered the following ballot position for
draft-ietf-oauth-jwsreq-32: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/



--
COMMENT:
--

After reading Sec 10.5, I was a little unclear how the client and auth server 
necessarily achieve interoperability, but I think it's just an editorial fix.

If the server advertises that a signed object is required, then it cannot 
communicate with a client that does not support the extension. But if the 
object_required metadata is missing, then what is the metadata that tells the 
client to use a signed object if it can?

IIUC the answer is that the server metadata includes the 
request_object_signing_alg_values_supported and/or 
request_object_encryption_alg_values_supported parameter in the metadata. It 
might be helpful to spell that out here.

Is this correct?

Mike> Yes, correct.  I've added the clarifying point that you suggested by 
adding this paragraph to the end of Section 10.5:
Note that even if "require_signed_request_object"
metadata values are not present, the client MAY use signed request 
objects,
provided that there are signing algorithms mutually supported by 
the client and the server.
Use of signing algorithm metadata is described in Section 4.

Thanks again,
-- Mike

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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
To: The IESG 
Cc: draft-ietf-oauth-jws...@ietf.org; oauth-cha...@ietf.org; oauth@ietf.org; 
hannes.tschofe...@gmx.net
Subject: Éric Vyncke's No Objection on draft-ietf-oauth-jwsreq-32: (with 
COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-oauth-jwsreq-32: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/



--
COMMENT:
--

Thank you for the work put into this document. Not too many differences since 
my review on the -26 (hence I reviewed mainly the diff).

Please find below some non-blocking COMMENT points (but replies would be 
appreciated).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1 --
Is it normal that the abstract has a) and b) while the introduction has a), b), 
and c) ?

Mike> Thanks for the catch.  We've added (c) to the abstract.

-- Section 5.2 --
I see that "Many phones in the market as of this writing" is still in the 
text... Does this assertion still hold in 2021 ? Is it backed by some 
references ?

Mike> I'm not sure the degree to which this is still true.  Also referring to 
this rationale, Lars Eggert suggested that we change the "MUST NOT exceed 512 
characters" to "SHOULD NOT exceed 512 characters".  We have addressed this in 
the manner suggested by Lars.

Thanks again,
-- Mike

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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
To: The IESG 
Cc: draft-ietf-oauth-jws...@ietf.org; oauth-cha...@ietf.org; oauth@ietf.org; 
hannes.tschofe...@gmx.net
Subject: Lars Eggert's No Objection on draft-ietf-oauth-jwsreq-32: (with 
COMMENT)

Lars Eggert has entered the following ballot position for
draft-ietf-oauth-jwsreq-32: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/



--
COMMENT:
--

Section 5.2, paragraph 5, comment:
>The entire Request URI MUST NOT exceed 512 ASCII characters.  There
>are three reasons for this restriction.
>
>1.  Many phones in the market as of this writing still do not accept
>large payloads.  The restriction is typically either 512 or 1024
>ASCII characters.
>
>2.  On a slow connection such as 2G mobile connection, a large URL
>would cause the slow response and therefore the use of such is
>not advisable from the user experience point of view.

What is the third reason?

Mike> Changed "three" to "two".

Also, 512 bytes at 2G speeds (~40Kb/s) take ~100ms to transmit; it's not clear 
that larger payloads would therefore be so much worse, given that the 2G 
latencies are probably the overriding issue here. Would a SHOULD NOT suffice?

Mike> This is now a SHOULD.

---
All comments below are very minor change suggestions that you may choose to 
incorporate in some way (or ignore), as you see fit. There is no need to let me 
know what you did with these suggestions.

Section 4, paragraph 10, nit:
-Signing it with the "RS256" algorithm results in this Request Object
+Signing it with the "RS256" algorithm [RFC7518] results in this Request 
Object
+  ++

Mike> I added the missing reference.

Thanks again!
-- Mike



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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 comments from Watson Ladd.  
The only normative change made since draft 28 was to change the MIME Type from 
"oauth.authz.req+jwt" to "oauth-authz-req+jwt", per advice from the designated 
experts.

As a reminder, this specification takes the JWT Request Object from Section 6 
of OpenID Connect Core (Passing Request Parameters as 
JWTs) and 
makes this functionality available for pure OAuth 2.0 applications - and does 
so without introducing breaking changes.  This is one of a series of 
specifications bringing functionality originally developed for OpenID Connect 
to the OAuth 2.0 ecosystem.  Other such specifications included OAuth 2.0 
Dynamic Client Registration Protocol [RFC 
7591] and OAuth 2.0 Authorization Server 
Metadata [RFC 8414].

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-31

An HTML-formatted version is also available at:

  *   https://self-issued.info/docs/draft-ietf-oauth-jwsreq-31.html

   -- Mike

P.S.  This notice was also posted at https://self-issued.info/?p=2152 and as 
@selfissued.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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; oauth@ietf.org; 
last-c...@ietf.org; draft-ietf-oauth-jwsreq@ietf.org
Subject: Re: Secdir last call review of draft-ietf-oauth-jwsreq-30

On Wed, Mar 17, 2021 at 2:47 PM Mike Jones  wrote:
>
> I’ve created the pull request 
> https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/14/ applying the 
> proposed changes below to the draft.  Unless suggestions for changes are 
> received, we’ll merge this and publish -31 to address Watson’s comments.

I think these changes as addres my concerns. I wish that we could further 
restrict to a known-good, easily implementable profile, but we can't get 
everything we want.

Sincerely,
Watson Ladd

>
>
>
>    -- 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 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
> Subject: [EXTERNAL] Re: Secdir last call review of 
> draft-ietf-oauth-jwsreq-30
>
>
>
> On Sat, Oct 31, 2020 at 6:13 AM Nat Sakimura  wrote:
>
> >
>
> > Hi Watson,
>
> >
>
> > Thanks very much for the review. I thought I have sent my response
>
> > earlier, which I actually did not. It was sitting in my draft box. I
>
> > apologize for it.
>
>
>
> My apologies for missing it in my inbox for a number of months.
>
> >
>
> > My responses inline:
>
> >
>
> > On Sat, Sep 26, 2020 at 9:46 AM Watson Ladd via Datatracker
>
> >  wrote:
>
> > >
>
> > > Reviewer: Watson Ladd
>
> > > Review result: Serious Issues
>
> > >
>
> > > I generated this review of this document as part of the security
>
> > > directorate's ongoing effort to review all IETF documents being
>
> > > processed by the IESG.  These comments were written with the 
> > > intent
>
> > > of improving security requirements and considerations in IETF
>
> > > drafts.  Comments not addressed in last call may be included in AD
>
> > > reviews during the IESG review.  Document editors and WG chairs should 
> > > treat these comments just like any other last call comments.
>
> > >
>
> > > Two minor issues: On page 4, "This offers an additional degree of
>
> > > privacy protection." should be reworded. I don't think it makes
>
> > > sense in context, where authenticity was discussed.
>
> >
>
> >
>
> > In the course of the edit, explanation about two distinct privacy
>
> > benefits was collated in one sentence and has become very difficult 
> > to
>
> > parse.
>
> >
>
> > What it is trying to express as privacy benefits are the following.
>
> >
>
> > 1) The authorization request content is sent to the AS in the
>
> > backchannel so it will not be exposed through the browser to the 
> > eyes
>
> > of an active or passive outsider observing what is going on in the
>
> > browser.  In the RFC6749 framework case, the authorization request
>
> > goes through the browser redirect and it could leak to the adversary
>
> > via WPAD/PAC Attack, referrer, browser history, etc. Also, if the
>
> > browser was infected by an adversary controlled malware, the content
>
> > can be sniffed by the adversary. In the case of JAR, it does not
>
> > happen. This is one privacy benefit it is trying to explain.
>
> >
>
> > 2) The location that the authorization request is getting pushed to
>
> > does not have to be the AS. A trusted third party that examines the
>
> > content for the conformance to the collection minimization principle
>
> > may act as the party that accepts the authorization request and 
> > issues
>
> > the request_uri. AS can then just evaluate the domain part of
>
> > request_uri to evalu

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

[Mike Jones]

I’ve created the pull request 
https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/14/ applying the proposed 
changes below to the draft.  Unless suggestions for changes are received, we’ll 
merge this and publish -31 to address Watson’s comments.

   -- 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 for your review, Watson.  My replies to your comments below are 
prefixed by "Mike>".



-Original Message-
From: Watson Ladd mailto:watsonbl...@gmail.com>>
Sent: Tuesday, December 15, 2020 9:01 PM
To: Nat Sakimura mailto:nat@nat.consulting>>
Cc: secdir mailto:sec...@ietf.org>>; IETF oauth WG 
mailto:oauth@ietf.org>>; 
last-c...@ietf.org<mailto:last-c...@ietf.org>; 
draft-ietf-oauth-jwsreq@ietf.org<mailto:draft-ietf-oauth-jwsreq@ietf.org>
Subject: [EXTERNAL] Re: Secdir last call review of draft-ietf-oauth-jwsreq-30



On Sat, Oct 31, 2020 at 6:13 AM Nat Sakimura 
mailto:nat@nat.consulting>> wrote:

>

> Hi Watson,

>

> Thanks very much for the review. I thought I have sent my response

> earlier, which I actually did not. It was sitting in my draft box. I

> apologize for it.



My apologies for missing it in my inbox for a number of months.

>

> My responses inline:

>

> On Sat, Sep 26, 2020 at 9:46 AM Watson Ladd via Datatracker

> mailto:nore...@ietf.org>> wrote:

> >

> > Reviewer: Watson Ladd

> > Review result: Serious Issues

> >

> > I generated this review of this document as part of the security

> > directorate's ongoing effort to review all IETF documents being

> > processed by the IESG.  These comments were written with the intent

> > of improving security requirements and considerations in IETF

> > drafts.  Comments not addressed in last call may be included in AD

> > reviews during the IESG review.  Document editors and WG chairs should 
> > treat these comments just like any other last call comments.

> >

> > Two minor issues: On page 4, "This offers an additional degree of

> > privacy protection." should be reworded. I don't think it makes

> > sense in context, where authenticity was discussed.

>

>

> In the course of the edit, explanation about two distinct privacy

> benefits was collated in one sentence and has become very difficult to

> parse.

>

> What it is trying to express as privacy benefits are the following.

>

> 1) The authorization request content is sent to the AS in the

> backchannel so it will not be exposed through the browser to the eyes

> of an active or passive outsider observing what is going on in the

> browser.  In the RFC6749 framework case, the authorization request

> goes through the browser redirect and it could leak to the adversary

> via WPAD/PAC Attack, referrer, browser history, etc. Also, if the

> browser was infected by an adversary controlled malware, the content

> can be sniffed by the adversary. In the case of JAR, it does not

> happen. This is one privacy benefit it is trying to explain.

>

> 2) The location that the authorization request is getting pushed to

> does not have to be the AS. A trusted third party that examines the

> content for the conformance to the collection minimization principle

> may act as the party that accepts the authorization request and issues

> the request_uri. AS can then just evaluate the domain part of

> request_uri to evaluate that the authorization request is conformant

> to this principle. This is another privacy benefit from the point of

> view of the individual user.



I'm fine with any fix to the sentence that makes sense. Don't think we need to 
insert the above but I very much appreciate the explanation.



Mike> Given that its meaning is fairly inscrutable, and that the two benefits 
described by Nat above are partially related to paragraphs other than the one 
with the privacy statement, I propose that we simply delete the sentence "This 
offers an additional degree of privacy protection." from this paragraph.



> > It took me a while to understand what the by reference method is:

> > maybe the intro should say via URL instead of by reference.

>

>

> request_uri can be URL or a handle such as URN. That is why the "by

> reference" word is being used, per the suggestion of the WG.



I'm fine with that, just noting my confusion.



Mike> Understood.  I looked at ways to possibly move the "by reference" text 
that follo

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

[Mike Jones]

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
Subject: [EXTERNAL] Re: Secdir last call review of draft-ietf-oauth-jwsreq-30



On Sat, Oct 31, 2020 at 6:13 AM Nat Sakimura 
mailto:nat@nat.consulting>> wrote:

>

> Hi Watson,

>

> Thanks very much for the review. I thought I have sent my response

> earlier, which I actually did not. It was sitting in my draft box. I

> apologize for it.



My apologies for missing it in my inbox for a number of months.

>

> My responses inline:

>

> On Sat, Sep 26, 2020 at 9:46 AM Watson Ladd via Datatracker

> mailto:nore...@ietf.org>> wrote:

> >

> > Reviewer: Watson Ladd

> > Review result: Serious Issues

> >

> > I generated this review of this document as part of the security

> > directorate's ongoing effort to review all IETF documents being

> > processed by the IESG.  These comments were written with the intent

> > of improving security requirements and considerations in IETF

> > drafts.  Comments not addressed in last call may be included in AD

> > reviews during the IESG review.  Document editors and WG chairs should 
> > treat these comments just like any other last call comments.

> >

> > Two minor issues: On page 4, "This offers an additional degree of

> > privacy protection." should be reworded. I don't think it makes

> > sense in context, where authenticity was discussed.

>

>

> In the course of the edit, explanation about two distinct privacy

> benefits was collated in one sentence and has become very difficult to

> parse.

>

> What it is trying to express as privacy benefits are the following.

>

> 1) The authorization request content is sent to the AS in the

> backchannel so it will not be exposed through the browser to the eyes

> of an active or passive outsider observing what is going on in the

> browser.  In the RFC6749 framework case, the authorization request

> goes through the browser redirect and it could leak to the adversary

> via WPAD/PAC Attack, referrer, browser history, etc. Also, if the

> browser was infected by an adversary controlled malware, the content

> can be sniffed by the adversary. In the case of JAR, it does not

> happen. This is one privacy benefit it is trying to explain.

>

> 2) The location that the authorization request is getting pushed to

> does not have to be the AS. A trusted third party that examines the

> content for the conformance to the collection minimization principle

> may act as the party that accepts the authorization request and issues

> the request_uri. AS can then just evaluate the domain part of

> request_uri to evaluate that the authorization request is conformant

> to this principle. This is another privacy benefit from the point of

> view of the individual user.



I'm fine with any fix to the sentence that makes sense. Don't think we need to 
insert the above but I very much appreciate the explanation.



Mike> Given that its meaning is fairly inscrutable, and that the two benefits 
described by Nat above are partially related to paragraphs other than the one 
with the privacy statement, I propose that we simply delete the sentence "This 
offers an additional degree of privacy protection." from this paragraph.



> > It took me a while to understand what the by reference method is:

> > maybe the intro should say via URL instead of by reference.

>

>

> request_uri can be URL or a handle such as URN. That is why the "by

> reference" word is being used, per the suggestion of the WG.



I'm fine with that, just noting my confusion.



Mike> Understood.  I looked at ways to possibly move the "by reference" text 
that follows in a few paragraphs earlier to possibly make this clearer, but it 
would mess up the logical flow of the Introduction.  Unless you have a better 
suggestion, I propose that we leave this as-is.



> > And now for the thorny issues with this draft. Signatures and

> > encryption are different. And encrypting a signed blob doesn't mean the 
> > signer encrypted it.

> > Then there are a plethora of methods specified in the draft  to

> > authenticate the blob, which will give different results in

> > maliciously constructed examples. The security considerations

> > section should discuss what the encrypted vs signed choices give in

> > the way of security, and it doesn't. This makes me worry.

>

> We don’t expect the encryption to ensure authenticity, that’s what the

> signatures are used for.



This needs to be very clearly spelled out in the text. Lots of people will not 
understand this. The wording of section 10.2 is at best ambivalent, with 
multiple alternatives presented as acceptable.



Mike> After the sentence at 10.2 (b) about symmetric encryption, I propose that 
we add the following sentence 

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

[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 Secured Authorization Request (JAR): IPR Confirmation

Hi Mike, Nat, John,

I am updating the shepherd writeup for the "The OAuth 2.0 Authorization 
Framework: JWT Secured Authorization Request (JAR)" specification, see 
https://tools.ietf.org/id/draft-ietf-oauth-jwsreq-30.txt, and given the changes 
I need your IPR confirmation again. (Mike joined as co-author later and hence I 
need his confirmation anyway.)

One item in the template requires me to indicate whether each document author 
has confirmed that any and all appropriate IPR disclosures required for full 
conformance with the provisions of BCP 78 and BCP 79 have already been filed.

Could you please confirm?

Ciao
Hannes


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC Review of PAR

[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] WGLC Review of PAR

That is not correct.

The authorization code one-time-use is directly between the client and the AS. 
The client has a number of mechanisms to ensure it only presents the 
authorization code to the AS once, such as a session that was set when the user 
started at the client.

In contrast, in a redirect from the client to the AS, the client loses control 
on how many times the user-agent loads the URL at the AS. Additionally, there 
is unlikely to be an active browser session at the AS, so the AS can not easily 
differentiate between a URL load from the same user, or different users. If 
one-time-use, one of them MUST fail. If the two requests happen to be from the 
same user (because of a reload, which the user did because the AS was slow to 
respond), there is no way for the AS to know which of the requests is the one 
that is current in front of the user. While the AS can internally ensure 
processing of the request once, one-time-use would dictate that it provides a 
failure message to one of the requests.

/Dick


ᐧ

On Thu, Aug 27, 2020 at 7:17 AM Justin Richer 
mailto:jric...@mit.edu>> wrote:
We already have this same property with authorization codes, and it’s managed 
today reasonably well (in my opinion). If you submit the same request URI twice 
in the same browser (the refresh you’re talking about), it shouldn’t start two 
separate authorization requests, but it would be reasonable to detect that the 
same session attached to the same request URI value showed up twice and 
continue the session as appropriate.

None of this is in conflict with “one time use”, in my view, since you’re 
actively detecting the session and source of the value.

 — Justin


On Aug 26, 2020, at 6:16 PM, Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:

I think one-time use may be overly restrictive, and I don't think it is the 
property that we actually want.

Give the request URI is in a redirect from the browser, there is a good chance 
of a race condition where the same browser request is made more than once, for 
example, while the browser is loading the authorization URL at the AS, the user 
could refresh the page causing the authorization URL to be reloaded. Would the 
reload count as a second use? One could argue it either way.

What I think we want from what I understand, is the request URI MUST be unique 
so that there is no confusion on which request is being referenced.

I did not see anything about the expiry time of the request URI (but I did not 
look super hard). If that is not there, then I think the request URI MUST 
expire in a "short" period of time.



ᐧ

On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell 
mailto:40pingidentity@dmarc.ietf.org>>
 wrote:
Thanks Justin. Just a couple more responses to responses inline below (but with 
lots of content that needs no further discussion removed).

A TL;DR for the WG is that I'd like to get some wider feedback on the question 
of changing the one-time-use condition on the request_uri from a SHOULD to a 
MUST.

On Tue, Aug 25, 2020 at 4:57 PM Justin Richer 
mailto:jric...@mit.edu>> wrote:
Hi Brian, just a couple responses inline where it seemed fitting. Thanks for 
going through everything!
 — Justin


On Aug 25, 2020, at 6:01 PM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:

Thanks for the review and comments Justin. Replies (or attempts thereat) are 
inline below.


On Wed, Aug 19, 2020 at 2:06 PM Justin Richer 
mailto:jric...@mit.edu>> wrote:
I’ve done a full read through of the PAR specification, and here are my notes 
on it.


¶2: Of necessity, this spec mixes parameters in the authorization endpoint 
and token endpoint registries into a single request. Is there any danger of 
conflict between them? The registry holds them in one list but they could 
possibly have different semantics in both places..

I think that technically such danger does exist but that it's highly unlikely 
in practice. Especially because the only token endpoint parameters that are 
relevant to PAR are those that deal with client authentication (currently 
client_secret, client_assertion, and client_assertion_type). I'm also not sure 
what can reasonably be done about it given the way the registries are. I guess 
PAR could update the registration for those three (client_secret, 
client_assertion, and client_assertion_type) to also indicate authorization 
request as a usage location with some commentary that it's only for avoiding 
name collisions. And offer some guidance about doing the same for any future 
client auth methods being defined. But honestly I'm not sure what, if anything, 
to do here?

And yes it is super unfortunate that 

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

[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 others.

The downsides of using an Introspection Endpoint should be described in the 
Privacy Considerations section.

   -- Mike

From: OAuth  On Behalf Of Dick Hardt
Sent: Wednesday, August 26, 2020 9:52 AM
To: Torsten Lodderstedt 
Cc: last-c...@ietf.org; oauth 
Subject: Re: [OAUTH-WG] Last Call: 
 (JWT Response for OAuth 
Token Introspection) to Proposed Standard



On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt 
mailto:40lodderstedt@dmarc.ietf..org>>
 wrote:
Hi Denis,

> On 25. Aug 2020, at 16:55, Denis 
> mailto:denis.i...@free..fr>> wrote:

> The fact that the AS will know exactly when the introspection call has been 
> made and thus be able to make sure which client
> has attempted perform an access to that RS and at which instant of time. The 
> use of this call allows an AS to track where and when
> its clients have indeed presented an issued access token.

That is a fact. I don’t think it is an issue per se. Please explain the privacy 
implications.

As I see it, the privacy implication is that the AS knows when the client (and 
potentially the user) is accessing the RS, which is also an indication of when 
the user is using the client.

I think including this implication would be important to have in a Privacy 
Considerations section.

/Dick
ᐧ
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

Answering Filip and Vladirmir’s question about adding normative language around 
“typ” and “sub”:  Anytime you add a new required feature, you are breaking 
existing deployments.  Suppose we added the normative requirement “If a ‘typ’ 
header parameter is present, ASs MUST reject the Request object if its value is 
not ‘oauth.authz.req+jwt’”.  One could then write a certification test sending 
the AS a different “typ” value – which to pass, ASs would have to reject the 
JWT.  Every existing deployment would fail this test!  That’s exactly what we 
don’t want to have happen.

Brian asked for security considerations.  The IESG asked for security 
considerations.  I added them in the PR – working with Nat and John.  They 
point the way to the future without breaking existing deployments.  That’s as 
it should be.

   -- Mike

From: OAuth  On Behalf Of Warren Parad
Sent: Saturday, August 15, 2020 9:27 AM
To: Vladimir Dzhuvinov 
Cc: oauth 
Subject: [EXTERNAL] Re: [OAUTH-WG] Benjamin Kaduk's No Objection on 
draft-ietf-oauth-jwsreq-26: (with COMMENT)

In the case of
if the Request Object includes a sub claim with the value of the client_id the 
AS MUST reject the request

What would the expectation be in terms of a client_credentials grant?

From experience, the sub is frequently populated with the client_id value and 
the client_id is not used. Which would mean breaking for that type of grant 
wouldn't it?


[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture. Implement 
Authress<https://bit.ly/37SSO1p>.


On Sat, Aug 15, 2020 at 11:08 AM Vladimir Dzhuvinov 
mailto:vladi...@connect2id.com>> wrote:

+1 to make the "typ" check, as Filip suggested, normative, as existing client 
and RP deployments with undefined "typ" will not be affected. New deployments 
should be encouraged to type the JWT, and thus be made safer.



Regarding the "sub != client_id" check -- could a simple rejection of all JWTs 
with "sub" present suffice?

I find it difficult to imagine what else a client could end up setting the 
"sub" claim to, if it does end up populating it for some reason.

Rejecting JWTs with "sub=client_id" or "sub" present will break deployments 
where a client for some reason sets the "typical" JWT claims, and "sub" is a 
typical one, but if those deployments happen to accept client_secret_jwt or 
private_key_jwt client authentication, they could well be vulnerable to 
cross-JWT confusion attacks.



Vladimir
On 14/08/2020 13:58, Filip Skokan wrote:
Hi Mike, Nat,

I thought we would go as far as making these normative requirements

  *   if the Request Object includes a sub claim with the value of the 
client_id the AS MUST reject the request
  *   if the Request Object is explicitly typed (typ) its value MUST be ...
First rejects client assertions to be passed as Request Objects. Second rejects 
all future typed JWT profiles from being used as Request Objects without 
worrying 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 
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://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10/address-iesg-and-working-group-comments/diff#chg-draft-ietf-oauth-jwsreq.xml.
  Please review!

This is only the first commit, albeit, one that addresses some of the must 
substantive issues.  More commits will follow addressing additional IESG 
comments.

-- Mike

-Original Message-
From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Benjamin Kaduk
Sent: Thursday, August 13, 2020 2:59 PM
To: Brian Campbell 
mailto:bcampb...@pingidentity.com>>
Cc: draft-ietf-oauth-jws...@ietf.org<mailto:draft-ietf-oauth-jws...@ietf.org>; 
oauth-cha...@ietf.org<mailto:oauth-cha...@ietf.org>; The IESG 
mailto:i...@ietf.org>>; oauth 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on 
draft-ietf-oauth-jwsreq-26: (with COMMENT)

Oops, that's my bad.  Thanks for the correction -- I've linked to your message 
in the datatracker (but didn't bother to have the datatracker send a third copy 
of my updated-again ballot position).

-Ben

On Thu, Aug 13, 2020 at 03:00:33PM -0600, Brian Campbell wrote:
> While some discussio

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

[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://bitbucket.org/Nat/oauth-jwsreq/pull-requests/10/address-iesg-and-working-group-comments/diff#chg-draft-ietf-oauth-jwsreq.xml.
  Please review!

This is only the first commit, albeit, one that addresses some of the must 
substantive issues.  More commits will follow addressing additional IESG 
comments.

-- Mike

-Original Message-
From: OAuth  On Behalf Of Benjamin Kaduk
Sent: Thursday, August 13, 2020 2:59 PM
To: Brian Campbell 
Cc: draft-ietf-oauth-jws...@ietf.org; oauth-cha...@ietf.org; The IESG 
; oauth 
Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on 
draft-ietf-oauth-jwsreq-26: (with COMMENT)

Oops, that's my bad.  Thanks for the correction -- I've linked to your message 
in the datatracker (but didn't bother to have the datatracker send a third copy 
of my updated-again ballot position).

-Ben

On Thu, Aug 13, 2020 at 03:00:33PM -0600, Brian Campbell wrote:
> While some discussion of why explicit typing was not used might be 
> useful to have, that thread started with a request for security 
> considerations prohibiting use of the "sub" with a client ID value. 
> Because such a request JWT could be repurposed for JWT client 
> authentication. And explicit typing wouldn't help in that situation.
> 
> On Tue, Aug 11, 2020 at 2:50 PM Benjamin Kaduk via Datatracker < 
> nore...@ietf.org> wrote:
> 
> >
> > 
> > --
> > COMMENT:
> > 
> > --
> >
> > [updated to note that, per
> > https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0
> > eaE/ and the JWT BCP (RFC 8725), some discussion of why explicit 
> > typing is not used would be in order]
> >
> >
> 
> --
> _CONFIDENTIALITY NOTICE: This email may contain confidential and 
> privileged material for the sole use of the intended recipient(s). Any 
> review, use, distribution or disclosure by others is strictly 
> prohibited.  If you have received this communication in error, please 
> notify the sender immediately by e-mail and delete the message and any 
> file attachments from your computer. Thank you._

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[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 also performs JOSE registrations.  So that’s definitely a viable path 
forward.  (This document is currently in AUTH48 status, and so is about to 
become an RFC.)

Filip, the JOSE working group closed after RFCs 7515-7518 and 7520 were 
completed.  Note that it’s possible to register algorithms, etc. in the IANA 
JOSE registries https://www.iana.org/assignments/jose/jose.xhtml without the 
spec coming from a working group – and indeed, without coming from a working 
group at all.

  -- Mike

From: OAuth  On Behalf Of Dick Hardt
Sent: Monday, August 10, 2020 10:27 AM
To: Filip Skokan 
Cc: oauth 
Subject: Re: [OAUTH-WG] ECDH-1PU encryption algorithm

I'm supportive of this work.

It is not clear that it is in the charter of the OAuth WG.


On Mon, Aug 10, 2020 at 9:01 AM Filip Skokan 
mailto:panva...@gmail.com>> wrote:
Hi Neil,

I'm interested in seeing both AES SIV and ECDH-1PU for JOSE. Not sure how to go 
about it tho since JOSE is a concluded WG.

Out of curiosity, why is it a concluded WG? Did IETF/JOSE WG not consider the 
need to further maintain/expand the JOSE algorithms as time goes on?

S pozdravem,
Filip Skokan


On Mon, 10 Aug 2020 at 10:29, Neil Madden 
mailto:neil.mad...@forgerock.com>> wrote:
Thanks Vladimir,

Responses below

> On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov 
> mailto:vladi...@connect2id.com>> wrote:
>
> Hi Neil,
>
> I definitely like the elegance of the proposed alg for JOSE, it provides
> something that isn't currently available in the various classes of algs
> made standard in JOSE.
>
> I also wanted to ask what's happening with AES SIV for JOSE, if there's
> traction / feedback / support there as well?
>
> https://tools.ietf.org/html/draft-madden-jose-siv-mode-02

Thanks for bringing this up. I’ve not received much feedback about this one, 
and I haven’t been very good at pushing it. If there is interest then I’d 
certainly be interested in bringing this forward too.

That draft might be a better fit for eg the COSE WG though, which could then 
also register identifiers for JOSE. What do you think?

>
> Vladimir
>
>
>>> On 05/08/2020 13:01, Neil Madden wrote:
>> Hi all,
>> You may remember me from such I-Ds
>> as https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, which
>> proposes adding a new encryption algorithm to JOSE. I’d like to
>> reserve a bit of time to discuss it at one of the upcoming interim
>> meetings.
>> The basic idea is that in many cases in OAuth and OIDC you want to
>> ensure both confidentiality and authenticity of some token - for
>> example when transferring an ID token containing PII to the client
>> through the front channel, or for access tokens intended to be handled
>> by a specific RS without online token introspection (such as the JWT
>> access token draft). If you have a shared secret key between the AS
>> and the client/RS then you can use symmetric authenticated encryption
>> (alg=dir or alg=A128KW etc). But if you need to use public key
>> cryptography then currently you are limited to a nested
>> signed-then-encrypted JOSE structure, which produces much larger token
>> sizes.
>> The draft adds a new “public key authenticated encryption” mode based
>> on ECDH in the NIST standard “one-pass unified” model. The primary
>> advantage for OAuth usage is that the tokens produced are more compact
>> compared to signing+encryption (~30% smaller for typical access/ID
>> token sizes in compact serialization). Performance-wise, it’s roughly
>> equivalent. I know that size concerns are often a limiting factor in
>> choosing whether to encrypt tokens, so this should help.
>> In terms of implementation, it’s essentially just a few extra lines of
>> code compared to an ECDH-ES implementation. (Some JOSE library APIs
>> might need an adjustment to accommodate the extra private key needed
>> for encryption/public key for decryption).
>> I’ve received a few emails off-list from people interested in using it
>> for non-OAuth use-cases such as secure messaging applications. I think
>> these use-cases can be accommodated without significant changes, so I
>> think the OAuth WG would be a good venue for advancing this.
>> I’d be interested to hear thoughts and discussion on the list prior to
>> any discussion at an interim meeting.
>> — Neil

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf

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

[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 changes to working ecosystems.  The 
Request Object was defined by OpenID Connect in 2004, so this is very much an 
existing use – not a new use.  (The OAuth JAR draft, like several other 
previous OAuth drafts, is bringing existing OpenID Connect functionality into 
the OAuth world – intentionally doing so in such a way as to not break existing 
usages.)

I agree with Brian’s assessment that the cost/benefit of adding a “typ” field 
to the Request Object doesn’t have a reasonable cost/benefit ratio.

  -- Mike

From: OAuth  On Behalf Of Brian Campbell
Sent: Thursday, July 23, 2020 1:30 PM
To: dba...@leastprivilege.com
Cc: oauth 
Subject: [EXTERNAL] Re: [OAUTH-WG] swapping a jwsreq/JAR JWT for a client 
authentication JWT

In hindsight, yeah, having explicit JWT typing everywhere would be nice.. But 
retrofitting would be a very major undertaking, which I don't think could 
reasonably be justified considering cost–benefit.

I can't speak directly for the Jwsreq authors but I suspect considerations 
around backward/forward compatibility with OIDC's JWT request and even existing 
implementations of the Jwsreq draft that has been in draft forever came into 
play.

On Wed, Jul 22, 2020 at 11:38 PM Dominick Baier 
mailto:dba...@leastprivilege.com>> wrote:
Even more. Jwsreq should have it. But the authors decided against it.

———
Dominick Baier


On 23. July 2020 at 07:38:04, Dominick Baier 
(dba...@leastprivilege.com) wrote:
Good point.. Thanks, Brian.

We should retrofit typs everywhere..in hindsight.

———
Dominick Baier


On 22. July 2020 at 23:55:20, Brian Campbell 
(bcampb...@pingidentity.com) wrote:
Because it wouldn't actually prevent it in this case due to JWT assertion 
client authentication (a.k.a. private_key_jwt) having come about well before 
the JWT BCP and the established concept of using the 'typ' header to prevent 
cross-JWT confusion. Thus there's no validation rule regarding the 'typ' header 
defined in RFC 7523 for JWT client authentication. Explicitly typing the 
request object JWT doesn't do anything to prevent it from being used in the 
context of previously existing JWT applications like client auth.

On Wed, Jul 22, 2020 at 10:32 AM Dominick Baier 
mailto:dba...@leastprivilege.com>> wrote:
Why not use a typ header as suggested by the JWT BCP?

———
Dominick Baier


On 22. July 2020 at 17:37:41, Brian Campbell 
(bcampbell=40pingidentity@dmarc.ietf.org)
 wrote:
The TL;DR here is a somewhat tentative suggestion that a brief security 
consideration be added to 
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
 that prohibits the inclusion of a 'sub' claim containing the client id value 
in the request object JWT so as to prevent the request object JWT (which is 
exposed to the user agent) from being erroneously accepted as a valid JWT for 
client authentication.

Some more details and the discussion that led to this here email can be found 
at https://github.com/oauthstuff/draft-oauth-par/issues/41

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited...  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited..  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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

+1

Von: OAuth mailto:oauth-boun...@ietf.org>> im Auftrag 
von Dick Hardt mailto:dick.ha...@gmail.com>>
Gesendet: Sonntag, 21. Juni 2020 20:42
An: Rifaat Shekh-Yusef mailto:rifaat.s.i...@gmail.com>>
Cc: oauth mailto:oauth@ietf.org>>
Betreff: Re: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in place of 
IETF108

+1

On Sat, Jun 20, 2020 at 12:34 PM Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:
All,

As you know, IETF108 will be online, and based on the discussion during the 
last interim meeting series, our plan is to schedule another series of these 
meetings for the OAuth WG.
Based on the WG feedback, the plan is to have a series of one hour meetings, 
and to discuss one document per meeting.

Based on the above, we would like to get the WG opinion on the following 
proposal:

1. Meeting day/time would be Monday @ 12:00pm Eastern Time (same as the last 
interim series)

2. Have around 9 meetings spread over 3 months:

  *   July meetings, before IETF108: July 6, 13, and 20
  *   August meetings: August 3, 10, 17
  *   September meetings: September 7, 14, 21

Thoughts?

Regards,
 Rifaat & Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[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 Behalf Of Brian Campbell
Sent: Thursday, June 18, 2020 1:32 PM
To: Daniel Fett 
Cc: oauth 
Subject: [EXTERNAL] Re: [OAUTH-WG] Mix-Up Revisited

In my (probably simplistic) understanding of things, the root underlying issue 
that allows for mix-up in its variations is the lack of anything identifying 
the AS in the authorization response. Following from that, introducing and 
using an `iss` authorization response parameter has always seemed like the most 
straightforward approach for mitigating the issue (which was part of the 
draft-ietf-oauth-mix-up-mitigation but other parameters were also included and, 
for reasons I'm not sure about, interest in that work faded in favor of telling 
clients to use per AS redirect URIs) . Though for the `iss` authorization 
response parameter to be effective, all parties involved need to know about it 
and act on it. So I think it'd need to be something more than a passing 
recommendation in the BCP. It should be defined, registered, explained, etc.. 
Actually introducing a new parameter is maybe going beyond the expected scope 
of the BCP (or 2.1). But maybe that's ok, if we're at least more intentional 
about it.

On Sun, Jun 7, 2020 at 7:53 AM Daniel Fett 
mailto:f...@danielfett.de>> wrote:
Hi all,
I was wondering if we should move towards introducing and (more explicitly) 
recommending the iss parameter in the security BCP, for the reasons laid out 
below and in the article (which is now at 
https://danielfett.de/2020/05/04/mix-up-revisited/).

Any thoughts on this?

-Daniel

Am 04.05.20 um 19:34 schrieb Daniel Fett:

Hi all,

to make substantiated recommendations for FAPI 2.0, the security considerations 
for PAR, and the security BCP, I did another analysis on the threats that arise 
from mix-up attacks. I was interested in particular in two questions:

  *   Does PAR help preventing mix-up attacks?
  *   Do we need JARM to prevent mix-up attacks?

I wrote down several attack variants and configurations in the following 
document: https://danielfett.github.io/notes/oauth/Mix-Up%20Revisited.html

The key takeaways are:

  1.  The security BCP needs to make clear that per-AS redirect URIs are only 
sufficient if OAuth Metadata is not used to resolve multiple issuers. 
Otherwise, per-Issuer redirect URIs or the iss parameter MUST be used.
  2.  PAR-enabled authorization servers can protect the integrity better and 
protect against Mix-Up Attacks better if they ONLY accept PAR requests.
  3.  We should emphasize the importance of the iss parameter (or issuer) in 
the authorization response. Maybe introduce this parameter in the security BCP 
or another document?
  4.  Sender-constrained access tokens help against mix-up attacks when the 
access token is targeted.
  5.  Sender-constraining the authorization code (PAR + PAR-DPoP?) might be 
worth looking into.

I would like to hear your thoughts!

-Daniel


___

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited..  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Downgrade attacks on PKCE

[Mike Jones]

Like Filip and Neil and I believe Ryan, I prefer the dynamic option 2.  It 
keeps existing clients working when possible, which should be a goal of OAuth 
2.1.

   Thanks,
   -- Mike

From: Dick 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>> wrote:
We (ForgeRock) already support solution 1 as a configuration option, but I 
prefer solution 2 and have raised a ticket for us to implement it. For us at 
least it’s a trivial fix and seems more robust against configuration errors.

— Neil


On 30 May 2020, at 08:58, Daniel Fett 
mailto:f...@danielfett.de>> wrote:

Hi all,

Aaron, Dick, Torsten and I today discussed the downgrade attacks on PKCE [1] 
and how to mitigate them in OAuth 2.1 and 2.0. We came to the conclusion that 
we have two options:

1. "Static" Solution

For every client_id that is registered with an AS, the AS MUST either always 
enforce the use of PKCE or always enforce the use of nonce. Whether PKCE or 
nonce is enforced can be part of the client registration or configured in other 
ways.

In other words: A single client is not allowed to switch between using PKCE and 
using nonce.

Note that the client is allowed to use the respective other mechanism on top of 
the enforced one.

Properties:

  *   Easy to understand mitigation.
  *   Implementation is mainly a new data field and a check in the 
authorization request.
  *   Not compatible to deployments where clients sometimes use nonce and 
sometimes use PKCE with the same client_id.

2. "Dynamic" Solution

Each AS that supports PKCE MUST check whether a code challenge is contained in 
the authorization request. This information MUST be bound to the code that is 
issued.

When a code arrives at the token endpoint, the AS MUST do the following check:

  1.  If there was a code_challenge in the authorization request for which this 
code was issued, there must be a code_verifier in the token request and it must 
be verified according to RFC7636. (This is no change from the current behavior 
in RFC7636.)
  2.  If there was no code_challenge in the authorization request, any request 
to the token endpoint containing a code_verifier MUST be rejected.

Properties:

  *   No change in behavior needed for properly implemented clients. Backwards 
compatible for all existing deployments.
  *   Implementation is mainly some logic for the authorization endpoint, token 
endpoint, and a new data field in the authorization session maintained by the 
AS.
  *   Slightly more complex to implement for the AS, maybe.
We would like to hear the feedback from the working group on these two 
solutions before proceeding to propose wording for the affected documents.

[1] https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/

-Daniel

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

I disagree with the language below.  It’s perfectly legal to switch, as the 
same client may do both OpenID Connect and pure OAuth interactions, depending 
upon whether the “openid” scope is included.  Both can be secure.

If the OpenID Connect `nonce` is used to mitigate authorization code
injection instead of `code_challenge`, client and authorization server
MUST ensure that the mitigation is applied to every interaction with
the client and that the client cannot 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.

I’d rather that the onus be put on new code, than existing code.  For instance 
new code wanting to require PKCE on all interactions could use something like a 
“require_pkce” dynamic client registration parameter (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: [EXTERNAL] Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

So if I'm understanding this correctly, it sounds like the AS needs to reject a 
token request with code_verifier if the authorization code was issued in 
response to a request that did not contain a code_challenge. This to me sounds 
like it would be simpler to just say the code_challenge and code_verifier are 
always required.

That said, I do understand the previously discussed concerns around existing 
OpenID Connect clients.

I believe the text that Daniel proposed is the best of both worlds, and I 
support making this change in both OAuth 2.1 and the Security BCP.

Aaron Parecki



On Tue, May 19, 2020 at 9:29 AM Nov Matake 
mailto:mat...@gmail.com>> wrote:
Yes.

The root problem isn’t the mix-use of PKCE and nonce, it’s PKCE implementation 
bug.
Yeah, all PKCE implementation MUST reject such requests, regardless it’s OAuth 
2.1 or 2.0.

(and it’s probably because of PKCE spec’s ambiguity..)


2020/05/20 1:13、Mike Jones 
mailto:michael.jo...@microsoft.com>>のメール:

So it sounds me like the fix is to have servers reject PKCE requests with 
incomplete parameter sets: requests that only contains one of code_challenge 
and code_verified.  Will that eliminate the attack, Nov?

   -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Nov Matake
Sent: Monday, May 18, 2020 11:50 PM
To: Daniel Fett mailto:f...@danielfett.de>>
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

Sure, feel free to add the senario to your post.

FYI:
my OAuth2 server ruby gem rejects such token requests,
https://github.com/nov/rack-oauth2/blob/master/lib/rack/oauth2/server/extension/pkce.rb#L28
and Google also does the same.
https://gist.github.com/nov/9feba86685bd3b18b4bf7bfb88022046

So I'm guessing such behavior is relatively rare-case, hopefully.

iPadから送信

2020/05/19 15:43、Daniel Fett 
mailto:f...@danielfett.de>>のメール:

Hi,

Am 19.05.20 um 04:55 schrieb Nov Matake:
I thought the server MUST reject such token requests, but I couldn’t find such 
definition in RFC7636...

> The client will send the code, along with a (now not matching) code_verifier 
> to the server. The server will ignore the code_verifier (as it was not 
> expected) and send back an access token and ID token to the client.
https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/#noncepkce-sidestep-attack

If the behavior is acceptable by RFC7636, "Nonce/PKCE Sidestep Attack” would be 
possible.

I *think* that there is nothing preventing servers from sometimes using PKCE 
and sometimes using Nonce. I assume that this is out of the scope of the 
existing specifications.

I would be interested to hear how actual implementations handle this in 
practice.

Plus, with such AS behavior, CSRF protection using PKCE can also be bypassed as 
below.
1. The attacker removes code_challenge from his/her own AuthZ Req, receives a 
non-code_challenge-bound code, and sends it to the victim.
2. The client receives the attacker’s code from the victim, and sends it to the 
AS w/ the valid code_verifier bound to the victim’s browser session.
3. The AS ignores the code_verifier and returns tokens.

If that’s the case, current OAuth 2.0 PKCE implementation can be weaker than 
expected..

Excellent point!

Would it be okay if I add that attack to the original post (with credits, of 
course)?

-Daniel

nov

2020/05/19 1:54、Daniel Fett mailto:f...@danielfett.de>>のメール:

Hi all,

Talking to Torsten, we realized that providing a generic extension point here 
is probably not a good idea. It is really hard to tell what protects you from 
code injection 

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

[Mike Jones]

authorization response by attackers. The use of the
`code_challenge` parameter is RECOMMENDED to this end. For
confidential clients, the OpenID Connect `nonce` parameter and ID
Token Claim {{OpenID}} MAY be used instead of or in addition to the
`code_challenge` parameter for this purpose. The `code_challenge` or
OpenID Connect `nonce` value MUST be transaction-specific and securely
bound to the client and the user agent in which the transaction was
started.

If the OpenID Connect `nonce` is used to mitigate authorization code
injection instead of `code_challenge`, client and authorization server
MUST ensure that the mitigation is applied to every interaction with
the client and that the client cannot 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 um 01:01 schrieb Mike Jones:

I agree with Nov that obscuring the language in 9.7 would be a disservice to 
developers.



The Security BCP, which has already going the WGLC, explicitly calls out the 
use of nonce as part of the best practices.  OAuth 2.1 should do no less.



The 9.7 language that Aaron proposed was the result of many people's 
contributions and a vigorous discussion.  Let's publish the next version of 2.1 
with that language intact, as I believe it represents at least a local point of 
hard-won consensus.  Let's get that language into the record of drafts.



There's always time to debate it and change it later in subsequent drafts, but 
let's not now lose what it took a lot of effort to achieve.



Thanks,

-- Mike



-Original Message-

From: Nov Matake <mailto:mat...@gmail.com>

Sent: Thursday, May 14, 2020 3:18 AM

To: Torsten Lodderstedt 
<mailto:tors...@lodderstedt.net>

Cc: OAuth WG <mailto:oauth@ietf.org>; Mike Jones 
<mailto:michael.jo...@microsoft.com>

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



There is no specific mechanism right now.

But future developers won’t be able to read the reason why the extension point 
is given only for confidential clients.



On May 14, 2020, at 18:32, Torsten Lodderstedt 
<mailto:tors...@lodderstedt.net> wrote:



Are you aware of any suitable mechanism? I’m asking since from my perspective 
this clause is mainly intended to allow existing OpenID Connect deployments to 
use nonce instead of PKCE in combination with OAuth 2.1. It’s a compromise. I 
think we should not encourage others to invent their own OAuth security 
mechanisms.



On 14. May 2020, at 09:37, Nov Matake 
<mailto:mat...@gmail.com> wrote:



Hi,



Why not allowing public clients use "other suitable mechanisms” then?

OAuth WG can allow both type of clients do so, then OIDF will define nonce as 
the alternative only for confidential clients.



2020/05/14 15:56、Torsten Lodderstedt 
<mailto:torsten=40lodderstedt@dmarc.ietf.org>のメール:



Hi all,



I would also like to thank everybody for the substantial discussion.



The proposed change for Section 4.1.2.1 works for me (as already stated). I’m 
not fully comfortable with the proposed change for Section 9.7 for the 
following reasons:



- The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of PKCE 
instead of requiring it (with a well-defined exception).

- Given the latest findings re nonce I don’t feel comfortable with recommending 
any mechanism that this WG is not responsible for and thus did not conduct the 
security threat analysis for. I think the better way for us as WG is to define 
the extension point for other mechanisms. The OpenID Foundation (or any other 
body) can then fill in and issue a statement that nonce (or another suitable 
mechanism) fulfils the requirements of the extension point.



Based on this considerations, I propose the following text for Section 9.7:



Clients MUST prevent injection (replay) of authorization codes into

the authorization 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

same way or other suitable mechanisms to mitigate authorization code

injection.



This text follows the logic in Section 4.1.2.1 and allows use of the nonce for 
confidential clients.



best regards,

Torsten.



On 12. May 2020, at 02:21, Mike Jones 
<mailto:Michael.Jones=40microsoft@dmarc.ietf.org>
 wrote:



That works for me.  Thanks all for the useful back-and-forth that got us to 
this point of clarity.  I suspect many of us learned things along the way; I 
know that I did!



Cheers,

   

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

[Mike Jones]

I agree with Nov that obscuring the language in 9.7 would be a disservice to 
developers.

The Security BCP, which has already going the WGLC, explicitly calls out the 
use of nonce as part of the best practices.  OAuth 2.1 should do no less.

The 9.7 language that Aaron proposed was the result of many people's 
contributions and a vigorous discussion.  Let's publish the next version of 2.1 
with that language intact, as I believe it represents at least a local point of 
hard-won consensus.  Let's get that language into the record of drafts.

There's always time to debate it and change it later in subsequent drafts, but 
let's not now lose what it took a lot of effort to achieve.

Thanks,
-- Mike

-Original Message-
From: Nov Matake  
Sent: Thursday, May 14, 2020 3:18 AM
To: Torsten Lodderstedt 
Cc: OAuth WG ; Mike Jones 
Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1

There is no specific mechanism right now.
But future developers won’t be able to read the reason why the extension point 
is given only for confidential clients.

> On May 14, 2020, at 18:32, Torsten Lodderstedt  
> wrote:
> 
> Are you aware of any suitable mechanism? I’m asking since from my perspective 
> this clause is mainly intended to allow existing OpenID Connect deployments 
> to use nonce instead of PKCE in combination with OAuth 2.1. It’s a 
> compromise. I think we should not encourage others to invent their own OAuth 
> security mechanisms. 
> 
>> On 14. May 2020, at 09:37, Nov Matake  wrote:
>> 
>> Hi,
>> 
>> Why not allowing public clients use "other suitable mechanisms” then?
>> OAuth WG can allow both type of clients do so, then OIDF will define nonce 
>> as the alternative only for confidential clients.
>> 
>>> 2020/05/14 15:56、Torsten Lodderstedt 
>>> のメール:
>>> 
>>> Hi all,
>>> 
>>> I would also like to thank everybody for the substantial discussion.  
>>> 
>>> The proposed change for Section 4.1.2.1 works for me (as already stated). 
>>> I’m not fully comfortable with the proposed change for Section 9.7 for the 
>>> following reasons:
>>> 
>>> - The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of PKCE 
>>> instead of requiring it (with a well-defined exception).
>>> - Given the latest findings re nonce I don’t feel comfortable with 
>>> recommending any mechanism that this WG is not responsible for and thus did 
>>> not conduct the security threat analysis for. I think the better way for us 
>>> as WG is to define the extension point for other mechanisms. The OpenID 
>>> Foundation (or any other body) can then fill in and issue a statement that 
>>> nonce (or another suitable mechanism) fulfils the requirements of the 
>>> extension point. 
>>> 
>>> Based on this considerations, I propose the following text for Section 9.7:
>>> 
>>> Clients MUST prevent injection (replay) of authorization codes into 
>>> the authorization 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 
>>> same way or other suitable mechanisms to mitigate authorization code 
>>> injection.
>>> 
>>> This text follows the logic in Section 4.1.2.1 and allows use of the nonce 
>>> for confidential clients.
>>> 
>>> best regards,
>>> Torsten. 
>>> 
>>>> On 12. May 2020, at 02:21, Mike Jones 
>>>>  wrote:
>>>> 
>>>> That works for me.  Thanks all for the useful back-and-forth that got us 
>>>> to this point of clarity.  I suspect many of us learned things along the 
>>>> way; I know that I did!
>>>> 
>>>> Cheers,
>>>> -- Mike
>>>> 
>>>> 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 text:
>>>> 
>>>> Clients MUST prevent injection (

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

[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 adding an appendix that lists out a bunch of existing OAuth 
extensions, and the device grant is in there. I also replaced the "Extension 
Grants" example in section 4.3 
(https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.3) with the 
device grant since that is deployed far wider than the SAML Assertion grant 
that was in that example in RFC6749. This will be published as version -03 in 
the next few days. Do you think that would be enough?

Aaron Parecki


On Tue, May 12, 2020 at 2:39 PM Phillip Hunt 
mailto:phil.h...@independentid.com>> wrote:
One of the use cases brought up in the ROPC thread mentioned that redirect was 
hard to do in some cases (like IoT). This reminded me of RFC8628, the OAuth 
Device Authorization Grant. I mention it because for *some* of the cases who 
say redirection is hard may be able to use the Device Authz Grant.

Would it be worth including a section in OAuth 2.1 referencing RFC8628 or, 
possibly incorporating it?

Phil Hunt
@independentid
phil.h...@independentid.com



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

That works for me.  Thanks all for the useful back-and-forth that got us to 
this point of clarity.  I suspect many of us learned things along the way; I 
know that I did!

   Cheers,
   -- Mike

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 text:

Clients MUST prevent injection (replay) of authorization codes into the
authorization response by attackers. The use of the `code_challenge`
parameter is RECOMMENDED to this end. For confidential clients, the
OpenID Connect `nonce` parameter and ID Token Claim {{OpenID}} MAY be used
instead of or in addition to the `code_challenge` parameter for this
purpose. The `code_challenge` or OpenID Connect `nonce` value MUST be
transaction-specific and securely bound to the client and the user agent
in which the transaction was started.

This change better clarifies the specific circumstances under which the "nonce" 
parameter is sufficient to protect against authorization code injection.

Aaron Parecki

On Mon, May 11, 2020 at 11:55 AM Neil Madden 
mailto:neil.mad...@forgerock.com>> wrote:
I am happy with this proposed wording. Thanks for updating it.

— Neil


On 11 May 2020, at 19:52, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:

Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!

We would like to propose the following text, which is a slight variation from 
the text Neil proposed. This would replace the paragraph in 4.1.2.1 
(https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1) that 
begins with "If the client does not send the "code_challenge" in the request..."

"An AS MUST reject requests without a code_challenge from public clients, and 
MUST reject such requests from other clients unless there is reasonable 
assurance that the client mitigates authorization code injection in other ways. 
See section 9.7 for details."

Section 9.7 is where the nuances of PKCE vs nonce are described.

As Neil described, we believe this will allow ASs to support both OAuth 2.0 and 
2.1 clients simultaneously. The change from Neil's text is the clarification of 
which threats, and changing to MUST instead of SHOULD. The "MUST...unless" is 
more specific than "SHOULD", and since we are already describing the explicit 
exception to the rule, it's more clear as a MUST here.

Aaron Parecki




___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[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: [OAUTH-WG] OAuth 2.1 - require PKCE?

Just as upgrading to OAuth 2.0 from OAuth 1.0 was voluntary, why is upgrading 
to OAuth 2.1 not voluntary?

OAuth 2.0 obsoleted OAuth 1.0, just as OAuth 2.1 is obsoleting OAuth 2.1. Our 
goal is for new deployments, that are reading the drafts, to use the best 
practices.

If existing deployments don't want the advantages of a new version or 
extension, there is nobody forcing them to upgrade -- hence my confusion on 
your statement that it is "mandatory". Upgrading to OAuth 2.0 from OAuth 1.0 
was not mandatory, and some deployments still use OAuth 1.0 today.



ᐧ

On Sun, May 10, 2020 at 12:51 PM Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
If I’m not mistaken, the OAuth 2.1 draft is intended to make OAuth 2.0 (RFC 
6749) obsolete, just like OAuth 2.0 (RFC 6749) made OAuth 1.0 (RFC 5849) 
obsolete.  That’s what makes me think developers would view updating as 
mandatory.  If you’re willing to remove the “replaces 6749” clause from 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 mailto:dick.ha...@gmail.com>>
Sent: Sunday, May 10, 2020 12:38 PM
To: Mike Jones mailto:michael.jo...@microsoft.com>>
Cc: Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>>; 
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, just as the 
other extensions. Similarly, OAuth 1.0 deployments upgrading to OAuth 2.0 was 
voluntary.

Would you clarify why you think upgrading to OAuth 2.1 would be mandatory?


On Sun, May 10, 2020 at 12:02 PM Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
I agree with actively maintaining and improving the OAuth 2.0 specs by adding 
enhancements that are voluntary to use.  I’ve worked on many such improvements, 
including Dynamic Client Registration, Authorization Metadata, the Device Flow, 
Token Exchange, DPoP, and support PAR and RAR, etc.  The issue that’s the 
subject is the current discussion is whether to make use of another 
enhancement, PKCE, mandatory in cases where it’s actually not needed, rather 
than making its use voluntary like the other enhancements, which I certainly 
support.

   -- Mike

From: Torsten Lodderstedt 
mailto:40lodderstedt@dmarc.ietf.org>>
Sent: Sunday, May 10, 2020 3:15 AM
To: Mike Jones mailto:michael.jo...@microsoft.com>>
Cc: Daniel Fett mailto:f...@danielfett.de>>; 
oauth@ietf.org<mailto: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:
OAuth 2.1 was supposed to not introduce breaking changes.
I cannot remember the WG met that decision. Can you please refer to the 
respective thread?

Requiring exact redirect URI matching is already a breaking change. Do you 
oppose against this as well?


If you want to do that, please do it in TxAuth instead.

Interesting statement. Does it mean you want to conserve OAuth 2.0 and force 
any enhancements/improvements to go into TXAuth? This would cause huge 
migration efforts for existing deployments wanting to benefit from those 
enhancements.

I think existing deployments are better served by actively maintaining and 
evolving the 2.x line. For example, PAR and RAR are attempts to improve OAuth 
2.x and make it usable for new use cases. That’s better protection of existing 
investments than sending them of to TXAuth.
Kind regards,
Torsten.


   -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Daniel Fett
Sent: Thursday, May 7, 2020 11:50 PM
To: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

+1 to all what Aaron said. Thanks for pointing this out!

We need to address this in the security BCP and this will be a normative change 
that affects OpenID Connect Core (just as our current recommendation on the 
usage of nonce).

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 think there are very good reasons to simplify this down to

- use PKCE
- you may or may not use state

First and foremost, not many people will understand why there are cases when 
the BCP/OAuth 2.1 mandate PKCE and some

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

[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; Torsten 
Lodderstedt 
Subject: Re: [OAUTH-WG] Re: OAuth 2.1 - require PKCE?

But if an AS upgrades to OAuth 2.1 then it MUST reject authorization requests 
that don’t include a code_challenge (section 4.1.2.1), so this will only be 
possible when all clients support PKCE.

This makes it impossible for a 2.1-compliant AS to also support non-PKCE 2.0 
clients (i.e., the vast majority of them).

I think we can have a 2.1 spec that says clients and servers MUST support PKCE 
without this hard-fail clause. Otherwise I can’t see how we’d ever ship with 
2.1-compliance enabled out-of-the-box.

— Neil

On 10 May 2020, at 20:38, Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:

Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, just as the 
other extensions. Similarly, OAuth 1.0 deployments upgrading to OAuth 2.0 was 
voluntary.

Would you clarify why you think upgrading to OAuth 2.1 would be mandatory?


On Sun, May 10, 2020 at 12:02 PM Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
I agree with actively maintaining and improving the OAuth 2.0 specs by adding 
enhancements that are voluntary to use.  I’ve worked on many such improvements, 
including Dynamic Client Registration, Authorization Metadata, the Device Flow, 
Token Exchange, DPoP, and support PAR and RAR, etc.  The issue that’s the 
subject is the current discussion is whether to make use of another 
enhancement, PKCE, mandatory in cases where it’s actually not needed, rather 
than making its use voluntary like the other enhancements, which I certainly 
support.

   -- Mike

From: Torsten Lodderstedt 
mailto:40lodderstedt@dmarc.ietf.org>>
Sent: Sunday, May 10, 2020 3:15 AM
To: Mike Jones mailto:michael.jo...@microsoft.com>>
Cc: Daniel Fett mailto:f...@danielfett.de>>; 
oauth@ietf.org<mailto: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:
OAuth 2.1 was supposed to not introduce breaking changes.
I cannot remember the WG met that decision. Can you please refer to the 
respective thread?

Requiring exact redirect URI matching is already a breaking change. Do you 
oppose against this as well?


If you want to do that, please do it in TxAuth instead.

Interesting statement. Does it mean you want to conserve OAuth 2.0 and force 
any enhancements/improvements to go into TXAuth? This would cause huge 
migration efforts for existing deployments wanting to benefit from those 
enhancements.

I think existing deployments are better served by actively maintaining and 
evolving the 2.x line. For example, PAR and RAR are attempts to improve OAuth 
2.x and make it usable for new use cases. That’s better protection of existing 
investments than sending them of to TXAuth.
Kind regards,
Torsten.


   -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Daniel Fett
Sent: Thursday, May 7, 2020 11:50 PM
To: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

+1 to all what Aaron said. Thanks for pointing this out!

We need to address this in the security BCP and this will be a normative change 
that affects OpenID Connect Core (just as our current recommendation on the 
usage of nonce).

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 think there are very good reasons to simplify this down to

- use PKCE
- you may or may not use state

First and foremost, not many people will understand why there are cases when 
the BCP/OAuth 2.1 mandate PKCE and some where they don't. However, 
understanding why you have to do something is key to compliance. The short 
version "PKCE protects the code; there is a specific case where it is not 
needed, but its better to use it all the time" is easy to understand. We will 
not see many implementations following the long version above correctly.

Second, we dramatically reduce technical complexity by reducing cases that need 
to be handled. We reduce correctness and compliance testing complexity in the 
same way. We reduce the cost of security analysis, which scales really badly to 
more cases.

And finally, using nonce to protect against code injection is less robust than 
PKCE. AS have a better track record than clients when it comes to correctly 
implementing security mechanisms.

Yes, thi

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

[Mike Jones]

If I’m not mistaken, the OAuth 2.1 draft is intended to make OAuth 2.0 (RFC 
6749) obsolete, just like OAuth 2.0 (RFC 6749) made OAuth 1.0 (RFC 5849) 
obsolete.  That’s what makes me think developers would view updating as 
mandatory.  If you’re willing to remove the “replaces 6749” clause from 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 - require PKCE?

Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, just as the 
other extensions. Similarly, OAuth 1.0 deployments upgrading to OAuth 2.0 was 
voluntary.

Would you clarify why you think upgrading to OAuth 2.1 would be mandatory?


On Sun, May 10, 2020 at 12:02 PM Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
I agree with actively maintaining and improving the OAuth 2.0 specs by adding 
enhancements that are voluntary to use.  I’ve worked on many such improvements, 
including Dynamic Client Registration, Authorization Metadata, the Device Flow, 
Token Exchange, DPoP, and support PAR and RAR, etc.  The issue that’s the 
subject is the current discussion is whether to make use of another 
enhancement, PKCE, mandatory in cases where it’s actually not needed, rather 
than making its use voluntary like the other enhancements, which I certainly 
support.

   -- Mike

From: Torsten Lodderstedt 
mailto:40lodderstedt@dmarc.ietf.org>>
Sent: Sunday, May 10, 2020 3:15 AM
To: Mike Jones mailto:michael.jo...@microsoft.com>>
Cc: Daniel Fett mailto:f...@danielfett.de>>; 
oauth@ietf.org<mailto: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:
OAuth 2.1 was supposed to not introduce breaking changes.
I cannot remember the WG met that decision. Can you please refer to the 
respective thread?

Requiring exact redirect URI matching is already a breaking change. Do you 
oppose against this as well?


If you want to do that, please do it in TxAuth instead.

Interesting statement. Does it mean you want to conserve OAuth 2.0 and force 
any enhancements/improvements to go into TXAuth? This would cause huge 
migration efforts for existing deployments wanting to benefit from those 
enhancements.

I think existing deployments are better served by actively maintaining and 
evolving the 2.x line. For example, PAR and RAR are attempts to improve OAuth 
2.x and make it usable for new use cases. That’s better protection of existing 
investments than sending them of to TXAuth.
Kind regards,
Torsten.


   -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Daniel Fett
Sent: Thursday, May 7, 2020 11:50 PM
To: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

+1 to all what Aaron said. Thanks for pointing this out!

We need to address this in the security BCP and this will be a normative change 
that affects OpenID Connect Core (just as our current recommendation on the 
usage of nonce).

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 think there are very good reasons to simplify this down to

- use PKCE
- you may or may not use state

First and foremost, not many people will understand why there are cases when 
the BCP/OAuth 2.1 mandate PKCE and some where they don't. However, 
understanding why you have to do something is key to compliance. The short 
version "PKCE protects the code; there is a specific case where it is not 
needed, but its better to use it all the time" is easy to understand. We will 
not see many implementations following the long version above correctly.

Second, we dramatically reduce technical complexity by reducing cases that need 
to be handled. We reduce correctness and compliance testing complexity in the 
same way. We reduce the cost of security analysis, which scales really badly to 
more cases.

And finally, using nonce to protect against code injection is less robust than 
PKCE. AS have a better track record than clients when it comes to correctly 
implementing security mechanisms.

Yes, this will make a number of implementations non-spec-compliant, but I do 
not think that this is a huge problem. Software needs to adapt all the time and 
a software that has not been changed in a while is probably not one you would 
want to use anyway. We are setting a new goal for implementations to meet and 
eventually, maintained implementations will get there.

-

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

[Mike Jones]

> Did I got it right that nonce does not protect public clients from code 
> theft/replay?

I believe that the OpenID Connect Code Hash (“c_hash”) claim protects against 
this.  I’d be interested in hearing John Bradley’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 successful, secure OAuth 2.0 and OpenID Connect 
deployments that we have the responsibility to be stewards of.  This working 
group should be proud of what it’s accomplished.  Part of good stewardship is 
not unnecessarily bifurcating the ecosystem into non-interoperable segments.  
OAuth 2.1 should facilitate the already secure OAuth 2.0 deployments remaining 
part of the interoperable OAuth 2.1 set of deployments – not intentionally 
doing the opposite.

If it ain’t broke, don’t fix it!
Did I got it right that nonce does not protect public clients from code 
theft/replay? I would consider this a security issue.

   -- Mike

From: Aaron Parecki mailto:aa...@parecki.com>>
Sent: Friday, May 8, 2020 8:34 PM
To: OAuth WG mailto:oauth@ietf.org>>
Cc: Dick Hardt mailto:dick.ha...@gmail.com>>; Torsten 
Lodderstedt mailto:tors...@lodderstedt.net>>; Mike 
Jones mailto:michael.jo...@microsoft.com>>
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 for spec 
simplicity – a goal that I do understand.  However, by writing these few 
sentences or paragraphs, we’ll make it clear to developers that hundreds or 
thousands of deployed OpenID Connect RPs won’t have to change their 
deployments.  That’s optimizing for interoperability and minimizing the burden 
on developers, which are far more important.

I appreciate the concern about optimizing for spec simplicity. I also agree 
that spec simplicity should not necessarily be the driving goal.

However, what you've described is the opposite of interoperability and 
minimizing the burden on developers. Requiring PKCE in OAuth 2.1, without any 
exceptions, will optimize for interoperability between OAuth 2.1 clients and 
servers. Without the requirement of PKCE, there will always be the question of 
"but does this OAuth 2.1 client work with this OAuth 2.1 server or not?", which 
will only be able to be answered by investigating the docs to look for PKCE 
support, or by checking the AS metadata document if it publishes one (which it 
is not required to do).

Optimizing for interoperability and minimizing the burden on developers is 
absolutely a good goal, and requiring PKCE is a great way to accomplish that. 
OAuth 2.0 and OpenID Connect implementations that don't support PKCE will 
continue to work as they currently do, they just won't be able to call 
themselves OAuth 2.1 compliant, just as is the case as if they don't follow the 
other recommendations that are in OAuth 2.1 and the Security BCP.

Aaron


On Thu, May 7, 2020 at 6:42 PM Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
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 for spec 
simplicity – a goal that I do understand.  However, by writing these few 
sentences or paragraphs, we’ll make it clear to developers that hundreds or 
thousands of deployed OpenID Connect RPs won’t have to change their 
deployments.  That’s optimizing for interoperability and minimizing the burden 
on developers, which are far more important.

As Brian Campbell wrote, “They are not equivalent and have very different 
ramifications on interoperability”.

Even if you’re optimizing for writing, taking a minimally invasive protocol 
change approach will optimize that, overall.  If we proceed as you’re 
suggesting, a huge amount of writing will occur on StackOverflow, Medium, 
SlashDot, blogs, and other developer forums, where confused developers will ask 
“Why do I have to change my deployed code?” with the answers being “Despite 
what the 2.1 spec says, there’s no need to change your deployed code.”

I’d gladly write a few sentences in our new specs now to prevent ongoing 
confusion and interop problems that would otherwise result.  Let me know when 
you’re ready to incorporate them into the spec text.

   -- Mike

From: Aaron Parecki mailto:aa...@parecki.com>>
Sent: Thursday, May 7, 2020 4:39 PM
To: Dick Hardt mailto:dick.ha...@gmail.com>>
Cc: OAuth WG mailto:oauth@ietf.org>>; Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>>;

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

[Mike Jones]

I agree with actively maintaining and improving the OAuth 2.0 specs by adding 
enhancements that are voluntary to use.  I’ve worked on many such improvements, 
including Dynamic Client Registration, Authorization Metadata, the Device Flow, 
Token Exchange, DPoP, and support PAR and RAR, etc.  The issue that’s the 
subject is the current discussion is whether to make use of another 
enhancement, PKCE, mandatory in cases where it’s actually not needed, rather 
than making its use voluntary like the other enhancements, which I certainly 
support.

   -- 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:
OAuth 2.1 was supposed to not introduce breaking changes.
I cannot remember the WG met that decision. Can you please refer to the 
respective thread?

Requiring exact redirect URI matching is already a breaking change. Do you 
oppose against this as well?


If you want to do that, please do it in TxAuth instead.

Interesting statement. Does it mean you want to conserve OAuth 2.0 and force 
any enhancements/improvements to go into TXAuth? This would cause huge 
migration efforts for existing deployments wanting to benefit from those 
enhancements.

I think existing deployments are better served by actively maintaining and 
evolving the 2.x line. For example, PAR and RAR are attempts to improve OAuth 
2.x and make it usable for new use cases. That’s better protection of existing 
investments than sending them of to TXAuth.
Kind regards,
Torsten.


   -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Daniel Fett
Sent: Thursday, May 7, 2020 11:50 PM
To: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

+1 to all what Aaron said. Thanks for pointing this out!

We need to address this in the security BCP and this will be a normative change 
that affects OpenID Connect Core (just as our current recommendation on the 
usage of nonce).

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 think there are very good reasons to simplify this down to

- use PKCE
- you may or may not use state

First and foremost, not many people will understand why there are cases when 
the BCP/OAuth 2.1 mandate PKCE and some where they don't. However, 
understanding why you have to do something is key to compliance. The short 
version "PKCE protects the code; there is a specific case where it is not 
needed, but its better to use it all the time" is easy to understand. We will 
not see many implementations following the long version above correctly.

Second, we dramatically reduce technical complexity by reducing cases that need 
to be handled. We reduce correctness and compliance testing complexity in the 
same way. We reduce the cost of security analysis, which scales really badly to 
more cases.

And finally, using nonce to protect against code injection is less robust than 
PKCE. AS have a better track record than clients when it comes to correctly 
implementing security mechanisms.

Yes, this will make a number of implementations non-spec-compliant, but I do 
not think that this is a huge problem. Software needs to adapt all the time and 
a software that has not been changed in a while is probably not one you would 
want to use anyway. We are setting a new goal for implementations to meet and 
eventually, maintained implementations will get there.

-Daniel


Am 08.05.20 um 01:38 schrieb Aaron Parecki:
Backing up a step or two, there's another point here that I think has been 
missed in these discussions.

PKCE solves two problems: stolen authorization codes for public clients, and 
authorization code injection for all clients. We've only been talking about 
authorization code injection on the list so far. The quoted section of the 
security BCP (4.5.3) which says clients can do PKCE or use the nonce, is only 
talking about preventing authorization code injection.

The nonce parameter solves authorization code injection if the client requests 
an ID token. Public clients using the nonce parameter are still susceptible to 
stolen authorization codes so they still need to do PKCE as well.

The only case where OpenID Connect clients don't benefit from PKCE is if they 
are also confidential clients. Public client OIDC clients still need to do PKCE 
even if they check the nonce.

OpenID Connect servers working with confidential clients still benefit from 
PKCE because they can then enforce the authorization code injection protection

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

[Mike Jones]

There’s a huge ecosystem of successful, secure OAuth 2.0 and OpenID Connect 
deployments that we have the responsibility to be stewards of.  This working 
group should be proud of what it’s accomplished.  Part of good stewardship is 
not unnecessarily bifurcating the ecosystem into non-interoperable segments.  
OAuth 2.1 should facilitate the already secure OAuth 2.0 deployments remaining 
part of the interoperable OAuth 2.1 set of deployments – not intentionally 
doing the opposite.

If it ain’t broke, don’t fix it!

   -- Mike

From: 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 for spec 
simplicity – a goal that I do understand.  However, by writing these few 
sentences or paragraphs, we’ll make it clear to developers that hundreds or 
thousands of deployed OpenID Connect RPs won’t have to change their 
deployments.  That’s optimizing for interoperability and minimizing the burden 
on developers, which are far more important.

I appreciate the concern about optimizing for spec simplicity. I also agree 
that spec simplicity should not necessarily be the driving goal.

However, what you've described is the opposite of interoperability and 
minimizing the burden on developers. Requiring PKCE in OAuth 2.1, without any 
exceptions, will optimize for interoperability between OAuth 2.1 clients and 
servers. Without the requirement of PKCE, there will always be the question of 
"but does this OAuth 2.1 client work with this OAuth 2.1 server or not?", which 
will only be able to be answered by investigating the docs to look for PKCE 
support, or by checking the AS metadata document if it publishes one (which it 
is not required to do).

Optimizing for interoperability and minimizing the burden on developers is 
absolutely a good goal, and requiring PKCE is a great way to accomplish that. 
OAuth 2.0 and OpenID Connect implementations that don't support PKCE will 
continue to work as they currently do, they just won't be able to call 
themselves OAuth 2.1 compliant, just as is the case as if they don't follow the 
other recommendations that are in OAuth 2.1 and the Security BCP.

Aaron


On Thu, May 7, 2020 at 6:42 PM Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
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 for spec 
simplicity – a goal that I do understand.  However, by writing these few 
sentences or paragraphs, we’ll make it clear to developers that hundreds or 
thousands of deployed OpenID Connect RPs won’t have to change their 
deployments.  That’s optimizing for interoperability and minimizing the burden 
on developers, which are far more important.

As Brian Campbell wrote, “They are not equivalent and have very different 
ramifications on interoperability”.

Even if you’re optimizing for writing, taking a minimally invasive protocol 
change approach will optimize that, overall.  If we proceed as you’re 
suggesting, a huge amount of writing will occur on StackOverflow, Medium, 
SlashDot, blogs, and other developer forums, where confused developers will ask 
“Why do I have to change my deployed code?” with the answers being “Despite 
what the 2.1 spec says, there’s no need to change your deployed code.”

I’d gladly write a few sentences in our new specs now to prevent ongoing 
confusion and interop problems that would otherwise result.  Let me know when 
you’re ready to incorporate them into the spec text.

   -- Mike

From: Aaron Parecki mailto:aa...@parecki.com>>
Sent: Thursday, May 7, 2020 4:39 PM
To: Dick Hardt mailto:dick.ha...@gmail.com>>
Cc: OAuth WG mailto:oauth@ietf.org>>; Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>>; Mike Jones 
mailto:michael.jo...@microsoft.com>>
Subject: Re: OAuth 2.1 - require PKCE?

Backing up a step or two, there's another point here that I think has been 
missed in these discussions.

PKCE solves two problems: stolen authorization codes for public clients, and 
authorization code injection for all clients. We've only been talking about 
authorization code injection on the list so far. The quoted section of the 
security BCP (4.5.3) which says clients can do PKCE or use the nonce, is only 
talking about preventing authorization code injection.

The nonce parameter solves authorization code injection if the client requests 
an ID token. Public clients using the nonce parameter are still susceptible to 
stolen authorization codes so they still need to do PKCE as well.

The only case where OpenID Connect clients don't benefi

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

[Mike Jones]

Actually, the first paragraph of the Security BCP section at 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1, 
which has gone through WGLC, includes the use of “nonce” to prevent 
authorization code injection as a best practice.  That’s already a pretty 
strong stamp 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 anything new here. We are discussing adoption of best 
practice.

The disconnect appears to be that one dependent standard’s “typical” use 
(nonces) does not have the ietf consensus as best practice.

This lack of consensus needs to be resolved.

Phil


On May 8, 2020, at 12:37 PM, Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:

FYI: An objective of OAuth 2.1 is not to introduce anything new -- it is OAuth 
2.0 with best practices.

On Thu, May 7, 2020 at 10:36 PM Philippe De Ryck 
mailto:phili...@pragmaticwebsecurity.com>> 
wrote:
From working with a lot of developers on understanding OAuth 2.0 and OIDC, I 
definitely vote for simplicity. Understanding the subtle nuances of when a 
nonce is fine and when PKCE should be used is impossible without in-depth 
knowledge of the flows and their properties. Misunderstandings will cause 
security vulnerabilities, which can easily be avoided.

Since OAuth 2.1 is a separate spec, I don’t really see a problem with existing 
code not being compliant. They support OAuth 2.0, and if they want to be OAuth 
2.1 compliant, they add PKCE. If I’m not mistaken, other requirements of OAuth 
2.1 would also clash with existing deployments (e.g., using non-exact redirect 
URIs).

I believe that optimizing for making OAuth 2.1 easier to understand will yield 
the highest return.

Philippe



On 8 May 2020, at 03:42, Mike Jones 
mailto:Michael.Jones=40microsoft@dmarc.ietf.org>>
 wrote:

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 for spec 
simplicity – a goal that I do understand.  However, by writing these few 
sentences or paragraphs, we’ll make it clear to developers that hundreds or 
thousands of deployed OpenID Connect RPs won’t have to change their 
deployments.  That’s optimizing for interoperability and minimizing the burden 
on developers, which are far more important.

As Brian Campbell wrote, “They are not equivalent and have very different 
ramifications on interoperability”.

Even if you’re optimizing for writing, taking a minimally invasive protocol 
change approach will optimize that, overall.  If we proceed as you’re 
suggesting, a huge amount of writing will occur on StackOverflow, Medium, 
SlashDot, blogs, and other developer forums, where confused developers will ask 
“Why do I have to change my deployed code?” with the answers being “Despite 
what the 2.1 spec says, there’s no need to change your deployed code.”

I’d gladly write a few sentences in our new specs now to prevent ongoing 
confusion and interop problems that would otherwise result.  Let me know when 
you’re ready to incorporate them into the spec text.

   -- Mike

From: Aaron Parecki mailto:aa...@parecki.com>>
Sent: Thursday, May 7, 2020 4:39 PM
To: Dick Hardt mailto:dick.ha...@gmail.com>>
Cc: OAuth WG mailto:oauth@ietf.org>>; Torsten Lodderstedt 
mailto:tors...@lodderstedt..net>>; Mike Jones 
mailto:michael.jo...@microsoft.com>>
Subject: Re: OAuth 2.1 - require PKCE?

Backing up a step or two, there's another point here that I think has been 
missed in these discussions.

PKCE solves two problems: stolen authorization codes for public clients, and 
authorization code injection for all clients. We've only been talking about 
authorization code injection on the list so far. The quoted section of the 
security BCP (4.5.3) which says clients can do PKCE or use the nonce, is only 
talking about preventing authorization code injection.

The nonce parameter solves authorization code injection if the client requests 
an ID token. Public clients using the nonce parameter are still susceptible to 
stolen authorization codes so they still need to do PKCE as well.

The only case where OpenID Connect clients don't benefit from PKCE is if they 
are also confidential clients. Public client OIDC clients still need to do PKCE 
even if they check the nonce.

OpenID Connect servers working with confidential clients still benefit from 
PKCE because they can then enforce the authorization code injection protection 
server-side rather than cross their fingers that clients implemented the nonce 
check properly.

I really don't think it's worth the amount of explanation this will take in the 
future to w

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

[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 the facts, balancing 
interoperability and simplicity.  That’s what we should therefore say in the 
spec (possibly rewording it to make it easier to parse and understand).

I would be OK going so far as also saying something along the lines of:
  - Alternatively, new implementations may choose to always use PKCE, provided 
that the client somehow can determine that the server it is communicating with 
also supports PKCE.
That seems like a viable compromise, giving developers accurate information 
that is actionable.

But mandating PKCE in all cases, even when unnecessary, would be an interop 
disaster and would cause many to simply ignore the new spec.

OAuth 2.1 was supposed to not introduce breaking changes.  If you want to do 
that, please do it in TxAuth instead.

   -- Mike

From: OAuth  On Behalf Of Daniel Fett
Sent: Thursday, May 7, 2020 11:50 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

+1 to all what Aaron said. Thanks for pointing this out!

We need to address this in the security BCP and this will be a normative change 
that affects OpenID Connect Core (just as our current recommendation on the 
usage of nonce).

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 think there are very good reasons to simplify this down to

- use PKCE
- you may or may not use state

First and foremost, not many people will understand why there are cases when 
the BCP/OAuth 2.1 mandate PKCE and some where they don't. However, 
understanding why you have to do something is key to compliance. The short 
version "PKCE protects the code; there is a specific case where it is not 
needed, but its better to use it all the time" is easy to understand. We will 
not see many implementations following the long version above correctly.

Second, we dramatically reduce technical complexity by reducing cases that need 
to be handled. We reduce correctness and compliance testing complexity in the 
same way. We reduce the cost of security analysis, which scales really badly to 
more cases.

And finally, using nonce to protect against code injection is less robust than 
PKCE. AS have a better track record than clients when it comes to correctly 
implementing security mechanisms.

Yes, this will make a number of implementations non-spec-compliant, but I do 
not think that this is a huge problem. Software needs to adapt all the time and 
a software that has not been changed in a while is probably not one you would 
want to use anyway. We are setting a new goal for implementations to meet and 
eventually, maintained implementations will get there.

-Daniel


Am 08.05.20 um 01:38 schrieb Aaron Parecki:
Backing up a step or two, there's another point here that I think has been 
missed in these discussions.

PKCE solves two problems: stolen authorization codes for public clients, and 
authorization code injection for all clients. We've only been talking about 
authorization code injection on the list so far. The quoted section of the 
security BCP (4.5.3) which says clients can do PKCE or use the nonce, is only 
talking about preventing authorization code injection.

The nonce parameter solves authorization code injection if the client requests 
an ID token. Public clients using the nonce parameter are still susceptible to 
stolen authorization codes so they still need to do PKCE as well.

The only case where OpenID Connect clients don't benefit from PKCE is if they 
are also confidential clients. Public client OIDC clients still need to do PKCE 
even if they check the nonce.

OpenID Connect servers working with confidential clients still benefit from 
PKCE because they can then enforce the authorization code injection protection 
server-side rather than cross their fingers that clients implemented the nonce 
check properly.

I really don't think it's worth the amount of explanation this will take in the 
future to write an exception into OAuth 2.1 or the Security BCP for only some 
types of OpenID Connect clients when all clients would benefit from PKCE anyway.

Aaron



On Wed, May 6, 2020 at 10:48 AM Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:
Hello!

We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is best 
practice for OAuth 2.0. It is not common in OpenID Connect servers as the nonce 
solves some of the issues that PKCE protects against. We think that most OpenID 
Connect implementations also support OAuth 2.0, and hence have support for PKCE 
if following best practice

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

[Mike Jones]

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 for spec 
simplicity – a goal that I do understand.  However, by writing these few 
sentences or paragraphs, we’ll make it clear to developers that hundreds or 
thousands of deployed OpenID Connect RPs won’t have to change their 
deployments.  That’s optimizing for interoperability and minimizing the burden 
on developers, which are far more important.

As Brian Campbell wrote, “They are not equivalent and have very different 
ramifications on interoperability”.

Even if you’re optimizing for writing, taking a minimally invasive protocol 
change approach will optimize that, overall.  If we proceed as you’re 
suggesting, a huge amount of writing will occur on StackOverflow, Medium, 
SlashDot, blogs, and other developer forums, where confused developers will ask 
“Why do I have to change my deployed code?” with the answers being “Despite 
what the 2.1 spec says, there’s no need to change your deployed code.”

I’d gladly write a few sentences in our new specs now to prevent ongoing 
confusion and interop problems that would otherwise 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 PKCE?

Backing up a step or two, there's another point here that I think has been 
missed in these discussions.

PKCE solves two problems: stolen authorization codes for public clients, and 
authorization code injection for all clients. We've only been talking about 
authorization code injection on the list so far. The quoted section of the 
security BCP (4.5.3) which says clients can do PKCE or use the nonce, is only 
talking about preventing authorization code injection.

The nonce parameter solves authorization code injection if the client requests 
an ID token. Public clients using the nonce parameter are still susceptible to 
stolen authorization codes so they still need to do PKCE as well.

The only case where OpenID Connect clients don't benefit from PKCE is if they 
are also confidential clients. Public client OIDC clients still need to do PKCE 
even if they check the nonce.

OpenID Connect servers working with confidential clients still benefit from 
PKCE because they can then enforce the authorization code injection protection 
server-side rather than cross their fingers that clients implemented the nonce 
check properly.

I really don't think it's worth the amount of explanation this will take in the 
future to write an exception into OAuth 2.1 or the Security BCP for only some 
types of OpenID Connect clients when all clients would benefit from PKCE anyway.

Aaron



On Wed, May 6, 2020 at 10:48 AM Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:
Hello!

We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is best 
practice for OAuth 2.0. It is not common in OpenID Connect servers as the nonce 
solves some of the issues that PKCE protects against. We think that most OpenID 
Connect implementations also support OAuth 2.0, and hence have support for PKCE 
if following best practices.

The advantages or requiring PKCE are:

- a simpler programming model across all OAuth applications and profiles as 
they all use PKCE

- reduced attack surface when using  S256 as a fingerprint of the verifier is 
sent through the browser instead of the clear text value

- enforcement by AS not client - makes it easier to handle for client 
developers and AS can ensure the check is conducted

What are disadvantages besides the potential impact to OpenID Connect 
deployments? How significant is that impact?

Dick, Aaron, and Torsten

ᐧ
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[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 OpenID Connect 
nonce to prevent authorization code injection.  Whereas the fourth paragraph 
says "Authorization servers MUST support PKCE [RFC7636].".  This imposes a 
requirement on servers that isn't present for corresponding clients.  (I missed 
this internal discrepancy within the specification when I did my review.)

I therefore request that the fourth paragraph by change to read: "OAuth Servers 
MUST support PKCE [RFC7636] unless they are only used for OpenID Connect 
Authentication Requests", making the requirements on clients and servers 
parallel.  That way PKCE will still be there unless you don't need it.  (And it 
still could be there if the server implementer chooses to have it in all cases, 
but that should be their call.)

   Thank you,
   -- Mike

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

Requiring a change to every deployed RP is not “a very small leap”.  It’s an 
invasive big deal, introducing a breaking change and bifurcating a 
well-functioning ecosystem without sufficient cause.

What this actually points out to me is that we should modify the language in 
the Security BCP to say something like “OAuth Servers MUST support PKCE unless 
they are only used for OpenID Connect Authentication Requests”.  I’d thought 
that that was already the case, as that mirrors the client requirements and I 
apparently failed to read it closely enough.  I’ll submit a separate request 
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 to this point about server vs client requirements, since both the 
Security BCP and OAuth 2.1 currently say that ASs MUST support PKCE, isn't that 
already imposing additional requirements on OpenID Connect providers that don't 
currently exist in OpenID Connect alone?

OPs that want to be compliant with the Security BCP will need to add PKCE 
support if they don't already have it (many of them already support it so for 
many of them this will not be any change), so it seems like a very small leap 
to also require clients implement PKCE as well.

On Wed, May 6, 2020 at 12:31 PM Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
I realize what it says about servers.  My point is that OAuth 2.1’s 
requirements on clients should match those in the security BCP and not try to 
go beyond them.

   -- Mike

From: Aaron Parecki mailto:aa...@parecki.com>>
Sent: Wednesday, May 6, 2020 12:24 PM
To: Mike Jones mailto:michael.jo...@microsoft.com>>
Cc: Dick Hardt mailto:dick.ha...@gmail.com>>; 
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

Yes, the BCP says *clients* may use either PKCE or nonce to prevent 
authorization code injection. Shortly after that quoted segment is the below:

> Authorization servers MUST support PKCE [RFC7636].

On 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:

   Clients MUST prevent injection (replay) of authorization codes into
   the authorization response by attackers.  The use of PKCE 
[RFC7636<https://tools.ietf.org/html/rfc7636>]
   is RECOMMENDED to this end.  The OpenID Connect "nonce" parameter and
   ID Token Claim 
[OpenID<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#ref-OpenID>]
 MAY be used as well.  The PKCE challenge or
   OpenID Connect "nonce" MUST be transaction-specific and securely
   bound to the client and the user agent in which the transaction was
   started.

We should not attempt to change that in OAuth 2.1, as doing so would needlessly 
break already working and secure clients.

   -- Mike

From: Aaron Parecki mailto:aa...@parecki.com>>
Sent: Wednesday, May 6, 2020 11:56 AM
To: Mike Jones mailto:michael.jo...@microsoft.com>>
Cc: Dick Hardt mailto:dick.ha...@gmail.com>>; 
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

> In particular, authorization servers shouldn’t be required to support PKCE 
> when they already support the OpenID Connect nonce.

The Security BCP already requires that ASs support PKCE: 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 
Are you suggesting that the Security BCP change that requirement as well? If 
so, that's a discussion that needs to be had ASAP. If not, then that's an 
implicit statement that it's okay for OpenID Connect implementations to not be 
best-practice OAuth implementations. And if that's the case, then I also think 
it's acceptable that they are not complete OAuth 2.1 implementations either.






On Wed, May 6, 2020 at 11:21 AM Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
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 
https://openid.net/certification/), none of which have ever been required to 
support PKCE.  Therefore, most don’t.

Per feedback already provided, I believe that OAuth 2.1 should align with the 
guidance already in the draft Security BC

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

[Mike Jones]

It could, but that would require an explicit decision by the OpenID Connect 
working group to make existing RPs incompatible with new OPs, breaking 
interoperability.  That’s not a decision we should make lightly or without a 
compelling reason to do so.

   -- 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 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:

Yes, FAPI requires PKCE, which is great.  Many of its requirements come from 
OpenID Connect but some of them are intentionally incompatible – such as 
requiring that Basic authentication not be supported, whereas Connect requires 
that it be supported.  It’s a different ecosystem with different requirements.

Don’t get me wrong, I support PKCE where it makes sense, such as when you’re 
doing bare OAuth without OpenID Connect.  But trying to impose an unnecessary 
requirement on a working and secure ecosystem will just create grief for us and 
our customers and lessen our credibility as stewards of the OAuth ecosystem.

   -- Mike

From: Aaron Parecki mailto:aa...@parecki.com>>
Sent: Wednesday, May 6, 2020 12:29 PM
To: Steinar Noem mailto:stei...@udelt.no>>
Cc: Phillip Hunt 
mailto:phil.h...@independentid.com>>; Mike Jones 
mailto:michael.jo...@microsoft.com>>; 
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

I should add that even some OpenID Connect profiles require PKCE, such as FAPI:

https://openid.net/specs/openid-financial-api-part-1.html#authorization-server

So the precedent for requiring PKCE already exists within some OpenID Connect 
profiles.

On Wed, May 6, 2020 at 12:23 PM Aaron Parecki 
mailto:aa...@parecki.com>> wrote:
Yes, and also, many of those providers very likely already support PKCE 
already. Skimming through that list of certified OPs, I recognize many names 
there from providers that I know support PKCE.

On Wed, May 6, 2020 at 12:18 PM Steinar Noem 
mailto:stei...@udelt.no>> wrote:
So, wouldn't a MUST just mean that we would have some OPs that are 2.1 
compliant and some that aren't?

ons. 6. mai 2020 kl. 21:12 skrev Phillip Hunt 
mailto:phil.h...@independentid.com>>:
Mike,

The point of 2.1 is to raise the security bar..

Yes it adds new MUST requirements.

But what about OIDC would break other than required implementation of PKCE to 
support 2.1?

Eg Would additional signaling be required to facilitate interoperability and 
migration between versions? Would that be an oauth issue or an OIDC one?

Phil



On May 6, 2020, at 11:56 AM, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:

> In particular, authorization servers shouldn’t be required to support PKCE 
> when they already support the OpenID Connect nonce.

The Security BCP already requires that ASs support PKCE: 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 
Are you suggesting that the Security BCP change that requirement as well? If 
so, that's a discussion that needs to be had ASAP. If not, then that's an 
implicit statement that it's okay for OpenID Connect implementations to not be 
best-practice OAuth implementations. And if that's the case, then I also think 
it's acceptable that they are not complete OAuth 2.1 implementations either.






On Wed, May 6, 2020 at 11:21 AM Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
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 
https://openid.net/certification/), none of which have ever been required to 
support PKCE.  Therefore, most don’t.

Per feedback already provided, I believe that OAuth 2.1 should align with the 
guidance already in the draft Security BCP, requiring EITHER the use of PKCE or 
the OpenID Connect nonce.  Trying to retroactively impose unnecessary 
requirements on existing deployments is unlikely to succeed and will 
significantly reduce the relevance of the OAuth 2.1 effort.

In particular, authorization servers shouldn’t be required to support PKCE when 
they already support the OpenID Connect nonce.  And clients shouldn’t reject 
responses from servers that don’t support PKCE when they do contain the OpenID 
Connect nonce.  Doing so would unnecessarily break things and create confusion 
in the marketplace.

  -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>>