[OAUTH-WG] Re: [Technical Errata Reported] RFC9470 (7951)

[Justin Richer]

This seems to be logical - the authentication event would always be before the 
token was issued in the usual case. However, assuming that the AS "upgrades" an 
existing token in-place during a step up, isn't it possible for the latest 
relevant authentication event to come after the token was initially issued?

 - Justin

From: RFC Errata System 
Sent: Wednesday, May 22, 2024 2:30 PM
To: vitto...@auth0.com ; bcampb...@pingidentity.com 
; debcool...@gmail.com ; 
paul.wout...@aiven.io ; hannes.tschofe...@arm.com 
; rifaat.s.i...@gmail.com 
Cc: tomasz.kuczyn...@man.poznan.pl ; 
oauth@ietf.org ; rfc-edi...@rfc-editor.org 

Subject: [OAUTH-WG] [Technical Errata Reported] RFC9470 (7951)

The following errata report has been submitted for RFC9470,
"OAuth 2.0 Step Up Authentication Challenge Protocol".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7951

--
Type: Technical
Reported by: Tomasz Kuczyński 

Section: 6.2

Original Text
-
 "exp": 1639528912,
 "iat": 1618354090,
 "auth_time": 1646340198,

Corrected Text
--
 "exp": 1639528912,
 "iat": 1618354090,
 "auth_time": 1618354090,

Notes
-
I noticed a small inconsistency in the example "Figure 7: Introspection 
Response". It seems that the time for the user-authentication event should be 
less than or equal to the time of token issuance to ensure logical coherence.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
will log in to change the status and edit the report, if necessary.

--
RFC9470 (draft-ietf-oauth-step-up-authn-challenge-17)
--
Title   : OAuth 2.0 Step Up Authentication Challenge Protocol
Publication Date: September 2023
Author(s)   : V. Bertocci, B. Campbell
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Stream  : IETF
Verifying Party : IESG

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

Re: [OAUTH-WG] OAuth for Browser-Based Apps

[Justin Richer]

I think it does warrant mentioning, because the main assumptions about an spa 
are that everything goes from the browser to the api itself. It might be 
surprising to a user or even a naive developer that every request goes through 
another party as a black box. Even if it's all first party abd deployed 
together, that model should be called out by the draft as an assumption for 
privacy. After all, this section is for considerations - things you should 
think about that might not be obvious.

- Justin

From: Philippe De Ryck 
Sent: Sunday, March 24, 2024 5:40 AM
To: Justin Richer 
Cc: oauth 
Subject: Re: [OAUTH-WG] OAuth for Browser-Based Apps

Hi Justin,

Thank you for your detailed review.

> §9+ this draft should add privacy considerations, particularly for BFF 
> pattern's proxy architecture.e

I wanted to ask for a bit more context on this comment. I understand that 
having a proxy as a separate entity would expose all requests/responses to this 
entity. However, in the context of a BFF, the frontend and the BFF belong 
together (i.e., they are one application deployed as two components). The 
frontend and BFF are deployed and operated by the same party, so I’m not sure 
if this comment effectively applies.

Looking forward to hearing from you.

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

Re: [OAUTH-WG] draft-zhang-jose-json-fine-grained-access

[Justin Richer]

Thank you for presenting your proposal to the group in Brisbane.

Reading through the draft, it seemed that there are really two topics in here, 
and I'm wondering how they could be split:

1, a data structure for complex access rights

2, a cryptographic mechanism for selectively encrypting some of those rights to 
protect them from unintentional audiences.

The data structure used to convey the access rights seems very similar to the 
object structure defined by RAR, RFC9396: https://www.rfc-editor.org/rfc/RFC9396

I was unable to find something in this data structure that is required to 
provide the cryptographic hiding functionality, have I missed something? Or 
would it be possible to apply this to RAR objects?

Does the key distribution happen or of band of the protocol? In the oauth 
world, would these keys become part of the RS configuration?

Thank you,

- Justin

From: OAuth  on behalf of jiangcheng 

Sent: Tuesday, March 19, 2024 9:42 PM
To: OAuth@ietf.org 
Cc: zhangjl382 ; jill32 
Subject: [OAUTH-WG] draft-zhang-jose-json-fine-grained-access


Dear oauth，



  We have a draft and we are looking forward to soliciting comments on it.

  
https://datatracker.ietf.org/doc/draft-zhang-jose-json-fine-grained-access/


Best regards

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

Re: [OAUTH-WG] DPoP introspection not including verification

[Justin Richer]

While I don’t have an answer for the question asked, I do want to note that in 
order to do a proper validation, the introspection request would have to 
include the values of the DPoP proof, but also the expected HTM and HTU values 
from the RS, as the AS would not know these directly.

— Justin

On Mar 10, 2024, at 4:05 PM, Dick Hardt  wrote:

Hey

I was reading over RFC 9449 and was surprised that introspection did not take 
the DPoP header so that the introspection endpoint could do the check on the 
DPoP proof rather than forcing the Resource Server to do it.

https://datatracker.ietf.org/doc/html/rfc9449#name-jwk-thumbprint-confirmation-

Curious what was the reasoning behind this?

/Dick
___
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-WG] OAuth for Browser-Based Apps

[Justin Richer]

As promised at the last meeting, I have been able to do a full review of the 
OAuth for Browser Based Applications draft spec, and my notes are attached, 
indexed by sections and paragraphs where possible.

Even though my notes are extensive, I do want to say that overall the document 
is in great shape and I think it offers great guidance and necessary support to 
application developers. Many of my comments focus around clarifying intent, 
consistency in language, and addressing specific concerns like when the 
document might be too opinionated (or not opinionated enough).

Thank you to the authors for this momentous work!

— Justin




OAuth for browser-based apps

Title and throughout: should we use "applications" instead of "apps"? The 
document is not consistent.

§1:

¶1 should be specific here and elsewhere:
"implementing OAuth 2.0" -> "implementing OAuth 2.0 clients"

¶2 perhaps "is known as" or "is referred to" instead of nicknamed?

BCP for native apps should be the reference, not the RFC

"implement OAuth clients"

¶3 perhaps "This specification, OAuth 2.0 for Browser-Based Apps, ..."

"implementing OAuth <> native apps and browser-based apps"

§2: nit, there's a BCP to reference here instead of 2119 directly

§3: if not expanding "app" to "application" throughout, perhaps call out here, 
even though it's fairly obvious it doesn't hurt

¶4 does "this" refer to the phrase "JavaScript applications" or the document as 
a whole and its recommendations?

§4:

¶1 the use of "were" is confusing here since OAuth 2.0 is considered one 
protocol framework; perhaps rephrase:

"At the time that OAuth 2.0 was initially specified in [RFC6749] and 
[RFC6750],"

"authorization code flow" -> "authorization code grant type" ... and throughout 
the rest of the document, generally change "flow" to "grant type" when 
referring to the official grant names. same applies to "implicit" flow and any 
others

"this was one" -> "this limitation(?) was one"

¶3 add a reference for CORS?

exposure of tokens is not the problem for refresh tokens historically, it's 
been the lack of client credentials in SPAs and poor storage mechanisms to go 
with the refresh token

¶4 second sentence has many asides and parentheticals and is hard to follow, 
suggest rewording


§5 does "JavaScript" here also refer to other browser-based execution 
languages, or is this advice JavaScript only? The definition in §3 only calls 
out "JavaScript application" specifically, not "JavaScript" being used as a 
generic in general

¶1 remove commas from "vectors, such as ... files, give an"

¶2 "JS" -> "JavaScript" (and elsewhere), or expand and define on first use

is the bold formatting really necessary to make this point?

¶3 perhaps instead of "the first part" and "the second part", link sections 
directly and number them specifically (5.1, 5.2) so as to prevent the reader 
from tripping over what constitutes the first or second "part"

¶4 it feels odd to introduce what other sections will do in this section, but 
I'm not sure where else to put this pointer, which is likely helpful to the 
reader if they're going all the way through the document

§5.1 suggest removal of "range from trivial to sophisticated" as it implies 
ranking even though the next sentence says there is no implied ranking; and 
adversarial toolkits can sometimes make sophisticated attacks trivial to 
execute in practice.

§5.1.1 why does this scenario underestimate the capabilities of an attacker? It 
is real and can cause damage. I think what might be intended here is that if a 
developer focuses only on thwarting this trivial attack they are 
underestimating an attacker's ability, is that the case? In any event perhaps 
such value judgement isn't helpful unless it's tied to specific guidance for 
the reader.

§5.1.2 the attack in §5.1.1 does not depend on theft of token from the payload 
of the token response but rather from storage; is this difference intended? or 
is "the payload" meant to refer to the attacker's payload of malicious code?

¶2 I believe the second bullet list is supposed to have a sub-list, but this 
was not rendered as such in the version I reviewed

§5.1.3

"Setup" -> "set up"

add reference for "Web Messaging"?

It should be noted that a precondition to step (3) is that it's only possible 
if the authz code can be issued silently and in a frame context, or else the 
payload would need to manipulate the AS into doing so; this is mentioned in the 
closing paragraph but it felt out of place not to put it sooner

§5.2.1 nit, it's not impersonation of the user so much as impersonation of the 
legitimate client application

§5.2.2 same nit as above, not the user but the client; any other place this 
appears should also be aligned

¶2: suggest "considers the access token to be valid" -> "accepts the valid 
access token".

¶5 the "additionally" doesn't follow from the preceding text, suggest pulling 
it out or re-ordering the topics here

§5.2.3

¶2 CORS 

Re: [OAUTH-WG] For review/discussion: Cedar profile of OAuth Rich Authorization Requests

[Justin Richer]

On top of that, since the RAR structure is fundamentally an array, existing 
open banking stuff could still use their types alongside the cedar type, if 
they wanted. Combining them would be an interesting exercise for each 
ecosystem, but you’ll run into that regardless of the vertical.

— Justin

On Feb 23, 2024, at 4:14 PM, Brian Campbell  wrote:

Yeah, communication of intent was not supposed to be the purpose of the type 
parameter value. Although I do (now) see how many of the examples in 
RAR/RFC9396 kinda read that way. The 
https://www.rfc-editor.org/rfc/rfc9396.html#section-2-2.2 definition of type 
tries to convey what it is intended to do, which is that it "determines the 
allowable contents of the object that contains it." Shortly after at 
https://www.rfc-editor.org/rfc/rfc9396.html#section-2.1-2 it talks about using 
a collision-resistant value for applications expected to be widely deployed 
(e.g., beyond a single AS), which seems appropriate for Cedar, and is followed 
by an example that uses a URL as the type value.




On Fri, Feb 23, 2024 at 1:38 PM Cecchetti, Sarah 
mailto:40amazon@dmarc.ietf.org>> 
wrote:

Interesting. We considered using the type parameter, but decided against it. In 
the examples in the spec, the spirit of type seems to be an indication of the 
intent of the request (for example "customer_information" or 
"payment_initiation.") We were concerned about breaking existing open banking 
implementations if we took away the ability for the client to include an intent 
in the request and substitute the format of the request. We would like for 
existing open banking implementations to simply use a consistent format for 
their requests, not to override the intent of the request if that's something 
that's important for them to communicate.

If communication of intent is not important, we're happy to just specify the 
content the type parameter and define a new policySet parameter, or possibly 
just give guidance to put a policy set within "privileges."


Sarah Cecchetti



From: Brian Campbell 
mailto:40pingidentity@dmarc.ietf.org>>
Sent: Friday, February 23, 2024 11:25:56 AM
To: Justin Richer
Cc: Cecchetti, Sarah; oauth
Subject: RE: [EXTERNAL] [OAUTH-WG] For review/discussion: Cedar profile of 
OAuth Rich Authorization Requests


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'm inferring some intent (apologies if I've got it wrong!) but I think it'd 
make the most sense for this work to start with defining a RAR type value 
(something like "https://cedarpolicy.com<https://cedarpolicy.com/>") and define 
that type as having the "policySet"  parameter. An updated example figure 1 
from the draft would look like the below.  As Justin said, RAR intends the 
“type” field as the extensibility point that defines the semantics of all other 
parts in the typed object. So it would be saying this is a Cedar type 
authorization_details element and it contains this "policySet" parameter that 
has the actual Cedar policy in it.



{
"type": "https://cedarpolicy.com<https://cedarpolicy.com/>"
"policySet": "
  permit (
principal == BankA::User::\"696d28c8-8912-41d2-b182-aa7087323318\",
action == BankA::Action::\"initiate\",
resource == 
Creditor::\"https://example.com/payments\<https://example.com/payments%5C>"
)
when { context.instructedAmount.currency == \"EUR\" &&
context.instructedAmount.amount == decimal(\"123.50\") &&
resource.creditorName == \"Merchant A\" &&
resource.creditorAccount.bic == \"ABCIDEFFXXX\" &&
resource.creditorAccount.iban == \"DE02100100109307118603\" &&
context.remittanceInformationUnstructured == \"Ref Number Merchant\"
};
"
}

On Thu, Feb 22, 2024 at 11:15 AM Justin Richer 
mailto:jric...@mit.edu>> wrote:
Hi Sarah,

Thanks for putting that draft together. As one of the authors of RAR, I wanted 
to chime in.

First, I do think that this is a great use of RAR. The whole idea behind RAR 
was to give people structures that they could use beyond what scopes allow, and 
tying this to a computable policy language like Cedar makes a lot of sense to a 
lot of use cases. In particular, as with any other RAR object, this could show 
up in the client’s request to the AS, the AS’s response to the client, or the 
token’s resulting metadata (basically AS message to the RS via the token), and 
having an explicit policy in each of those places deserves discussion.

Next, I wanted to provide some specific feedback about the implementation 
proposed in the draft, because I t

Re: [OAUTH-WG] For review/discussion: Cedar profile of OAuth Rich Authorization Requests

[Justin Richer]

Hi Sarah,

Thanks for putting that draft together. As one of the authors of RAR, I wanted 
to chime in.

First, I do think that this is a great use of RAR. The whole idea behind RAR 
was to give people structures that they could use beyond what scopes allow, and 
tying this to a computable policy language like Cedar makes a lot of sense to a 
lot of use cases. In particular, as with any other RAR object, this could show 
up in the client’s request to the AS, the AS’s response to the client, or the 
token’s resulting metadata (basically AS message to the RS via the token), and 
having an explicit policy in each of those places deserves discussion.

Next, I wanted to provide some specific feedback about the implementation 
proposed in the draft, because I think there are a few ways it could go and 
each might make sense.

One of the benefits to RAR is that it’s the “type” field that defines the 
semantics of all other parts in the typed object — which also makes 
interoperable definitions a bit trickier. With that in mind, what is the 
intended target of the “rarFormat” and “policySet” fields?

Is the goal of this draft to define another set of “Common Data Fields” to be 
used across different types, as is done in RAR section 2.2? 
(https://www.rfc-editor.org/rfc/rfc9396.html#name-common-data-fields) If so, 
that should be called out explicitly, as is done in RFC9396. Are there intended 
interactions with other common data fields, such as filtering the policy based 
on location or action, for example?

Or is the goal that these be defined in a specific set of “type” values that 
would comply to this format? If so, what are the conditions for using and 
extending this format? The way the “rarFormat” text is currently written, it 
seems to put constraints on the rest of the object defined by the “type”, so is 
the intent that you’d have rar-cedar-compliant types that follow this pattern?

Or is the goal to define a generic and extensible field set that can be re-used 
by other policy languages? That seems to be hinted at with the separate format 
and data fields, but as written only one is defined so it’s difficult to tell, 
at this stage, what the intended abstraction points are. If only one is 
defined, then would it make sense to just define a single “cedarPolicy” 
parameter instead of the two? And if there’s another format that comes along, 
it can follow Cedar’s example and do something similar. The “type” would define 
how to handle having different policy formats in a single object, to avoid 
overlaps.

And if the answer to all of this is “I don’t know”, that’s also reasonable at 
this stage as these are great questions for the WG to answer. :)

Finally, since RAR is based on JSON data types, and Cedar uses multi-line 
strings (at least for display in the examples), the intent of this value 
translation is going to have to be spelled out. As in, a real example on the 
wire would need to have all the newlines encoded as \n and the like, in order 
to be JSON. This is almost certainly me reading too much into the hand-crafted 
examples on a new drafts, but I wanted to raise this as something that’ll need 
to be solved for Cedar and, depending on the answers above, other languages. In 
other words, can we always assume that a policy is always encoded as a single 
string, or is there other structure that might work better? This is not my area 
of expertise and I have no opinions on the answer, so if strings are good 
enough that’s fine by me. :)

Thank you, and I hope to see this work continue!

 — Justin

On Feb 21, 2024, at 5:06 PM, Cecchetti, Sarah 
 wrote:

I have submitted a new draft:

https://datatracker.ietf.org/doc/html/draft-cecchetti-oauth-rar-cedar

This is intended to be a profile of RFC 9396 OAuth 2.0 Rich Authorization 
Requests (OAuth RAR). OAuth RAR defines an authorization_details parameter, but 
leaves the format of the parameter open. This profile defines a rarFormat 
parameter to further constrain authorization_details to use a specific format 
called "cedar."

The use case for this draft is the same as the OAuth RAR use case - i.e. open 
banking specifically, and fine-grained authorization generally. The intent is 
to make the standard more interoperable by specifying the policy language which 
will be used to communicate the authorization request and response. The 
language used in these examples is Cedar, an open-source policy language - 
https://www.cedarpolicy.com/en. Putting Cedar policy sets within an OAuth token 
enables the client and RS to conduct transactions which conform to specific 
fine-grained policies which have been blessed(signed) by the AS.

Open Questions:

  1.  Should we create a separate informational draft defining the Cedar 
language itself within the universe of the IETF? Or is it fine to leave that 
undefined?
  2.  Is rarFormat the right name for this parameter?
  3.  Should policySet be required?
  4.  I tried to keep this draft fairly simple and duplicate 

Re: [OAUTH-WG] [Technical Errata Reported] RFC7591 (7782)

[Justin Richer]

I believe this correction is valid, though I think that the changing of a 
normative requirement is beyond an erratum. 

Ultimately, though, this comes down to the definition of what "a client" is, 
which is pretty fuzzy in OAuth. The AS needs to be able to issue the same 
identifier to what it feels is an instance of the same client software, if it 
wants to do that. You can think of these instances as different clients in a 
way, which is what the ’SHOULD NOT’ was for. However, if you contend that these 
instances are "the same client" then the 'MUST NOT' makes sense. 

In the end, I’m not sure how much difference this change would actually make 
for implementations, because of the fuzziness around the definitions. I’m 
hopeful that some of the new language in OAuth 2.1 around client types and 
instances and registration will help settle this and we can call things 
something consistent.

As such, I’m on the fence whether we should accept or reject the erratum — 

 - if we accept, that’s a normative change, but not likely to affect other 
implementations (especially those that implement the OIDC version already)
 - if we reject, we obviously don’t change implementations but we also keep 
carrying this ambiguity forward

 — Justin

> On Jan 25, 2024, at 1:25 AM, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC7591,
> "OAuth 2.0 Dynamic Client Registration Protocol".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7782
> 
> --
> Type: Technical
> Reported by: Tim Würtele 
> 
> Section: 3.2.1
> 
> Original Text
> -
> client_id
>  REQUIRED.  OAuth 2.0 client identifier string.  It SHOULD NOT be
>  currently valid for any other registered client, though an
>  authorization server MAY issue the same client identifier to
>  multiple instances of a registered client at its discretion.
> 
> Corrected Text
> --
> client_id
>  REQUIRED.  OAuth 2.0 client identifier string.  It MUST NOT be
>  currently valid for any other registered client, though an
>  authorization server MAY issue the same client identifier to
>  multiple instances of a registered client at its discretion.
> 
> Notes
> -
> Allowing the same client_id for multiple clients is a contradiction to:
> 
> 1. This document, Section 1.3, (D), 2nd bullet point: "a client identifier 
> that is unique at the server"
> 
> 2. This document, Section 3.1: "The authorization server assigns this client 
> a unique client identifier"
> 
> 3. (normative reference) RFC 6749, Section 2.2: "The authorization server 
> issues the registered client a client identifier -- a unique string 
> representing the registration information provided by the client. [...] The 
> client identifier is unique to the authorization server."
> 
> 4. (non-normative reference) OpenID Connect Dynamic Client Registration 1.0 
> incorporating errata set 2, Section 2: "Clients have metadata associated with 
> their unique Client Identifier at the Authorization Server."; Section 3.1: 
> "The Authorization Server assigns this Client a unique Client Identifier"; 
> Section 3.2: "client_id REQUIRED. Unique Client Identifier. It MUST NOT be 
> currently valid for any other registered Client. "
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it 
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> will log in to change the status and edit the report, if necessary.
> 
> --
> RFC7591 (draft-ietf-oauth-dyn-reg-30)
> --
> Title   : OAuth 2.0 Dynamic Client Registration Protocol
> Publication Date: July 2015
> Author(s)   : J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. 
> Hunt
> Category: PROPOSED STANDARD
> Source  : Web Authorization Protocol
> Area: Security
> Stream  : IETF
> Verifying Party : IESG

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

Re: [OAUTH-WG] [Errata Rejected] RFC7519 (5648)

[Justin Richer]

As much as I agree that suggesting a pronunciation in a spec like this is 
silly, I believe the errata should be rejected as the text was agreed upon by 
the WG as it stands. This is not an error, but rather a stylistic disagreement 
from the reporter.

-Justin


From: OAuth  on behalf of RFC Errata System 

Sent: Thursday, January 11, 2024 9:53 PM
To: adelcam...@gmail.com ; m...@microsoft.com 
; ve7...@ve7jtb.com ; 
n-sakim...@nri.co.jp 
Cc: rfc-edi...@rfc-editor.org ; i...@ietf.org 
; oauth@ietf.org 
Subject: [OAUTH-WG] [Errata Rejected] RFC7519 (5648)

The following errata report has been rejected for RFC7519,
"JSON Web Token (JWT)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5648

--
Status: Rejected
Type: Editorial

Reported by: Andy Delcambre 
Date Reported: 2019-03-08
Rejected by: Roman Danyliw (IESG)

Section: 1

Original Text
-
JSON Web Token (JWT) is a compact claims representation format
   intended for space constrained environments such as HTTP
   Authorization headers and URI query parameters.  JWTs encode claims
   to be transmitted as a JSON [RFC7159] object that is used as the
   payload of a JSON Web Signature (JWS) [JWS] structure or as the
   plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling
   the claims to be digitally signed or integrity protected with a
   Message Authentication Code (MAC) and/or encrypted.  JWTs are always
   represented using the JWS Compact Serialization or the JWE Compact
   Serialization.

   The suggested pronunciation of JWT is the same as the English word
   "jot".



Corrected Text
--
JSON Web Token (JWT) is a compact claims representation format
   intended for space constrained environments such as HTTP
   Authorization headers and URI query parameters.  JWTs encode claims
   to be transmitted as a JSON [RFC7159] object that is used as the
   payload of a JSON Web Signature (JWS) [JWS] structure or as the
   plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling
   the claims to be digitally signed or integrity protected with a
   Message Authentication Code (MAC) and/or encrypted.  JWTs are always
   represented using the JWS Compact Serialization or the JWE Compact
   Serialization.


Notes
-
The suggested pronunciation is strange and confusing. It makes it hard to 
onboard new people verbally and always requires an explanation of the 
pronunciation. The standard already has a perfectly reasonable initialism of 
JWT that clearly refers to JSON Web Tokens. It is jarring to suggest a 
pronunciation that does not map to the letters of the spec, and in my 
experience often leads to confusion when used.
 --VERIFIER NOTES--
This guidance was produced with the consensus of the WG.  Per 
https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/,
 "Errata are items that were errors at the time the document was published"

--
RFC7519 (draft-ietf-oauth-json-web-token-32)
--
Title   : JSON Web Token (JWT)
Publication Date: May 2015
Author(s)   : M. Jones, J. Bradley, N. Sakimura
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
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] Shepherd Review of draft-ietf-oauth-security-topics-23

[Justin Richer]

On Jan 3, 2024, at 12:30 PM, axel.nenn...@telekom.de wrote:

The email discussion triggered me jumping into the discussion.
Also, I am looking into this from a Camara PoV.
https://github.com/camaraproject/IdentityAndConsentManagement
Camara is about to define what is a MUST for authorization servers etc and we 
are taking FAPI and the OAuth2 security best practices as input.

So, when we write our own security profile in Camara, we are probably going to 
copy the language "Authorization servers MUST support PKCE 
[RFC7636]."
We then have no problem requiring clients to use PKCE.

Coming back to draft-ietf-oauth-security-topics-23. That document's language 
feels like it would really, really likes to require PKCE support, but then it 
does not go there.
"Public clients MUST use PKCE"
"For confidential clients, the use of PKCE 
[RFC7636]
 is RECOMMENDED"
"Authorization servers MUST support PKCE 
[RFC7636]."
"Although PKCE was designed as a mechanism to protect native apps, this advice 
applies to all kinds of OAuth clients, including web applications."


I read this as pretty clear advice — the AS has to support it, but doesn’t 
universally require it. Public clients have to use it, so an AS could 
reasonably require it automatically for public clients. Confidential clients 
can use it, and it’s a good idea, but it would be surprising for an AS to 
enforce it on a confidential client. Of course, even today, an AS can decide 
that any particular client has to use PKCE for whatever reason, so we’re not 
that different in the "maybe" space than we are now.


The following two lines are talking about different things:

I still think that the MAY in 2.1
"Clients that have ensured that the authorization server supports Proof Key for 
Code Exchange (PKCE, 
[RFC7636])
 MAY rely on the CSRF protection provided by PKCE. "

This is not about the client using or not using PKCE — it’s about the client 
relying on PKCE for CSRF protection, which was previously relegated to state 
and nonce parameters alone.

and the MUST in 2.1.1
"Authorization servers MUST support PKCE 
[RFC7636]."

This just means it has to be available at the AS for anyone to use, and, as 
above, possibly required for some circumstances.

do not go well together.

//Axel


 — Justin


From: OAuth mailto:oauth-boun...@ietf.org>> on behalf 
of Daniel Fett 
mailto:mail=40danielfett...@dmarc.ietf.org>>
Date: Wednesday, 3. January 2024 at 17:48
To: oauth@ietf.org 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-security-topics-23

Hi Axel,

It is to be expected that not all AS will immediately upgrade to adhere to the 
security BCP after its release. So a client who wants to use PKCE may encounter 
AS that don't support it.

See also the discussion in 
https://mailarchive.ietf.org/arch/msg/oauth/ZiwEfenZZlboikXxBLes5ebPmBw/

-Daniel

Am 03.01.24 um 17:39 schrieb 
axel.nenn...@telekom.de:
Hi Daniel,

there is also this sentence in this section 
https://oauthstuff.github.io/draft-ietf-oauth-security-topics/draft-ietf-oauth-security-topics.html#name-authorization-code-grant
 in a paragraph on it own.

"Authorization servers MUST support PKCE 
[RFC7636]."

Why must a client "ensure" that the AS supports PKCE if the security best 
practices say the AS MUST support PKCE?

//Axel


From: OAuth  on behalf 
of Daniel Fett 

Date: Wednesday, 3. January 2024 at 14:01
To: oauth@ietf.org 

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

Hi Axel,

I would be happy to see OAuth move away from state as a CSRF protection 
mechanism in the future, but there is not too much to be gained from relying 
solely on PKCE right now. The main advantage is that relying on PKCE 
incentivizes clients to properly manage the session state in a cookie instead 
of relying on a parameter. Beyond that, there's a small reduction in effort 
required by the client, messages will be smaller messages, etc.. The 
disadvantage is that a client puts CSRF protection in the hands of the AS. 
Therefore, we chose the wording "ensure" to say that the client has be sure 
that the AS actually implements PKCE correctly before 

Re: [OAUTH-WG] [Technical Errata Reported] RFC7519 (7720)

[Justin Richer]

This errata should be rejected, as stated in the write up, the change in text 
is too much for an errata. If the WG wants to revise JWT at this level it 
should be a full bis document.

It's worth noting that the two other time based claims, nbf and exp, allow for 
clock skew in processing, but both of these claims have defined semantics about 
rejection whereas iat does not. One could argue that the libraries mentioned in 
the issue are doing things the spec doesn't say to do, but this kind of 
processing is extremely common.

- Justin


From: OAuth  on behalf of RFC Errata System 

Sent: Friday, December 1, 2023 5:06 PM
To: m...@microsoft.com ; ve7...@ve7jtb.com 
; n-sakim...@nri.co.jp ; r...@cert.org 
; paul.wout...@aiven.io ; 
hannes.tschofe...@arm.com ; rifaat.s.i...@gmail.com 

Cc: verge...@gmail.com ; oauth@ietf.org ; 
rfc-edi...@rfc-editor.org 
Subject: [OAUTH-WG] [Technical Errata Reported] RFC7519 (7720)

The following errata report has been submitted for RFC7519,
"JSON Web Token (JWT)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7720

--
Type: Technical
Reported by: Timothy Vergenz 

Section: 4.1.6

Original Text
-
4.1.6.  "iat" (Issued At) Claim

The "iat" (issued at) claim identifies the time at which the JWT was
issued.  This claim can be used to determine the age of the JWT.  Its
value MUST be a number containing a NumericDate value.  Use of this
claim is OPTIONAL.

Corrected Text
--
4.1.6.  "iat" (Issued At) Claim

The "iat" (issued at) claim identifies the time at which the JWT was
issued.  This claim can be used to determine the age of the JWT.  Its
value MUST be a number containing a NumericDate value.  Use of this
claim is OPTIONAL. Implementors MUST NOT reject otherwise-valid JWTs
with "iat" claims that appear to be from the future; token issuers
desiring this behavior may require it by including an "nbf" claim.

Notes
-
There is substantial confusion and disagreement among JWT library implementors 
about whether to reject JWTs with `iat` claims that appear to be from the 
future due to clock drift. This confusion has led to over half a dozen Github 
issues & PRs over the years in libraries in many different ecosystems, and lots 
of strong disagreement among library developers and users.

Based on a sample of the top Google search results for jwt client libraries in 
11 different language ecosystems, the majority (7) of the libraries sampled do 
not reject future `iat` claims, while the remaining 4 *do* reject future `iat` 
claims by default. Of those 4 who do, *all* of them have had Github issues 
filed (by different unique users) in which the user was having a JWT 
unexpectedly rejected by a token validator using the library whose clock had 
drifted from that of the token issuer enough to trigger `iat`-based rejection.

I propose we update the spec to explicitly prohibit rejection of future-`iat` 
JWTs (especially since token issuers have always been able to opt into this 
behavior using an `nbf` claim). Since this RFC has been published and cannot be 
edited, a new superseding RFC will have to be published and this one deprecated 
in order for the suggested change to make it out of the errata and into an 
actual RFC doc.

I'm not sure if this merits a full RFC republish -- but as a data point for 
impact consideration, it's worth noting that this confusion has almost 
certainly wasted at least multiple hours per person (on average) of *dozens* of 
developers' time over the years, and led to at least half a dozen production 
bugs that I've seen mentioned. One of these bugs cropped up in my own 
organization on 2023-11-31 and has been observed previously but was 
misunderstood and not resolved; the 2023-11-31 occurence involved 10+ people in 
discussion. One Github issue I saw described an elongated full web server 
outage attributed to this confusion which cropped up during a 
leap-second-related clock drift issue. I'm filing this errata request on 
calendar day 3+ of discussing this issue in my organization (if you include 
past times this issue has cropped up).

Thanks for your consideration! I look forward to hearing back.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
will log in to change the status and edit the report, if necessary.

--
RFC7519 (draft-ietf-oauth-json-web-token-32)
--
Title   : JSON Web Token (JWT)
Publication Date: May 2015
Author(s)   : M. Jones, J. Bradley, N. Sakimura
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area 

Re: [OAUTH-WG] sub_id in draft for Transaction tokens

[Justin Richer]

I disagree with the utility of just "sub" here. The subject of the token is 
always contextual to the issuer of that subject - however, the "iss" field here 
is the issuer of the transaction token and not the issuer of the subject 
identifier. As such, it's much less ambiguous to use the compound field. The 
concerns are similar to SET, where sub_id was initially defined - - the source 
context for the subject can't be assumed to be the same as that of the 
transaction token.

-Justin

From: OAuth  on behalf of Atul Tulshibagwale 

Sent: Thursday, October 26, 2023 4:07 PM
To: Kai Lehmann 
Cc: oauth@ietf.org 
Subject: Re: [OAUTH-WG] sub_id in draft for Transaction tokens

Hi Kai,
Thanks for this and other feedback you have provided.

The primary reason for using "sub_id" was to enable a format that can be more 
expressive than the "sub", which is always a string.

I can see the benefit of having either "sub" or "sub_id" in the Transaction 
Tokens spec. "sub" will allow for more compact tokens where a richer subject 
format is not required.

Atul


On Thu, Oct 26, 2023 at 1:52 AM Kai Lehmann 
mailto:401und1...@dmarc.ietf.org>> wrote:

Hi all,



I very much like the draft. We have a similar token mechanism implemented for 
our service infrastructure.



I am not quite sure about the reasoning behind using “sub_id” for the subject 
identifier instead of using “sub” as used across OAuth technology. The 
referenced draft for SubjectIdentifiers is related to a security event 
environment. The origin of the sub can be manifold in those scenarios. In the 
OAuth environment, on the other hand, we do usually have the original access 
token at the beginning of the call and there, a sub is usually present and well 
defined within the trust boundary.



In our implementation, we simply create an internal token (that’s our term for 
it) and copy the sub from the AT. We have a few entry points where we do not 
have a user interaction (for instance incoming mail via SMTP which needs to be 
delivered to the end-users mailbox storage). In those scenarios, we allow the 
very small list of gateways (e.g. SMTPD) to call the token exchange with other 
parameters than the AT. The recipient email address needs to be provided which 
is being used to look up the actual subject identifier (in our case it’s a UUID 
tied to the user account) which is put into the created internal token. This 
way we ensure that the “sub” claim is always the same type/format. The internal 
services do not need to interpret/support multiple formats as they can rely on 
the token exchange server to provide it.



The referenced draft for subject identifiers for security events allows for the 
“sub” in parallel to the “sub_id”. My suggestion would be to allow to use 
either “sub” or “sub_id”. I would use “sub” as long as all parties (workloads) 
within the trust boundary understand what the sub value is and it is guaranteed 
that the transaction tokens are generated with the same sub format/type.



Best regards,

Kai



___
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] Reservations and observations about draft JWT and CWT Status List

[Justin Richer]

Your premise relies on a feature of JSON that does not exist. JSON does not 
provide well-defined behavior for repeated names within an object:

When the names within an object are not
unique, the behavior of software that receives such an object is
unpredictable.


From: https://www.rfc-editor.org/rfc/rfc8259.html#section-4

 — Justin


On Oct 2, 2023, at 1:12 PM, Denis  wrote:



The latest draft (i.e. draft-looker-oauth-jwt-cwt-status-list-latest) which is 
available at :
https://vcstuff.github.io/draft-looker-oauth-jwt-cwt-status-list/draft-looker-oauth-jwt-cwt-status-list.html
includes the following illustrative drawing:

+--++---+
|  | References |   |
|  |--->|   |
| Referenced Token || Status List Token |
|  (JSON or CBOR)  ||(JWT or CWT)   |
|  |  Describes Status  |   |
|  |<---|   |
+--++---+

This drawing is not identical to the drawing of the referenced draft.

On the left side, "JSON or CBOR" are mentioned instead of "JWT or CWT".
However, such change would indeed be appropriate (and in both rectangles as 
explained below).

In section 4. of JWT [RFC7519]  The text states:

 The JWT Claims Set represents a JSON object whose members are the 
claims conveyed by the JWT.
 The Claim Names within a JWT Claims Set MUST be unique. JWT parsers 
MUST either reject JWTs
 with duplicate Claim Names or use a JSON parser that returns only the 
lexically last duplicate member name (...).

In [RFC8392] such sentence is not present which means that a Claim does not 
need to be unique.

However, in some applications, it might be useful to use JSON tokens that 
contain several occurrences of the same claim within it.
In addition, the processing of such tokens would not necessarily need to follow 
the description made in section 7 of [RFC7519], i.e. JWTs.

As a first example, let us consider the case where the URI placed under the 
"status_list " claim does not respond.
For resilience considerations, another URI should be defined. This can be 
handled in two ways:

- using a more complex claim structure for the "status_list" claim, or

- allowing the inclusion of several "status_list" claims.

As another example, currently the claim "nationalities" has been registered by 
the IANA. See: https://www.iana.org/assignments/jwt/jwt.xhtml

In order to support selective disclosure, the claim "nationality" should be 
defined, so that two "nationality" claims can be present,
in order to allow bi-national users to choose which "nationality" claim(s) to 
disclose, without disclosing that they have two nationality claims.

   Note: Using a different name for tokens supporting credentials, e.g., 
JXT ot CXT (with the letter "X" different from the letter "J")
would address this problem.

The abstract states:

 This specification defines status list data structures for 
representing the status of JSON Web Tokens (JWTs) [RFC7519] and
 CBOR Web Tokens (CWTs) [RFC8392]. The status list data structures 
themselves are also represented as JWTs or CWTs.

Both sentences imply restrictions since they limit the use of the mechanism 
only to JWTs and CWTs.

Limiting the use of the Status List mechanism to JWTs and CWTs would not allow 
other forms of JSON or CBOR tokens
to take advantage of the mechanism described in this draft.
The abstract should be modified to be able to support other forms of JSON or 
CBOR tokens,
while JWTs and CWTs should be mentioned as examples.

In order to allow future evolutions, the same kind of change should be done for 
Status List Tokens.

In order to allow for such a possibility, the title should include "JSON and 
CBOR" rather than "JWT and CWT".

Proposed changes:

1) Change proposal for the title of the document:

 JSON and CBOR encoded Status Lists

2) Change proposal for the Abstract:

 This specification defines status list data structures for 
representing the status of JavaScript Object Notation (JSON) tokens [RFC8259] 
and
 of Concise Binary Object Representation (CBOR) tokens [RFC7049] (see 
also [RFC8949]), such as JSON Web Tokens (JWTs) [RFC7519] and
 CBOR Web Tokens (CWTs) [RFC8392].

 The status list data structures themselves are represented as JSON 
tokens or CBOR tokens.

3) The same kind of change should be done within the document, e.g. :

+--++--+
|  | References |  |
|  |--->|  |
|   Referenced Token   ||   Status List Token  |
| (JSON or CBOR token) || 

Re: [OAUTH-WG] Review of draft-ietf-regext-rdap-openid

[Justin Richer]

Hi Roman,

The concerns of this document are largely specific to OpenID Connect, and not 
vanilla OAuth, but of course many of us in the community overlap and I’m happy 
to help provide some feedback here. I’m not familiar with RDAP, so if any of my 
concerns are addressed by other aspects of the RDAP ecosystem, I would be happy 
to be corrected.

That said, I believe parts of the approach are fundamentally flawed as it 
conflates the RS and client roles in a potentially dangers and certainly 
confusing way.

Some thoughts as I read through this:


§3.2.1:

 - there seems to be some conflation of the RP and RS roles here in the RDAP 
server; it seems more proper that the RDAP server is the RS, and the RDAP 
client is the RP (the same as the OAuth client); this seems to stem from a 
problem with how the RDAP server actually gets user claims, see paragraph below 
for more

§3.1.3:

 - this seems to assume the authorization code grant type; though this is 
explained a little bit more in 3.1.4.2, it’s not clear that other grant types 
are supported here within this protocol
 - the first section on “session-oriented clients” conflates the end-user with 
the client (to wit: "An RDAP client (acting as an OpenID End-User)”); 
consequently it’s unclear who is getting “redirected” or interacting at any 
step; more properly, it seems that the end-user is interacting with the RDAP 
client to initiate the flow, which is borne out in the diagram

More importantly, in this section it becomes clear that the core of the 
specification’s “token-oriented” approach relies on the RDAP client passing the 
access token to the RDAP server and then having the RDAP server replay that 
same token to the OpenID IdP in order to get user claims. It is not considered 
good practice to have the RS replay the access tokens it receives to an 
external party, and on the surface this could potentially be exploited by an 
attacker. This also fails under sender-constrained token usage, wherein the 
RDAP client would need to also share key material with the RDAP server in order 
for the latter to use the token.

A better pattern would be a profile of OAuth Token Introspection (RFC7667) 
wherein user information could be specified. This would also allow the RDAP 
server to authenticate its call to the OpenID IdP. Introspection was designed 
specifically to allow the RS to call back to the AS to determine what (and who) 
a token is for, and it provides an extensible mechanism for doing so. An 
alternative would be to profile the access token itself to contain user 
information in a format readable by the RDAP server. More on this in the note 
for §6.3 below.

§3.1.5.1

- The registry information here should be in a separate IANA section that is 
forward-referenced from here
- which parties are responsible for validating the allowed purposes claims? 
Does the IdP need to know the list of allowed purposes applicable to the RS 
(RDAP server)?

§4.1

 - I appreciate that the fav1 data structure separates the applicable flags 
into a clear substructure, which will be easier to process as an extension to 
existing code

§4.2

- RFC3986 doesn’t actually specify the key=value format normatively; these 
days, that belongs to the HTML URL specification from WHATWG and so I would 
recommend that this reference be used instead: 
https://url.spec.whatwg.org/#application/x-www-form-urlencoded


§4.2.1

 - is it really the case that a client can only request a single purpose, but 
multiple can be authorized? I’m not an expert in the RDAP world, but this would 
seem to be quickly turn insufficient as purposes are not required to be 
completely separate and distinct from each other in the registration section

§4.3

- I think this section was probably meant to be a subsection of 4.2?

§5.1.1

 - OpenID Connect does not define a single global string value for a user 
identifier; instead only the tuple of issuer and subject are considered 
suitably unique; ergo, the UserID value in the data structure would need to 
have either a construction method or some other specification, or to have this 
declared as RDAP-server-specific explicitly

§5.1.2

 - this seems to replicate RFC8628, OAuth Device Flow, without any of the 
implementation detail or security considerations of that specification; 
furthermore, the device flow isn’t specified in OpenID Connect (which is being 
profiled here) though its use is far from unheard of in practice; this use is 
further expanded in §5.2.4, but it’s unclear that that’s why this is here

§5.2.1

 - I’m unclear when reading this whether the identifier in question is an OAuth 
client_id or a user identifier, as the text seems to indicate it can be either; 
these represent drastically different things, and one could argue that 
separating the identity of the client software from the identity of the 
end-user is the entire point of OAuth and protocols like it
 - Ultimately this seems to be a discovery step 

Re: [OAUTH-WG] Questions on OAuth Protected Resource Metadata

[Justin Richer]

I think we’re used to thinking of scopes in terms of things that a developer 
can read and understand, but that’s not always going to be true. For automated 
systems like this, the developer isn’t always expected to understand the scope 
— they probably don’t even see it in many cases. The client software knows the 
API, but at the OAuth layer, the client just needs to know what values to put 
into the OAuth flow to be able to call the RS and have it work. That value 
could very well be an opaque string, which is supported by the 6750 response 
header already as well.

 — Justin

On Sep 22, 2023, at 1:58 PM, Atul Tulshibagwale  wrote:

Hi,

#1 is clear now. Thanks Warren
On #2, thanks Neil and Warren for your clarifications. Does it make sense to 
include language that warns against requesting unknown scopes in the OPRM draft?

Atul

On Thu, Sep 21, 2023 at 11:17 AM Neil Madden 
mailto:neil.e.mad...@gmail.com>> wrote:
On 21 Sep 2023, at 17:19, Atul Tulshibagwale 
mailto:a...@sgnl.ai>> wrote:

Hi all,
I'm still looking for answers to these two 
questions
 regarding the OPRM draft that was recently adopted by the WG:

  1.  If I have a resource server that has multiple endpoints, each of which 
require different scopes, how should those be handled? For example, in the SSF 
spec, the SSF Transmitter has a Create Stream endpoint and a Polling endpoint. 
The scopes required for these are different. How would the client know which 
scope is to be used with which endpoint?
  2.  Does the spec encourage insecure behavior in the caller by requesting 
tokens with scopes that they do not understand? I.e. If an authorization server 
is known to provide valuable tokens with certain scopes, can a malicious 
resource server trick the client into requesting a more powerful token, which 
it then uses to access some other service? Since the consent dialog is likely 
to show two trusted names (i.e. the requesting client and the authorization 
server), the user would be prone to providing consent, even if the scope looks 
unnecessarily permissive.

Regarding point 2, if this is a threat then it's already enabled by RFC 6750, 
which defines the `WWW-Authenticate: Bearer scope="..."` challenge header that 
can be used to indicate which scopes a client needs to access a resource. Even 
just misleading documentation for how to access the RS could enable this 
threat. That's not to say that this isn't worth considering (it is), but I 
don't think this draft makes the situation worse than now.

-- 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-WG] Fwd: New Version Notification for draft-gilman-wimse-use-cases-00.txt

[Justin Richer]

Hi all,

Back at IETF116 in Yokohama, Evan Gilman presented information about SPIFFE, a 
workload security platform. At IETF 117 in SF, we presented a set of questions 
and possible new work, to lots of positive feedback. Now we’ve set up the 
Workload Identity in Multi System Environments (WIMSE) mailing list for 
discussing things, wi...@ietf.org<mailto:wi...@ietf.org> — and we’ve just 
published the following -00 use cases document. If this topic area interests 
you, please take a look through the use cases (it’s pretty short right now) and 
join the conversation on the WIMSE mailing list.

Thanks,
 — Justin

Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-gilman-wimse-use-cases-00.txt
Date: August 28, 2023 at 1:53:01 PM EDT
To: "Evan Gilman" , "Joseph Salowey" , 
"Justin Richer" , "Pieter Kasselman" 


A new version of Internet-Draft draft-gilman-wimse-use-cases-00.txt has been
successfully submitted by Justin Richer and posted to the
IETF repository.

Name: draft-gilman-wimse-use-cases
Revision: 00
Title:Workload Identity Use Cases
Date: 2023-08-28
Group:Individual Submission
Pages:7
URL:  https://www.ietf.org/archive/id/draft-gilman-wimse-use-cases-00.txt
Status:   https://datatracker.ietf.org/doc/draft-gilman-wimse-use-cases/
HTML: https://www.ietf.org/archive/id/draft-gilman-wimse-use-cases-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-gilman-wimse-use-cases


Abstract:

  Workload identity systems like SPIFFE provide a unique set of
  security challenges, constraints, and possibilities that affect the
  larger systems they are a part of.  This document seeks to collect
  use cases within that space, with a specific look at both the OAuth
  and SPIFFE technologies.

Discussion Venues

  This note is to be removed before publishing as an RFC.

  Source for this draft and an issue tracker can be found at
  https://github.com/bspk/draft-gilman-wimse-use-cases.



The IETF Secretariat



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

Re: [OAUTH-WG] [Technical Errata Reported] RFC7662 (7607)

[Justin Richer]

I don’t think it’s necessary to enumerate all of the possible parties that 
could have had a hand in revoking the token — it have also been revoked by the 
AS through some backend process or through administrative action. If a token is 
revoked, it’s revoked — and the RS doesn’t generally care why or who did it, 
just that the token is no good. It doesn’t hurt to list the client here, but 
it’s not necessary. As such, I still say the errata should be rejected.

 — Justin

On Aug 19, 2023, at 6:32 PM, Fulong Sun  wrote:

Hi Justin,

Yes, the resource owner can revoke, but the client also can revoke the token, 
why do not write both of them?

孙福龙
Fulong Sun

东软教育科技集团・IDC
IDC of Neusoft Education Technology Group

Office: +86 (411) 82379410 -9 / 6602
Mobile: +86 13478953390
E-mail: sunful...@neusoft.edu.cn<mailto:sunful...@neusoft.edu.cn>
Address: Room 305, Building A5, No. 8, Software Park Road, Dalian, Liaoning, 
China

From: Justin Richer 
Sent: 2023年8月18日 20:54
To: RFC Errata System ; i...@justin.richer.org; 
r...@cert.org; paul.wout...@aiven.io; hannes.tschofe...@arm.com; 
rifaat.s.i...@gmail.com
Cc: sunful...@neusoft.edu.cn; oauth@ietf.org
Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7662 (7607)

The resource owner can revoke the token out of band, this errata should be 
rejected.

- Justin

From: OAuth mailto:oauth-boun...@ietf.org>> on behalf 
of RFC Errata System 
mailto:rfc-edi...@rfc-editor.org>>
Sent: Thursday, August 17, 2023 2:42 PM
To: i...@justin.richer.org<mailto:i...@justin.richer.org> 
mailto:i...@justin.richer.org>>; 
r...@cert.org<mailto:r...@cert.org> mailto:r...@cert.org>>; 
paul.wout...@aiven.io<mailto:paul.wout...@aiven.io>mailto:paul.wout...@aiven.io>>;
 hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com> 
mailto:hannes.tschofe...@arm.com>>; 
rifaat.s.i...@gmail.com<mailto:rifaat.s.i...@gmail.com>mailto:rifaat.s.i...@gmail.com>>
Cc: sunful...@neusoft.edu.cn<mailto:sunful...@neusoft.edu.cn> 
mailto:sunful...@neusoft.edu.cn>>; 
oauth@ietf.org<mailto:oauth@ietf.org> mailto:oauth@ietf.org>>; 
rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>mailto:rfc-edi...@rfc-editor.org>>
Subject: [OAUTH-WG] [Technical Errata Reported] RFC7662 (7607)

The following errata report has been submitted for RFC7662,
"OAuth 2.0 Token Introspection".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7607

--
Type: Technical
Reported by: Fulong Sun 
mailto:sunful...@neusoft.edu.cn>>

Section: 2.2

Original Text
-
a given token has been issued by this authorization server, has not been 
revoked by the resource owner, and is within its given time window of validity

Corrected Text
--
a given token has been issued by this authorization server, has not been 
revoked by the resource owner or client, and is within its given time window of 
validity

Notes
-
RFC 7009 defined a given token can be revoke by client, so should write client 
here.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC7662 (draft-ietf-oauth-introspection-11)
--
Title   : OAuth 2.0 Token Introspection
Publication Date: October 2015
Author(s)   : J. Richer, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
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] [Technical Errata Reported] RFC7662 (7607)

[Justin Richer]

The resource owner can revoke the token out of band, this errata should be 
rejected.

- Justin

From: OAuth  on behalf of RFC Errata System 

Sent: Thursday, August 17, 2023 2:42 PM
To: i...@justin.richer.org ; r...@cert.org 
; paul.wout...@aiven.io ; 
hannes.tschofe...@arm.com ; rifaat.s.i...@gmail.com 

Cc: sunful...@neusoft.edu.cn ; oauth@ietf.org 
; rfc-edi...@rfc-editor.org 
Subject: [OAUTH-WG] [Technical Errata Reported] RFC7662 (7607)

The following errata report has been submitted for RFC7662,
"OAuth 2.0 Token Introspection".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7607

--
Type: Technical
Reported by: Fulong Sun 

Section: 2.2

Original Text
-
a given token has been issued by this authorization server, has not been 
revoked by the resource owner, and is within its given time window of validity

Corrected Text
--
a given token has been issued by this authorization server, has not been 
revoked by the resource owner or client, and is within its given time window of 
validity

Notes
-
RFC 7009 defined a given token can be revoke by client, so should write client 
here.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC7662 (draft-ietf-oauth-introspection-11)
--
Title   : OAuth 2.0 Token Introspection
Publication Date: October 2015
Author(s)   : J. Richer, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
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] [Editorial Errata Reported] RFC6749 (7569)

[Justin Richer]

This errata seems to be spam.

From: OAuth  on behalf of RFC Errata System 

Sent: Friday, July 21, 2023 10:32 PM
To: rfc-edi...@rfc-editor.org 
Cc: brunoatlass...@outlook.com.br ; 
oauth@ietf.org 
Subject: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (7569)

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7569

--
Type: Editorial
Reported by: BRUNO LEITE DA SILVA 

Section: 6749

Original Text
-
BANCO.COM

Corrected Text
--
BANCO.COM/

Notes
-
/ALLISSUR

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC6749 (draft-ietf-oauth-v2-31)
--
Title   : The OAuth 2.0 Authorization Framework
Publication Date: October 2012
Author(s)   : D. Hardt, Ed.
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

___
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] [IANA #1270468] expert review for draft-ietf-oauth-dpop (oauth-parameters)

[Justin Richer]

Hi al — sorry, I missed these first couple emails entirely.

Yes, I have read the document and I approve this registration.

 — Justin

> On Apr 12, 2023, at 1:45 AM, Amanda Baber via RT 
>  wrote:
> 
> Hi Justin,
> 
> Can you review this OAuth Dynamic Client Registration Metadata request before 
> Thursday?
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-14#name-oauth-dynamic-client-regist
> 
> thanks,
> Amanda
> 
> On Mon Apr 10 20:08:46 2023, david.dong wrote:
>> Dear Justin,
>> 
>> Hello. Have you had a chance to review these proposed registrations?
>> 
>> The due date is Wednesday April 12th, 2023, as this document is on
>> this week's IESG telechat agenda.
>> 
>> Thank you very much for your time.
>> 
>> Best regards,
>> 
>> David Dong
>> IANA Services Specialist
>> 
>> On Thu Apr 06 15:22:17 2023, david.dong wrote:
>>> Dear Justin (cc: oauth WG),
>>> 
>>> As the designated expert for the OAuth Dynamic Client Registration
>>> 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/
>>> 
>>> The due date is Wednesday April 12th, 2023. This document is on next
>>> week's IESG telechat agenda.
>>> 
>>> -
>>> Eleventh, in the OAuth Dynamic Client Registration 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_bound_access_tokens
>>> Metadata Description: Boolean value specifying whether the client
>>> always uses DPoP for token requests
>>> Change Controller: IETF
>>> Specification Document(s): [ RFC-to-be; Section 5.2 ]
>>> 
>>> As this section of the draft also requests registrations in a
>>> Specification Required (see RFC 8126) registry, the IESG-designated
>>> experts for the OAuth Dynamic Client Registration Metadata registry
>>> have asked that you send a review request to the mailing list
>>> specified in RFC7591. 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/oauth-parameters/
>>> 
>>> With thanks,
>>> 
>>> David Dong
>>> IANA Services Specialist
> 

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

Re: [OAUTH-WG] [IANA #1267319] expert review for draft-ietf-oauth-step-up-authn-challenge (oauth-parameters)

[Justin Richer]

These two registrations look good to me.

Thanks,
 — Justin

> On Feb 27, 2023, at 6:11 PM, David Dong via RT 
>  wrote:
> 
> Dear Justin (cc: oauth wg),
> 
> As the designated expert for the OAuth Token Introspection Response registry, 
> can you review the proposed registration in 
> draft-ietf-oauth-step-up-authn-challenge for us? Please see
> 
> https://datatracker.ietf.org/doc/draft-ietf-oauth-step-up-authn-challenge/
> 
> The due date is March 13 2023.
> 
> If this is OK, when the IESG approves the document for publication, we'll 
> make the registration at
> 
> https://www.iana.org/assignments/oauth-parameters/
> 
> 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)

[Justin Richer]

Hi Mark, a quick note on one item:

- Section 4.1 defines the DPoP header field as a JWT, which (as I understand 
it) is a base64-encoded string. If that's the case, I'd recommend making it a 
Structured Field Item (see RFC8941 s 3.3) with a fixed type of Byte Sequence (s 
3.3.5). That will require changing the syntax to add a prefix and suffix of ":".

A JWT cannot be sent as a Byte Sequence because it is not :just: Base64. 
Specifically, a JWT in compact serialization (which is what’s intended here) is 
encoded as three sets of Base64url separated by periods “.”, which are outside 
the base64URL alphabet. If anything, this fits the “token68” rule, which I 
:think: means that it could be defined as sf-token here, to make it a fully 
structured field, but I’m not entirely sure.

I’ll let the document authors chime in on other comments.

 — Justin



- The DPoP-Nonce header field's syntax isn't obviously specified. It should be. 
I'd suggest a Structured Field Item with a fixed type of String (RFC 8941 s 
3.3.3), which would surrounding the value with quotes.

- Neither header has interoperable parsing or serialisation specified; 
divergent error handling may cause interoperability problems. Adopting 
Structured Fields would address this.

- See RFC9110 s 16.3.2 for things that should be considered when defining new 
HTTP fields. I suspect that the document needs to be more explicit about at 
least some of these items. Adopting Structured Fields would address some (but 
not all) of these questions.

- See also 
 for 
the preferred editorial style when defining new HTTP fields.

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

Cheers,




On 19 Jan 2023, at 5:30 am, David Dong via RT 
mailto:drafts-expert-review-comm...@iana.org>>
 wrote:

Dear Mark Nottingham and Roy Fielding (cc: oauth WG),

As the designated experts for the http-fields 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 February 1st, 2023.

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

https://www.iana.org/assignments/http-fields/http-fields.xhtml

We'll wait for both reviewers to respond unless you tell us otherwise.

With thanks,

David Dong
IANA Services Specialist

--
Mark Nottingham   https://www.mnot.net/

___
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] Small bug in DPoP 12

[Justin Richer]

I agree with Brian’s proposed fix — that is a “target URI” as defined by 
“HTTP”. The fact that it’s :also: required to be HTTPS is separate.

 — Justin

On Jan 9, 2023, at 7:58 AM, Brian Campbell 
mailto:bcampbell=40pingidentity@dmarc.ietf.org>>
 wrote:

Thanks Dominick,

I believe they should both use HTTP because that claim and check is about 
something from HTTP semantics. And the general requirement to use HTTPS is 
stated elsewhere. I'll update that accordingly as part of IETF last 
call.

On Sun, Jan 8, 2023 at 8:01 AM Dominick Baier 
mailto:dba...@leastprivilege.com>> wrote:
Hi,

While implementing I found

Section 4.2 says

htu: The HTTP target URI (Section 7.1 of [RFC9110]), without query and fragment 
parts, of the request to which the JWT is attached.


While Section 4.3 says

the htu claim matches the HTTPS URI value for the HTTP request in which the JWT 
was received, ignoring any query and fragment parts


HTTP vs HTTPS

cheers
Dominick

___
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

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

Re: [OAUTH-WG] Privacy considerations regarding RAR and authorization_details in AT JWT

[Justin Richer]

Hi Kai,

Both of those approaches are common approaches for preventing the leakage of 
private information in JWTs, and neither is specific to the RAR specification. 
The use of RAR objects does make it easier to have more specific detail, but 
that detail could have easily been leaked through a scope or any other custom 
claim in a JWT. The important thing for RAR is to point out the RAR object as a 
:source: of that kind of data and call out the desired effect of mitigation 
(ie, limiting to the intended audience of the token). General mechanisms for 
reaching that mitigation, such as introspection and multi-target encryption, 
aren’t really for RAR to define since they aren’t specific to RAR in the 
slightest.

In the end, you’ve drawn exactly the right conclusions from the text that we 
would hope an implementor would draw from reading this text. As such, to me, 
that means the text is doing its job. If we can make that clearer, and help 
more people reach that same conclusion more quickly, the editors would love any 
hint on what you think we might be able to do.

Thank you,
 — Justin

> On Dec 19, 2022, at 3:02 AM, Kai Lehmann 
>  wrote:
> 
> Hi,
> 
> In the privacy considerations section of the RAR specification 
> (https://www.ietf.org/archive/id/draft-ietf-oauth-rar-21.html#name-privacy-considerationsit)
>  it is stated:
> 
> 
> “The AS needs to take into consideration the privacy implications when
> sharing authorization_details with the client or resource servers.
> The AS should share this data with those parties on a "need to know"
> basis as determined by local policy.“
> 
> The proposed standard recommends to embedd the authorization_details in the 
> JWT-based Access Token "filtered to the specific audience".
> 
> I assume audience restricted ATs are meant here.
> 
> My concern is that there can be multiple RS which the client intents to use 
> the AT for. Even with audience restricted ATs, it may be the case that 
> personal information being part of the authorization_details should only be 
> visible to one of the AS and not the others. I don't really see how the 
> Authorization Server is able to craft ATs which can be used for all of the 
> given audience while only one or some ought to be able to read the 
> authorization_details. Even if the AS is able to enforce a policy to allow 
> only one audience with the authorization request, it does not prevent the 
> client from accidentally misusing the issued AT with another RS for which it 
> was not intended and thus leaking personal information to that RS.
> 
> I think that in order to prevent authorization_details to be accessible by 
> multiple RS, Token Introspection should still be used to validate JWT-based 
> ATs and only include the authorization_details in the Token introspection 
> response which the RS need to know.
> 
> Another approach would be to have an authorization_details section encrypted 
> asymmetrically for each audience separately so that each RS can only extract 
> the authorization_details it needs. That could mean JWTs inside of JWTs.
> 
> I think it would help to add more details to the privacy considerations or 
> even describe how exactly this can be achieved.
> 
> Best regards,
> Kai
> 
> ___
> 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-Nonce IANA HTTP Header

[Justin Richer]

Thanks, Brian!

 — Justin

On Dec 20, 2022, at 5:54 PM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:

Thanks Justin,

It'll be fixed in the next draft revision. I happened to notice the oversight 
as well when working on the AD review and have already added it in the document 
source in github.

On Tue, Dec 20, 2022 at 3:44 PM Justin Richer 
mailto:jric...@mit.edu>> wrote:
DPoP Authors:

I just noticed that the DPoP-Nonce header is not registered in the current 
version of the DPoP spec. This should be added under section 12.8, HTTP Message 
Header Field Names Registration. It’s a clerical oversight but needs to be 
fixed before the document is finalized.

 — Justin

___
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] DPoP-Nonce IANA HTTP Header

[Justin Richer]

DPoP Authors:

I just noticed that the DPoP-Nonce header is not registered in the current 
version of the DPoP spec. This should be added under section 12.8, HTTP Message 
Header Field Names Registration. It’s a clerical oversight but needs to be 
fixed before the document is finalized.

 — Justin

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

[Justin Richer]

Apologies, sending from the correct email account this time. Please do not 
reply to the other address.

Thank you,
 — Justin

On Dec 12, 2022, at 1:45 PM, Justin Richer 
mailto:jus...@richer.org>> wrote:

Francesca,

Thanks for the pointer! I read through the referenced RFC as well and I agree 
with Brian’s take. I don’t think there’s enough similarity in the domain or the 
solution to warrant a meaningful comparison here. It seems that RFC9237 was not 
written in such a way as for it to be generally applicable, and that seems to 
be the intentional design. Section 2.2 of that document specifically states 
that it’s limited in a number of ways, such as the statement that it’s for 
"statically identifiable objects”. These limitations seem to put it in a 
squarely different camp from RAR, which is intended to allow expression of 
general-purpose security elements across many different styles of APIs. The 
various examples in the RAR draft should, hopefully, make that clear.

I personally think that mentioning RFC9237 would only confuse readers of this 
specification.

 — Justin

On Dec 12, 2022, at 1:22 PM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:

Thanks Francesca,

I must admit that I was not aware of RFC9237. After a quick look, however, it 
really is intended for Ace and IoT (as you point out) and I don't believe I 
could write anything sufficiently meaningful about any similarities to this 
document to warrant inclusion.

On Mon, Dec 12, 2022 at 9:10 AM Francesca Palombini via Datatracker 
mailto:nore...@ietf.org>> wrote:
Francesca Palombini has entered the following ballot position for
draft-ietf-oauth-rar-18: 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-rar/



--
COMMENT:
--

Thank you for the work on this document.

Many thanks to Thomas Fossati for his ART ART review:
https://mailarchive.ietf.org/arch/msg/art/EckO_3zF-gnI83Q_HmO5xREursI/ and
thanks to the authors for addressing Thomas' comments.

No other comments from me, just a note: I was wondering if it wouldn't have
made sense to informally reference and discuss in a short paragraph RFC9237 and
its applicability to OAuth given its content - I will accept that it might not
be the case since 9237 is really intended for Ace and IoT but the similarities
made me question it.

Francesca




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] [Gen-art] [Last-Call] Genart last call review of draft-ietf-oauth-rar-15

[Justin Richer]

FWIW, this is in line with what I understood the previous sentences to mean as 
well — so I’m happy for this being a simpler and more precise language.

What we were really trying to avoid is things like, for example, someone 
putting a URI in as their “type” value and doing URI-level equivalence between 
two different type values. In other words, “http://example.com”, 
“http://example.com:80/“, and “http://example.com/“ would all be different 
“type” values according to RAR because the strings are different.

 — Justin

On Dec 1, 2022, at 3:45 PM, Brian Campbell 
mailto:bcampbell=40pingidentity@dmarc.ietf.org>>
 wrote:



On Wed, Nov 30, 2022 at 5:04 PM Robert Sparks 
mailto:rjspa...@nostrum.com>> wrote:


On 11/30/22 5:53 PM, Brian Campbell wrote:


On Wed, Nov 30, 2022 at 4:08 PM Robert Sparks 
mailto:rjspa...@nostrum.com>> wrote:


On 11/30/22 2:39 PM, Brian Campbell wrote:


On Thu, Nov 17, 2022 at 3:45 PM Robert Sparks 
mailto:rjspa...@nostrum.com>> wrote:

I have two major issues that I think need discussion:

Major Issue 1) The document seems to be specifying a new way of
comparing json names, claiming it is what RFC8259 requires, but I
disagree that RFC8259 says what this document is claiming. If I'm
correct, the document is trying to rely on the text in section 7 of
RFC8259 to support the idea that implementation MUST NOT alter the json
names (such as applying Unicode normalization) before comparison and
that the comparison MUST be performed octet-by-octet. Rather, section 7
says something more like "you better escape and unescape stuff correctly
if you’re going to do unicode codepoint by codepoint comparison" which
is a completely different statement.

If I'm right, and this is a new comparison rule that goes beyond what
JSON itself defines, I think the group should seek extra guidance from
Unicode experts. If I'm wrong and this behavior is defined somewhere
else, please provide a better pointer to the definition.

In many environments, its unusual for an implementation relying on a
stack below it to have any say at all on whether normalization is going
to be applied to the unicode before the application gets to look. Rather
than trying to work around the problem you've identified with
normalization by specifying the comparison algorithm, consider just
making stronger statements about the strings used in the json names the
document defines. Why _can't_ you restrict the authorization_details
values to ascii? If it's because you want to present the string to a
user, consider putting a presentation string elsewhere in the json that
is not used for comparison.

To the best of my understanding, it's not trying to specify a new or different 
way of comparing JSON names or values. I think it's only trying to say that the 
application must not do any *additional* normalization of the string values 
that it gets from the JSON stack or any other extra processing for the sake of 
comparison. I think anyway.

Honestly, I didn't really (and still don't) understand the concerns that some 
of the WG had that led to the text in question. So I didn't pay close attention 
to it while thinking to myself there can't be harm in saying to do a 
byte-by-byte comparison with no additional processing. But here we are...

Does that halfhearted explanation alleviate your concerns at all? Or, with that 
explanation in mind, are there specific changes to the text (in sec 
12 and 
sec 2, 
I think) that would alleviate your concerns? Or do we need to consider just 
deleting those parts?

I did track down this issue about it 
https://github.com/oauthstuff/draft-oauth-rar/issues/28 for maybe added context.
Thanks for that pointer. If that's the extent, then I really think the group 
should walk this back just a little and answer why restricting these names to 
(a subset of) ascii is an unacceptable thing to do. The conversation there 
reinforces my guess that these aren't meant for display to users, so why take 
on the additional complexity? Make it easy for implementors to get it right 
with much less effort.

Yes, that guess is correct that type value is not meant for display to users 
(the issue is about type value). I can't confidently say the same about names 
and values that any particular type will define. I don't think it matters 
though. It's not that restricting is unacceptable but that it's not necessary. 
Just using the values that come from the JSON layer is enough. And I'd contend 
there's not really additional complexity. It just appears like additional 
complexity because of the unnecessary and maybe less than idea wording in the 
draft. Wording that I'd be more than happy to try and fix up or just remove.

If you can change it to "compare these the same way you would compare anything 
else out of json" and the group is fine with it, then great.

Okay, I've changed 

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

[Justin Richer]

I support adoption of this draft. It’s important work that affects a number of 
areas in and around OAuth.

 — Justin

On Nov 15, 2022, at 6:43 AM, 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] AD review of draft-ietf-oauth-rar-12

[Justin Richer]

Thank you, Roman — I put together a PR with those changes here:

https://github.com/oauthstuff/draft-oauth-rar/pull/89

 — Justin

> On Oct 27, 2022, at 1:51 PM, Roman Danyliw  wrote:
> 
> Hi!
> 
> I appreciate the updated in -13 and -14.  Most of the AD feedback has been 
> addressed there.  Combing through the multiple sub-threads, I've pruned to 
> text to cover what is the residual feedback.  See below.
> 
> To keep this document moving, I'm going to start IETF LC on it.  Please 
> address this feedback concurrently.
> 
>>> -----Original Message-
>>> From: Justin Richer 
>>> Sent: Thursday, September 15, 2022 11:20 AM
>>> To: Roman Danyliw 
>>> Cc: oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12
>>> 
>>> Hi Roman, some responses inline.
>>> 
>>>> On Sep 14, 2022, at 6:30 PM, Roman Danyliw  wrote:
> 
> [snip]
> 
>>>> ** Section 6.1
>>>> 
>>>> However, when comparing a new request to an existing request,
>>>>  authorization servers can use the same processing techniques as used
>>>>  in granting the request in the first place to determine if a resource
>>>>  owner needs to authorize the request.
>>>> 
>>>> Why is it possible to assess two arbitrary requests in this case to
>>>> determine "if
>>> a resource owner needs to authorize the request", but the prior
>>> paragraph explicitly calls out that comparing two arbitrary requests
>>> is not feasible?  To me is seems like comparing two requests to
>>> understand if more or less permissions are being requested is
>>> equivalent to determining if a new request exceed the current request to
>> determine if going back to the resource owner is needed.
>>>> 
>>> 
>>> It might be possible to do such a comparison in a specific case, but
>>> we can’t add logic in the general case. In OAuth, scopes are supposed
>>> to be purely additive, so if you have another scope it’s for “more”
>>> things. We know in practice that that’s not always how it works.
>>> Things get much more complex with RAR because you could have an object
>>> with :more: fields in it that makes things more :strict: by the
>>> presence of those fields. That’s all going to be up to the “type”
>>> definition though, so if you understand the “type” definition you
>>> could do a comparison based on that. To me the text is clear, can you 
>>> suggest
>> how we could clarify this?
>> 
>> OLD 1
>> Since the nature of an authorization details request
>>   is based solely on the API or APIs that it is describing, there is
>>   not a simple means of comparing any two arbitrary authorization
>>   details requests.
>> 
>> NEW 1
>> Since the semantics of the fields in the authorization details result will be
>> implementation specific to a given API or set of APIs, there is a no 
>> standardized
>> mechanism to compare two arbitrary authorization detail requests.
>> 
>> OLD 2
>>   However, when comparing a new request to an existing request,
>> 
>> NEW 2
>> 
>> When comparing a new request to an existing request, ...
> 
> [snip]
> 
> 
>>>> ** Section 11.2.
>>>> 
>>>> Accept authorization_details parameter in authorization requests
>>>> including basic syntax check  for compliance with this
>>>> specification
>>>> 
>>>> Why only "basic syntax checking"?  Perhaps "syntax checking"?
>>> 
>>> I’m not positive, but I think the guidance here is meant for “basic”
>>> to mean more like “make sure it’s a JSON object and that it has a type
>>> field” as opposed to “check the type field’s value and run it against a JSON
>> Schema definition”.
>> 
>> I don't think this is worth unpacking and would just recommend:
>> 
>> OLD
>> *  Accept authorization_details parameter in authorization requests
>>  including basic syntax check for compliance with this
>>  specification
>> 
>> NEW
>> *  Accept authorization_details parameter in authorization requests
>>  Conformant with this this specification
> 
> Thanks,
> Roman
> 
> ___
> 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] AD review of draft-ietf-oauth-rar-12

[Justin Richer]

Thank you, Torsten!

 — Justin

On Oct 24, 2022, at 12:18 PM, Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:

Hi Roman,

I just published revision -14 with the all the agreed changes.

https://www.ietf.org/archive/id/draft-ietf-oauth-rar-14.html

best regards,
Torsten.

Am 24.10.2022 um 13:07 schrieb Roman Danyliw 
mailto:r...@cert.org>>:

Hi Torsten!

Thanks for the response.  More inline ...

-Original Message-
From: Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>>
Sent: Tuesday, October 18, 2022 9:00 AM
To: Roman Danyliw mailto:r...@cert.org>>
Cc: oauth@ietf.org; Brian Campbell 
mailto:bcampb...@pingidentity.com>>;
jric...@mit.edu
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12

Hi Roman,

thanks for you review.

I’m trying to do the next round for the outstanding issues you raised.

Am 15.09.2022 um 00:30 schrieb Roman Danyliw 
mailto:r...@cert.org>>:

Hi!

I performed an AD review of draft-ietf-oauth-rar-12.  Thanks for this
document.  My feedback is as follows:

** Section 2. Editorial

This field MUST be compared using an exact byte match of the string
 value against known types by the AS.

Consider if you want to introduce how the lack of match will be handled here
- it is covered later.

I’m not sure how to handle this as there is no direct consequence (in the sense
of error condition) other then that different byte arrays constitute different
types.

We could state something like this: "String values with different byte
representations constitute different types.“ ?

Works for me.


** Section 2.2.

All data fields are OPTIONAL for use by a given API
 definition.

I don't follow how this is true in the general case.  I was under the impression
that this section defined what is expected to be common fields.  Couldn't some
AS with a particular type require their presence?

** Section 3.  Editorial

OLD
In case of authorization requests as defined in [RFC6749],
 implementors MAY consider to use

NEW
In case of authorization requests as defined in [RFC6749],
 implementors MAY consider using ...

** Section 3.  Typo. s/intiate/initiate/

** Section 5.  Typo.

OLD
authorization details type
 or authorization details

NEW
authorization_details type
 or authorization_details

The spec uses authorization details types to refer to the general concept and
authorization_details to refer to the parameter. I think the former is
appropriate at this place.

Understood.


** Section 6.1

However, when comparing a new request to an existing request,
 authorization servers can use the same processing techniques as used
 in granting the request in the first place to determine if a resource
 owner needs to authorize the request.

Why is it possible to assess two arbitrary requests in this case to determine 
"if
a resource owner needs to authorize the request", but the prior paragraph
explicitly calls out that comparing two arbitrary requests is not feasible?  To 
me
is seems like comparing two requests to understand if more or less permissions
are being requested is equivalent to determining if a new request exceed the
current request to determine if going back to the resource owner is needed.

** Section 6.1.  Typo. s/isaunce/issuance/

** Section 7.

 If the client does not specify
 the authorization_details token request parameters, the AS determines
 the resulting authorization details at its discretion.  The
 authorization server MAY consider the values of other parameters such
 as resource and scope if they are present during this processing, and
 the details of such considerations are outside the scope of this
 specification.

This guidance seems to indicate the use of the scope parameter is optional in
determining the authorization details.  Section 3.1 says "The AS MUST consider
both sets of requirements in combination with each other for the given
authorization request."  My read is that this is conflicting guidance and 
Section
3.1 is correct.

Justin: „You aren’t required to use “scope” in order to use
“authorization_details”, but we do want to say that the AS is allowed to (or
even is supposed to) consider both “scope” and “authorization_details” when
determining the resulting access for any given request that might have both.
The guidance in 3.1 should probably say “the AS MUST consider all
requirements present on a request” or something like that?“

Section 3 already states that the AS must consider scope and resource in
addition to authorisation details. I suggest to drop that sentence entirely.

Works for me.


** Figure 15.  The text prior to this figure says that for "For our running
example, this would look like this" indicating that this figure is similar to
previous examples.  There is one key different - this is the first use of a
"payment_initiator" type with the API URL prepended.

** Section 7.1. Typo. s/sub set/subset/

** Section 8.  What is the difference between this section and Section 5
beyond this 

Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12

[Justin Richer]

Thank you, that’s a much better way to say that. I think more of that paragraph 
can actually be pulled back, so I’m proposing this as the opening paragraph to 
that section:

This specification defines a set of common data fields that are designed to be 
usable across different types of APIs. This specification does not require the 
use of any of these common fields by an API definition, but instead provides 
them as reusable generic components for API designers to make use of. The 
allowable values of all fields are determined by the API being protected, as 
defined by a particular "type" value.

This removes the problematic normative language but, I believe, still gets the 
intent across. I’ve put in a PR that makes this change here:

https://github.com/oauthstuff/draft-oauth-rar/pull/88

Please let us know if this works for you. Thanks for your helpful input!

 — Justin

On Oct 14, 2022, at 12:50 PM, Roman Danyliw 
mailto:r...@cert.org>> wrote:

Hi Justin!

-Original Message-----
From: Justin Richer mailto:jric...@mit.edu>>
Sent: Thursday, September 15, 2022 11:20 AM
To: Roman Danyliw mailto:r...@cert.org>>
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12

Hi Roman, some responses inline.

On Sep 14, 2022, at 6:30 PM, Roman Danyliw 
mailto:r...@cert.org>> wrote:


[snip]

** Section 2.2.

All data fields are OPTIONAL for use by a given API
 definition.

I don't follow how this is true in the general case.  I was under the impression
that this section defined what is expected to be common fields.  Couldn't some
AS with a particular type require their presence?

Yes — a particular “type” value can require any of these fields, but a type is
itself not *required* to use any of these fields. That’s what we were trying to
convey with the OPTIONAL here. Is there a better way to communicate this?
Maybe we should just leave off the “OPTIONAL” flag here, but we wanted
people to realize that the common elements don’t have to be used by each
“type”, while every request needs to have a “type”.

We're on the same page.  It's up to the API/particular type field to decide 
which fields to use and this specification doesn't require any of them.  They 
are presented here for the possibility of reuse in common use cases.  I would 
recommend:

OLD
   All data fields are OPTIONAL for use by a given API
  definition.  The allowable values of all fields are determined by the
  API being protected.

NEW
The allowable values of all fields are determined by the API (as defined by a 
particular "type" value) being protected.  This specification does not require 
the use of any of these common fields.


[snip]

** Section 6.1

However, when comparing a new request to an existing request,
 authorization servers can use the same processing techniques as used
 in granting the request in the first place to determine if a resource
 owner needs to authorize the request.

Why is it possible to assess two arbitrary requests in this case to determine 
"if
a resource owner needs to authorize the request", but the prior paragraph
explicitly calls out that comparing two arbitrary requests is not feasible?  To 
me
is seems like comparing two requests to understand if more or less permissions
are being requested is equivalent to determining if a new request exceed the
current request to determine if going back to the resource owner is needed.


It might be possible to do such a comparison in a specific case, but we can’t 
add
logic in the general case. In OAuth, scopes are supposed to be purely additive,
so if you have another scope it’s for “more” things. We know in practice that
that’s not always how it works. Things get much more complex with RAR
because you could have an object with :more: fields in it that makes things
more :strict: by the presence of those fields. That’s all going to be up to the
“type” definition though, so if you understand the “type” definition you could
do a comparison based on that. To me the text is clear, can you suggest how
we could clarify this?

OLD 1
Since the nature of an authorization details request
  is based solely on the API or APIs that it is describing, there is
  not a simple means of comparing any two arbitrary authorization
  details requests.

NEW 1
Since the semantics of the fields in the authorization details result will be 
implementation specific to a given API or set of APIs, there is a no 
standardized mechanism to compare two arbitrary authorization detail requests.

OLD 2
  However, when comparing a new request to an existing request,

NEW 2

When comparing a new request to an existing request, ...

[snip]

** Section 7.

 If the client does not specify
 the authorization_details token request parameters, the AS determines
 the resulting authorization details at its discretion.  The
 authorization server MAY consider the values of other parameters such
 as r

Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12

[Justin Richer]

Hi Roman, some responses inline.

> On Sep 14, 2022, at 6:30 PM, Roman Danyliw  wrote:
> 
> Hi!
> 
> I performed an AD review of draft-ietf-oauth-rar-12.  Thanks for this 
> document.  My feedback is as follows:   
> 
> ** Section 2. Editorial
> 
> This field MUST be compared using an exact byte match of the string
>   value against known types by the AS.
> 
> Consider if you want to introduce how the lack of match will be handled here 
> - it is covered later.
> 
> ** Section 2.2.
> 
> All data fields are OPTIONAL for use by a given API
>   definition.  
> 
> I don't follow how this is true in the general case.  I was under the 
> impression that this section defined what is expected to be common fields.  
> Couldn't some AS with a particular type require their presence?

Yes — a particular “type” value can require any of these fields, but a type is 
itself not *required* to use any of these fields. That’s what we were trying to 
convey with the OPTIONAL here. Is there a better way to communicate this? Maybe 
we should just leave off the “OPTIONAL” flag here, but we wanted people to 
realize that the common elements don’t have to be used by each “type”, while 
every request needs to have a “type”.

> 
> ** Section 3.  Editorial
> 
> OLD
> In case of authorization requests as defined in [RFC6749],
>   implementors MAY consider to use
> 
> NEW
> In case of authorization requests as defined in [RFC6749],
>   implementors MAY consider using ...  
> 
> ** Section 3.  Typo. s/intiate/initiate/
> 
> ** Section 5.  Typo.
> 
> OLD
> authorization details type
>   or authorization details
> 
> NEW
> authorization_details type
>   or authorization_details
> 
> ** Section 6.1
> 
>  However, when comparing a new request to an existing request,
>   authorization servers can use the same processing techniques as used
>   in granting the request in the first place to determine if a resource
>   owner needs to authorize the request.   
> 
> Why is it possible to assess two arbitrary requests in this case to determine 
> "if a resource owner needs to authorize the request", but the prior paragraph 
> explicitly calls out that comparing two arbitrary requests is not feasible?  
> To me is seems like comparing two requests to understand if more or less 
> permissions are being requested is equivalent to determining if a new request 
> exceed the current request to determine if going back to the resource owner 
> is needed.
> 

It might be possible to do such a comparison in a specific case, but we can’t 
add logic in the general case. In OAuth, scopes are supposed to be purely 
additive, so if you have another scope it’s for “more” things. We know in 
practice that that’s not always how it works. Things get much more complex with 
RAR because you could have an object with :more: fields in it that makes things 
more :strict: by the presence of those fields. That’s all going to be up to the 
“type” definition though, so if you understand the “type” definition you could 
do a comparison based on that. To me the text is clear, can you suggest how we 
could clarify this?

> ** Section 6.1.  Typo. s/isaunce/issuance/
> 
> ** Section 7.
> 
>   If the client does not specify
>   the authorization_details token request parameters, the AS determines
>   the resulting authorization details at its discretion.  The
>   authorization server MAY consider the values of other parameters such
>   as resource and scope if they are present during this processing, and
>   the details of such considerations are outside the scope of this
>   specification.
> 
> This guidance seems to indicate the use of the scope parameter is optional in 
> determining the authorization details.  Section 3.1 says "The AS MUST 
> consider both sets of requirements in combination with each other for the 
> given authorization request."  My read is that this is conflicting guidance 
> and Section 3.1 is correct.

You aren’t required to use “scope” in order to use “authorization_details”, but 
we do want to say that the AS is allowed to (or even is supposed to) consider 
both “scope” and “authorization_details” when determining the resulting access 
for any given request that might have both. The guidance in 3.1 should probably 
say “the AS MUST consider all requirements present on a request” or something 
like that?

> 
> ** Figure 15.  The text prior to this figure says that for "For our running 
> example, this would look like this" indicating that this figure is similar to 
> previous examples.  There is one key different - this is the first use of a 
> "payment_initiator" type with the API URL prepended.
> 
> ** Section 7.1. Typo. s/sub set/subset/
> 
> ** Section 8.  What is the difference between this section and Section 5 
> beyond this text explicitly stating the name of the error value 
> (invalid_authorization_details).  I'd recommend stating the normative 
> behavior twice; that is, why are both sections needed?
> 
> ** Section 9.2.  Editorial.  There is 

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

[Justin Richer]

Also, I wanted to take a moment to respond specifically to something in the 
shepherd’s review:

>  • The DPoP Proof contains a hash of the Access Token, and the Access Token 
> contains a hash of the public key in the DPoP Proof. Why do you need both? 
> Would one of these be sufficient?

The access token is not guaranteed to “contain” a hash of the public key — 
that’s only if you’re using JWTs and if you’re using the confirmation method 
specified in here. You are completely free to use non-JWT tokens with 
introspection or use some other means to look up the right keys associated with 
the token.

The other aspect, which I hope is covered by the text in the PR, is that it’s 
about binding it in both directions. Binding the key to the token means that 
you can’t use the token without presenting the key. That’s the fundamental 
problem of proof-of-possession that DPoP is solving. Binding the token to the 
proof means that you can’t use the proof without the token. This is a part of 
making sure you’re binding the proof to the request as-presented. It also means 
that you can’t take a token-less-but-signed call to the RS and add a token 
value that you can’t generate a signature for and have it work.

 — Justin


On Aug 5, 2022, at 1:00 PM, Justin Richer 
mailto:jric...@mit.edu>> wrote:

I think Brian’s just in Danial about this one, but we’ll let it slide.

And I have in fact gone through and added text about ATH:

https://github.com/danielfett/draft-dpop/pull/168

I opted to add this in the introduction of the section about using access 
tokens instead of a separate security consideration because it’s really 
fundamental to the token use here.

 — Justin


On Jul 27, 2022, at 7:11 PM, Brian Campbell 
mailto:bcampbell=40pingidentity@dmarc.ietf.org>>
 wrote:

I need to make one more apology - this time for the incorrect spelling of Dr. 
Fett's name (should be Daniel not Danial). My apologies.

On Wed, Jul 27, 2022 at 6:43 PM Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
Thanks Rifaat and others for the vibrant* discussions about the DPoP draft in 
the side meeting yesterday.

I thought it'd be appropriate to share/reiterate the three action items we'd 
agreed on during the meeting (as I remember anyway):

  1.  Justin to review the text about why we have the AT hash and either create 
a PR adding additional motivations or say that what we have is already 
sufficient
  2.  Danial to add some text to further explain decisions with respect to PAR
  3.  Brian (aka me) to add a parenthetical remark to the Signature Algorithms 
subsection listing 'ES256'

PR's for the latter two are 
here<https://github.com/danielfett/draft-dpop/pull/165> and 
here<https://github.com/danielfett/draft-dpop/pull/166> respectively.  And yes, 
this message is, at least in part, a passive-aggressive reminder to Justin 
about #1.

The slides that I used to try and help guide the discussions are attached. They 
are admittedly rather suboptimal but I'm including them for the sake of 
transparency (and because they have a couple of photos).


* my apologies for being overly vibrant at times




On Wed, Jul 6, 2022 at 4:32 PM Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
Thanks Rifaat!
I will make those changes in the document source and come to Philly prepared to 
discuss the other items. One of the side meetings seems like a good forum for 
that, good idea.

On Tue, Jul 5, 2022 at 11:14 AM Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:
Thanks Brian!
See my replies inline below.


On Thu, Jun 30, 2022 at 6:52 PM Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
Thanks for shepherding Rifaat. And apologies for the slow reply. My attempts at 
answering questions and responding to comments are inline below.


On Fri, Jun 3, 2022 at 11:55 AM Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:
The following is my review as a document shepherd:

Section 4.3
Last sentence
Since the document uses “SHOULD”, this implies that there are some valid cases 
where this is not needed.
Should a text be added to explain when this is not needed?


What about giving a bit more context about why they should? Changing that 
sentence to say, "To reduce the likelihood of false negatives, servers SHOULD 
employ Syntax-Based Normalization (Section 
6.2.2<https://rfc-editor.org/rfc/rfc3986> of [RFC3986]) and Scheme-Based 
Normalization (Section 6.2.2<https://rfc-editor.org/rfc/rfc3986> of [RFC3986]) 
before comparing the htu claim." And also maybe changing it to a little 
"should".

Yes, that works.
I suggest keeping it as "SHOULD" to encourage implementers to use this, unless 
they have a really good reason not to.




Section 6.1

  1.
First sentence - what is the reason for using “SHOULD”, instead of “MUST” in 
this case?


Good question. I think it was a bit of carryover from OAuth in genera

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

[Justin Richer]

I think Brian’s just in Danial about this one, but we’ll let it slide.

And I have in fact gone through and added text about ATH:

https://github.com/danielfett/draft-dpop/pull/168

I opted to add this in the introduction of the section about using access 
tokens instead of a separate security consideration because it’s really 
fundamental to the token use here.

 — Justin


On Jul 27, 2022, at 7:11 PM, Brian Campbell 
mailto:bcampbell=40pingidentity@dmarc.ietf.org>>
 wrote:

I need to make one more apology - this time for the incorrect spelling of Dr. 
Fett's name (should be Daniel not Danial). My apologies.

On Wed, Jul 27, 2022 at 6:43 PM Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
Thanks Rifaat and others for the vibrant* discussions about the DPoP draft in 
the side meeting yesterday.

I thought it'd be appropriate to share/reiterate the three action items we'd 
agreed on during the meeting (as I remember anyway):

  1.  Justin to review the text about why we have the AT hash and either create 
a PR adding additional motivations or say that what we have is already 
sufficient
  2.  Danial to add some text to further explain decisions with respect to PAR
  3.  Brian (aka me) to add a parenthetical remark to the Signature Algorithms 
subsection listing 'ES256'

PR's for the latter two are 
here and 
here respectively.  And yes, 
this message is, at least in part, a passive-aggressive reminder to Justin 
about #1.

The slides that I used to try and help guide the discussions are attached. They 
are admittedly rather suboptimal but I'm including them for the sake of 
transparency (and because they have a couple of photos).


* my apologies for being overly vibrant at times




On Wed, Jul 6, 2022 at 4:32 PM Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
Thanks Rifaat!
I will make those changes in the document source and come to Philly prepared to 
discuss the other items. One of the side meetings seems like a good forum for 
that, good idea.

On Tue, Jul 5, 2022 at 11:14 AM Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:
Thanks Brian!
See my replies inline below.


On Thu, Jun 30, 2022 at 6:52 PM Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
Thanks for shepherding Rifaat. And apologies for the slow reply. My attempts at 
answering questions and responding to comments are inline below.


On Fri, Jun 3, 2022 at 11:55 AM Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:
The following is my review as a document shepherd:

Section 4.3
Last sentence
Since the document uses “SHOULD”, this implies that there are some valid cases 
where this is not needed.
Should a text be added to explain when this is not needed?


What about giving a bit more context about why they should? Changing that 
sentence to say, "To reduce the likelihood of false negatives, servers SHOULD 
employ Syntax-Based Normalization (Section 
6.2.2 of [RFC3986]) and Scheme-Based 
Normalization (Section 6.2.2 of [RFC3986]) 
before comparing the htu claim." And also maybe changing it to a little 
"should".

Yes, that works.
I suggest keeping it as "SHOULD" to encourage implementers to use this, unless 
they have a really good reason not to.




Section 6.1

  1.
First sentence - what is the reason for using “SHOULD”, instead of “MUST” in 
this case?


Good question. I think it was a bit of carryover from OAuth in general not 
strictly defining access token format or content. And wanting to not encroach 
on that. But that's kinda covered/allowed for in general by Section 6 already. 
And Section 6.2 is effectively the same as 6.1 but for introspection and it 
doesn't use "SHOULD". I think the “SHOULD” in the first sentence of 6.1 should 
be removed thereby making it an implicit must - like "when using JWT, this is 
how it is". That would align with the way it's described for introspection. 
Also leaves some room for hash algorithm agility via a new confirmation method 
member (described in 
https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-09.html#name-access-token-and-public-key)
 without going against a "MUST"

I am fine with removing the "SHOULD" to make it an implicit must.





  1.
The DPoP Proof contains a hash of the Access Token, and the Access Token 
contains a hash of the public key in the DPoP Proof.

Why do you need both? Would one of these be sufficient?


The latter (AT containing a hash of the public key in the DPoP Proof) is needed 
and largely sufficient for the main goals of binding the AT to a key held by 
the client. The former (DPoP Proof containing a hash of the AT) was added later 
via very rough WG consensus - it can prevent some esoteric swapping of tokens 
that I never really understood to be honest and also limits the impact of using 
maliciously precomputed and exfiltrated proofs 

Re: [OAUTH-WG] Protected resource access error codes (draft-ietf-oauth-v2-1-05, §5.2.3)

[Justin Richer]

The response from the RS is not the purview of the core OAuth framework RFC6749 
but the token presentation, RFC6750, which has this to say on the matter:


   When a request fails, the resource server responds using the
   appropriate HTTP status code (typically, 400, 401, 403, or 405) and
   includes one of the following error codes in the response:


Basically, it’s not the job of the token layer to dictate what the API’s 
response codes are, or how they’re used. Honestly, having the “error codes” at 
listed is a bit awkward because the RFC can’t say how those codes are returned 
“in the response” in a way that makes sense for the API. While the spec is 
talking about an HTTP WWW-Authenticate header field, it could also be returned 
elsewhere. Are we talking in a JSON object? In an XML document? In some other 
header field? Anything could be most appropriate for a given API, including 
more that I can’t think of here. That said, in practice you see a lot of 
JSON-based APIs these days that have a simple object with an “error” field that 
uses these common values, so even though it’s API-specific you do at least see 
some common behavior in addition to the header.

Since RFC6749 and RFC6750 are being combined into 2.1, I would expect this 
approach to continue. It might be a good question to ask of the editors of 2.1 
at the meeting next week.

 — Justin


On Jul 20, 2022, at 10:46 AM, João Craveiro 
mailto:h...@jcraveiro.com>> wrote:

Hi list,

I’ve been exploring the current OAuth 2.1 draft particularly deep to prepare 
some didactic material, and from that exploration the following stood out as 
being IMO worthy of some discussion. It’s specifically (as the subject points 
out) about Section 5.2.3 (accessing protected resources).

1. Failure to access a resource may not be due to insufficient scope, but to 
insufficient permission. E.g. a request to Google’s Drive API GET 
/files/:fileId endpoint might have the appropriate …/auth/drive scope, but the 
user doesn’t have the permission to see that specific file. Would this deserve 
its own mention, or is this still considered insufficient scope (with the 
unfortunate reality that there’s no scope allowing the resource owner to read a 
file they weren’t given access to)?

2. Still on the above, masking 403s as 404s is a widely used and accepted 
practice, which even the HTTP specification foresees (RFC 9110, §15.5.4):
   > An origin server that wishes to "hide" the current existence of a 
forbidden target resource MAY instead respond with a status code of 404 (Not 
Found).
   That’s in fact what happens in the Google Drive API example above. Since 
OAuth 2.1 is (unlike 2.0) venturing into providing guidance on this matter, 
would it make sense to include this possibility for completeness sake?

OAuth 2.0 leaves error message specifics out of scope (cf. RFC 6749, §7.2), so 
any change here to reflect current practice / advice wouldn’t break OAuth 2.1’s 
backwards compatibility.

Please me know your thoughts and/or any way I can actively contribute to 
improving this in the future OAuth version.


Cheers,
Cravvie

—
João Craveiro
https://jcraveiro.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] IPR Disclosures - OAuth 2.0 Rich Authorization Requests

[Justin Richer]

I am not aware of any IPR issues for this specification and have no disclosures 
to make.

 — Justin

> On Apr 6, 2022, at 9:34 AM, Hannes Tschofenig  
> wrote:
> 
> Authors,
>  
> as part of the shepherd write-up, all authors of draft-ietf-oauth-rar must 
> confirm
> that any and all appropriate IPR disclosures required for full conformance
> with the provisions of BCP 78 and BCP 79 have already been filed.
>  
> Please, reply to this email on the mailing list and indicate if you are
> aware of any IPRs associated with this document.
>  
> 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 
> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC for DPoP Document

[Justin Richer]

Denis,

This is why the use of “iat” and “nonce” are recommended, to prevent this kind 
of replay, and these are already discussed in the draft. Having a highly 
targeted request with narrow presentation window is desirable in most cases, 
but some applications of DPoP do want to have a pre-generated proof that can be 
re-used on multiple requests. In this case, it becomes kind of bearer token in 
its own right, since it’s not strictly tied to a single HTTP request. This 
isn’t an attack, it’s an artifact of DPoP’s limited attachment to the HTTP 
message. If a client pre-generates a generic proof and gives it to another 
client, then that’s exactly the same as the client handing over its access 
token (which it would also need to do). 

The proof and the token are credentials, by definition.

Subject identifiers within the token do not prevent this kind of collusion, as 
has been previously discussed at length. Nothing stops Alice from giving her 
token that says “This is Alice” to Bob and having Bob use it. The RS will know 
it’s Alice’s token, but it’s still valid and Bob can act as Alice. If Alice is 
over 18 then Bob will get access to the things that Alice can get because she’s 
over 18. The call still works. Please stop pretending that adding a user 
identifier to the token solves the problem you are describing, it simply does 
not.

 — Justin

> On Mar 29, 2022, at 11:39 AM, Denis  wrote:
> 
> Hi  Justin,
> 
> In this scenario, the “legitimate” client never gives away its secrets (if it 
> is using a secure platform, it can't). It never give away its credentials 
> either.
> 
> When using key bound access tokens, a RS can't know whether the access token 
> is presented by the “legitimate” client  or by an“illegitimate” client.
> 
> One of the goals is also to prevent a client to monetize the selling of "key 
> bound access tokens" to other end-users. 
> 
> As I have already indicated, there exists a solution able to prevent such 
> scenario in some specific cases (i.e. in the case of RS long-term user 
> accounts).
> 
> Denis
> 
> 
>> If the “legitimate” client willingly gives away its secrets and tokens to 
>> the “illegitimate” client, then the latter isn’t actually “illegitimate” 
>> anymore.
>> 
>> What I was saying is that the “attack" is not even necessary if the clients 
>> are in fact working together. 
>> If the “legitimate” client knowing gives away its credentials, it is 
>> accepting that the receiver of those credentials can do anything it wants 
>> with those credentials. That’s why they are credentials.
>> 
>>  — Justin
>> 
>> PS: I did not “break” the thread, I replied to a message in the thread. 
>> That’s how email lists work.
>> 
>>> On Mar 29, 2022, at 9:19 AM, Denis >> <mailto:denis.i...@free.fr>> wrote:
>>> 
>>> Hi  Justin,
>>> 
>>> You broke the thread since you have not re-used the last message which was:
>>> Steinar,
>>> 
>>> As you have guessed, no data (except the token and some crypto checksums) 
>>> is passing through the clients. 
>>> 
>>> Once the legitimate client has allowed the illegitimate client to use the 
>>> token, the illegitimate client can do anything it wants with it.
>>> The legitimate client can be kept fully ignorant of what illegitimate 
>>> client is doing.
>>> 
>>> The data flow is minimum: if the token allows to view a 4 Gb movie, that 
>>> data flow does not flow between the clients.
>>> 
>>> Furthermore, the content of the token may allow the illegitimate client to 
>>> use it during days or months.
>>> Suppose that the token indicates "over 18". If the user is over 18 now, he 
>>> will certainly be "over 18" the next days, months or years.  
>>> There is no need to refresh the token as it would be the case if the token 
>>> included a home address.
>>> This message explains why this collaborative attack is very different from 
>>> simply forwarding messages between clients.
>>> 
>>> The illegitimate client can do anything it wants without disclosing what it 
>>> is doing to the legitimate client.
>>> The traffic between the clients is kept to the very minimum.
>>> 
>>> Denis
>>> 
>>>> +1
>>>> 
>>>> Am 29.03.22 um 15:10 schrieb Justin Richer:
>>>>> And this is exactly the problem with the “collaborating clients” attack, 
>>>>> as has been pointed out any number of times it’s been brought up before. 
>>>>> If two clients are willingly collaborating in this way, th

Re: [OAUTH-WG] WGLC for DPoP Document

[Justin Richer]

If the “legitimate” client willingly gives away its secrets and tokens to the 
“illegitimate” client, then the latter isn’t actually “illegitimate” anymore.

What I was saying is that the “attack" is not even necessary if the clients are 
in fact working together. If the “legitimate” client knowing gives away its 
credentials, it is accepting that the receiver of those credentials can do 
anything it wants with those credentials. That’s why they are credentials.

 — Justin

PS: I did not “break” the thread, I replied to a message in the thread. That’s 
how email lists work.

> On Mar 29, 2022, at 9:19 AM, Denis  wrote:
> 
> Hi  Justin,
> 
> You broke the thread since you have not re-used the last message which was:
> Steinar,
> 
> As you have guessed, no data (except the token and some crypto checksums) is 
> passing through the clients. 
> 
> Once the legitimate client has allowed the illegitimate client to use the 
> token, the illegitimate client can do anything it wants with it.
> The legitimate client can be kept fully ignorant of what illegitimate client 
> is doing.
> 
> The data flow is minimum: if the token allows to view a 4 Gb movie, that data 
> flow does not flow between the clients.
> 
> Furthermore, the content of the token may allow the illegitimate client to 
> use it during days or months.
> Suppose that the token indicates "over 18". If the user is over 18 now, he 
> will certainly be "over 18" the next days, months or years.  
> There is no need to refresh the token as it would be the case if the token 
> included a home address.
> This message explains why this collaborative attack is very different from 
> simply forwarding messages between clients.
> 
> The illegitimate client can do anything it wants without disclosing what it 
> is doing to the legitimate client.
> The traffic between the clients is kept to the very minimum.
> 
> Denis
> 
>> +1
>> 
>> Am 29.03.22 um 15:10 schrieb Justin Richer:
>>> And this is exactly the problem with the “collaborating clients” attack, as 
>>> has been pointed out any number of times it’s been brought up before. If 
>>> two clients are willingly collaborating in this way, they do not need to 
>>> share any cryptographic material and impersonate each other.
>>> 
>>> You don’t need to steal my license if I’m willing to just go buy you beer.
>>> 
>>> The DPoP draft does address signed request re-use, which some see as a 
>>> feature to be carefully applied.
>>> 
>>>  — Justin
>>> 
>>>> On Mar 28, 2022, at 1:04 PM, Steinar Noem >>> <mailto:stei...@udelt.no>> wrote:
>>>> 
>>>> Interesting, but won't two collaborating clients just pass any data they 
>>>> want to each other? Why would these collaborating clients go through the 
>>>> trouble of exchanging private keys, dpop proofs or tokens? Could you 
>>>> elaborate some more on the scenario? 
>>>> 
>>>> S
>>>> 
>>>> man. 28. mar. 2022 kl. 16:29 skrev Denis >>> <mailto:denis.i...@free.fr>>:
>>>> Rifaat & Hannes,
>>>> Hereafter are my comments:
>>>> 
>>>> The introduction states :
>>>> 
>>>>Recipients of such tokens are then able to verify the binding of 
>>>> the token to the key pair that  the client has demonstrated 
>>>>that it holds via the DPoP header, thereby providing some assurance 
>>>> that the client presenting the token also possesses the private key. 
>>>> 
>>>>In other words, the legitimate presenter of the token is 
>>>> constrained to be the sender that holds and can prove possession of the 
>>>> private part of the key pair.
>>>> 
>>>> The client presenting the token does not necessarily possess the private 
>>>> key. The client presenting the token has been able to use 
>>>> the results of some cryptographic functions using the private part of the 
>>>> key pair. 
>>>> 
>>>> These results may be communicated by one client to another client, if the 
>>>> two clients agree to collaborate. This statement will be added later on.
>>>> 
>>>> Proposed rewording:
>>>> 
>>>>Recipients of such tokens are then able to verify the binding of 
>>>> the token to the key pair that  the client has demonstrated 
>>>>that it holds via the DPoP header, thereby providing some assurance 
>>>> that the client presenting the token e

Re: [OAUTH-WG] access token hash claim name in oauth-dpop draft

[Justin Richer]

Yes, it was considered, discussed, and rejected. The reason being “at_hash” has 
a somewhat convoluted definition (left-bits of a hash of an access token in the 
context of a JOSE object, etc), to fit some of the design constraints of ID 
Tokens. DPoP proofs do not have those same constraints. DPoP opted, correctly 
in my opinion, to simplify this by declaring a single hashing algorithm and 
using its full output value. Cryptographic agility would be achieved by 
defining a new claim with a new hashing algorithm.

 — Justin

> On Mar 28, 2022, at 10:41 AM, Rohan Mahy  
> wrote:
> 
> Hi,
> Did you consider using the (already IANA registered) at_hash claim defined 
> in: 
> https://openid.net/specs/openid-connect-core-1_0.html#CodeIDToken 
> 
> instead of defining a new ath claim?
> 
> It seems like if we don't use at_hash we should explain why ath is 
> better/different.
> Thanks,
> -rohan
> ___
> 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 DPoP Document

[Justin Richer]

And this is exactly the problem with the “collaborating clients” attack, as has 
been pointed out any number of times it’s been brought up before. If two 
clients are willingly collaborating in this way, they do not need to share any 
cryptographic material and impersonate each other.

You don’t need to steal my license if I’m willing to just go buy you beer.

The DPoP draft does address signed request re-use, which some see as a feature 
to be carefully applied.

 — Justin

> On Mar 28, 2022, at 1:04 PM, Steinar Noem  wrote:
> 
> Interesting, but won't two collaborating clients just pass any data they want 
> to each other? Why would these collaborating clients go through the trouble 
> of exchanging private keys, dpop proofs or tokens? Could you elaborate some 
> more on the scenario? 
> 
> S
> 
> man. 28. mar. 2022 kl. 16:29 skrev Denis  >:
> Rifaat & Hannes,
> Hereafter are my comments:
> 
> The introduction states :
> 
>Recipients of such tokens are then able to verify the binding of the 
> token to the key pair that  the client has demonstrated 
>that it holds via the DPoP header, thereby providing some assurance 
> that the client presenting the token also possesses the private key. 
> 
>In other words, the legitimate presenter of the token is constrained 
> to be the sender that holds and can prove possession of the private part of 
> the key pair.
> 
> The client presenting the token does not necessarily possess the private key. 
> The client presenting the token has been able to use 
> the results of some cryptographic functions using the private part of the key 
> pair. 
> 
> These results may be communicated by one client to another client, if the two 
> clients agree to collaborate. This statement will be added later on.
> 
> Proposed rewording:
> 
>Recipients of such tokens are then able to verify the binding of the 
> token to the key pair that  the client has demonstrated 
>that it holds via the DPoP header, thereby providing some assurance 
> that the client presenting the token either also possesses 
>the private key or has been able to use the result of cryptographic 
> computations from another client that possesses the private key. 
> 
>In other words, the presenter of the token can prove that it has been 
> able to use the results of cryptographic computations performed 
>by using the private part of the key pair. 
> 
> The objectives states
> 
>The primary aim of DPoP is to prevent unauthorized or illegitimate 
> parties from using leaked or stolen access tokens, 
>by binding a token to a public key upon issuance and requiring that 
> the client proves possession of the corresponding 
>private key when using the token.
> 
> DPoP does not prevent unauthorized or illegitimate parties from using access 
> tokens, as soon as two clients agree to collaborate.
> 
> Proposed rewording:
> 
>The primary aim of DPoP is to bind a token to a public key upon 
> issuance and requiring that the client proves possession 
>of the corresponding private key when using the token.  This does not 
> demonstrate that the client presenting the token is 
>necessarily the legitimate client. In the case of non-collaborating 
> clients, DPoP prevents unauthorized or illegitimate parties 
>from using leaked or stolen access tokens. In the case of 
> collaborating clients, the security of DPoP is ineffective 
>(see section 11.X).
> 
> Section 11 is about "Security Considerations" and addresses the following 
> topics:
> 
>  11.1.  DPoP Proof Replay
>  11.2.  DPoP Proof Pre-Generation
>  11.3.  DPoP Nonce Downgrade
>  11.4.  Untrusted Code in the Client Context
>  11.5.  Signed JWT Swapping
>  11.6.  Signature Algorithms
>  11.7.  Message Integrity
>  11.8.  Access Token and Public Key Binding
>  11.9.  Authorization Code and Public Key Binding
> 
> The case of collaborative clients should be addressed within section 11.
> 
> Text proposal. 
> 
>  11.X. Collaborative clients
> 
> DPoP demonstrates that the client presenting the token has been 
> able to use the results of some cryptographic functions
> using the private part of the key pair.
> 
> If a client agrees to collaborate with another client, the 
> security of DPoP is no longer effective.  When two clients   agree to 
> collaborate, 
> these results of the cryptographic computations performed by one 
> client may be communicated to another client. 
> 
> Even if the private key used for DPoP is stored in such a way 
> that it cannot be exported, e.g., in a hardware or software security module, 
> the client can perform all the cryptographic computations needed 
> by the other client to create DPoP proofs. 
> 
> The client can easily create new DPoP proofs as long as the 

Re: [OAUTH-WG] DPoP and Client Registration Access Token

[Justin Richer]

Way back when we wrote dynamic registration, we made the decision to always 
have the registration token just be a bearer token. Part of this is because 
OAuth2 doesn’t really have a separate “access token” data structure that we 
could just replicate in this spot, so there’s no “token type” or other meta 
parameters around the token value itself that come back. The other reason is 
that without a process to dynamically bind the key during registration, it 
didn’t make sense to require other credentials alongside the token. For another 
example of where this confusion comes into play, just see any of the discussion 
here about whether the DPoP binding applies to the refresh token, which comes 
alongside the access token.

I think you’re absolutely right that things like DPoP (and even MTLS, or 
alternatives like HTTP Signatures) raise the question of binding the 
registration token in the same way that you can bind other access tokens. To do 
this, though, you’d need to extend dynamic registration’s response. I think 
you’ve got the right idea here, but you’d need to add a bunch of signaling in 
the request and response. I think a dopp-specific flag, or a new field instead 
of “registration_access_token” would both do the job with different properties. 
You’d also need to define how to use the DPoP proof at the registration request.

All of that seems like it’d fit neatly into a self-contained extension of 
dynamic registration.

 — Justin

> On Mar 12, 2022, at 7:32 PM, Nicolas Mora  wrote:
> 
> Hello,
> 
> While reading the last DPoP document (draft 6), I was wondering about other 
> access tokens delivered by the AS, especially the Registration Access Token 
> during Dynamic Client Management Registration [1].
> 
> The OAuth 2.0 Dynamic Client Registration Management Protocol RFC states 
> that: [2]
> 
> "(D)   The authorization server registers the client and returns:
> [...]
> *  a registration access token to be used when calling the
>client configuration endpoint."
> 
> I'm considering the DPoP objectives would be relevant when using the Dynamic 
> Client Registration Management Protocol, when the AS provides an access token 
> for client.
> 
> Although, adding the DPoP proof JWT during the client registration would be 
> different than in the /token endpoint. The client registration endpoint can 
> be authorized by an access token, therefore this access token can be enforced 
> using DPoP.
> 
> A solution I thought of is to add the DPoP proof in the client registration 
> request itself.
> 
> The following example is a sample showing a client registration authorized 
> through an access token enforced with DPoP, and a DPoP proof inside the 
> registration request. The DPoP jkt will then be attached to the registration 
> access token, so the registered client would have to add a DPoP proof each 
> time it calls the Client Registration Management endpoint.
> 
> POST /register HTTP/1.1
> Content-Type: application/json
> Accept: application/json
> Host: server.example.com
> Authorization: DPoP Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU
> DPoP: eyJ0eXAiOiJkcG9[...]xyz
> 
> {
>  "redirect_uris": [
>"https://client.example.org/callback;,
>"https://client.example.org/callback2;],
>  "client_name": "My Example Client",
>  "client_name#ja-Jpan-JP":
> "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
>  "token_endpoint_auth_method": "client_secret_basic",
>  "logo_uri": "https://client.example.org/logo.png;,
>  "jwks_uri": "https://client.example.org/my_public_keys.jwks;,
>  "example_extension_parameter": "example_value",
>  "DPoP": "eyJ0eXAiOiJkcG9[...]abc"
> }
> 
> The client registration DPoP content should use a different key and a 
> different jti than the one used with the DPoP access token, but the htm and 
> htu values would be the same.
> 
> Any thought about that?
> 
> /Nicolas
> 
> [1] https://datatracker.ietf.org/doc/html/rfc7592
> [2] https://datatracker.ietf.org/doc/html/rfc7592#section-1.3
> 
> ___
> 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] can a resource server provide indications about expected access tokens?

[Justin Richer]

Hi Nikos,

If you mean indicate to the client, then in my view, no — not directly in a 
delegation protocol like OAuth, at least. The format of the token, and its 
contents, are abstracted away. As has been mentioned in the thread already, you 
can return a “scope” and other parameters to the client to indicate what it 
should ask for, as well as “resource” or even “authorization_details” to use 
RAR structures. However, there’s an important point that I see so many 
engineers trip over:


- Scope, resource, authorization_details (RAR), audience, etc: parameters that 
the client uses to describe what it wants in a request. Let’s call this the 
“request set”.
- iss, sub, claims, attributes, etc: items inside a JWT access token (when you 
use that format) to tell an RS what the token’s good for. Let’s call this the 
“access set”.


The client and AS communicate using the “request set”, while the AS and RS 
communicate in the “access set”. It’s the job of the AS — literally the primary 
function of the role of AS — is to translate the “request set” into an 
artifact, the access token, that can be interpreted in the “access set”. The 
access token is the artifact that provides that abstraction to the client, and 
the AS is the mechanism through which a client’s understanding of what it’s 
asking for gets translated to what the RS actually understands. 

What gets confusing is that sometimes these are the same in practice — you can 
use “scope” in both places as an abstraction in the access token itself. I’ve 
seen that work many times. But when you do that it does seem like the client is 
saying “put the following things inside the access token”, when what’s really 
happening is the client is saying “I want access to the following things” and 
the AS is taking that list and saying “that means these other things are what 
go in the access token”.

The entire purpose of a delegation protocol is that translation from “request 
set” to “access set” semantics. Trying to skip that gets you out of delegation 
protocol territory pretty quickly.

 — Justin



> On Dec 11, 2021, at 5:35 AM, Nikos Fotiou  wrote:
> 
> Hi,
> 
> I have a use case where a resource server is protected  and can only be 
> accessed if a JWT is presented. Is there any way for the server to "indicate" 
> the "expected" format of the JWT. For example,  respond to unauthorized 
> requests with something that would be translated into "I expect tokens form 
> iss X with claims [A,B,C]"
> 
> Best,
> Nikos
> 
> --
> Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
> Researcher - Mobile Multimedia Laboratory
> Athens University of Economics and Business
> https://mm.aueb.gr
> 
> ___
> 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 changes to RFC 8705 (oauth-mtls)

[Justin Richer]

I disagree with this take. If there are confirmation methods at all, it’s no 
longer a Bearer token, and pretending that it is doesn’t help anyone. I think 
combining confirmation methods is interesting, but then you get into a weird 
space of how to define the combinations, and what to do if one is missing, etc. 
It opens up a weird space for interop problems. It’s not insurmountable, but I 
don’t think it’s a trivial as it might look at first.

Plus, the “backwards compatible” argument is what led to the existing RFC using 
Bearer again. In my view, this actually opens up the possibility of downgrade 
attacks against the RS, where a lazy RS doesn’t check the binding because it 
sees “Bearer” and calls it a day. The thing is, turning off that kind of 
checking is the kind of problem that fails open, like turning off XML signature 
validation in a SAML environment. The good assertions still pass, and bad 
assertions happen to also look fine. I don’t think that’s a good space to be 
in, and re-using “Bearer” like the existing spec does is a problem for that 
reason.

I would personally love to see a bis of this RFC, but because of inertia around 
existing deployments, I don’t expect it. I think we’d see a lot of confusion 
around which version of things to use.

 — Justin

> On Dec 9, 2021, at 8:52 AM, Neil Madden  wrote:
> 
> I don’t mind about a new error code, although I think it’s of limited value - 
> error codes (rather than descriptive error *messages*) imply that the client 
> may be able to dynamically react to the situation and so something different. 
> But TLS client certs are usually configured statically, so it seems highly 
> unlikely that the client could satisfy this requirement on its own. 
> (Especially without all the other hints that would be missing from the TLS 
> layer, like trusted CAs, supported signature algorithms, etc).
> 
> I am against changing the token type/scheme from Bearer to MTLS.  Mostly 
> because of backwards compatibility issues - we already have customers that 
> have deployed mTLS widely, but also because of conceptual issues I have 
> generally with distinct token_type/schemes:
> 
> 1. Whether an access token is mTLS-bound or a pure bearer token is a property 
> of what the RS enforces, not intrinsic to the token. As far as I am aware, 
> there is no spec anywhere that says what an RS should do if it doesn’t 
> understand a particular confirmation method associated with an access token. 
> So you can easily at present have a situation where an AT is valid at 
> multiple RSes, some of which understand mTLS-binding and some of which do 
> not. Indeed, this is very likely (and desirable) when you are in the process 
> of rolling out stronger security mechanisms on an RS-by-RS basis. (And what 
> if you later decide to move from mTLS to DPoP?) IMO requiring that ATs always 
> have one and only one associated PoP mechanism is a recipe for ossification.
> 
> 2. IMO the “token_type” and Authorization scheme should be primarily about 
> how the AT itself is conveyed to the RS, not about how any associated proof 
> is. Although “Bearer” is not the most appropriate name, I would rather we 
> stuck to that one scheme for conveying ATs regardless of whether they are 
> pure bearer tokens, bound tokens, or whatever. To me, the important part of 
> “Bearer” is that it tells the RS that it can send this token directly to an 
> introspection endpoint (or examine it locally) without first performing some 
> additional processing on it.
> 
> 3. I am generally in favour of allowing ATs to have 0, 1, 2 or any number of 
> confirmation methods associated with them. If we want to make it easier for a 
> client to figure out which ones an RS supports, I’d rather see this as an 
> enhancement to the Bearer WWW-Authentication challenge - e.g. 
> WWW-Authenticate: Bearer … supported_cnf_methods=mtls,dpop
> 
> Anyway, can of worms well and truly opened…
> 
> — Neil
> 
>> On 9 Dec 2021, at 13:23, Dmitry Telegin 
>> > > wrote:
>> 
>> There following changes to RFC 8705 have been proposed:
>> - introduce a new error code (e.g. "invalid_mtls_certificate") to be used 
>> when the certificate is required by the AS/RS, but the underlying stack has 
>> been misconfigured and the client didn't send one;
>> - for bound token use, change Authorization scheme from Bearer to MTLS;
>> - for token response returning a bound token, change token_type from Bearer 
>> to MTLS
>> 
>> See discussion: 
>> https://mailarchive.ietf.org/arch/msg/oauth/XfeH2q0Rwa2YocsR484xk-8LMqc/ 
>> 
>> 
>> Accepting the changes would imply a new RFC and the obsolescence of the 
>> current one. Two questions so far:
>> - what's the group's general stance on this, would that be a welcome change?
>> - if so, could we also hear from the implementors if there any other issues 
>> / suggested changes.
>> 
>> Dmitry

Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing client certificate

[Justin Richer]

Yes, this I agree with. This is why I think we should probably have:

Authorization: Bearer foo...
Authorization: DPoP foo...
Authorization: HTTPSig foo...
Authorization: MTLS foo…

And so on. If you’ve got a middle box that’s adding its own attestations to the 
request, that’s not adding additional presentations to the access token. 

 — Justin

> On Nov 16, 2021, at 6:05 PM, 乗松隆志 / NORIMATSU，TAKASHI 
>  wrote:
> 
> Hello,
>  
> Considering that several technologies has emerged for realizing sender 
> constrained tokens (e.g. holder-of-key bound : certificate bound by MTLS, 
> DPoP, etc ... in the future), it might be good to show which kind of 
> technology is used for sender constraint token explicitly with Authentication 
> header value if there is a chance that RS allows several technologies for 
> sender constrained access token.
>  
> Regards,
> Takashi Norimatsu
> Hitachi, Ltd.
>  
> From: Justin Richer  
> Sent: Tuesday, November 16, 2021 1:18 AM
> To: Dmitry Telegin 
> Cc: oauth ; 乗松隆志 / NORIMATSU，TAKASHI 
> 
> Subject: [!]Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing 
> client certificate
>  
> On Nov 12, 2021, at 8:30 AM, Dmitry Telegin  <mailto:dmit...@backbase.com>> wrote:
>  
> Just to make sure I understand the process, is it going to be something like 
> draft-XX-oauth-mtls-rfc8705-bis -> draft-ietf-oauth-mtls-rfc8705-bis -> 
> new RFC that will obsolete the current one? CCing my colleague Takashi 
> Norimatsu who worked on MTLS holder-of-key for Keycloak, perhaps he has more 
> ideas for improvements.
>  
>  
> That’s the most likely path if it happens, yes. And that’s if the WG wants to 
> make that change, which would break things.
> 
> 
> As for this stance:
> The MTLS draft also re-uses “Bearer” as a token header, which is also a 
> mistake in my opinion.
>  
> Did you mean the re-use of the "Bearer" scheme for the Authorization header 
> and WWW-Authenticate challenge? If so, and if we decide to introduce a new 
> scheme, I think this would imply a new value for the "token_type" token 
> response attribute as well.
>  
>  
> I actually meant the use in the “Authorization: Bearer ” header, as 
> well as the token type. In my opinion both of those should be something other 
> than “bearer” because it’s not a bearer token, it’s TLS bound. The argument 
> in the WG at the time was that it would allow easier upgrades from existing 
> implementations. I personally hold that this decision allows for more 
> dangerous downgrades instead. 路♀️
>  
>  
> — Justin
>  
> 
> 
> Of particular interest to me is the question whether different binding 
> mechanisms (DPoP, MTLS) could co-exist, or should they be mutually exclusive; 
> this deserves a separate thread though.
>  
> - Dmitry
>  
>  
>  
>  
> On Thu, Nov 11, 2021 at 10:22 AM Justin Richer  <mailto:jric...@mit.edu>> wrote:
> Only if this working group wanted to take up the work of making a new 
> revision of the standard, but I haven't seen any indication of desire to do 
> that here. One possibility is for you to propose an update as an individual 
> draft to the group here. 
> 
> -Justin
> 
> From: Dmitry Telegin [dmit...@backbase.com <mailto:dmit...@backbase.com>]
> Sent: Wednesday, November 10, 2021 1:34 PM
> To: Justin Richer
> Cc: oauth
> Subject: Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing 
> client certificate
> 
> Thanks for the reply. That makes sense.
> 
> Given that MTLS is not a draft but rather a proposed standard (RFC 8705), do 
> you think there is a chance the changes you proposed could land in MTLS one 
> day?
> 
> On Wed, Nov 10, 2021 at 6:24 PM Justin Richer  <mailto:jric...@mit.edu><mailto:jric...@mit.edu <mailto:jric...@mit.edu>>> 
> wrote:
> This is just my interpretation, but this feels more like invalid token, 
> because you’re not presenting all of the material required for the token 
> itself. The DPoP draft has added “invalid_dpop_proof” as an error code, which 
> I think is even better, but the MTLS draft is missing such an element and 
> that is arguably a mistake in the document. The MTLS draft also re-uses 
> “Bearer” as a token header, which is also a mistake in my opinion.
> 
> But given the codes available, “invalid_token” seems to fit better because 
> you aren’t messing up the request _to the resource_ itself, you’re messing up 
> the token presentation.
> 
>  — Justin
> 
> On Nov 10, 2021, at 10:17 AM, Dmitry Telegin 
>  <mailto:40backbase@dmarc.ietf.org><mailto:dmitryt 
> <mailt

Re: [OAUTH-WG] DPoP and MTLS - friends or foes?

[Justin Richer]

I would expect them to be able to co-exist in an implementation, but not both 
be used on the same token. One of the implementations that I work on supports 
both DPoP and MTLS on access tokens (as well as bearer tokens), and we use 
metadata stored in the token objects to switch between these.

 — Justin


> On Nov 12, 2021, at 11:37 AM, Dmitry Telegin 
>  wrote:
> 
> As an implementer of one binding mechanism (DPoP) for the AS (Keycloak) that 
> already features another (MTLS), I'm running into the question whether we 
> should allow those two to be used simultaneously (which could be of course 
> extrapolated to other hypothetical mechanisms). By "simultaneously" I mean 
> binding a single token using both methods given that the material for both 
> has been provided with the request.
> 
> I guess currently mutual exclusivity is implied. Though in theory the "cnf" 
> section of the AT could contain both "jkt" and "x5t#S256", the mechanisms are 
> using different values for "token_type" and authentication scheme ("DPoP" for 
> DPoP, "Bearer" for MTLS, though the latter might change to "MTLS" in the 
> future) and we define no mechanism to combine them (could be "Bearer+DPoP" or 
> "DPoP+MTLS" for example, which would be valid as per RFCs 7230 and 7235).
> 
> I apologize if the question has been asked before; didn't find anything 
> relevant in the ML. The implementer of MTLS for Keycloak also voted for 
> mutually exclusive behavior.
> 
> - Dmitry
> Backbase / Keycloak
> 
> ___
> 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] RFC 8705 (oauth-mtls): RS error code for missing client certificate

[Justin Richer]

On Nov 12, 2021, at 8:30 AM, Dmitry Telegin  wrote:
> 
> Just to make sure I understand the process, is it going to be something like 
> draft-XX-oauth-mtls-rfc8705-bis -> draft-ietf-oauth-mtls-rfc8705-bis -> 
> new RFC that will obsolete the current one? CCing my colleague Takashi 
> Norimatsu who worked on MTLS holder-of-key for Keycloak, perhaps he has more 
> ideas for improvements.
> 

That’s the most likely path if it happens, yes. And that’s if the WG wants to 
make that change, which would break things.

> As for this stance:
> The MTLS draft also re-uses “Bearer” as a token header, which is also a 
> mistake in my opinion.
> 
> Did you mean the re-use of the "Bearer" scheme for the Authorization header 
> and WWW-Authenticate challenge? If so, and if we decide to introduce a new 
> scheme, I think this would imply a new value for the "token_type" token 
> response attribute as well.
> 

I actually meant the use in the “Authorization: Bearer ” header, as well 
as the token type. In my opinion both of those should be something other than 
“bearer” because it’s not a bearer token, it’s TLS bound. The argument in the 
WG at the time was that it would allow easier upgrades from existing 
implementations. I personally hold that this decision allows for more dangerous 
downgrades instead. 路‍♀️


— Justin


> Of particular interest to me is the question whether different binding 
> mechanisms (DPoP, MTLS) could co-exist, or should they be mutually exclusive; 
> this deserves a separate thread though.
> 
> - Dmitry



> 
> On Thu, Nov 11, 2021 at 10:22 AM Justin Richer  <mailto:jric...@mit.edu>> wrote:
> Only if this working group wanted to take up the work of making a new 
> revision of the standard, but I haven't seen any indication of desire to do 
> that here. One possibility is for you to propose an update as an individual 
> draft to the group here. 
> 
> -Justin
> 
> From: Dmitry Telegin [dmit...@backbase.com <mailto:dmit...@backbase.com>]
> Sent: Wednesday, November 10, 2021 1:34 PM
> To: Justin Richer
> Cc: oauth
> Subject: Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing 
> client certificate
> 
> Thanks for the reply. That makes sense.
> 
> Given that MTLS is not a draft but rather a proposed standard (RFC 8705), do 
> you think there is a chance the changes you proposed could land in MTLS one 
> day?
> 
> On Wed, Nov 10, 2021 at 6:24 PM Justin Richer  <mailto:jric...@mit.edu><mailto:jric...@mit.edu <mailto:jric...@mit.edu>>> 
> wrote:
> This is just my interpretation, but this feels more like invalid token, 
> because you’re not presenting all of the material required for the token 
> itself. The DPoP draft has added “invalid_dpop_proof” as an error code, which 
> I think is even better, but the MTLS draft is missing such an element and 
> that is arguably a mistake in the document. The MTLS draft also re-uses 
> “Bearer” as a token header, which is also a mistake in my opinion.
> 
> But given the codes available, “invalid_token” seems to fit better because 
> you aren’t messing up the request _to the resource_ itself, you’re messing up 
> the token presentation.
> 
>  — Justin
> 
> On Nov 10, 2021, at 10:17 AM, Dmitry Telegin 
>  <mailto:40backbase@dmarc.ietf.org><mailto:dmitryt 
> <mailto:dmitryt>=40backbase@dmarc.ietf.org 
> <mailto:40backbase@dmarc.ietf.org>>> wrote:
> 
> Any updates on this one? The missing certificate case looks more like 
> "invalid_request" to me:
> 
> 
> invalid_request
>  The request is missing a required parameter, includes an
>  unsupported parameter or parameter value, repeats the same
>  parameter, uses more than one method for including an access
>  token, or is otherwise malformed.  The resource server SHOULD
>  respond with the HTTP 400 (Bad Request) status code.
> 
> 
> On Fri, Sep 24, 2021 at 2:23 AM Dmitry Telegin  <mailto:dmit...@backbase.com><mailto:dmit...@backbase.com 
> <mailto:dmit...@backbase.com>>> wrote:
> From the document:
> 
> 
>The protected resource MUST obtain, from its TLS implementation
>layer, the client certificate used for mutual TLS and MUST verify
>that the certificate matches the certificate associated with the
>access token.  If they do not match, the resource access attempt MUST
>be rejected with an error, per 
> [RFC6750<https://datatracker.ietf.org/doc/html/rfc6750 
> <https://datatracker.ietf.org/doc/html/rfc6750>>], using an HTTP 401 status
>code and the "invalid_token" error code.
> 
> S

Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing client certificate

[Justin Richer]

Only if this working group wanted to take up the work of making a new revision 
of the standard, but I haven't seen any indication of desire to do that here. 
One possibility is for you to propose an update as an individual draft to the 
group here. 

-Justin

From: Dmitry Telegin [dmit...@backbase.com]
Sent: Wednesday, November 10, 2021 1:34 PM
To: Justin Richer
Cc: oauth
Subject: Re: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing client 
certificate

Thanks for the reply. That makes sense.

Given that MTLS is not a draft but rather a proposed standard (RFC 8705), do 
you think there is a chance the changes you proposed could land in MTLS one day?

On Wed, Nov 10, 2021 at 6:24 PM Justin Richer 
mailto:jric...@mit.edu>> wrote:
This is just my interpretation, but this feels more like invalid token, because 
you’re not presenting all of the material required for the token itself. The 
DPoP draft has added “invalid_dpop_proof” as an error code, which I think is 
even better, but the MTLS draft is missing such an element and that is arguably 
a mistake in the document. The MTLS draft also re-uses “Bearer” as a token 
header, which is also a mistake in my opinion.

But given the codes available, “invalid_token” seems to fit better because you 
aren’t messing up the request _to the resource_ itself, you’re messing up the 
token presentation.

 — Justin

On Nov 10, 2021, at 10:17 AM, Dmitry Telegin 
mailto:dmitryt=40backbase@dmarc.ietf.org>>
 wrote:

Any updates on this one? The missing certificate case looks more like 
"invalid_request" to me:


invalid_request
 The request is missing a required parameter, includes an
 unsupported parameter or parameter value, repeats the same
 parameter, uses more than one method for including an access
 token, or is otherwise malformed.  The resource server SHOULD
 respond with the HTTP 400 (Bad Request) status code.


On Fri, Sep 24, 2021 at 2:23 AM Dmitry Telegin 
mailto:dmit...@backbase.com>> wrote:
>From the document:


   The protected resource MUST obtain, from its TLS implementation
   layer, the client certificate used for mutual TLS and MUST verify
   that the certificate matches the certificate associated with the
   access token.  If they do not match, the resource access attempt MUST
   be rejected with an error, per 
[RFC6750<https://datatracker.ietf.org/doc/html/rfc6750>], using an HTTP 401 
status
   code and the "invalid_token" error code.

Should the same error code be used in the case when the resource failed to 
obtain a certificate from the TLS layer? This could happen, for example, if the 
TLS stack has been misconfigured (e.g. verify-client="REQUESTED" instead of 
"REQUIRED" for Undertow), and the user agent provided no certificate.

Thanks,
Dmitry

___
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] RFC 8705 (oauth-mtls): RS error code for missing client certificate

[Justin Richer]

This is just my interpretation, but this feels more like invalid token, because 
you’re not presenting all of the material required for the token itself. The 
DPoP draft has added “invalid_dpop_proof” as an error code, which I think is 
even better, but the MTLS draft is missing such an element and that is arguably 
a mistake in the document. The MTLS draft also re-uses “Bearer” as a token 
header, which is also a mistake in my opinion. 

But given the codes available, “invalid_token” seems to fit better because you 
aren’t messing up the request _to the resource_ itself, you’re messing up the 
token presentation.

 — Justin

> On Nov 10, 2021, at 10:17 AM, Dmitry Telegin 
>  wrote:
> 
> Any updates on this one? The missing certificate case looks more like 
> "invalid_request" to me:
> 
> invalid_request
>  The request is missing a required parameter, includes an
>  unsupported parameter or parameter value, repeats the same
>  parameter, uses more than one method for including an access
>  token, or is otherwise malformed.  The resource server SHOULD
>  respond with the HTTP 400 (Bad Request) status code.
> 
> On Fri, Sep 24, 2021 at 2:23 AM Dmitry Telegin  > wrote:
> From the document:
> 
>The protected resource MUST obtain, from its TLS implementation
>layer, the client certificate used for mutual TLS and MUST verify
>that the certificate matches the certificate associated with the
>access token.  If they do not match, the resource access attempt MUST
>be rejected with an error, per [RFC6750 
> ], using an HTTP 401 status
>code and the "invalid_token" error code.
> 
> Should the same error code be used in the case when the resource failed to 
> obtain a certificate from the TLS layer? This could happen, for example, if 
> the TLS stack has been misconfigured (e.g. verify-client="REQUESTED" instead 
> of "REQUIRED" for Undertow), and the user agent provided no certificate.
> 
> Thanks,
> Dmitry
> 
> ___
> 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] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[Justin Richer]

Dick, you would probably be interested in the Oblivious HTTP effort that has 
recently been chartered to solve similar encapsulation problems in HTTP. 

- Justin

From: OAuth [oauth-boun...@ietf.org] on behalf of Dick Hardt 
[dick.ha...@gmail.com]
Sent: Friday, October 22, 2021 6:08 PM
To: Richard Backman, Annabelle
Cc: David Waite; oauth
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of 
Possession Tokens with HTTP Message Signature

I have a use case for a self contained request that can be independently 
verified by multiple parties. IE, not just have PoP at HTTP endpoint, but by 
components doing processing further down the line. It also provides 
non-repudiation.

For example, a JWT that is sent as an HTTP payload includes the request and the 
access token.

mTLS, DPoP, and HTTP signing don't provide this functionality

It is not clear if others have similar requirements, or if there is value in 
standardization effort, but I wanted to call out a use case not solved by the 
current efforts.

/Dick

On Wed, Oct 13, 2021 at 2:55 PM Richard Backman, Annabelle 
mailto:40amazon@dmarc.ietf.org>> 
wrote:
If keeping DPoP simple means we have to have come up with 10 different variants 
to handle all the different cases that it doesn't support, then it isn't 
keeping it simple, it is just pushing the problem forward to the implementers 
to figure out which set of RFCs to implement.

I'm hoping we can stop at 3: mTLS, DPoP, and Justin's draft. If someone has use 
cases that aren't covered by one or more of those, they should bring those up 
so we can discuss them and decide what changes are warranted. (Either here, or 
in HTTPbis if changes should be made to Message Signatures) My preference 
would've been to stop at 2, but the consensus has not been in favor of 
expanding the scope of use cases served by DPoP.

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D=zerocontent=593dd17a-bb93-449b-8126-3b72052d76b2]ᐧ
___
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

[Justin Richer]

I wanted to jump back to the top of the thread to point out something that 
seems to be getting missed:


This is not a call for adoption of HTTP Message Signatures. That document 
already exists in the HTTP WG and will be published as an RFC from that group. 
If you want to have discussions  about  how the HTTP Message Signatures 
specification works, come  to the HTTP working group for those  discussions.

This is a call for adoption of an OAuth application of the HTTP Message 
Signatures spec. Signatures will exist with or without the OAuth WG’s use of 
it, and I would argue that people are going to attach OAuth access  tokens to 
requests  using HTTP Message Signatures whether or not  the OAuth WG picks up 
the work. The question is whether those  applications are going to be isolated 
profiles and silos, like they are today, or whether there can be one way to use 
them together across different systems.

My recommendation is that  the OAuth WG define how exactly HTTP Message 
Signatures should be  used  with OAuth, which is what  this proposal is  for.

 — Justin


> On Oct 6, 2021, at 5:01 PM, Rifaat Shekh-Yusef  
> wrote:
> 
> 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

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

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

[Justin Richer]

> On Oct 14, 2021, at 8:47 AM, Warren Parad  
> wrote:
> 
> I feel like there are a bunch of pieces of the implementation fundamentally 
> missing here, so we are back to, as it is right now, the draft isn't 
> sufficient.

Of course the draft isn’t sufficient for  publication — that’s what the call 
for adoption is all about! It’s not meant to say “this is done, let’s ship it”, 
it’s meant  to say “this is an idea, let’s finish it in the WG”.

> What prevents the signature from being used without this RFC?

I’m not sure what you’re asking here. HTTP Message Signatures  can be  used 
without the OAuth-specific RFC. Someone could also use HTTP Signatures with 
OAuth tokens without following anything from the OAuth WG. There are people 
doing that today in the wild, using the  predecessors  of the  HTTP Message 
Signatures draft and their own grafting.

> How do you do expect the symmetric key exchange to be oauth compliant?

I can think of a number of approaches that would work: Pre-registration of 
keys, key derivation functions, cloud key escrow systems — these are things 
that the OAuth profile of HTTP Signatures would have to answer, as I laid out 
in my presentation.

> How does the RS know that there is supposed to be a signature, if the client 
> doesn't provide it?

The same way that it knows there’s supposed to be a particular MTLS certificate 
or DPoP Proof today — the token metadata. The RS can get that through 
introspection, through something in the token itself (like the JWT “cnf” 
claim), or some other internal system. 

 — Justin

> 
>   
> Warren Parad
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement Authress 
> .
> 
> 
> On Wed, Oct 13, 2021 at 11:55 PM Richard Backman, Annabelle 
> mailto:richa...@amazon.com>> wrote:
>> If keeping DPoP simple means we have to have come up with 10 different 
>> variants to handle all the different cases that it doesn't support, then it 
>> isn't keeping it simple, it is just pushing the problem forward to the 
>> implementers to figure out which set of RFCs to implement.
> 
> I'm hoping we can stop at 3: mTLS, DPoP, and Justin's draft. If someone has 
> use cases that aren't covered by one or more of those, they should bring 
> those up so we can discuss them and decide what changes are warranted. 
> (Either here, or in HTTPbis if changes should be made to Message Signatures) 
> My preference would've been to stop at 2, but the consensus has not been in 
> favor of expanding the scope of use cases served by DPoP.
> 
> 
>> If there are really so many cases, then I think we need to focus on 
>> recreating PoP in an extensible way that allows the DPoP to sit on top, and 
>> other RFCs to be layered in without a bunch of RFCs to all have competing 
>> semantics.
> 
> This is what we are doing with Message Signatures. We're providing a general 
> purpose signature mechanism, which higher-level protocols can build on.
> 
> 
>> Here's a great example. I think having an additional header is unjustified, 
>> DPoP, Signature, or whatever you want to call it. But the only thing more 
>> unjustified than that is having different headers for different 
>> implementations of PoP. We can start with a new Draft that just says, PoP 
>> header is X, end of story, might as well call it Authorization-Extra-Info, 
>> and then layer in what you want in there.
> 
> I can see the argument for DPoP including the proof in the `Authorization` 
> header field, since the proof is intrinsically related to the access token 
> and request authorization – not making a judgement on that, as this is the 
> wrong thread and I don't have a horse in that race. Packing everything into a 
> single header field doesn't make sense for Message Signatures, since they may 
> or may not have anything to do with request authorization, access tokens, or 
> anything of the sort. Additionally, the use of separate `Signature-Input` and 
> `Signature` header fields allows us to have a very simple field syntax using 
> Structured Field Values for HTTP 
> , and makes it easy for 
> intermediaries to chain signatures. (E.g., a reverse proxy might add an 
> `X-Forwarded-For` header field, and add a Message Signature covering that 
> header field plus the PoP signature included by the client.) …and I'll stop 
> there lest we dive into topics for the HTTPbis WG.
> 
> —
> Annabelle Backman (she/her)
> richa...@amazon.com 
> 
> 
> 
> 
>> On Oct 13, 2021, at 12:01 PM, Warren Parad > > 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.
>> 
>> 
>> If keeping DPoP simple means we have to have come up with 10 different 
>> variants to handle all the different cases that it doesn't support, then it 
>> isn't keeping it 

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

[Justin Richer]

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

[Justin Richer]

Thanks for the clarification, though I certainly disagree with your conclusion.

If you have additional outstanding concerns with the HTTP Sig document, 
Annabelle and I would welcome your feedback and engagement in HTTP to ensure 
those are addressed. :)

Thanks,
 — Justin

> On Oct 6, 2021, at 5:24 PM, Dick Hardt  wrote:
> 
> I meant it is not yet adopted as an RFC. 
> 
> To be clear, I think you are doing great work on the HTTP Sig doc, and a 
> number of concerns I have with HTTP signing have been addressed => I just 
> think that doing work in the OAuth WG on a moving and unproven draft in the 
> HTTP WG is not a good use of resources in the OAuth WG at this time.
> 
> 
> ᐧ
> 
> On Wed, Oct 6, 2021 at 2:20 PM Justin Richer  <mailto:jric...@mit.edu>> wrote:
> > HTTP Sig looks very promising, but it has not been adopted as a draft
> 
> Just to be clear, the HTTP Sig draft is an official adopted document of the 
> HTTP Working Group since about a year ago. I would not have suggested we 
> depend on it for a document within this WG otherwise.
> 
>  — Justin
> 
>> On Oct 6, 2021, at 5:08 PM, Dick Hardt > <mailto:dick.ha...@gmail.com>> wrote:
>> 
>> I am not supportive of adoption of this document at this time. 
>> 
>> I am supportive of the concepts in the document. Building upon existing, 
>> widely used, proven security mechanisms gives us better security.
>> 
>> HTTP Sig looks very promising, but it has not been adopted as a draft, and 
>> as far as I know, it is not widely deployed.
>> 
>> We should wait to do work on extending HTTP Sig for OAuth until it has 
>> stabilized and proven itself in the field. We have more than enough work to 
>> do in the WG now, and having yet-another PoP mechanism is more likely to 
>> confuse the community at this time.
>> 
>> An argument to adopt the draft would be to ensure HTTP Sig can be used in 
>> OAuth.
>> Given Justin and Annabelle are also part of the OAuth community, I'm sure 
>> they will be considering how HTTP Sig can apply to OAuth, so the overlap is 
>> serving us already.
>> 
>> /Dick
>> 
>> 
>> ᐧ
>> 
>> On Wed, Oct 6, 2021 at 2:04 PM Aaron Parecki > <mailto:aa...@parecki.com>> wrote:
>> I support adoption of this document.
>> 
>> - Aaron
>> 
>> On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef > <mailto:rifaat.s.i...@gmail.com>> wrote:
>> 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/ 
>> <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 
>> <https://www.ietf.org/mailman/listinfo/oauth>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth 
>> <https://www.ietf.org/mailman/listinfo/oauth>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth 
>> <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

[Justin Richer]

> HTTP Sig looks very promising, but it has not been adopted as a draft

Just to be clear, the HTTP Sig draft is an official adopted document of the 
HTTP Working Group since about a year ago. I would not have suggested we depend 
on it for a document within this WG otherwise.

 — Justin

> On Oct 6, 2021, at 5:08 PM, Dick Hardt  wrote:
> 
> I am not supportive of adoption of this document at this time. 
> 
> I am supportive of the concepts in the document. Building upon existing, 
> widely used, proven security mechanisms gives us better security.
> 
> HTTP Sig looks very promising, but it has not been adopted as a draft, and as 
> far as I know, it is not widely deployed.
> 
> We should wait to do work on extending HTTP Sig for OAuth until it has 
> stabilized and proven itself in the field. We have more than enough work to 
> do in the WG now, and having yet-another PoP mechanism is more likely to 
> confuse the community at this time.
> 
> An argument to adopt the draft would be to ensure HTTP Sig can be used in 
> OAuth.
> Given Justin and Annabelle are also part of the OAuth community, I'm sure 
> they will be considering how HTTP Sig can apply to OAuth, so the overlap is 
> serving us already.
> 
> /Dick
> 
> 
> ᐧ
> 
> On Wed, Oct 6, 2021 at 2:04 PM Aaron Parecki  > wrote:
> I support adoption of this document.
> 
> - Aaron
> 
> On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef  > wrote:
> 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 
> 
> ___
> 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] Adding the option to use server-supplied nonces to DPoP

[Justin Richer]

Hi Mike, thanks for this writeup and bringing this attack surface to the 
attention of the group! I would like to also discuss how this attack and 
solution could be applied to the proposed HTTP Message Signatures based draft 
for OAuth 2:

https://www.ietf.org/archive/id/draft-richer-oauth-httpsig-00.html 


The generic HTTP Message Signatures draft already includes a “nonce” parameter 
that can be used with the signature, so no new fields need to be defined:

https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-06.html#section-2.3.1-4.3
 


However, the OAuth2 application draft doesn’t currently do anything special 
with this parameter. If I’m reading this PR for DPoP and the surrounding issues 
correctly, then I believe the one missing piece is adding the `nonce=…` portion 
to the `WWW-Authenticate` response header, and requiring the client to use that 
on the next request. The OAuth2-httpsig draft doesn’t define a use of this 
header, yet, but I could see something similar happening there.

However, I’m also wondering if this is something we should bring to the HTTP 
working group and have something in the full HTTP Message Signatures draft. 
This draft doesn’t deal with the `Authorization` or `WWW-Authenticate` headers, 
but it does define an `Accept-Signature` header to signal required parameters 
and signed components, for exactly this kind of negotiation. The OAuth2-httpsig 
draft could simply direct the AS/RS to return this `Accept-Signature` header 
with a nonce field in order to cause the client to sign subsequent requests 
using the server-provided nonce.

What are your thoughts on these proposals?

 — Justin

> On Sep 17, 2021, at 1:03 PM, Mike Jones 
>  wrote:
> 
> 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.
> Introducing a new phishing technique for compromising Office 365 accounts 
> (o365blog.com) 
> 

Re: [OAUTH-WG] OAuth Interim Meetings

[Justin Richer]

I would like to present the proposed HTTP signatures draft, and separately I 
think it would also be beneficial to the OAuth wg to present an update on the 
progress of GNAP. 

-Justin

From: OAuth [oauth-boun...@ietf.org] on behalf of Rifaat Shekh-Yusef 
[rifaat.s.i...@gmail.com]
Sent: Saturday, September 4, 2021 11:22 AM
To: oauth
Subject: [OAUTH-WG] OAuth Interim Meetings

All,

We would like to start a new series of interim meetings later in September.
Please, let us know if you would like to present during one of these meetings.

Regards,
 Rifaat & Hannes

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

Re: [OAUTH-WG] RAR 05 - Token response with sensitive data in draft-ietf-oauth-rar-05

[Justin Richer]

This is a fair point... The privacy and security considerations talk about this 
a bit as I recall, but likely need to in more depth and specificity. This is an 
intentional message channel to the client from the AS, but if the AS is blindly 
sending all information it might be saying more than it means to say to an 
entity that doesn't need that detail to function. Scopes have similar issues, 
but this structure adds more opportunities for mistakes just due to the 
possible increased complexity. 

-Justin

From: OAuth [oauth-boun...@ietf.org] on behalf of Jacob Ideskog 
[jacob.ides...@curity.io]
Sent: Friday, September 3, 2021 10:42 AM
To: oauth
Subject: [OAUTH-WG] RAR 05 - Token response with sensitive data in 
draft-ietf-oauth-rar-05

Hi all,

I have a question about section 7.0 and 7.1 in draft-ietf-oauth-rar-05 that 
describes the token response.

The authorization_details values could be sensitive in their nature. The 
example in section 7.1 highlights this nicely. The accounts array is empty when 
the client requests it, but is enriched by the AS and returned to the client in 
the token response.

This means that the AS may leak potentially sensitive information to the client 
in a new place. Before this was only possible in the ID Token or UserInfo or if 
the AS returned a JWT as an access token which the client popped open (even 
though it shouldn't).

I understand that the spec considers this an option for the AS to enrich or 
not. I think the enrichment is good and necessary, but with the side-effect of 
it ending up in the token response it becomes an issue.

Is the token response a mirror of the authorization_details claim in the 
corresponding access token, or can it be a masked version?

Perhaps the security considerations section should be updated with a statement 
with regards to the fact that the client may see claim data only intended for 
the RS?

Regards
Jacob Ideskog



--
Jacob Ideskog
CTO
Curity AB
---
Sankt Göransgatan 66, Stockholm, Sweden
M: +46 70-2233664
ja...@curity.io
curity.io
---

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

Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663)

[Justin Richer]

I personally don’t agree with this errata. Token Revocation was never meant to 
act as a protected resource, but rather as a function of the AS. The client is 
known to the AS and so authentication is expected here.

 — Justin

> On Aug 22, 2021, at 5:14 AM, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC7009,
> "OAuth 2.0 Token Revocation".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6663
> 
> --
> Type: Technical
> Reported by: Ashvin Narayanan 
> 
> Section: 2.1
> 
> Original Text
> -
> The client constructs the request by including the following
>   parameters using the "application/x-www-form-urlencoded" format in
>   the HTTP request entity-body:
> 
>   token   REQUIRED.  The token that the client wants to get revoked.
> 
>   token_type_hint  OPTIONAL.  A hint about the type of the token
>   submitted for revocation.  Clients MAY pass this parameter in
>   order to help the authorization server to optimize the token
>   lookup.  If the server is unable to locate the token using
>   the given hint, it MUST extend its search across all of its
>   supported token types.  An authorization server MAY ignore
>   this parameter, particularly if it is able to detect the
>   token type automatically.  This specification defines two
>   such values:
> 
>   * access_token: An access token as defined in [RFC6749],
> Section 1.4
> 
>   * refresh_token: A refresh token as defined in [RFC6749],
> Section 1.5
> 
>   Specific implementations, profiles, and extensions of this
>   specification MAY define other values for this parameter
>   using the registry defined in Section 4.1.2.
> 
>   The client also includes its authentication credentials as described
>   in Section 2.3. of [RFC6749].
> 
>   For example, a client may request the revocation of a refresh token
>   with the following request:
> 
> POST /revoke HTTP/1.1
> Host: server.example.com
> Content-Type: application/x-www-form-urlencoded
> Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
> 
> token=45ghiukldjahdnhzdauz_type_hint=refresh_token
> 
>   The authorization server first validates the client credentials (in
>   case of a confidential client) and then verifies whether the token
>   was issued to the client making the revocation request.  If this
>   validation fails, the request is refused and the client is informed
>   of the error by the authorization server as described below.
> 
> Corrected Text
> --
> The client calls the revocation endpoint using an HTTP
>   POST [RFC7231] request with the following parameters sent as
>   "application/x-www-form-urlencoded" data in the request body:
> 
>   token   REQUIRED.  The token that the client wants to get revoked.
> 
>   token_type_hint  OPTIONAL.  A hint about the type of the token
>   submitted for revocation.  Clients MAY pass this parameter in
>   order to help the authorization server to optimize the token
>   lookup.  If the server is unable to locate the token using
>   the given hint, it MUST extend its search across all of its
>   supported token types.  An authorization server MAY ignore
>   this parameter, particularly if it is able to detect the
>   token type automatically.  This specification defines two
>   such values:
> 
>   * access_token: An access token as defined in [RFC6749],
> Section 1.4
> 
>   * refresh_token: A refresh token as defined in [RFC6749],
> Section 1.5
> 
>   Specific implementations, profiles, and extensions of this
>   specification MAY define other values for this parameter
>   using the registry defined in Section 4.1.2.
> 
>   The client MUST also include in the request, the access token it received 
>   from the authorization server. It must do so in the same way as it  would  
>   when accessing a protected resource, as describe in [RFC6749], Section 7.
> 
>   The following is a non-normative example request in which the client uses 
>   its access token to revoke the associated refresh token:
> 
> POST /revoke HTTP/1.1
> Host: server.example.com
> Content-Type: application/x-www-form-urlencoded
> Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW
> 
> token=45ghiukldjahdnhzdauz_type_hint=refresh_token
> 
>   The following is a non-normative example request in which the client uses 
>   its access token to revoke the same access token:
> 
> POST /revoke HTTP/1.1
> Host: server.example.com
> Content-Type: application/x-www-form-urlencoded
> Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW
> 
> token=czZCaGRSa3F0MzpnWDFmQmF0M2JW_type_hint=access_token
> 
>   The 

Re: [OAUTH-WG] DPoP 03 - introspection - token_type?

[Justin Richer]

I think it can be a really simple mention as suggested here. I put it in a pull 
request:

https://github.com/danielfett/draft-dpop/pull/72 
<https://github.com/danielfett/draft-dpop/pull/72>

I was actually surprised to see that the `token_type` value wasn’t already 
required to be DPoP (case insensitive) so I added that, too.

 — Justin

> On Aug 16, 2021, at 6:20 PM, Brian Campbell  
> wrote:
> 
> Yeah, I believe that logically follows from the definition of token_type in 
> introspection and RFC 6749. 
> 
> Do y'all think it needs to be mentioned in DPoP though? I'm not sure, to be 
> honest. 
> 
> 
> 
> On Mon, Aug 16, 2021 at 5:46 AM Justin Richer  <mailto:jric...@mit.edu>> wrote:
> Yes, it should be. Good catch. 
> 
> -Justin
> 
> From: OAuth [oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] on 
> behalf of Vladimir Dzhuvinov [vladi...@connect2id.com 
> <mailto:vladi...@connect2id.com>]
> Sent: Sunday, August 15, 2021 12:02 PM
> To: oauth@ietf.org <mailto:oauth@ietf.org>
> Subject: [OAUTH-WG] DPoP 03 - introspection - token_type?
> 
> The token introspection RFC defines the optional "token_type" member and
> I just noticed that draft-ietf-oauth-dpop-03 doesn't mention it.
> 
> https://datatracker.ietf.org/doc/html/rfc7662#section-2.2 
> <https://datatracker.ietf.org/doc/html/rfc7662#section-2.2>
> 
> Would it be sensible to mention that if the "token_type" gets set in a
> introspection response, it must be "DPoP"?
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-03#section-6.2 
> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-03#section-6.2>
> 
> Vladimir
> 
> --
> Vladimir Dzhuvinov
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth 
> <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] DPoP 03 - introspection - token_type?

[Justin Richer]

Yes, it should be. Good catch. 

-Justin

From: OAuth [oauth-boun...@ietf.org] on behalf of Vladimir Dzhuvinov 
[vladi...@connect2id.com]
Sent: Sunday, August 15, 2021 12:02 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] DPoP 03 - introspection - token_type?

The token introspection RFC defines the optional "token_type" member and
I just noticed that draft-ietf-oauth-dpop-03 doesn't mention it.

https://datatracker.ietf.org/doc/html/rfc7662#section-2.2

Would it be sensible to mention that if the "token_type" gets set in a
introspection response, it must be "DPoP"?

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-03#section-6.2

Vladimir

--
Vladimir Dzhuvinov


___
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 Signatures

[Justin Richer]

Needless to say, but as the author of both this draft and the draft that it 
would replace, I am in favor of adoption of this document. There are still a 
lot of open questions to answer — such as key introduction and management 
practices — and I think there is a lot of power in the intersection of the 
OAuth and HTTPSig spaces.

 — Justin

> On Jul 16, 2021, at 12:31 PM, Rifaat Shekh-Yusef  
> wrote:
> 
> All,
> 
> This is a call for adoption for the OAuth Proof of Possession Tokens with 
> HTTP Message Signatures draft as a WG document:
> https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/ 
> 
> 
> Please, provide your feedback on the mailing list by July 30th.
> 
> 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 and implicit/hybrid flows

[Justin Richer]

Binding the access token is not required for FAL3. FAL has nothing to say about 
access tokens:

https://pages.nist.gov/800-63-FAQ/#q-c8 
<https://pages.nist.gov/800-63-FAQ/#q-c8>

FAL3 is about presenting proof of a key representing the user alongside an 
assertion representing the user. In OIDC this would mean something like the ID 
token having a key identifier inside of it and the RP prompting the user for 
the key. This has nothing to do with access tokens, or even calling an identity 
API like a UserInfo Endpoint. DPoP doesn’t help with any of that since DPoP is 
about access tokens.

 — Justin

> On Jul 16, 2021, at 1:18 PM, John Bradley  wrote:
> 
> Binding the token would be required for OAuth or Connect to meet the SP800-63 
> FAL3 requirements. 
> 
> Something like DPoP might work.  I don't think DPoP itself should directly 
> add support. 
> 
> I don't know if people really care about FAL3,  unfourtunatly the simple 
> solution of using token-binding seems quite dead in browsers. 
> 
> John B. 
> 
> 
> 
> 
> 
> On Fri, Jul 16, 2021, 12:29 PM Justin Richer  <mailto:jric...@mit.edu>> wrote:
> I personally hope we don’t. JAR already gives us signed requests at the 
> authorization endpoint, though the last piece would be binding the token. 
> 
>  — Justin
> 
> > On Jul 15, 2021, at 6:47 PM, Dmitry Telegin 
> >  > <mailto:40backbase@dmarc.ietf.org>> wrote:
> > 
> > Hi,
> > 
> > The DPoP spec currently defines how to obtain a DPoP-bound token via token 
> > endpoint invocations (namely, authorization_code and refresh_token grants). 
> > But it is also possible to obtain access token prior to code-to-token 
> > exchange, via OAuth implicit/hybrid flows.
> > 
> > Do we have any plans to support DPoP in authorization endpoint (in addition 
> > to token endpoint) and implicit/hybrid flows? Is yes, what it might look 
> > like? a "dpop" request parameter or a "DPoP" header?
> > 
> > Regards,
> > Dmitry
> > ___
> > OAuth mailing list
> > OAuth@ietf.org <mailto:OAuth@ietf.org>
> > https://www.ietf.org/mailman/listinfo/oauth 
> > <https://www.ietf.org/mailman/listinfo/oauth>
> 
> ___
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth 
> <https://www.ietf.org/mailman/listinfo/oauth>

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

Re: [OAUTH-WG] DPoP and implicit/hybrid flows

[Justin Richer]

I personally hope we don’t. JAR already gives us signed requests at the 
authorization endpoint, though the last piece would be binding the token. 

 — Justin

> On Jul 15, 2021, at 6:47 PM, Dmitry Telegin 
>  wrote:
> 
> Hi,
> 
> The DPoP spec currently defines how to obtain a DPoP-bound token via token 
> endpoint invocations (namely, authorization_code and refresh_token grants). 
> But it is also possible to obtain access token prior to code-to-token 
> exchange, via OAuth implicit/hybrid flows.
> 
> Do we have any plans to support DPoP in authorization endpoint (in addition 
> to token endpoint) and implicit/hybrid flows? Is yes, what it might look 
> like? a "dpop" request parameter or a "DPoP" header?
> 
> Regards,
> Dmitry
> ___
> 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] RAR WGLC comment

[Justin Richer]

I agree with this change, but with one caveat (already expressed in the PR) 
that an AS should be aware that clients can now send scope, resource, and 
authorization_details parameters together on a single request. It’s not up to 
RAR to define how all of those fit together, but an AS implementing RAR is 
going to need to know that it’s going to have to deal with this potentially 
unwieldy mix. 

 — Justin

> On Jun 20, 2021, at 6:54 AM, Torsten Lodderstedt 
>  wrote:
> 
> Hi all,
> 
> I created a PR for this change. 
> 
> https://github.com/oauthstuff/draft-oauth-rar/pull/76 
> 
> 
> Please review and comment/approve. 
> 
> best regards,
> Torsten. 
> 
>> Am 19.06.2021 um 17:01 schrieb Filip Skokan > >:
>> 
>> I support such change.
>> 
>> Odesláno z iPhonu
>> 
>>> 19. 6. 2021 v 15:36, Torsten Lodderstedt 
>>> >> >:
>>> 
>>> 
>>> Hi Brian,
>>> 
>>> the idea was to use resource indicators as convenient short cut to support 
>>> audience restricted access tokens. However, I agree this can be achieved by 
>>> specifying authorization details in the token request as well.
>>> 
>>> So I‘m fine with dropping resource indicators for RAR at all. This means 
>>> RAR on one hand and scopes + resource indicators on the other hand are 
>>> clearly decoupled and independent.
>>> 
>>> best regards,
>>> Torsten.
>>> 
 Am 18.06.2021 um 20:13 schrieb Brian Campbell 
 >>> >:
 
 
 In my reading and understanding of the text and intent, the content and 
 meaning of a particular authorization details object are fully governed by 
 its "type". And while the draft provides a set of common data elements 
 intended to be usable across different types (locations, actions, 
 datatypes, identifier, privileges) a specific type is free to define 
 whatever suits its needs. A type definition may or may not involve those 
 common elements and could even use the same name(s) with different meaning 
 or structure. 
 
 So, while I understand the motivation behind the RFC8707 resource 
 parameter being usable in a token request to make the AS filter, the 
 included authorization details of the resultant token based on the 
 "locations" element[1], I'm a bit concerned about a layering problem here. 
 The authorization details objects of the grant might not contain a 
 "locations" element or might have one with a different meaning or 
 structure.  
 
 The draft also describes using the authorization_details token request 
 parameter to specify the authorization details a client wants the AS to 
 assign to a particular access token[2]. So the problematic resource 
 parameter behaviour is also kind of redundant. I think maybe it should be 
 removed.
 
 [*] described in 
 https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-6.2 
 
  and mentioned at 
 https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-1-8 
 
  and in 
 https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#section-7-1 
 
 
 [2] 
 https://www.ietf.org/archive/id/draft-ietf-oauth-rar-05.html#name-token-request
  
 
 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

Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (6613)

[Justin Richer]

I personally agree with this report, the new proposed wording is better.

OAuth 2.1 editors, please take note!

 — Justin

> On Jun 22, 2021, at 8:01 PM, Benjamin Kaduk  wrote:
> 
> This looks correct to me; could the authors/WG please confirm?
> 
> Thanks,
> 
> Ben
> 
> On Thu, Jun 17, 2021 at 12:04:37PM -0700, RFC Errata System wrote:
>> The following errata report has been submitted for RFC6749,
>> "The OAuth 2.0 Authorization Framework".
>> 
>> --
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid6613
>> 
>> --
>> Type: Editorial
>> Reported by: Daniel Barclay 
>> 
>> Section: 3.3
>> 
>> Original Text
>> -
>> The value of the scope parameter is expressed as a list of space-delimited, 
>> case-sensitive strings
>> 
>> Corrected Text
>> --
>> The value of the scope parameter is expressed as a space-delimited list of 
>> case-sensitive strings
>> 
>> Notes
>> -
>> The original/current seems to be a bit confusing.
>> 
>> The value is not a collection of space-delimited strings (whatever a 
>> "space-delimited string" would be), but it a space-delimited (representation 
>> of) a collection of strings.
>> 
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party  
>> can log in to change the status and edit the report, if necessary. 
>> 
>> --
>> RFC6749 (draft-ietf-oauth-v2-31)
>> --
>> Title   : The OAuth 2.0 Authorization Framework
>> Publication Date: October 2012
>> Author(s)   : D. Hardt, Ed.
>> Category: PROPOSED STANDARD
>> Source  : Web Authorization Protocol
>> Area: Security
>> Stream  : IETF
>> Verifying Party : IESG
> 
> ___
> 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-WG] Fwd: New Version Notification for draft-richer-oauth-httpsig-00.txt

[Justin Richer]

As promised at the last interim meeting, I’ve sat down and put together a first 
strawman for PoP tokens using HTTP Message Signatures. As you can see, it’s 
pretty short. I’ve intentionally scoped it down to only pre-registered keys 
(unlike DPoP’s dynamically presented keys), but this could change. I haven’t 
put in the pieces for token key confirmation that would be required for this 
work, which both the MTLS and DPoP drafts have.

 — Justin

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-richer-oauth-httpsig-00.txt
> Date: June 21, 2021 at 11:52:14 AM EDT
> To: "Justin Richer" 
> 
> 
> A new version of I-D, draft-richer-oauth-httpsig-00.txt
> has been successfully submitted by Justin Richer and posted to the
> IETF repository.
> 
> Name: draft-richer-oauth-httpsig
> Revision: 00
> Title:OAuth Proof of Possession Tokens with HTTP Message 
> Signatures
> Document date:2021-06-21
> Group:Individual Submission
> Pages:8
> URL:
> https://www.ietf.org/archive/id/draft-richer-oauth-httpsig-00.txt
> Status: https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/
> Html:   
> https://www.ietf.org/archive/id/draft-richer-oauth-httpsig-00.html
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-richer-oauth-httpsig
> 
> 
> Abstract:
>   This extension to the OAuth 2.0 authorization framework defines a
>   method for using HTTP Message Signatures to bind access tokens to
>   keys held by OAuth 2.0 clients.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 

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

Re: [OAUTH-WG] Can a client send the Authorization Request?

[Justin Richer]

So the text of RFC8705 is fixed, it could eventually be updated and obsoleted 
by another RFC, but that would take a new effort from the WG to consider it 
worthwhile. Not likely to happen for an implementation note like this, 
unfortunately. But OAuth 2.1 is meant to account for all of the different 
extensions and profiles of OAuth that are already out there, so it’s a really 
good place to discuss that kind of thing.

 — Justin

> On May 27, 2021, at 3:13 AM, A. Rothman  wrote:
> 
> Maybe also worth mentioning something in RFC 8705, being the "OAuth MTLS" 
> spec, along with the main OAuth 2.1 spec... I don't know how you'll arrange 
> the RFCs next time around :-)
> 
> On 5/26/21 2:43 AM, Aaron Parecki wrote:
>> Honestly it didn't even occur to me that someone would try this, since the 
>> entire point of the authorization endpoint is that it's the thing the user's 
>> browser talks to. Adding MTLS just means you're going to have to send the 
>> user to some other endpoint instead, which is then effectively acting as the 
>> authorization endpoint anyway. So yeah I could see adding some language 
>> around the authorization endpoint needing to be accessible by the user agent 
>> without MTLS or other funny stuff.
>> 
>> PAR also fits in nicely in that case since the PAR endpoint could be 
>> protected with MTLS since it *is* intended to only be accessible from the 
>> OAuth client.
>> 
>> Aaron
>> 
>> On Tue, May 25, 2021 at 4:38 PM Justin Richer > <mailto:jric...@mit.edu>> wrote:
>> I'm actually wondering if we should add discussion about not putting mtls on 
>> the authorisation endpoint into OAuth 2.1. Aaron et al, thoughts? 
>> 
>> -Justin
>> ____
>> From: A. Rothman [amich...@amichais.net <mailto:amich...@amichais.net>]
>> Sent: Tuesday, May 25, 2021 7:03 PM
>> To: Justin Richer
>> Cc: Sascha Preibisch; IETF oauth WG
>> Subject: Re: [OAUTH-WG] Can a client send the Authorization Request?
>> 
>> Justin,
>> 
>> Thanks for this analysis. It pretty much sums up my own thoughts about this 
>> better than I could have :-)
>> 
>> I just hope I wasn't 'leading the witness' too much... I'll have to 
>> double-check the details to make sure I didn't miss anything, but as I 
>> understand it, that's more or less it.
>> 
>> btw it occurred to me that PAR wouldn't solve this specific problem either - 
>> if I understood correctly, it still ends with the user agent sending an 
>> Authorization Request to the AS, just with PAR-specific parameters instead 
>> of the usual ones... if so, and if the endpoint is still required to use 
>> mTLS, thus needs to be sent by the client... it would just be kicking the 
>> can down the road and violating the PAR spec instead.
>> 
>> Thanks again for your time and explanations,
>> 
>> Amichai
>> 

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

Re: [OAUTH-WG] Can a client send the Authorization Request?

[Justin Richer]

I'm actually wondering if we should add discussion about not putting mtls on 
the authorisation endpoint into OAuth 2.1. Aaron et al, thoughts? 

-Justin

From: A. Rothman [amich...@amichais.net]
Sent: Tuesday, May 25, 2021 7:03 PM
To: Justin Richer
Cc: Sascha Preibisch; IETF oauth WG
Subject: Re: [OAUTH-WG] Can a client send the Authorization Request?

Justin,

Thanks for this analysis. It pretty much sums up my own thoughts about this 
better than I could have :-)

I just hope I wasn't 'leading the witness' too much... I'll have to 
double-check the details to make sure I didn't miss anything, but as I 
understand it, that's more or less it.

btw it occurred to me that PAR wouldn't solve this specific problem either - if 
I understood correctly, it still ends with the user agent sending an 
Authorization Request to the AS, just with PAR-specific parameters instead of 
the usual ones... if so, and if the endpoint is still required to use mTLS, 
thus needs to be sent by the client... it would just be kicking the can down 
the road and violating the PAR spec instead.

Thanks again for your time and explanations,

Amichai

On 5/26/21 1:21 AM, Justin Richer wrote:
It’s different, and I think in this specific case it’s more likely to be less 
secure because of a lot of other red flags that I’m seeing around this 
description.

One, requiring MTLS on all endpoints without thinking through what that 
actually means for developers. This is going to force developers to come up 
with weird workarounds that you don’t anticipate instead of building things 
into the protocol with good expectations and boundaries. I can only guess to 
motivations, but it feels strongly like “TLS is good, MTLS must be better” 
style security architecture decisions, which are almost always wrong.

Two, they’re asking you to break HTTP norms by reading a Location header and 
passing it to another party instead of following it as the HTTP spec says to 
do. Assuming that this location header points to something that isn’t protected 
by MTLS, you have to wonder why they want to put MTLS over the authorization 
endpoint in the first place if you’re chucking someone over to a non-MTLS 
endpoint after that. It’s a weird decision.

Three, there is not a flaw in OAuth that MTLS on this endpoint would fix. There 
are plenty of known downsides and holes in the authorization endpoint, thus the 
invention of PAR and GNAP as mentioned earlier in the thread, but neither of 
these require MTLS and both make use of a specific message on an endpoint 
that’s not the authorization endpoint.

Ultimately, it’s the attitude that bothers me more than the specifics here. It 
might be “secure” in its design, but it’s asking people to do something 
different from what’s specified elsewhere and it hasn’t received any scrutiny 
from a wide community like the PAR and GNAP specs have (and continue to have, 
as neither is fully final yet). They’re doing things off-book to workaround 
problems that they’ve created by trying to be “more secure”, the end result of 
which is more than likely going to make things less secure overall.

 — Justin

On May 25, 2021, at 4:21 PM, A. Rothman 
mailto:amich...@amichais.net>> wrote:


Justin,

Thanks for the clear answer. The distinction you make is indeed exactly the 
point I was asking about.

So I got the first answer, which is that it is not compliant.

Now the follow-up question is whether it is known to be any more or less secure 
than the normal flow, or simply unknown until further analysis is done, or 
dependent on their specific implementation in some way - although afaik they 
use an off-the-shelf standard OAUTH2 server, just expect it to be accessed from 
the client instead of from the user agent, due to their added mTLS requirement 
on the entire server (including the Authorization endpoint).

I'm still not sure what the motive is behind the mTLS requirement, though it's 
possible it just sounded like a good idea at the time to make it 'more secure', 
without realizing there are consequences (like being non-compliant with OAUTH2 
and/or opening new potential attack vectors, if that's also the case - still 
trying to figure that one out). Is there any flaw in OAUTH2 that would require 
such mTLS on this endpoint? Is it worth the risks involved in deviating from 
the normal flow?

Thanks,

Amichai

On 5/25/21 10:54 PM, Justin Richer wrote:
One point, the client doesn’t POST to the authorization endpoint, the resource 
owner’s browser is supposed to POST to the authorization endpoint — it’s an 
important distinction. And in the wild, this is really rare to see in use.

As written, this is not compliant with OAuth2. I agree that this sounds a lot 
like PAR, except for the fact that the URL getting sent back sounds like it’s 
used directly as the redirect. Where PAR sends back a URI to be tacked onto the 
authorization endpoint as a parameter, this is sending back the full URL to

Re: [OAUTH-WG] Can a client send the Authorization Request?

[Justin Richer]

It’s different, and I think in this specific case it’s more likely to be less 
secure because of a lot of other red flags that I’m seeing around this 
description.

One, requiring MTLS on all endpoints without thinking through what that 
actually means for developers. This is going to force developers to come up 
with weird workarounds that you don’t anticipate instead of building things 
into the protocol with good expectations and boundaries. I can only guess to 
motivations, but it feels strongly like “TLS is good, MTLS must be better” 
style security architecture decisions, which are almost always wrong.

Two, they’re asking you to break HTTP norms by reading a Location header and 
passing it to another party instead of following it as the HTTP spec says to 
do. Assuming that this location header points to something that isn’t protected 
by MTLS, you have to wonder why they want to put MTLS over the authorization 
endpoint in the first place if you’re chucking someone over to a non-MTLS 
endpoint after that. It’s a weird decision.

Three, there is not a flaw in OAuth that MTLS on this endpoint would fix. There 
are plenty of known downsides and holes in the authorization endpoint, thus the 
invention of PAR and GNAP as mentioned earlier in the thread, but neither of 
these require MTLS and both make use of a specific message on an endpoint 
that’s not the authorization endpoint.

Ultimately, it’s the attitude that bothers me more than the specifics here. It 
might be “secure” in its design, but it’s asking people to do something 
different from what’s specified elsewhere and it hasn’t received any scrutiny 
from a wide community like the PAR and GNAP specs have (and continue to have, 
as neither is fully final yet). They’re doing things off-book to workaround 
problems that they’ve created by trying to be “more secure”, the end result of 
which is more than likely going to make things less secure overall.

 — Justin

> On May 25, 2021, at 4:21 PM, A. Rothman  wrote:
> 
> Justin,
> 
> Thanks for the clear answer. The distinction you make is indeed exactly the 
> point I was asking about.
> 
> So I got the first answer, which is that it is not compliant.
> 
> Now the follow-up question is whether it is known to be any more or less 
> secure than the normal flow, or simply unknown until further analysis is 
> done, or dependent on their specific implementation in some way - although 
> afaik they use an off-the-shelf standard OAUTH2 server, just expect it to be 
> accessed from the client instead of from the user agent, due to their added 
> mTLS requirement on the entire server (including the Authorization endpoint).
> 
> I'm still not sure what the motive is behind the mTLS requirement, though 
> it's possible it just sounded like a good idea at the time to make it 'more 
> secure', without realizing there are consequences (like being non-compliant 
> with OAUTH2 and/or opening new potential attack vectors, if that's also the 
> case - still trying to figure that one out). Is there any flaw in OAUTH2 that 
> would require such mTLS on this endpoint? Is it worth the risks involved in 
> deviating from the normal flow?
> 
> Thanks,
> 
> Amichai
> 
> On 5/25/21 10:54 PM, Justin Richer wrote:
>> One point, the client doesn’t POST to the authorization endpoint, the 
>> resource owner’s browser is supposed to POST to the authorization endpoint — 
>> it’s an important distinction. And in the wild, this is really rare to see 
>> in use.
>> 
>> As written, this is not compliant with OAuth2. I agree that this sounds a 
>> lot like PAR, except for the fact that the URL getting sent back sounds like 
>> it’s used directly as the redirect. Where PAR sends back a URI to be tacked 
>> onto the authorization endpoint as a parameter, this is sending back the 
>> full URL to send the browser to. In this way, it sounds more like GNAP’s 
>> “redirect” interaction start method, which follows that pattern. 
>> 
>> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-05.html#name-redirect-to-an-arbitrary-ur
>>  
>> <https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-05.html#name-redirect-to-an-arbitrary-ur>
>> 
>> GNAP uses this pattern for both greater security and greater flexibility in 
>> this step — In my opinion it’s basically what PAR would have been if we 
>> hadn’t started with the parameterized authorization endpoint.
>> 
>>  — Justin
>> 
>>> On May 25, 2021, at 11:28 AM, Sascha Preibisch >> <mailto:saschapreibi...@gmail.com>> wrote:
>>> 
>>> Hello Amichai!
>>> 
>>> There could be several reasons why you see that behaviour in your web 
>>> browser. For example:
>>> 
>>> - This RFC suggest

Re: [OAUTH-WG] Can a client send the Authorization Request?

[Justin Richer]

One point, the client doesn’t POST to the authorization endpoint, the resource 
owner’s browser is supposed to POST to the authorization endpoint — it’s an 
important distinction. And in the wild, this is really rare to see in use.

As written, this is not compliant with OAuth2. I agree that this sounds a lot 
like PAR, except for the fact that the URL getting sent back sounds like it’s 
used directly as the redirect. Where PAR sends back a URI to be tacked onto the 
authorization endpoint as a parameter, this is sending back the full URL to 
send the browser to. In this way, it sounds more like GNAP’s “redirect” 
interaction start method, which follows that pattern. 

https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-05.html#name-redirect-to-an-arbitrary-ur
 


GNAP uses this pattern for both greater security and greater flexibility in 
this step — In my opinion it’s basically what PAR would have been if we hadn’t 
started with the parameterized authorization endpoint.

 — Justin

> On May 25, 2021, at 11:28 AM, Sascha Preibisch  
> wrote:
> 
> Hello Amichai!
> 
> There could be several reasons why you see that behaviour in your web 
> browser. For example:
> 
> - This RFC suggests sending a request to the authorization server, get a 
> session specific URL back which can be forwarded to the authorization server 
> via the browser. This is OAuth PAR (Pushed Authorization Request):  
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par 
> . I have also 
> made a video about this flow, maybe it matches what you are seeing on your 
> web server: https://www.youtube.com/watch?v=fE11HJRCL-k 
> 
> 
> - In addition RFC 6749 also allows a client to POST to the authorization 
> endpoint
> 
> I hope this helps,
> Sascha
> 
> On Tue, 25 May 2021 at 08:00, A. Rothman  > wrote:
> Hi,
> 
> In RFC 6749 section 4.1, the Authorization Code Grant flow starts with:
> 
> (A)  The client initiates the flow by directing the resource owner's
>  user-agent to the authorization endpoint.  The client includes
>  its client identifier, requested scope, local state, and a
>  redirection URI to which the authorization server will send the
>  user-agent back once access is granted (or denied).
> 
> (B)  The authorization server authenticates the resource owner (via
>  the user-agent) and establishes whether the resource owner
>  grants or denies the client's access request.
> 
> 
>  From this, and most explanation I've seen, I understand that the client 
> (e.g. my web server) is supposed to prepare the Authorization Request 
> URL but instead of sending it to the Authorization Server, it redirects 
> the user agent which is the one actually making the HTTP request. It 
> then goes back and forth with the Authorization Server (with HTML and 
> posting forms and whatnot), and eventually receives the Authorization 
> Response which redirects the user agent back to the client's callback 
> URL with the included code parameter. So as far as the Authorization 
> Request/Response flow goes, there is no direct communications between 
> the client and Authorization Server up to this point (before the token 
> exchange).
> 
> 1. Basically correct so far?
> 
> Now, I've encountered a provider that works slightly differently (but 
> still with the Authorization Code Grant scheme): the client (my web 
> server) is supposed to send the Authorization Request directly to the 
> Authorization Server, then receive some opaque URL, and redirect the 
> user agent to there to continue the process. I suppose this URL is 
> equivalent to one from the middle of the 'back and forth' in the 
> previous scenario. The rest of the flow continues the same. So 
> basically, the initial redirect response and HTTP request are reversed - 
> instead of first redirect and then request (from user agent), there is 
> first the request (from client)  and then redirect.
> 
> So the questions are:
> 
> 2. Is this compliant with the RFC?
> 
> 3. Is it any less secure? (even if not strictly compliant with the RFC's 
> flow, it may still be secure...)
> 
> 4. If it is less secure, what are the possible vulnerabilities or 
> attacks made possible here that are mitigated in the original flow?
> 
> 5. They claim the change is made because they insist on using MTLS on 
> all Authentication Server endpoints, including the Authorization 
> Endpoint. Does this make sense? Does it add security, or is the OAUTH2 
> flow just as secure without MTLS on the Authorization Endpoint?
> 
> Thanks,
> 
> Amichai
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 

Re: [OAUTH-WG] HTTP Message Signing and OAuth PoP

[Justin Richer]

Hi Rifaat,

If you’d like to keep the current mondays-at-noon-ET schedule I can support 
that. Any Monday this month would work for me, and I’ve reached out to 
Annabelle so hopefully she can join as well. I don’t know if I’d be able to 
have the rewrite of the OAuth PoP draft in hand by any of those dates, but the 
concept is straightforward enough to discuss with or without a draft.

Thanks,
 — Justin

> On Apr 29, 2021, at 2:51 PM, Rifaat Shekh-Yusef  
> wrote:
> 
> Hi Justin,
> 
> Thanks for the update on this,
> We would be happy to schedule an interim meeting to discuss this. 
> Do you have a date in mind?
> 
> Regards,
>  Rifaat & Hannes
> 
> 
> 
> 
> 
> On Thu, Apr 29, 2021 at 11:34 AM Justin Richer  <mailto:jric...@mit.edu>> wrote:
> Many of you will remember an old draft that I was the editor of that defined 
> OAuth proof of possession methods using HTTP Message Signing. When writing 
> that draft I invented my own scheme because there wasn’t an existing HTTP 
> message signature standard that was robust enough for our use cases. I’m 
> happy to say that the landscape has changed: Annabelle Backman and I have 
> been working in the HTTP Working Group on HTTP Message Signatures, a 
> general-purpose HTTP signing draft with a lot of power and a lot of 
> flexibility. There’s even a relatively straightforward way to map 
> JOSE-defined signature algorithms into this (even though, to be clear, it is 
> not JOSE-based). The current draft is here:
> 
> https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html 
> <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html>
> 
> This draft has gone through a lot of change in the last few months, but we, 
> the editors, believe that it’s at a fairly stable place in terms of the core 
> functioning of the protocol now. It’s not finished yet, but we think that any 
> changes that come from here will be smaller in scope, more of a cleanup and 
> clarification than the deep invasive surgery that has happened up until now.
> 
> One of the things about this draft is that, on its own, it is not sufficient 
> for a security protocol. By design it needs some additional details on where 
> to get key materials, how to negotiate algorithms, what fields need to be 
> covered by the signature, etc. I am proposing that we in the OAuth WG replace 
> the long-since-expired OAuth PoP working group draft with a new document 
> based on HTTP Message Signatures. I believe that this document can be 
> relatively short and to the point, given that much of the mechanics would be 
> defined in the HTTP draft. If this is something we would like to do in the 
> WG, I am volunteering to write the updated draft.
> 
> I also want to be very clear that I still believe that this lives beside 
> DPoP, and that DPoP should continue even as we pick this back up. In fact, I 
> think that this work would take some pressure off of DPoP and allow it to be 
> the streamlined point solution that it was originally intended to be.
> 
> If the chairs would like, I would also be happy to discuss this at an interim 
> meeting.
> 
>  — Justin
> ___
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth 
> <https://www.ietf.org/mailman/listinfo/oauth>

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

[OAUTH-WG] HTTP Message Signing and OAuth PoP

[Justin Richer]

Many of you will remember an old draft that I was the editor of that defined 
OAuth proof of possession methods using HTTP Message Signing. When writing that 
draft I invented my own scheme because there wasn’t an existing HTTP message 
signature standard that was robust enough for our use cases. I’m happy to say 
that the landscape has changed: Annabelle Backman and I have been working in 
the HTTP Working Group on HTTP Message Signatures, a general-purpose HTTP 
signing draft with a lot of power and a lot of flexibility. There’s even a 
relatively straightforward way to map JOSE-defined signature algorithms into 
this (even though, to be clear, it is not JOSE-based). The current draft is 
here:

https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html 


This draft has gone through a lot of change in the last few months, but we, the 
editors, believe that it’s at a fairly stable place in terms of the core 
functioning of the protocol now. It’s not finished yet, but we think that any 
changes that come from here will be smaller in scope, more of a cleanup and 
clarification than the deep invasive surgery that has happened up until now.

One of the things about this draft is that, on its own, it is not sufficient 
for a security protocol. By design it needs some additional details on where to 
get key materials, how to negotiate algorithms, what fields need to be covered 
by the signature, etc. I am proposing that we in the OAuth WG replace the 
long-since-expired OAuth PoP working group draft with a new document based on 
HTTP Message Signatures. I believe that this document can be relatively short 
and to the point, given that much of the mechanics would be defined in the HTTP 
draft. If this is something we would like to do in the WG, I am volunteering to 
write the updated draft.

I also want to be very clear that I still believe that this lives beside DPoP, 
and that DPoP should continue even as we pick this back up. In fact, I think 
that this work would take some pressure off of DPoP and allow it to be the 
streamlined point solution that it was originally intended to be.

If the chairs would like, I would also be happy to discuss this at an interim 
meeting.

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

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

[Justin Richer]

As mentioned, my own intention for using a new claim “ath” was to have a fixed 
hash size, not dependent on the surrounding JWS envelopes that “at_hash” is 
based on. I’ve implemented both approaches on several platforms now, and I 
greatly prefer the fixed hash. 

It’s a new name because it is a new claim with new contents and new semantics.

 — Justin

> On Apr 9, 2021, at 11:20 AM, John Bradley  wrote:
> 
> I think that using "auth" with the fixed full sha256 hash is fine.
> 
> The original response size reasons for truncating the hash in the definition 
> of at_hash are no longer really neccicary in current browsers and networks.
> 
> A new claim is fine.
> 
> On 4/9/2021 11:03 AM, Brian Campbell wrote:
>> For a hash of the access token in the proof JWT, discussion about whether to 
>> use the existing 'at_hash' claim or define a new 'ath' claim using only 
>> SHA-256 have been floating around since last year 
>> (https://mailarchive.ietf.org/arch/msg/oauth/QKMHo6gGRAaANadsAWWlSuRDzXA/ 
>>  
>> attempts to describe the tradeoffs) without a clear consensus emerging for 
>> one over the other. I've been on the fence myself seeing the merits and 
>> drawbacks in both. In the absence of clear preference or an obvious 'best' 
>> option, the PR from Justin 
>> https://mailarchive.ietf.org/arch/msg/oauth/C2G9cUetGSj6WnNcRdZE8wLR19I/ 
>>  
>> with the SHA-256 only 'ath' claim was sufficient to make the decision. 
>> 
>> I'm not married to the 'ath' but don't want to change it back and forth. I 
>> would like to see something like consensus for making a change. And strong 
>> consensus has been elusive here. 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Fri, Apr 9, 2021 at 1:45 AM Filip Skokan > > wrote:
>> I would support that too but only if the way it's calculated would get 
>> aligned as well. If it remains being a fixed sha256 of the whole token 
>> rather than what at_hash does, using a new claim makes sense. 
>> 
>> Odesláno z iPhonu
>> 
>>> 9. 4. 2021 v 5:38, 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 mailto:oauth-boun...@ietf.org>> On 
>>> Behalf Of Brian Campbell
>>> Sent: Wednesday, April 7, 2021 1:30 PM
>>> To: oauth mailto:oauth@ietf.org>>
>>> 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 

[OAUTH-WG] Access Token Hash for DPoP

[Justin Richer]

As discussed on the call yesterday, I have put together a modest proposal for 
adding access token hash to the DPoP draft.

https://github.com/danielfett/draft-dpop/pull/62 


Instead of using the existing OpenID Connect “at_hash” claim and definition, I 
opted for a new claim “ath” with a fixed hash method. While we could re-use the 
existing claim definition, I think it makes more sense to have the function be 
simpler. I made this decision based on years of feedback from developers on 
dealing with the OpenID definition: most of the confusion and errors come from 
deciding which hash algorithm to use and from the “left-bytes” truncation, both 
of which can fail in unsafe ways under the right error conditions. 

If SHA256 is obsoleted or another method is more appropriate given the space, 
then a new claim can be invented with defined semantics tied to a new hash 
method, obsoleting the “ath” method for “ath_but_better_this_time”. 

If people want to use the “at_hash” claim, this definition doesn’t actually get 
in the way of using that alongside “ath". We might want to change the normative 
requirement to something like “MUST include ‘ath’, ‘at_hash’, or another token 
hash method” instead, but I didn’t go that far here.

And finally, as I said on the call, I think this is a good idea and one I’ve 
implemented support for in a test project, but not something I consider 
make-or-break for publication of DPoP. 

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

Re: [OAUTH-WG] One-time token login

[Justin Richer]

I agree that it seems strange to use the authorization code in such a manner, 
though I can see how it could work on a technical basis. 

While it’s not an exact match, you might want to look at the Device Grant:

https://tools.ietf.org/html/rfc8628 

Here you issue a user-typable code that gets entered into the client app. While 
the canonical use for this is things like set top boxes, I’ve seen it used to 
onboard secondary devices using an out-of-band communication mechanism, which 
seems like it might fit here better.

Ultimately, OAuth is most comfortable living around web browsers, so any time 
you go outside of that space things start to look a little funny.

 — Justin

> On Mar 2, 2021, at 2:04 PM, Evert Pot  wrote:
> 
> Dear list,
> 
> We have a requirement to let users log in to an application via a code sent 
> by email.
> This code needs to be exchanged for an access/refresh token pair, and should 
> only work once.
> 
> The access/refresh token scope would give limited access to the application. 
> Since we already use the authorization_code flow for other (more sensitive) 
> parts of the application, I would like to re-use the OAuth2 framework for 
> parts of this.
> 
> It doesn't sit right with me to overload the 'code' in authorization_code, so 
> I was considering introducing a new custom grant_type for our application, 
> specific for this purpose.
> It seems that grant_type in the 'token' endpoint would support extension in 
> this manner, by using a uri such as https://vendor.example/email-token 
> 
> I'm comfortable implementing this, but curious:
> 
> Is there already some prior art that I'm not aware of? I'd rather not do a 
> custom grant_type if there's something standard I could do.
> Are there any major pitfalls associated with this?
> Evert
> 
> ___
> 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] We appear to still be litigating OAuth, oops

[Justin Richer]

Right, it’s possible to patch OAuth to do this, but the whole “registration 
equals trust” mindset is baked into OAuth at a really core level. That’s one of 
the main reasons there’s been hesitance at deploying dynamic registration. It’s 
an extension that changes your trust model’s assumptions, and does so in a way 
that is challenging for a lot of large scale providers.

That’s why I personally think it’s really important that we get away from that 
registration model in GNAP, so we don’t repeat that same problem in the same 
way. Some people will still deploy GNAP with static registration, but this 
model becomes more exceptional than baseline. The philosophy of what’s 
considered an extension vs. default is important.

 — Justin

> On Feb 25, 2021, at 3:41 AM, Seán Kelleher  wrote:
> 
> Yep, this is the big point - OAuth is designed to require the the third leg 
> of trust that creates the NxM problem.
> 
> I believe the snippet of Justin's that you quoted actually shows you how you 
> can forgo the trust element using dynamic client registration. It still 
> allows a "server" to identify requests and impose security policies via the 
> client ID, but without requiring the client author to manually register the 
> client in advance of using it (e.g. in the case where the client author 
> doesn't even know what servers the client is going to be connecting to). You 
> still need the client ID, but anyone can get one whenever they need it.
> 
> I'm also feeling a bit of confusion arising from a conflation of terms 
> between the regular client/server model and the terminology used in OAuth. To 
> be clear, in OAuth, the level of trust between the client and authZ server 
> only really depends on policy; as mentioned, dynamic client registration can 
> be used if you don't need any trust between the client and AS.
> 
> On Thu, 25 Feb 2021 at 08:22, Seán Kelleher  <mailto:s...@trustap.com>> wrote:
> Just to clarify, I assume in this discourse that the "server" in this client 
> and server relationship refers to an AS/RS pair in OAuth terminology? Based 
> on this, one big sticking point for me on the applicability of NxM, or even 
> 1xM, is that all of the "M" RSs need to publish the same interface for any 
> meaningful implementation in the first place.
> 
> It probably makes more sense with email clients, since as Bron said, there is 
> the common standard of POP. If we assume that all the email services that we 
> want to connect to publish the same POP interface, and would accept tokens in 
> the same way, then the way the authZ is handled is indeed the point of 
> divergence that needs to be resolved.
> 
> However, we're talking about NxM in the general case here. I feel like using 
> the likes of discovery and dynamic registration, etc. that's already 
> supported by OAuth, the "N" part of this equation is surmountable. But each 
> of the "M" servers also need to export the same interface, otherwise a client 
> is going to have to write custom code to deal with talking to the service 
> after the authZ step anyway, reintroducing the "problem" part of the NxM 
> problem.
> 
> As such, I would actually suggest constraining this discussion to just the 
> POP NxM problem rather than NxM in general because, for me at least, the 
> authZ part of the general case is the most "solved" part of the problem, and 
> the outstanding work lies more in consolidating the "M" RS interfaces.
> 
> On Wed, 24 Feb 2021 at 22:32, Bron Gondwana  <mailto:br...@fastmailteam.com>> wrote:
> On Thu, Feb 25, 2021, at 02:18, Justin Richer wrote:
>> I agree that the NxM problem is the purview of the whole IETF, but it’s 
>> something that we’re particularly interested in over in GNAP. As the editor 
>> of OAuth’s dynamic registration extension and the GNAP core protocol, I hope 
>> I can add to this conversation.
>> 
>> From a technical standpoint, OAuth’s dynamic client registration lets 
>> arbitrary clients talk to an AS, but the trust isn’t there in practice. On 
>> top of that I think this problem is exacerbated by a fundamental protocol 
>> design element of OAuth: the client_id that’s required. That field means 
>> there’s an assumption that a relationship was set up between the pieces of 
>> software, implied to be trusted by admins at the AS. Sure you can get that 
>> client_id under special circumstances, but there’s still a special weight 
>> handed to that and the dynamic stuff feels like you’re giving up control as 
>> an AS. In GNAP, the relationship is inverted, and it’s designed as 
>> “dynamic-first”, with pre-registered clients being an optimization on top of 
>> that.
> 
> Y

Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

[Justin Richer]

> On Feb 25, 2021, at 2:59 PM, Evert Pot  wrote:
> On 2021-02-25 3:41 a.m., Seán Kelleher wrote:
>> Yep, this is the big point - OAuth is designed to require the the third leg 
>> of trust that creates the NxM problem.
>> 
>> I believe the snippet of Justin's that you quoted actually shows you how you 
>> can forgo the trust element using dynamic client registration. It still 
>> allows a "server" to identify requests and impose security policies via the 
>> client ID, but without requiring the client author to manually register the 
>> client in advance of using it (e.g. in the case where the client author 
>> doesn't even know what servers the client is going to be connecting to). You 
>> still need the client ID, but anyone can get one whenever they need it.
> Apologies if this a dumb question, but how would you discover the dynamic 
> client registration endpoint after getting a 401 unauthorized?
> 
> I couldn't really find anything in RFC7591 about this.
> 
We deliberately left that level of discovery out of the registration spec 
(7591) because, as it turns out, RS-first discovery is a lot harder than it 
looks on the surface. There are some tricky privacy considerations around 
divulging an AS to an unknown party, and while not a dead-stop there you’ve got 
a lot of use cases where it hurts more than it helps.

In the end, we decided not to solve those aspects together and leave discovery 
for another spec. I think the call made sense at the time. Now, obviously, this 
assumption goes halfway out the window when you start doing the registration 
programmatically, and so discovery on a static relationship vs. discovery on a 
dynamic relationship are pretty different. 

We’re taking a different approach in GNAP, based on work that was done in User 
Manage Access (UMA):

https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-04.html#name-requesting-resources-with-i
 


Caveat, there are still a lot of open questions about the details of this, the 
focus in GNAP has been on the core delegation protocol so far, but it’s on our 
radar and we welcome the input.

And then there’s the considerations about hooking up more RS’s in real time, or 
even having the user/client SPECIFY the AS for the RS to talk to. So ultimately 
it’s an NxMxP problem, with client, AS, and RS in each slot varying differently 
depending on the API in question. In most OAuth use cases, the AS and RS have a 
pre-existing relationship that the client doesn’t know or care about. The 
client’s just trying to “call this API” and so it gets configured with all the 
bits it needs to ahead of time when it gets registered. But with a common API, 
like POP or IMAP, the client just needs to know how to get to the next step to 
keep going. 

This is one thing I’ve found security engineers simply Do Not Get more often 
than not: client developers don’t care about your security protocol. Your 
security is what gets in the way of them doing what they want to do, which is 
use the API and build an awesome thing. The simpler-to-follow we can make the 
security process, the better it will be for everyone.

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

Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

[Justin Richer]

I agree that the NxM problem is the purview of the whole IETF, but it’s 
something that we’re particularly interested in over in GNAP. As the editor of 
OAuth’s dynamic registration extension and the GNAP core protocol, I hope I can 
add to this conversation.

From a technical standpoint, OAuth’s dynamic client registration lets arbitrary 
clients talk to an AS, but the trust isn’t there in practice. On top of that I 
think this problem is exacerbated by a fundamental protocol design element of 
OAuth: the client_id that’s required. That field means there’s an assumption 
that a relationship was set up between the pieces of software, implied to be 
trusted by admins at the AS. Sure you can get that client_id under special 
circumstances, but there’s still a special weight handed to that and the 
dynamic stuff feels like you’re giving up control as an AS. In GNAP, the 
relationship is inverted, and it’s designed as “dynamic-first”, with 
pre-registered clients being an optimization on top of that.

Does this solve the NxM problem? No, because companies are still going to 
decide that they only talk to keys or identifiers that they know ahead of time. 
But the protocol puts the dynamic case forward as baseline and fits in much 
better with the likes of JMAP than OAuth ever could:

- {The Bat} creates a key pair.
- {User} enters their email address into {Bat}, {Bat} does discovery (maybe 
that’s a JMAP thing? Webfinger?) and finds the JMAP server and the GNAP 
endpoint for authentication as an option.
- {Bat} talks to the GNAP AS at {ISP} and presents the key it just made up. 
{ISP} has never seen this key, but knows how to talk GNAP and get the user to 
authorize {Bat} to access email.
- {User} does this using GNAP and gets back an access token that’s tied to the 
key {Bat} made back at the beginning. That token is tied (at the {ISP}) to the 
user’s account.

Yes, you can do all of this today with OAuth (and people have done so), but 
OAuth’s basic model of “go do discovery and registration first and THEN talk to 
me” is a trust impediment more than it is a technical impediment. The 
“negotiation” part of the GNAP name comes from the philosophy of “start talking 
first and figure out what you need as you go”. Instead of jumping through hoops 
to get something you can trust, you just start in and then decide how much you 
trust it. A corporate rollout could use its own key distribution mechanism and 
static registration to limit which client instances talk back to the company 
server, regardless of which accounts would authorize access on top of that. An 
internet-facing service is going to be more likely to take a TLS approach, of 
“I’ll talk to you in a secure fashion without caring who you are right now”.

We really are trying to make GNAP a consistent protocol at its core and learn 
from problems with OAuth in the wild, all while letting GNAP address a wider 
variety of use cases. I agree that GNAP could be clearer about specific use 
cases, and we’re working on the spec still so any help here is appreciated. 

 — Justin

> On Feb 24, 2021, at 7:15 AM, Bron Gondwana  wrote:
> 
> 
> 
> On Wed, Feb 24, 2021, at 23:09, Warren Parad wrote:
>> (I tend to trend lightly in the pronoun area, mostly because I'm shocked 
>> that openid included gender but not pronouns)
>> 
>> I hadn't heard that to be called the NxM problem, so that definitely cleared 
>> up the potential confusion (at least for me).
>> 
>> I think GNAPs lack of clarity is a non sequitur for the handling or not of 
>> the multitrust arbitrary-client with arbitrary-service, however it's lack of 
>> clarity for me prevents me from knowing whether GNAP actually seeks to solve 
>> this problem. So from an OAuth WG perspective we can still ask:
>> 
>> Is this or should this problem be left to GNAP to solve, or is an OAuth WG 
>> responsibility?
> 
> Honestly I think the problem space is the whole ietf's responsibility. 
> Protocols that allow an end user to safely transfer data between two parties 
> that don't have a pre-existing trust relationship are a key part of enabling 
> user freedom and user choice.
> 
> Bron.
> 
>> 
>> 
>> Warren Parad
>> Founder, CTO
>> Secure your user data with IAM authorization as a service. Implement 
>> Authress .
>> 
>> 
>> On Wed, Feb 24, 2021 at 12:39 PM Bron Gondwana > > wrote:
>> 
>> On Wed, Feb 24, 2021, at 22:04, Warren Parad wrote:
>>> I would prefer Bron to answer that question, as they are the one who 
>>> started this email thread.
>> 
>> You can also use he when talking about me, or she for that matter - I do 
>> enough group fitness classes where it's roughly assumed that the entire 
>> class is female, and I have an ambiguous enough name that I'm used to it.  
>> Most people use "he" most of the time.
>> 
>>> However let's look at GNAP, I've honestly been struggling to understand at 
>>> least one fully documented case that GNAP supports. It seems in 

Re: [OAUTH-WG] Authorization Header Encoding

[Justin Richer]

The issue was whether to remove the token68 portion and just use auth-param as 
part of the syntax, as far as I know. Bearer goes a little off from even the 
draft spec and admits as much in place. If we can improve the definition in 
2.1, or at least make it clearer what’s expected, then I think that’s better. 
I’ll guarantee you that developers aren’t following “token68” syntax in 
practice when making Bearer headers.

— Justin

> On Feb 17, 2021, at 6:35 PM, Brian Campbell 
>  wrote:
> 
> AFAIK the character set for the "Bearer" scheme in RFC6750 is what it is to 
> align with the token68 part of "credentials = auth-scheme [ 1*SP ( token68 / 
> #auth-param ) ]" from https://tools.ietf.org/html/rfc7235#section-2.1 
> <https://tools.ietf.org/html/rfc7235#section-2.1> (the draft that would 
> become RFC7235 is referenced by RFC6750 in 
> https://tools.ietf.org/html/rfc6750#section-2.1 
> <https://tools.ietf.org/html/rfc6750#section-2.1> where it says basically as 
> much). 
> 
> Also it looks like https://github.com/httpwg/http-core/issues/733 
> <https://github.com/httpwg/http-core/issues/733> was closed with no action. 
> 
> So I don't see what change would be made in OAuth 2.1 or elsewhere. Nor does 
> it seem like any change is needed or appropriate.  
> 
> On Mon, Feb 15, 2021 at 4:34 AM Vladimir Dzhuvinov  <mailto:vladi...@connect2id.com>> wrote:
> Hi Justin,
> 
> Thanks for alerting us on this development.
> 
> +1 for keeping the updated HTTP semantics unencumbered by the Authorization 
> header formatting in RFC 6750.
> 
> IMO revising the RFC 6750 to reflect that is too late now, as few people will 
> notice. So updating the Bearer header definition in OAuth 2.1 seems like the 
> most sensible move. I expect OAuth 2.0 implementers who maintain their 
> software to pick up the 2.1 spec, sooner or later.
> 
> Vladimir
> 
> 
> 
> On 12/02/2021 00:01, Justin Richer wrote:
>> The HTTP Working Group opened an issue for discussion in relation to the 
>> updated HTTP semantics specification. The core of the issue is the format of 
>> the “Authorization” header, which of course gets used by the “Bearer” scheme 
>> defined in RFC6750.
>> 
>> https://github.com/httpwg/http-core/issues/733 
>> <https://github.com/httpwg/http-core/issues/733>
>> 
>> As it turns out, Bearer defines a more limited character set than is allowed 
>> by core HTTP, and doesn’t follow the HTTP guidelines and definitions for the 
>> Authorization header. There were a few observations on the call:
>> 
>>  - The Bearer spec was limited because OAuth tokens were also allowed in 
>> HTTP URLs and form parameters (and therefore had to have a more limited 
>> character set)
>>  - In practice people don’t actually restrict the values they put into this 
>> field; pretty much any implementation is just going to concatenate whatever 
>> access token value they get to the magic word “Bearer” and send it
>>  - It’s not likely (or in my opinion proper) for the HTTP spec to change to 
>> address the oddities of RFC6750 and decisions that were made many years ago
>> 
>> So the question is, what do we do about it? We could do a revision of 6750 
>> that reflects reality better, pretty much just changing the ABNF.
>> 
>> Or, we could update the definition of the Bearer header in the upcoming 
>> OAuth 2.1 specification.
>> 
>> Are there other options?
>> 
>>  — Justin
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth 
>> <https://www.ietf.org/mailman/listinfo/oauth>
> -- 
> Vladimir Dzhuvinov
> ___
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth 
> <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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Digest for DPoP

[Justin Richer]

Two different specifications (GNAP and FAPI signatures) have recently profiled 
DPoP to use its signature method to protect a different kind of protocol 
entirely. One thing these methods have in common is that they both define an 
additional field for holding a digest of the HTTP Message Body:

https://bitbucket.org/openid/fapi/src/master/Financial_API_Simple_HTTP_Message_Integrity_Protocol.md#markdown-header-521-htd-the-digest-of-the-http-request-or-response-body
 


https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-03.html#name-demonstration-of-proof-of-p
 


Both of these have the same semantics, and we’re changing the name in GNAP to 
align with the FAPI one. This begs the question: do we want to just define this 
field as an optional component in DPoP instead of having these profiles do it 
separately? It would save them from needing to align with each other, and 
anyone else from inventing it again.

Is it worth defining this in DPoP directly, or does that complicate the spec 
too much? I’ve previously raised a similar question on including a hash of the 
access token in the DPoP request to the RS.

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

[OAUTH-WG] Authorization Header Encoding

[Justin Richer]

The HTTP Working Group opened an issue for discussion in relation to the 
updated HTTP semantics specification. The core of the issue is the format of 
the “Authorization” header, which of course gets used by the “Bearer” scheme 
defined in RFC6750.

https://github.com/httpwg/http-core/issues/733 


As it turns out, Bearer defines a more limited character set than is allowed by 
core HTTP, and doesn’t follow the HTTP guidelines and definitions for the 
Authorization header. There were a few observations on the call:

 - The Bearer spec was limited because OAuth tokens were also allowed in HTTP 
URLs and form parameters (and therefore had to have a more limited character 
set)
 - In practice people don’t actually restrict the values they put into this 
field; pretty much any implementation is just going to concatenate whatever 
access token value they get to the magic word “Bearer” and send it
 - It’s not likely (or in my opinion proper) for the HTTP spec to change to 
address the oddities of RFC6750 and decisions that were made many years ago

So the question is, what do we do about it? We could do a revision of 6750 that 
reflects reality better, pretty much just changing the ABNF.

Or, we could update the definition of the Bearer header in the upcoming OAuth 
2.1 specification.

Are there other options?

 — Justin

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

Re: [OAUTH-WG] Rich Authorization Requests feedbacks on implementation

[Justin Richer]

Hi Nicolas,

> On Jan 10, 2021, at 8:36 PM, Nicolas Mora 
>  wrote:
> 
> Hello,
> 
> I've implemented Rich Authorization Requests defined in 
> draft-ietf-oauth-rar-03 for Glewlwyd soon-to-be-released 2.5 [1], and I 
> humbly wanted to write my feedback about this implementation to share my 
> experience.
> 

> For starters, this implementation and my following feedbacks are based on the 
> prism of Glewlwyd's implementation and philosophy, and my limited experience 
> on OAuth2, so I appologize in advance if I write non-sense or big mistakes.
> 

Thanks for reaching out! Implementation experience is incredibly valued here in 
the IETF, especially when someone’s coming to the spec from “outside” the 
community. :)

> 1 - Design
> 
> The way I saw it, there are 2 different approaches to implement oauth2 rar: 
> either to get a token with a more detailed scope, or to get a one-time token 
> with extra grants.
> 
> Both are not exclusive, but a big difference I see between those 2 approaches 
> is the grant access from the user part. The second approach would require the 
> user to know what extra grant is asked by the client every time the client 
> asks for it, i.e. when the client redirects the user to the /authorization 
> endpoint.
> 
> To be more consistent with Glewlwyd's philosophy, I chose the first approach, 
> with those rules.
> The AS administrator declares what rar types are allowed [2]
>  - a rar type has a defined set of locations, actions, datatypes and enriched 
> authorization details that the client can ask for
>  - the client must be explicitly allowed to add a rar type in the 
> authorization request
>  - a rar type can be linked to one or more scope. In that case, the 
> authorization request must include at least one of the linked scope, and the 
> scope must be available for the user and the scope must be granted to the 
> client
>  - the client can add as many properties as required in the rar type, those 
> extra properties are not verified by the AS, on access granted, the extra 
> properties will be present in the "authorization_details" result.
> 

I think this is an interesting approach, but I’m not sure about a few things:

- What’s the utility of linking to a scope. Why require both structures to be 
interpreted together like that?
- There will absolutely be implementations that do not limit which RAR types 
(or even values) the client is allowed to send, much like there are 
implementations today that don’t restrict scopes on a per-client basis.
- I don’t think that we can say the AS doesn’t verify “extra required 
properties”, since the AS can (and arguably should) know about the details of 
the “type” being used, and enforce internal consistency and structure.

> On first use of a rar type by a client for a user, the user must grant to the 
> client the rar access [3]. That's why the grant message will show to the user 
> ALL access possible via this rar type
> Once this access is granted or not, the user will not be asked again on 
> another authorization request by the client (but is can be changed at any 
> time, as a scope grant).
> 

It’s always up to the AS to determine what the granted access is, whether it’s 
for a new token, a limitation of existing grant (via refresh token), or a 
client asking for something “additional” for whatever purpose. 

> 2 - Limitations
> 
> In this design, the AS has a limited control over the authorization_details 
> content, and the trust between the AS and the client must be high enough so 
> if a rar type can gain access to sensitive actions or information, the user 
> should know about it.

The AS has full control to interpret the authorization_details content, and 
apply it to access token granting policies, which include whether to ask the 
user to grant anything. 

> 
> Also, in the draft specification, the only mandatory element type in a rar is 
> the "type" element. In my point of view, this means that the business logic 
> is mostly defined by the RS, rather than the AS.

Just like “scope” in OAuth, it’s ultimately enforced by the RS, but the AS 
works in the process to interpret and potentially modify the meaning of the 
scope. 

> 
> Therefore, for a client implementation to be compliant with the specs, 
> there's not much to do: add as a parameter a JSON array with objects 
> containing at least one "type" string property in it.
> 

Yup — and even more, most clients will be sending in static or templated values 
that the developers get from documentation, much like they do with scopes in 
APIs today. Keeping it simple for clients is definitely a goal!

> 3 - Extensions
> 
> I believe one way to mitigate these limitations is to allow extensions to be 
> defined on top of the rar specifications. An extension can be declared like 
> this:
> 
> "RAR Extension XYZ:
> A rar whose type is XXX
> - Actions available: YYY, ZZZ or AAA
> - datatypes possibles: BBB, CCC, DDD or EEE
> - additional elements mandatory: an array of FFF 

Re: [OAUTH-WG] Tenancy in OAuth

[Justin Richer]

Hi Jaap,

There have been a number of efforts to address this kind of thing in the OAuth 
world. You can definitely use a special scope to encode this value, which has 
the benefit of fitting into the implementation limitations of nearly all OAuth 
systems out there. The “resource” parameter can also be used for the kind of 
thing, and it gives you a bucket that’s separate from “scope” so that you can 
keep the latter available for describing the API itself:

https://tools.ietf.org/html/rfc8707 

There’s also the Rich Authorization Request (RAR) draft that this group is 
currently working on, which provides a multi-dimensional way to describe 
access. It’s more complex than scopes, but it boils down to having JSON objects 
describe the elements needed. In this case you might put the API bits into the 
“actions” and “datatypes” fields, and put the tenant information into the 
“locations” field. I believe there are people using it in exactly this way 
today:

https://tools.ietf.org/html/draft-ietf-oauth-rar-03 


There are also some historical efforts to address this, including an “audience” 
and a (completely separate) “aud" parameter, but AFAIK neither of these have 
been raised to standard or even to common practice, and so I wouldn’t recommend 
it. I currently have a project to migrate a system that’s currently using one 
of these onto RAR.

 — Justin

> On Jan 12, 2021, at 11:20 AM, Jaap Francke 
>  wrote:
> 
> Hi,
>  
> I’m looking into the topic of tenancy. A multi-tenant service can be 
> considered as an OAuth Resource Server managing resources of different 
> tenants.
> An AS makes authorization decisions and communicates these using scopes, so 
> one way would be to ‘encode’ the tenant into the scope values.
> Another line of thought is to somehow bind/restrict an acces-token to a 
> certain tenant, leaving the set of scopes being used more static.
>  
> My question is whether this has been a topic that has been addressed in the 
> OAuth working group? Any common practice or draft?
> Thanks in advance for your replies.
>  
> Kind regards,
>  
> Jaap Francke
> Product Manager Identity
> +31(0)641495324
> mendix.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] DPoP followup I: freshness and coverage of signature

[Justin Richer]

I went and implemented this proposal of including a token hash in both an AS 
(java) and client (javascript) on a system that was already using DPoP and 
OpenID Connect. What I did there was just use the existing code we had on the 
AS-side to calculate the “at_hash” in the ID Token from OIDC, which I also used 
to verify on the token-accepting portions. I had to implement the function on 
the client side, but that was only a couple lines using a crypto library to do 
the heavy hash lift.

The most annoying part is dealing with the hash variability in the OIDC method. 
As Brian points out, this isn’t particularly robust, and it depends on the 
wrapper being JOSE. That’s not a huge deal because DPoP uses JOSE for its 
wrapper, but it’s still extra code to deal with — to the point where I just 
hardcoded the hash algorithm in my test so that I didn’t have to put together 
the switch case over the algorithm. 

So in at least my own experience, the addition is minimal on both client and 
server, and whatever we would decide for the hash algorithm would be simple 
enough to manage. I have a slight preference for just picking something like 
SHA256 and calling it a day (and defining other hashes in the future when 
SHA256 is broken), but that’s not a hill I care to die on.

 — Justin

> On Dec 14, 2020, at 4:27 PM, Brian Campbell 
>  wrote:
> 
> 
> 
> On Sat, Dec 12, 2020 at 1:22 AM Vladimir Dzhuvinov  > wrote:
> If the current DPoP has code complexity "X", the relative additional 
> complexity to include access token hashes doesn't seem like very much. An app 
> choosing DPoP means accepting the code complexity that comes with dealing 
> with keys, composing the signing inputs for the proofs, signing, the 
> necessary changes to the token and RS requests. On the other hand, for some 
> people that additional access token hash may become the straw that breaks the 
> camel's back, causing them to quit their jobs developing web apps and never 
> look back :)
> 
> Yeah, the relative additional complexity to include an access token hash 
> maybe isn't too much but it's also not not nothing. It's a different kind of 
> operation than the other things you listed (yes, I know there's a hash as 
> part of the signing but it's abstracted away from the developer in most 
> cases) and something that can be quite difficult to troubleshoot when 
> different parties arrive at different hash values. Hence my lack of 
> conviction on this one way or the other. 
>  
> 
> Have you thought about letting deployments decide about the access token 
> hash? To say look, there is also the option to bind an access token to the 
> DPoP proof, the security benefits can be such an such, and this is how it can 
> be done.
> 
> What I don't like about that proposal: 
> 
> It will complicate the spec
> 
> The current spec doesn't require implementers / deployments to make any 
> decisions, apart from adopt / not DPoP (okay, also choose a JWS alg) - which 
> is actually a great feature to have
> 
> I also don't like it for basically the same reasons. I've definitely aimed to 
> keep it simple from that perspective of not having a lot of optionality or 
> switches. It is a nice feature to have, when possible. 
> 
>  
> Vladimir
> 
> 
> 
> On 12/12/2020 01:58, Brian Campbell wrote:
>> Any type of client could use DPoP and (presumably) benefit from 
>> sender-constrained access tokens. So yeah, adding complexity specifically 
>> for browser-based applications (that only mitigates one variation of the 
>> attacks possible with XSS anyway)  has 'cost' impact to those clients as 
>> well. And should be considered in the cost/benefit. Including the AT hash 
>> isn't terribly complicated but it's not trivial either. I'm honestly still 
>> unsure but am leaning towards it not being worth adding. 
>> 
>> On Fri, Dec 11, 2020 at 2:14 AM Philippe De Ryck 
>> > > wrote:
>> The scenario you describe here is realistic in browser-based apps with XSS 
>> vulnerabilities, but it is pretty complex. Since there are worse problems 
>> when XSS happens, it’s hard to say whether DPoP should mitigate this. 
>> 
>> I’m wondering what other types of clients would benefit from using DPoP for 
>> access tokens? Mobile apps? Clients using a Client Credentials grant?
>> 
>> How are they impacted by any change made specifically for browser-based 
>> applications?
>> 
>> Philippe
>> 
>> 
>>> On 9 Dec 2020, at 23:57, Brian Campbell >> > wrote:
>>> 
>>> Thanks Philippe, I very much concur with your line of reasoning and the 
>>> important considerations. The scenario I was thinking of is: browser based 
>>> client where XSS is used to exfiltrate the refresh token along with 
>>> pre-computed proofs that would allow for the RT to be exchanged for new 
>>> access tokens and also pre-computed proofs that would work with those 
>>> access tokens for resource access. With 

Re: [OAUTH-WG] Token substitution in DPoP

[Justin Richer]

With the renewed work on HTTP Message Signatures[1] in the HTTP WG[2], I think 
we might have a good avenue for this ECDH-with-KDF flavor of message signature 
in that arena instead of trying to twist it into DPoP. I think that this 
signing mechanism will be a better base for a general PoP effort in OAuth, and 
I still believe that this could live alongside DPoP’s more specific focus and 
intentional limitations. 

 — Justin

[1] https://tools.ietf.org/id/draft-ietf-httpbis-message-signatures-01.html 
<https://tools.ietf.org/id/draft-ietf-httpbis-message-signatures-01.html>

[2] https://github.com/httpwg/http-extensions/ 
<https://github.com/httpwg/http-extensions/>


> On Nov 24, 2020, at 4:18 PM, Brian Campbell 
>  wrote:
> 
> It took me some time to warm to the ECDH based idea but I do think it has a 
> lot of merit. For whatever it's worth, I put the idea forth as one potential 
> path forward during the general PoP interim meeting back in March 
> (https://datatracker.ietf.org/meeting/interim-2020-oauth-02/materials/slides-interim-2020-oauth-02-sessa-oauth-20-proof-of-possession-00.pdf
>  
> <https://datatracker.ietf.org/meeting/interim-2020-oauth-02/materials/slides-interim-2020-oauth-02-sessa-oauth-20-proof-of-possession-00.pdf>
>  slide 8) but the WG consensus was to pursue a signature style PoP for the 
> current efforts, which was followed not long after by WG adoption of DPoP. I 
> could potentially see an ECDH-style-POP effort making a resurgence in the 
> future. But it's fundamentally pretty different.  
> 
> 
> 
> 
> On Tue, Nov 24, 2020 at 4:03 AM Neil Madden  <mailto:neil.mad...@forgerock.com>> wrote:
> I agree with Daniel that I’d be a bit wary of assuming that this could never 
> be exploited. For example, a server-side web app that signs DPoP proofs on 
> behalf of client-side Javascript (to keep the key safe on the server) and 
> reuses the key for different users could be a risk. 
> 
> IMO this is another symptom of the general issue of using signatures for 
> authentication - they are too strong for the job. The fact that a signature 
> is equally valid to all parties and at all times means you have to be very 
> careful to include enough context in the signature calculation to ensure all 
> these kinds of attacks are eliminated. And you have to ensure that all RSes 
> check the context. 
> 
> Contrast that to my suggestion to use ECDH [1], which was already immune to 
> such attacks by including the access token in the key derivation step. (And 
> in such a way that requires no additional data on the wire and is almost 
> impossible for the RS not to verify). Even without including the access token 
> in the KDF, the attack could only happen if the client reused its key and the 
> RS reused a challenge key pair. 
> 
> Macaroon access tokens [2] are also immune to this attack, as in that case 
> the constraints that go in the DPoP proof are directly attached to the access 
> token itself so there is no way to reuse them separately. (Interestingly, 
> macaroons have a more direct analogue of DPoP in the form of discharge 
> macaroons. Such discharge macaroons are required to be “prepared” before use, 
> which cryptographically binds them to the equivalent of the access token - so 
> this kind of attack was also considered and addressed there). 
> 
> [1]: https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmhoKLbavu9s/ 
> <https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmhoKLbavu9s/>
> [2]: 
> https://neilmadden.blog/2020/07/29/least-privilege-with-less-effort-macaroon-access-tokens-in-am-7-0/
>  
> <https://neilmadden.blog/2020/07/29/least-privilege-with-less-effort-macaroon-access-tokens-in-am-7-0/>
> 
> — Neil
> 
>> On 24 Nov 2020, at 09:38, Daniel Fett > <mailto:f...@danielfett.de>> wrote:
>> 
>> 
>> Thanks Justin for bringing this to our attention.
>> 
>> Right now, I don't think that this is a big problem and I wasn't able to 
>> come up with a way to improve the attack. I hope that it doesn't come back 
>> to haunt us when somebody does a more in-depth analysis...
>> 
>> That said, the lack of binding to the access token makes it easier to 
>> precompute proofs if somebody has a limited code execution opportunity in 
>> the client. We have this paragraph in the spec:
>> 
>>Malicious XSS code executed in the context of the browser-based
>>client application is also in a position to create DPoP proofs with
>>timestamp values in the future and exfiltrate them in conjunction
>>with a token.  These stolen artifacts can later be used together
>>independent of the client application to access protected resources.
>> 

Re: [OAUTH-WG] Token substitution in DPoP

[Justin Richer]

Correct, but the choice of using different keys is entirely in the hands of the 
client, as the AS accepts whatever key the client presents in its initial DPoP 
proof to bind to the token. If it’s on the client to prevent this kind of 
thing, we should at least mention it in the security considerations. If it’s 
something we want to prevent wholesale, we should expand the signature coverage 
to the access token, or at least a hash of the token.

 — Justin

> On Nov 20, 2020, at 9:30 PM, Nikos Fotiou  wrote:
> 
> Hi,
> The token is granted to a client based on the authorization grant and not the 
> client's key. Therefore, a client may use a different key per token. At least 
> this is an approach we are following. 
> 
> Best,
> Nikos
> 
> -Original Message-
> From: OAuth  On Behalf Of Justin Richer
> Sent: Friday, November 20, 2020 9:26 PM
> To: oauth 
> Subject: [OAUTH-WG] Token substitution in DPoP
> 
> While working on an implementation of DPoP recently, I realized that the 
> value of the access token itself is not covered by the DPoP signature at all. 
> What I’m wondering is whether or not this constitutes an attack surface that 
> we care about here. Here’s how it works:
> 
> 
> Let’s say that a client creates a DPoP key and uses that key to request two 
> tokens, T1 and T2, for different users, Alice and Bob, respectively. Alice is 
> malicious and wants to get Bob’s stuff. Alice manages to get a hold of Bob’s 
> token value, T2, through some means. Normally DPoP wouldn’t let Alice create 
> a new request using T2 since Alice doesn’t have the client’s key. However, if 
> Alice gets the client to create a request for her using T1, she can copy the 
> signature from that request onto a new request using T2. Since the signature 
> doesn’t cover the token value and the key is the same, the RS should accept 
> both requests, right?
> 
> An important aspect is that the parts needed to make this attack work are a 
> little weird: you’d need access to a valid signed request from the client 
> with T1 as well as access to a valid T2 attached to the same key in order to 
> make this substitution. However, this is effectively the same attack area 
> that bearer tokens have in a lot of ways, since it doesn’t require the 
> attacker gaining access to the singing key to generate or modify a signature, 
> nor does it require the attacker to generate or modify an access token 
> (merely obtain one).
> 
> 
> I’d like to understand if this is an actual attack against DPoP. If it isn’t, 
> how is it countered by DPoP today? If it is, do we discuss in the DPoP draft? 
> I didn’t see a mention of it there. If it’s not, should we discuss it there?
> 
> 
> The old OAuth PoP draft mitigates this attack by putting the access token 
> itself inside the signature body instead of a second header. Another option 
> would be to include a hash of the token value (such as OIDC’s “at_hash” 
> method used in ID Tokens) in the DPoP payload. With either of these 
> approaches, Alice having access to T1, T2, and a signed message for T1 does 
> not allow her to use T2 effectively.
> 
> — Justin
> ___
> 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-WG] Token substitution in DPoP

[Justin Richer]

While working on an implementation of DPoP recently, I realized that the value 
of the access token itself is not covered by the DPoP signature at all. What 
I’m wondering is whether or not this constitutes an attack surface that we care 
about here. Here’s how it works:


Let’s say that a client creates a DPoP key and uses that key to request two 
tokens, T1 and T2, for different users, Alice and Bob, respectively. Alice is 
malicious and wants to get Bob’s stuff. Alice manages to get a hold of Bob’s 
token value, T2, through some means. Normally DPoP wouldn’t let Alice create a 
new request using T2 since Alice doesn’t have the client’s key. However, if 
Alice gets the client to create a request for her using T1, she can copy the 
signature from that request onto a new request using T2. Since the signature 
doesn’t cover the token value and the key is the same, the RS should accept 
both requests, right?

An important aspect is that the parts needed to make this attack work are a 
little weird: you’d need access to a valid signed request from the client with 
T1 as well as access to a valid T2 attached to the same key in order to make 
this substitution. However, this is effectively the same attack area that 
bearer tokens have in a lot of ways, since it doesn’t require the attacker 
gaining access to the singing key to generate or modify a signature, nor does 
it require the attacker to generate or modify an access token (merely obtain 
one).


I’d like to understand if this is an actual attack against DPoP. If it isn’t, 
how is it countered by DPoP today? If it is, do we discuss in the DPoP draft? I 
didn’t see a mention of it there. If it’s not, should we discuss it there?


The old OAuth PoP draft mitigates this attack by putting the access token 
itself inside the signature body instead of a second header. Another option 
would be to include a hash of the token value (such as OIDC’s “at_hash” method 
used in ID Tokens) in the DPoP payload. With either of these approaches, Alice 
having access to T1, T2, and a signed message for T1 does not allow her to use 
T2 effectively.

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

Re: [OAUTH-WG] [JAR] scope parameter outside request object of OIDC request

[Justin Richer]

In my opinion, all parameters should be able to be passed inside the request 
object, including `scope`. 

We couldn’t do that kind of thing in OIDC because that would be a breaking 
change to existing requirements in OAuth 2. JAR is taking the step of 
overriding those requirements, and so it should do so with all parameters.

There are a lot of things in OIDC that are a little wonky like this, where the 
general solution turned out to be slightly different than the tightly fit 
solution that OIDC pioneered. Discovery and issuer URLs are another notable 
example beyond this one.

In my view, OIDC should be updated to redefine its behavior in light of the 
family of new general purpose protocol extensions, including JAR. This could 
probably be done in a way that an IdP could support both the “classic” way of 
doing request objects as well as the “new” way, but likely for different 
clients. In which case, I think the behavior switch would be similar to what 
Vladimir describes.

 — Justin

> On Sep 23, 2020, at 7:58 AM, Takahiko Kawasaki  wrote:
> 
> Hi Vladimir,
> 
> Thank you for your reply. It sounds that your opinion is "`scope` request 
> parameter must exist outside the request object even if JAR applies if the 
> authorization request is an OIDC request". I'm on the fence on this topic and 
> just wondered whether those who had wanted to remove `response_type` outside 
> the request object (although doing it was a breaking change) would want to 
> remove `scope` outside the request object too with the same motivation 
> (although I don't remember well what was the motivation). JAR dares to drop 
> `response_type`, so it would not be surprising to see that JAR dares to drop 
> `scope` (including `openid`) too.
> 
> OIDC Core 1.0 requires `response_type`, but JAR allows omission of the 
> parameter if the parameter is included in the request object.
> 
> If we applied the same logic, we would be able to state:
> 
> OIDC Core 1.0 requires `scope` (including `openid`), but JAR allows omission 
> of the parameter if the parameter is included in the request object.
> 
> In terms of `response_type`, practically speaking, JAR has modified OIDC Core 
> 1.0. Because JAR has already been allowed to go so far as that point, I would 
> say it is difficult to find a convincing reason not to allow omission of 
> `scope`.
> 
> AFAIK, in the context of OIDC Core 1.0, parameters that are required to exist 
> outside a request object even if they are included in the request object are 
> `client_id`, `response_type` and `scope`. Because `client_id` is mandatory in 
> JAR (it has become mandatory after long discussion), discussion for the 
> parameter is not needed. Because the community has already reached consensus 
> that `response_type` can be omitted, discussion for the parameter is not 
> needed, either. What I've brought here is discussion for `scope`, hopefully 
> the last parameter that is affected by JAR.
> 
> Again, I'm on the fence on this topic. However, because logical conclusion 
> (at least of mine) is that JAR should allow omission of `scope` (it also 
> should be noted that JAR's basic rule prohibits referring to request 
> parameters outside a request object), I want to see explicit consensus if 
> `scope` (including `openid`) outside a request object is still required even 
> after JAR is enabled.
> 
> In short, my question is "Should `scope` be omitted?" I guess that the 
> conclusion will affect the official conformance suite.
> 
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
> 
> 
> 
> On Tue, Sep 22, 2020 at 5:59 AM Vladimir Dzhuvinov  > wrote:
> Hi Taka,
> 
> On 21/09/2020 20:12, Takahiko Kawasaki wrote:
>> If we allow JAR (JWT Secured Authorization Request) to relax the requirement 
>> of `response_type` request parameter (outside a request object) from 
>> mandatory to optional, should we relax the following requirement of `scope` 
>> request parameter stated in OIDC Core 1.0 Section 6.1, too?
>> 
>> --
>> Even if a scope parameter is present in the Request Object value, a scope 
>> parameter MUST always be passed using the OAuth 2.0 request syntax 
>> containing the openid scope value to indicate to the underlying OAuth 2.0 
>> logic that this is an OpenID Connect request.
>> --
>> 
>> Otherwise, an authorization request like "client_id=...(_uri)=..." 
>> fails if the request object represents an OIDC request. An authorization 
>> request has to look like "client_id=...(_uri)=...=openid" 
>> (`scope` including `openid` has to be given) even if the authorization 
>> server conforms to JAR and allows omission of `response_type` request 
>> parameter.
> The bottom of section 5 has normative text which allows a JAR compliant 
> server to also comply with the OIDC spec with its own style of request / 
> request_uri parameter handling insofar as to not reject other query params 
> (such as scope, etc). The difference is that according to JAR 

Re: [OAUTH-WG] WGLC Review of PAR

[Justin Richer]

Nice work, Brian. Looks good to me! 

From: Brian Campbell [bcampb...@pingidentity.com]
Sent: Wednesday, September 2, 2020 3:41 PM
To: Justin Richer
Cc: Takahiko Kawasaki; Torsten Lodderstedt; oauth
Subject: Re: [OAUTH-WG] WGLC Review of PAR

Thanks Torsten, Taka, and Justin,

I took the revised text from Justin and tweaked it with some typo cleanup and 
minor adjustments to make what is hopefully a final proposal below. I had a 
similar feeling about the last paragraph not really fitting but don't have a 
better location to suggest so am just leaving it.

2.4. Management of Client Redirect URIs

While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri 
values in certain circumstances, or for the authorization server to apply its 
own matching semantics to the redirect_uri value presented by the client at the 
authorization endpoint, the OAuth Security BCP [I-D.ietf-oauth-security-topics] 
as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] require an authorization server 
exactly match the redirect_uri parameter against the set of redirect URIs 
previously established for a particular client. This is a means for early 
detection of client impersonation attempts and prevents token leakage and open 
redirection. As a downside, this can make client management more cumbersome 
since the redirect URI is typically the most volatile part of a client policy.

The exact matching requirement MAY be relaxed by the authorization server for a 
confidential client using pushed authorization requests since the authorization 
server authenticates the client before the authorization process starts and 
thus ensures it is interacting with the legitimate client. The authorization 
server MAY allow such clients to specify redirect_uri values that were not 
previously registered with the authorization server. This will give the client 
more flexibility (e.g. to mint distinct redirect URI values per authorization 
server at runtime) and can simplify client management. It is at the discretion 
of the authorization server to apply restrictions on supplied redirect_uri 
values, e.g. the authorization server MAY require a certain URI prefix or allow 
only a query parameter to vary at runtime.

The ability to set up transaction specific redirect URIs is also useful in 
situations where client ids and corresponding credentials and policies are 
managed by a trusted 3rd party, e.g. via client certificates containing client 
permissions. Such an externally managed client could interact with an 
authorization server trusting the respective 3rd party without the need for an 
additional registration step.

On Wed, Sep 2, 2020 at 8:09 AM Justin Richer 
mailto:jric...@mit.edu>> wrote:
The real conflict here is with the BCP and 2.1, both of which adopt the 
stricter matching semantics for redirect URIs than 6749 does on its own. This 
section would be needed to clarify how they relate to each other. That said, I 
think adding some of Taka’s observations to Torsten’s text wouldn’t hurt:

2.4. Management of redirect_uri

While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri 
values in certain circumstances, or for the AS to apply its own matching 
semantics to the redirect_uri value presented by the client at the 
authorization endpoint, the OAuth Security BCP [I-D.ietf-oauth-security-topics] 
as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] require an AS to excactly match the 
redirect_uri parameter against the set of redirect URIs previously established 
for a particular client. This is a means to early detect attempts to 
impersonate a client and prevent token leakage and open redirection. As a 
downside, it makes client management more complex since the redirect URI is 
typically the most volatile part of a client policy.

This requirement MAY be relaxed by the AS if a confidential client uses pushed 
authorization requests since the AS authenticates the client before the 
authorization process starts and that way ensures it interacts with the legit 
client. The AS MAY allow such clients to specify redirect_uri values not 
previously registered with the AS. This will give the client more flexibility 
(e.g. to mint AS-specific redirect URIs on the fly) and makes client management 
much easier. It is at the discretion of the AS to apply restriction on 
redirect_uri values, e.g. the AS MAY require a certain URI prefix or allow only 
a query parameter to vary at runtime.

I also feel like this paragraph belongs in a different section outside of here. 
I’m not sure where, but it doesn’t quite seem to fit, to me. It’s not the end 
of the world if it stays here though as it’s a decent view on the “why".

The aibility to set up transaction specific redirect URIs is also useful in 
situations where client ids and correspoding credentials and policies are 
managed by a trusted 3rd party, e.g. via client certifiates containing client 
permissions. Such an externally managed c

Re: [OAUTH-WG] WGLC Review of PAR

[Justin Richer]

 the client more 
> flexibility (e.g. to mint AS-specific redirect URIs on the fly) and makes 
> client management much easier. It is at the discretion of the AS to apply 
> restriction on redirect_uri values, e.g. the AS MAY require a certain URI 
> prefix or allow only a query parameter to vary at runtime.
> 
> Note: The aibility to set up transaction specific redirect URIs is also 
> useful in situations where client ids and correspoding credentials and 
> policies are managed by a trusted 3rd party, e.g. via client certifiates 
> containing client permissions. Such an externally managed client could 
> interact with an AS trusting the respective 3rd party without the need for an 
> additional registration step.
> 
> > On 29. Aug 2020, at 17:22, Justin Richer  > <mailto:jric...@mit.edu>> wrote:
> > 
> > I completely agree with the utility of the function in question here and it 
> > needs to be included. I’m in favor of creating a dedicated section for 
> > redirect_uri management, so that we can explain exactly how and why to 
> > relax the requirement from core OAuth. In addition, I think we want to 
> > discuss that the AS might have its own restrictions on which redirect URIs 
> > an authenticated client might be able to use. For example, registering a 
> > client with a Redirect URI prefix, or allowing only a query parameter to 
> > vary at runtime. All of these can be enforced in PAR because the client is 
> > presenting its authentication, as you point out, so the AS can determine 
> > which policies should apply.
> > 
> > — Justin
> > 
> >> On Aug 29, 2020, at 7:52 AM, Torsten Lodderstedt  >> <mailto:tors...@lodderstedt.net>> wrote:
> >> 
> >> 
> >>> 
> >>> 
> >>>   ¶6: Does the AS really have "the ability to authenticate and authorize 
> >>> clients”? I think what we mean here is "the ability to authenticate 
> >>> clients and validate client requests”, but I’m not positive of the 
> >>> intent. 
> >>> 
> >>> I think the intent is that the AS can check whether a client is 
> >>> authorized to make a particular authorization request (specific scopes, 
> >>> response type, etc.). But checking authorization to request authorization 
> >>> is confusing wording. I think your working is less confusing and still 
> >>> allows for the intent. 
> >>> 
> >>> I'll let Torsten interject if he feels differently as I think he 
> >>> originally wrote the text in question. 
> >> 
> >> that was the original intent. I think “validate" is fine. 
> >> 
> >>> 
> >>> 
> >>> 
> >>>   ¶7: I’m not sure I buy this example. Even if the clientID is managed 
> >>> externally, the association with a set or pattern of allowed redirect 
> >>> URIs is still important, and the AS will need to know what that is. I 
> >>> think this example could lead an AS developer to (erroneously and 
> >>> dangerously) conclude that they don’t have to check any other values in a 
> >>> request, including scope and redirect URI. It’s important that DynReg 
> >>> doesn’t alleviate that issue, but removal of DynReg doesn’t really change 
> >>> things in that regard. Suggest removing example or reworking paragraph.
> >>> 
> >>> I'm going to have to defer to Torsten on this because, to be honest, I'm 
> >>> not too sure about it myself. I tend to lean towards thinking the draft 
> >>> would be better off without it. 
> >>> 
> >> 
> >> In the traditional authorization flow, the redirect_uri serves as way to 
> >> make sure the AS is really talking to the legit client and the allowed 
> >> redirect_uri values are determined by the legit client at registration 
> >> time (might be manually).
> >> 
> >> With PAR, we have a much stronger means to ensure the AS is talking to the 
> >> legit client. That’s why I don’t see an issue with letting the client set 
> >> a per transaction redirect_uri. This will give the client more flexibility 
> >> (mint AS-specific redirect URIs on the fly) and makes client management 
> >> much easier since redirect URIs are the most volatile part of a client 
> >> policy. 
> >> 
> >> It also makes use of OAuth much easier in deployments where client 
> >> identities are managed by external entities (even without any idea of 
> >> OAuth). A prominent example is open banking in the EU (aka PSD2). The 
> >>

Re: [OAUTH-WG] Towards an RFC Errata to RFC 7662 ?

[Justin Richer]

I’m not sure that adding this amount of text to the privacy considerations 
section is appropriate for an errata. If we wanted to do this, I believe we’d 
need to do a new revision of 7662.

 — Justin

> On Sep 2, 2020, at 4:39 AM, Denis  wrote:
> 
> Hi Ben,
> 
> This new thread, i.e."Towards an RFC Errata to RFC 7662 ?" is used to discuss 
> one of the topics raised in: 
> Last Call:  (JWT Response 
> for OAuth Token Introspection) to Proposed Standard
> 
> Only the text relevant to this topic has been left.
> 
> The text that has been discussed and polished would perfectly fit into the 
> Privacy Consideration section from RFC 7662.
> 
> Here it is again:
> 
> Implementers should be aware that a token introspection request lets the AS 
> know when the client is accessing the RS, 
> which can also indicate when the user is using the client.  If this 
> implication is not acceptable, implementers can use 
> other means to carry access token data, e.g. directly transferring the data 
> needed by the RS within the access token.
> Privacy considerations sections do not change the protocol but only provide 
> some warnings. Warning the implementers is fine, 
> but warning the users and the clients should also be considered.
> 
> Thanks to your observations, I noticed that the sentence "the call described 
> in OAuth Introspection [RFC 7662] should be avoided" 
> is not appropriate. So I propose an additional text which is relevant for the 
> users:
> 
> Token introspection is an optional feature primarily intended for clients 
> that are unable to support structured access tokens, including their 
> validation. 
> However, the use of this call allows an AS to track where and exactly when 
> clients or users have indeed presented an issued access token to a RS. 
> Some users or clients may be concerned that such a feature allows the AS to 
> accurately trace them. If no Token introspection endpoint is published by an 
> AS, 
> users and clients can be confident that such tracing cannot happen. On the 
> contrary, when an introspection_endpoint is published by an AS [RFC8414], 
> users and clients have no way to know whether the RS will be allowed to use 
> it, nor whether it will effectively use it. If these implications are not 
> acceptable, 
> users or clients should not use an AS that publishes an 
> introspection_endpoint.
> Denis
> 
>> Hi all,
>> 
>> On Mon, Aug 31, 2020 at 09:58:11AM +0200, Denis wrote:
>>> The last text that has been proposed on the list about this thread is 
>>> the following:
>>> 
>>> Implementers should be aware that a token introspection request lets the AS 
>>> know when the client is accessing the RS, 
>>> which can also indicate when the user is using the client.  If this 
>>> implication is not acceptable, implementers can use 
>>> other means to carry access token data, e.g. directly transferring the data 
>>> needed by the RS within the access token.
>>> 
>>> The concerns of the implementers have nothing to do with the concerns of 
>>> the Users. Such a text proposal has nothing to do with a "User consent".
>>> 
>>> *Towards an RFC Errata to RFC 7662*
>>> 
>>> Mike Jones wrote:
>>> 
>>> 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.
>>> 
>>> I fully agree.
>>> 
>>> RFC 7662 should have incorporated a more detailed content such as:
>>> 
>>>   In OAuth 2.0 [RFC6749], the contents of tokens are opaque to 
>>> clients. However, the contents of tokens is not intended to be opaque to 
>>> RSs.
>>>   Token introspection is an OPTIONAL feature of an AS described in 
>>> OAuth Introspection [RFC 7662] intended for clients that are unable
>>>   to support structured access tokens including their validation. 
>>> The use of this call allows an AS to track where and when its clients 
>>> have indeed
>>>   presented an issued access token. As soon as the RS knows the 
>>> format of the access token, e.g. using structured token formats such as
>>>   JWT [RFC7519], and is able to validate its security features, the 
>>> call described in OAuth Introspection [RFC 7662] should be avoided, 
>>> otherwise
>>>   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. As soon as this call is 
>>> supported by an AS, the client or the user have no way to prevent the RS 
>>> to use it.
>>> 
>>> It might be useful to add it, e.g. using an RFC Errata.
>> I do not believe this would be an appropriate usage of an Errata Report --
>> it changes the meaning of the RFC away from what the WG intended at the
>> time of publication.
>> 
>> Use of tokens that are just opaque 

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

[Justin Richer]

Thanks, Dick. I agree with removing the excess parenthetical, but I 
intentionally avoided using a lowercase “may” in the middle of the text  (in 
favor of “can”) to avoid normative-sounding non-normative language, so I’d 
recommend that change be kept:

Implementers should be aware that a token introspection request lets the AS 
know when the client 
is accessing the RS, which can also indicate when the user is using 
the client. If this implication is not acceptable, implementers can use 
other means to carry 
access token data, e.g. directly transferring the data needed by the RS 
within the access token.

> On Aug 27, 2020, at 12:15 PM, Dick Hardt  wrote:
> 
> Here is a crisper revision.
> 
> Implementers should be aware that a token introspection request lets the AS 
> know when the client 
> is accessing the RS, which may indicate when the user is using 
> the client. If this implication is not acceptable, implementers can use 
> other means to carry 
> access token data, e.g. directly transferring the data needed by the RS 
> within the access token.
> ᐧ
> 
> On Thu, Aug 27, 2020 at 7:19 AM Justin Richer  <mailto:jric...@mit.edu>> wrote:
> I would clarify that this doesn’t necessarily say that the user’s there, and 
> remove the normative requirement (which doesn’t have enforceable teeth in 
> this context):
> 
> Implementers should be aware that a token introspection request lets the AS 
> know when the client 
> (and potentially the user) is accessing the RS, which can also indicate 
> when the user is using 
> the client. If this implication is not acceptable, implementers can use 
> other means to carry 
> access token data, e.g. directly transferring the data needed by the RS 
> within the access token.
> 
> 
>  — Justin
> 
>> On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt 
>> > <mailto:torsten=40lodderstedt@dmarc.ietf.org>> wrote:
>> 
>> Will the following text work for you?
>> 
>> Implementers should be aware that a token introspection request lets the AS 
>> know when the client 
>> (and potentially the user) is accessing the RS, which is also an 
>> indication of when the user is using 
>> the client. If this impliction is not accepatable, implementars MUST use 
>> other means to carry 
>> access token data, e.g. directly transferring the data needed by the RS 
>> within the access token.
>> 
>> 
>>> On 26. Aug 2020, at 23:12, Mike Jones 
>>> >> <mailto:Michael.Jones=40microsoft@dmarc.ietf.org>> wrote:
>>> 
>>> 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 mailto:oauth-boun...@ietf.org>> On 
>>> Behalf Of Dick Hardt
>>> Sent: Wednesday, August 26, 2020 9:52 AM
>>> To: Torsten Lodderstedt >> <mailto:torsten=40lodderstedt@dmarc.ietf.org>>
>>> Cc: last-c...@ietf.org <mailto:last-c...@ietf.org>; oauth >> <mailto:oauth@ietf.org>>
>>> 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:torsten=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 <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth 
>> <https://www.ietf.org/mailman/listinfo/oauth>
> 

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

Re: [OAUTH-WG] WGLC Review of PAR

[Justin Richer]

I completely agree with the utility of the function in question here and it 
needs to be included. I’m in favor of creating a dedicated section for 
redirect_uri management, so that we can explain exactly how and why to relax 
the requirement from core OAuth. In addition, I think we want to discuss that 
the AS might have its own restrictions on which redirect URIs an authenticated 
client might be able to use. For example, registering a client with a Redirect 
URI prefix, or allowing only a query parameter to vary at runtime. All of these 
can be enforced in PAR because the client is presenting its authentication, as 
you point out, so the AS can determine which policies should apply.

 — Justin

> On Aug 29, 2020, at 7:52 AM, Torsten Lodderstedt  
> wrote:
> 
> 
>> 
>> 
>>¶6: Does the AS really have "the ability to authenticate and authorize 
>> clients”? I think what we mean here is "the ability to authenticate clients 
>> and validate client requests”, but I’m not positive of the intent. 
>> 
>> I think the intent is that the AS can check whether a client is authorized 
>> to make a particular authorization request (specific scopes, response type, 
>> etc.). But checking authorization to request authorization is confusing 
>> wording. I think your working is less confusing and still allows for the 
>> intent. 
>> 
>> I'll let Torsten interject if he feels differently as I think he originally 
>> wrote the text in question. 
> 
> that was the original intent. I think “validate" is fine. 
> 
>> 
>> 
>> 
>>¶7: I’m not sure I buy this example. Even if the clientID is managed 
>> externally, the association with a set or pattern of allowed redirect URIs 
>> is still important, and the AS will need to know what that is. I think this 
>> example could lead an AS developer to (erroneously and dangerously) conclude 
>> that they don’t have to check any other values in a request, including scope 
>> and redirect URI. It’s important that DynReg doesn’t alleviate that issue, 
>> but removal of DynReg doesn’t really change things in that regard. Suggest 
>> removing example or reworking paragraph.
>> 
>> I'm going to have to defer to Torsten on this because, to be honest, I'm not 
>> too sure about it myself. I tend to lean towards thinking the draft would be 
>> better off without it. 
>> 
> 
> In the traditional authorization flow, the redirect_uri serves as way to make 
> sure the AS is really talking to the legit client and the allowed 
> redirect_uri values are determined by the legit client at registration time 
> (might be manually).
> 
> With PAR, we have a much stronger means to ensure the AS is talking to the 
> legit client. That’s why I don’t see an issue with letting the client set a 
> per transaction redirect_uri. This will give the client more flexibility 
> (mint AS-specific redirect URIs on the fly) and makes client management much 
> easier since redirect URIs are the most volatile part of a client policy. 
> 
> It also makes use of OAuth much easier in deployments where client identities 
> are managed by external entities (even without any idea of OAuth). A 
> prominent example is open banking in the EU (aka PSD2). The (technical) 
> identity of any PSD2-licensed client is asserted by an eIDAS compliant CA in 
> a special X.509 certificate. Those certificates contain the permissions 
> (access to account information and/or payment initiation allowed) and the 
> identity (member state specific). But they don’t contain OAuth policy values. 
> Nevertheless, the regulation requires any financial institution in the EU to 
> at runtime, without any registration, to accept and process calls from any 
> licensed PSD2 clients.
> 
> There are two ways to cope with it in OAuth context:
> a) use dynamic client registration with the X.509 cert as credential. 
> Unfortunately, RFC 7591 does not support other client authentication means 
> then an initial access token. Beside that, it would violate the text of the 
> regulation. 
> b) establish a redirect URL with every transaction. This is the recommended 
> approach in at least one of the PSD2 specs.
> 
> PAR is a clean way to solve that problem. 
> 
> I don’t want this text to cause confusing. On the other hand this potential 
> of PAR is way too important to not mention it at all. What about moving it 
> into a special section "redirect_uri management”?
> 
>> 
> 

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

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

[Justin Richer]

I would clarify that this doesn’t necessarily say that the user’s there, and 
remove the normative requirement (which doesn’t have enforceable teeth in this 
context):

Implementers should be aware that a token introspection request lets the AS 
know when the client 
(and potentially the user) is accessing the RS, which can also indicate 
when the user is using 
the client. If this implication is not acceptable, implementers can use 
other means to carry 
access token data, e.g. directly transferring the data needed by the RS 
within the access token.


 — Justin

> On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt 
>  wrote:
> 
> Will the following text work for you?
> 
> Implementers should be aware that a token introspection request lets the AS 
> know when the client 
> (and potentially the user) is accessing the RS, which is also an 
> indication of when the user is using 
> the client. If this impliction is not accepatable, implementars MUST use 
> other means to carry 
> access token data, e.g. directly transferring the data needed by the RS 
> within the access token.
> 
> 
>> On 26. Aug 2020, at 23:12, Mike Jones 
>>  wrote:
>> 
>> 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 
>>  wrote:
>> Hi Denis,
>> 
>>> On 25. Aug 2020, at 16:55, Denis  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

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

Re: [OAUTH-WG] WGLC Review of PAR

[Justin Richer]

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  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 client auth and protocol parameters got 
>> mixed together in the HTTP body. I didn't cause that situation but I've 
>> certainly contributed to it and for that I apologize. 
> 
> I think the only perfect solution is to go back in time and fix the 
> registries with based on the last decade of knowledge in using them. :P 
> 
> For this, I think maybe being very prescriptive about the fact that the only 
> parameters from the token endpoint that are allowed here are those used for 
> client authentication and that when they show up, they’re interpreted as in 
> the token endpoint request not the authorization endpoint request. Does that 
> work?
> 
> I think so, yes. And will work on incorporating some text towards that end. 
> 
> 
>  
>> I don’t see why a request URI with unguessable values isn’t a MUST for 
>> one-time-use, is there a reason?
>> 
>> The reason AFAIK was to n

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

[Justin Richer]

I would argue that by the nature of OAuth tokens not being bound to user 
presence or sessions, it’s not an indication that the user is present 
necessarily, unless you know something additional about the nature of the 
client. But it does tell the AS when the client is active for a particular AS, 
which in some cases is a privacy concern and in others it’s a signal into the 
AS for keeping an eye out for aberrant behavior that a single RS couldn’t 
detect.

This is all a general implication of the introspection process, and not unique 
to this draft. That said, it’s an aspect of privacy that we did not cover in 
the considerations for RFC7662, but I don’t know if it’s appropriate to add 
such a general consideration here.

 — Justin

> On Aug 26, 2020, at 12:52 PM, Dick Hardt  wrote:
> 
> 
> 
> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt 
>  > wrote:
> Hi Denis,
> 
> > On 25. Aug 2020, at 16:55, Denis  > > 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

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

Re: [OAUTH-WG] WGLC Review of PAR

[Justin Richer]

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  
> 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.
> 
> For additional context, I’ve implemented this specification for both a client 
> and a server in a couple of languages. Overall, I think it’s in good shape 
> and it makes sense from a developer’s perspective. I’ve got a few comments, 
> some small and some that might need more conversation within the WG,
> 
> Always nice to get feedback from implementation experience. Especially when 
> the overall is that it's "in good shape".
> 
> 
> Throughout: Suggest using “credentialed” instead of “confidential” client, as 
> introduced in OAuth 2.1 draft.
> 
> I'm hesitant to use *new* terminology from the 2.1 draft, which was just 
> recently adopted by the WG, in this document that is written as an extension 
> of OAuth 2.0 and is further along in the process going through WGLC. There's 
> a temporal dependency problem including potential risk of change after the 
> fact. 
> 
> Perhaps this draft could avoid use of the terms and be more explicit and 
> wordy with something like "clients having established authentication 
> credentials with the AS"? 

Fair point about the terminology, and while it’s verbose I think the more 
precise wording might be warranted here so as not to extend the problems and 
confusion with “confidential” clients as a term.

> 
>  
> §1: Suggest the problems list start with changing scopes or swapping client 
> IDs as scenarios in the first bullet, ACR is an esoteric use case for many 
> and not in OAuth 2 core, either remove it or put it at the end of the bullet.
> 
> Fair suggestion. Will look at reworking it a bit. 
>  
> 
>Suggest the second bullet note who the information needs to be protected 
> from, at least in passing. It’s not clear from this setup why the parameters 
> should be confidential, and this is a major motivation for this work.
> 
> Also a fair suggestion. Although there are some subtleties and complexities 
> that I think make this a little tricky to write. Will try though. 
> 
>  
>Avoid use of phrase “so-called” and just give the name “Request Object”.
> 
> Okay, yeah. I think a moment of terminology frustration slipped into the text 
> there. 
>  
> 
> 
>¶4: Perhaps overly pedantic but I suggest extending: “in exchange for a 
> request_uri value usable at the authorization server”. 
> 
> I like the pedanticness. 
>  
> 
>¶4/5: Alternatively, suggest combining these paragraphs: “This document 
> complements JAR by providing an interoperable way for the client to push its 
> authorization request parameters to the authorization server in exchange for 
> a request_uri usable at the authorization server. The document further allows 
> the client to push request objects as specified in JAR in exchange for a 
> request_uri usable at the authorization server.”
> 
>  Yeah, I think that working works better. 
> 
>  
> ¶12: “This is directly utilized” is a little ambiguous into what it’s 
> referring to. Would suggest rewording the start as: “This early stage client 
> authentication is used by this draft to allow confidential clients…” or 
> something of that sort.
> 
> Makes sense to be less ambiguous there. 
>  
> 
> ¶13: Not only is POST much harder to use, it’s also optional for the AS 
> to implement so it can’t be counted on by a client to be available generally. 
> (To be honest in retrospect we shouldn’t have included it in OAuth 2.)
> 
> Connect says the AS/OP must support both get and post. But your point on 
> optionality stands with respect to pure OAuth only ASs. Will add something 
> about that to the paragraph. 
>  
> 
> §2: Please provide a reference to JWT client assertion auth here (either the 
> assertion RFC or OIDC’s definition of the client auth methods mentioned). I 
> would also phrase this as direct guidance instead of a note/aside.
> 
> Will do. 
>  
> 
> §2.1: There’s some potential weirdness about client_id here. Since the authz 
> request was designed around not having client authentication, that request 
> requires client_id. However, here the client is authenticating, and the 
> client_id might be included elsewhere like the Basic header. A developer 
> might be curious about whether they need to include them twice.
> 
> Fair point ab

[OAUTH-WG] WGLC Review of PAR

[Justin Richer]

I’ve done a full read through of the PAR specification, and here are my notes 
on it.

For additional context, I’ve implemented this specification for both a client 
and a server in a couple of languages. Overall, I think it’s in good shape and 
it makes sense from a developer’s perspective. I’ve got a few comments, some 
small and some that might need more conversation within the WG,



Throughout: Suggest using “credentialed” instead of “confidential” client, as 
introduced in OAuth 2.1 draft.

§1: Suggest the problems list start with changing scopes or swapping client IDs 
as scenarios in the first bullet, ACR is an esoteric use case for many and not 
in OAuth 2 core, either remove it or put it at the end of the bullet.

   Suggest the second bullet note who the information needs to be protected 
from, at least in passing. It’s not clear from this setup why the parameters 
should be confidential, and this is a major motivation for this work.

   Avoid use of phrase “so-called” and just give the name “Request Object”.

   ¶4: Perhaps overly pedantic but I suggest extending: “in exchange for a 
request_uri value usable at the authorization server”.. 

   ¶4/5: Alternatively, suggest combining these paragraphs: “This document 
complements JAR by providing an interoperable way for the client to push its 
authorization request parameters to the authorization server in exchange for a 
request_uri usable at the authorization server. The document further allows the 
client to push request objects as specified in JAR in exchange for a 
request_uri usable at the authorization server.”

¶12: “This is directly utilized” is a little ambiguous into what it’s 
referring to. Would suggest rewording the start as: “This early stage client 
authentication is used by this draft to allow confidential clients…” or 
something of that sort.

¶13: Not only is POST much harder to use, it’s also optional for the AS to 
implement so it can’t be counted on by a client to be available generally. (To 
be honest in retrospect we shouldn’t have included it in OAuth 2.)

§2: Please provide a reference to JWT client assertion auth here (either the 
assertion RFC or OIDC’s definition of the client auth methods mentioned). I 
would also phrase this as direct guidance instead of a note/aside.

§2.1: There’s some potential weirdness about client_id here. Since the authz 
request was designed around not having client authentication, that request 
requires client_id. However, here the client is authenticating, and the 
client_id might be included elsewhere like the Basic header. A developer might 
be curious about whether they need to include them twice.

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

¶6: Does the AS really have "the ability to authenticate and authorize 
clients”? I think what we mean here is "the ability to authenticate clients and 
validate client requests”, but I’m not positive of the intent. 

¶7: I’m not sure I buy this example. Even if the clientID is managed 
externally, the association with a set or pattern of allowed redirect URIs is 
still important, and the AS will need to know what that is. I think this 
example could lead an AS developer to (erroneously and dangerously) conclude 
that they don’t have to check any other values in a request, including scope 
and redirect URI. It’s important that DynReg doesn’t alleviate that issue, but 
removal of DynReg doesn’t really change things in that regard. Suggest removing 
example or reworking paragraph.

§2.2: Is “expires_in” required? If so, can an AS decide that a request URI 
doesn’t expire after a certain amount of time? Related, what does a “0” or 
negative value mean, if anything? 

I don’t see why a request URI with unguessable values isn’t a MUST for 
one-time-use, is there a reason?

§2.3: Are the HTTP status codes a normative MAY or just an informative “can” as 
written?

§3: This bit should be normative as follows: "he authorization server MUST take 
the following steps beyond the processing rules…"

Clean up the tenses and voice of the numbered list, which are currently 
inconsistent.

§7.2: The AS should also make sure that the new redirect URI is applicable 
within that client’s domain or policies. So you wouldn’t want a legit-but-rogue 
client registering for someone else’s redirect URI in order to start an attack, 
for example. I think overall we might need better guidance around the redirect 
URI variability feature (which, to be clear, I’m hugely in favor of — but 
OAuth’s assumptions in the client model make this trickier to talk about and 
implement safely, so we need to be extra careful).

§7.3: As above, is there a reason that this isn’t a MUST? It’s a temporary 
credential representing a 

[OAUTH-WG] OAuth v.2.1 Readthrough

[Justin Richer]

As promised on the WG call, I’ve gone through the 2.1 document and I’ve made 
some notes and suggestions on my way through. A big thanks to the editors for 
putting this together, and particularly for Aaron who did the early heavy 
lifting on getting a reasonable start on this important work!

But first, a note: I realize that many portions of this are simply copied from 
6749 or related specifications, and I do not fault the editors for that. Even 
so, there are some places where the old language should be updated in this 
draft, since we have an opportunity to fix things and make them more readable 
on our way through. There are also a number of places that are redundant with 
each other as they clearly come from different source documents. A major goal 
of this work is to coalesce these differences into a single and easily 
understandable framework.



§Abstract

I think we should update “interaction between the RO and the HTTP Service” to 
be “the RO and an authorization service” or something like that instead, since 
“the HTTP service” referenced elsewhere in this paragraph is more precisely the 
RS and not the AS, yet the interaction and approval happens at the AS. OAuth 
2.0 allowed the AS and RS to be separate, and 2.1 should go further to admit 
that in a lot of cases today, they are separate. 

There’s been debate on the “replaces and obsoletes” language already, and I 
think there’s a lot of IETF process that we’ll need to sort out to get that 
language right.


§1: We should add a note on password use to this list:

 - Often the resource owner’s password is used with other unrelated services, 
and the additional exposure of sharing the password among components in one 
domain lowers the possible security in other domains where the password is 
shared.


  ¶3/4 can probably be collapsed to read better, and some of the language 
cleaned up. Recommend:

OAuth addresses these issues by introducing an authorization layer and 
separating the role of the client from that of the resource owner. In OAuth, 
the client requests access to resources controlled by the resource owner and 
hosted by the resource server. Instead of using the resource owner's 
credentials to access protected resources, the client obtains an access token - 
a credential representing a specific set of access attributes such as scope and 
lifetime. Access tokens are issued to clients by an authorization server with 
the approval of the resource owner. The client uses the access token to access 
the protected resources hosted by the resource server.

  ¶6: (and throughout document) avoid use of gendered pronouns in favor of 
singular “they” unless needed for clearer reading (such as an Alice and Bob 
scenario)

§1.2: This diagram could use an update to not show the client talking directly 
to the RO in the first step, especially because the ROPC grant has been removed 
here. The way it’s written now makes it look like the user gives something to 
the client which it then trades for a token directly, which doesn’t happen 
quite like that anywhere.

§1.3: Having taught many OAuth 2 classes to hundreds of people over the years, 
I can say with confidence that this definition of “grant” as a credential has 
historically been problematic and confusing to most people. And in particular, 
it doesn’t even really apply to the client credentials flow listed here: there 
is not a separate "credential representing authorization", just the client’s 
own authentication. Suggest new text to more accurately reflect what a “grant” 
is in the OAuth reality:

An authorization grant is a process by which a client obtains authorization 
from a resource owner to obtain an access token to act on that resource owner’s 
behalf. This specification defines...

Changing this would require a consensus call 

§1.3.X: I don’t see why we shouldn’t list the Device Flow here in this spec. 
It’s mentioned as an extension later, but we might as well list it here as a 
known and accepted grant type. 

§1.4: This section should mention introspection explicitly. Recommend rewriting 
the intro to ¶3:

The token make be used by the RS to retrieve the authorization information, or 
the token may self-contain the authorization information in a verifiable manner 
(i.e., a token string consisting of a signed data payload). One example of a 
token retrieval mechanism is Token Introspection [RFC7662], in which the RS 
calls an endpoint on the AS to validate the token presented by the client. One 
example of a structured token …

We may also want to mention CWT (RFC8392) here in passing. 

§1.5: “The string is usually opaque” should be “the string is opaque"

§1.6: this should probably refer to the TLS BCP195 here instead of the RFC and 
version.

§1.8: This should have explicit links to introspection (RFC7662), registration 
(RFC7591, RFC7592), and discovery (RFC8414) inline as they’re given as 
examples, instead of putting them all in the appendix. Perhaps also bring up 
JWTs