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

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

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

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

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

[Justin Richer]

Aaron,

The “request_uri” comes from OIDC originally, and is redefined in JAR. The 
original idea was to have a URL that the AS/IdP would be able to fetch to get a 
Request Object from, which is why JAR used to have language about “it MUST be 
fetchable and resolve to a JWT” (or something like that). JAR has backed off 
that requirement now (I believe), but those roots are still in the name. RAR 
opts to re-use that mechanism instead of inventing either a new parameter or 
returning a full Redirection URI.

 — Justin

> On Jul 24, 2020, at 3:12 AM, Torsten Lodderstedt 
>  wrote:
> 
> Hi Aaron, 
> 
> that’s a very good point. I was also in favour of just providing the client 
> with the URL it needs to send the user to (like XYZ and OAuth do). 
> 
> In the end, we decided to stay with the current approach since it fits with 
> the rest of the existing ecosystem, namely JAR and authorization endpoint 
> discovery. 
> 
> best regards,
> Torsten. 
> 
>> On 24. Jul 2020, at 00:49, Aaron Parecki  wrote:
>> 
>> I know this is a bit of an old thread to dig up, but as I'm working through 
>> this draft again, something is sticking out to me about this.
>> 
>> In every other instance of "*_uri" in OAuth and extensions, the value is a 
>> URI (usually https) which will be visited by the user's browser or be sent a 
>> POST request from a client. In the case of PAR, this "request_uri" is 
>> actually just an identifier that is *added* to an existing URL, the 
>> authorization endpoint, not a URL that will be visited itself. This 
>> discrepancy is bothering me.
>> 
>> I would have expected that either:
>> 
>> * The PAR response includes a "request_uri" which is the full URL that the 
>> client would redirect the user's browser to, OR
>> * The PAR response includes a "request_id" which it adds in the query string 
>> to the authorization endpoint and then redirects the browser to
>> 
>> For example:
>> 
>> POST /as/par HTTP/1.1
>> ...
>> response:
>> {
>>  "request_uri": 
>> "https://as.example.com/auth?request=bwc4JK-ESC0w8acc191e-Y1LTC2";,
>>  "expires_in": 60
>> }
>> 
>> then the user's browser is sent to whatever the value of "request_uri" is
>> 
>> OR
>> 
>> POST /as/par HTTP/1..1
>> ...
>> response:
>> {
>>  "request_id": 
>> "urn:ietf:params:oauth:request_uri:bwc4JK-ESC0w8acc191e-Y1LTC2",
>>  "expires_in": 60
>> }
>> 
>> then the "request_id" is added to the authorization endpoint (as currently 
>> described by PAR)
>> 
>> https://as.example.com/auth?client_id=s6BhdRkqt3&request_uri=urn%3Aietf%3Aparams%3Aoauth%3Arequest_uri%3Abwc4JK-ESC0w8acc191e-Y1LTC2
>> 
>> My personal preference is the first option, keeping the term "request_uri" 
>> but having it actually be the full URI, to simplify the job of the client. 
>> In that model, the client doesn't have to mess with building URLs, and 
>> actually provides additional flexibility for the AS as well since that 
>> endpoint no longer needs to be the exact same URL as the authorization 
>> endpoint.. 
>> 
>> ---
>> Aaron Parecki
>> https://aaronparecki.com
>> 
>> 
>> On Thu, Jan 16, 2020 at 8:25 AM Torsten Lodderstedt 
>>  wrote:
>> I just thought about another option. What if we change PAR to not use the 
>> request_uri parameter but a new parameter, e.g. request_id?
>> 
>> That would decouple both specs. The reason why we use request_uri was to 
>> make the life of clients easier since they can use the standard library 
>> function for request objects to pass the PAR reference to the AS. Is this 
>> worth the trouble?
>> 
>>> Am 16.01.2020 um 16:48 schrieb Justin Richer :
>>> 
>>> +1 to this approach, and it sounds like JAR might need to come back to go 
>>> through another round anyway thanks to the breaking changes the IESG pushed 
>>> into it after it left WGLC.
>>> 
>>> I’d rather see us get this right than publish something many of us think is 
>>> broken. 
>>> 
>>> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>>> 
>>> — 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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Namespacing "type" in RAR

[Justin Richer]

That’s fair — I think there’s value in reusable components but they don’t have 
to be controlled by a registry. I’ll back off the registry language for that 
bit and file an issue to that effect.

 — Justin

> On Jul 26, 2020, at 7:26 AM, Torsten Lodderstedt  
> wrote:
> 
> Hi,
> 
> the wording regarding type works for me.
> 
> Similar to Brian, I don’t understand how the data type registry is supposed 
> to work.
> 
> In my opinion, type and locations are completely different from the other 
> elements since they are required by the protocol itself. Their semantics must 
> not be changed by applications.
> 
> The other element types are reusable components, but I don’t understand how 
> an application or standard would refer to them, include them into there type 
> definition, and how overloading might happen. For example, are these elements 
> always included in the top level container or can they be used deeper in the 
> structure?
> 
> There are alternative solutions for reuse. I personally would use JSON 
> schemas to define such reusable elements and the authorization data types 
> utilizing them. 
> 
> I therefore don’t see the need for a RAR specific mechanism (a registry).
> 
> best regards,
> Torsten.
> 
>> Am 26.07.2020 um 02:48 schrieb Justin Richer :
>> 
>> Brian,
>> 
>> I can appreciate the confusion on the elements registry. It’s really about 
>> having a place to put re-usable components that people might use within 
>> their own “type” definitions, if they want to. The construct in use there is 
>> similar to what we used in Vectors of Trust (RFC8485), 
>> https://tools.ietf.org/html/rfc8485 <https://tools.ietf.org/html/rfc8485>
>> 
>> A VoT “trust framework” document can technically define whatever categories 
>> and values that it wants to. However, there is a registry for common 
>> categories, designed to be core dimensions applicable across a number of 
>> different trust frameworks. 
>> 
>> So the way that it works is that a “type” can redefine its own syntax and 
>> semantics for something like “actions” or “locations”, if it wants to, but 
>> the registry is giving people a place to look and say, “oh hey, someone 
>> already uses ‘actions’ in a general way, maybe that works for me and I can 
>> use that definition, or maybe I should find a different word”. So while 
>> “type” avoids the programmatic namespace collision of two different 
>> definitions of “action”, the registry helps to avoid developer confusion 
>> about having two different uses for the same word. 
>> 
>> It’s not foolproof, but it’s better than making every API designer start 
>> from a completely blank slate.
>> 
>>  — Justin
>> 
>>> On Jul 24, 2020, at 5:55 PM, Brian Campbell >> <mailto:bcampb...@pingidentity.com>> wrote:
>>> 
>>> I think I'm on board with the type being a just string and the guidance 
>>> provided about collision-resistance (rather than having a registry for 
>>> types or requiring type to be a URI or something along those lines). I 
>>> don't believe there's actually an issue with string comparison in that 
>>> context and so see no need for the draft to say anything special about it. 
>>> 
>>> In looking at the pull request, however, I'm surprised by there being a 
>>> registry for the data elements. And honestly confused about how that would 
>>> even work in practice. The contents of the authorization details object are 
>>> determined by the `type` parameter but there's also a registry of the 
>>> elements that can make up that content that are general across type. I 
>>> don't see how to reconcile that. 
>>> 
>>> On Mon, Jul 20, 2020 at 10:00 AM Justin Richer >> <mailto:jric...@mit.edu>> wrote:
>>> I created a pull request with some proposed language here:
>>> 
>>> https://github.com/oauthstuff/draft-oauth-rar/pull/52 
>>> <https://github.com/oauthstuff/draft-oauth-rar/pull/52>
>>> 
>>>  — Justin
>>> 
>>>> On Jul 20, 2020, at 7:42 AM, Justin Richer >>> <mailto:jric...@mit.edu>> wrote:
>>>> 
>>>> Since this is a recommendation for namespace, we could also just say 
>>>> collision-resistant like JWT, and any of those examples are fine. But that 
>>>> said, I think there’s something particularly compelling about URIs since 
>>>> they have somewhat-human-readable portions. But again, I’m saying it 
>>>> should be a recommendation to API developers and not a r

Re: [OAUTH-WG] Namespacing "type" in RAR

[Justin Richer]

Brian,

I can appreciate the confusion on the elements registry. It’s really about 
having a place to put re-usable components that people might use within their 
own “type” definitions, if they want to. The construct in use there is similar 
to what we used in Vectors of Trust (RFC8485), 
https://tools.ietf.org/html/rfc8485 <https://tools.ietf.org/html/rfc8485>

A VoT “trust framework” document can technically define whatever categories and 
values that it wants to. However, there is a registry for common categories, 
designed to be core dimensions applicable across a number of different trust 
frameworks. 

So the way that it works is that a “type” can redefine its own syntax and 
semantics for something like “actions” or “locations”, if it wants to, but the 
registry is giving people a place to look and say, “oh hey, someone already 
uses ‘actions’ in a general way, maybe that works for me and I can use that 
definition, or maybe I should find a different word”. So while “type” avoids 
the programmatic namespace collision of two different definitions of “action”, 
the registry helps to avoid developer confusion about having two different uses 
for the same word. 

It’s not foolproof, but it’s better than making every API designer start from a 
completely blank slate.

 — Justin

> On Jul 24, 2020, at 5:55 PM, Brian Campbell  
> wrote:
> 
> I think I'm on board with the type being a just string and the guidance 
> provided about collision-resistance (rather than having a registry for types 
> or requiring type to be a URI or something along those lines). I don't 
> believe there's actually an issue with string comparison in that context and 
> so see no need for the draft to say anything special about it. 
> 
> In looking at the pull request, however, I'm surprised by there being a 
> registry for the data elements. And honestly confused about how that would 
> even work in practice. The contents of the authorization details object are 
> determined by the `type` parameter but there's also a registry of the 
> elements that can make up that content that are general across type. I don't 
> see how to reconcile that. 
> 
> On Mon, Jul 20, 2020 at 10:00 AM Justin Richer  <mailto:jric...@mit.edu>> wrote:
> I created a pull request with some proposed language here:
> 
> https://github.com/oauthstuff/draft-oauth-rar/pull/52 
> <https://github.com/oauthstuff/draft-oauth-rar/pull/52>
> 
>  — Justin
> 
>> On Jul 20, 2020, at 7:42 AM, Justin Richer > <mailto:jric...@mit.edu>> wrote:
>> 
>> Since this is a recommendation for namespace, we could also just say 
>> collision-resistant like JWT, and any of those examples are fine. But that 
>> said, I think there’s something particularly compelling about URIs since 
>> they have somewhat-human-readable portions. But again, I’m saying it should 
>> be a recommendation to API developers and not a requirement in the spec. In 
>> the spec, I argue that “type” should be a string, full stop.
>> 
>> If documentation is so confusing that developers are typing in the wrong 
>> strings, then that’s bad documentation. And likely a bad choice for the 
>> “type” string on the part of the AS. You’d have the same problem with any 
>> other value the developer’s supposed to copy over.  :)
>> 
>> I agree that we should call out explicitly how they should be compared, and 
>> I propose we use one of the handful of existing string-comparison RFC’s here 
>> instead of defining our own rules.
>> 
>> While the type could be a dereferenceable URI, requiring action on the AS is 
>> really getting into distributed authorization policies. We tried doing that 
>> with UMA1’s scope structures and it didn’t work very well in practice (in my 
>> memory and experience). Someone could profile “type" on top of this if they 
>> wanted to do so, with support at the AS for that, but I don’t see a 
>> compelling reason for that to be a requirement as that’s a lot of complexity 
>> and a lot more error states (the fetch fails, or it doesn’t have a policy, 
>> or the policy’s in a format the AS doesn’t understand, or the AS doesn’t 
>> like the policy, etc). 
>> 
>> And AS is always free to implement its types in such a fashion, and that 
>> could make plenty of sense in a smaller ecosystem. And this is yet another 
>> reason that we define “type” as being a string to be interpreted and 
>> understood by the AS — so that an AS that wants to work this way can do so.
>> 
>>  — Justin
>> 
>> PS: thanks for pointing out the error in the example in XYZ, I’ll fix that 
>> prior to publication.
>> 
>>> On Jul 18, 2020, at 8:58 P

Re: [OAUTH-WG] Namespacing "type" in RAR

[Justin Richer]

The more I’ve been thinking about it, the more I like the idea of using 
“$schema” for that purpose. It’s already got a well-defined definition in the 
JSON Schema world that would be familiar to people doing that, and there’s no 
need to overload the “type” field for that purpose. You would be able to do the 
same thing with the “@context” field from JSONLD, which has similar semantics. 
If we tried to put those both into the “type” field, and AS would have a hard 
time supporting both types of APIs, and so our goal of allowing easy 
differentiation at the AS isn’t really met.

A quick straw man idea: 

We :could: define a value for “type” that is “https://schema.org/ 
<https://schema.org/>“ and have it define the “$schema” field and how to 
process the rest of the object using JSON Schema. Similar idea for something 
JSONLD based, it uses “https://json-ld.org <https://json-ld.org/>” and defines 
a “@context” field that says how to process the rest of the request object 
using JSON-LD.

And in all of these cases, the “type” field is always checked by the AS by 
doing a simple string comparison. The URI here is just to keep the two public 
spaces from stepping on each other in their definitions. 

As for Joseph’s comment about unicode: I think we can recommend that people use 
ASCII because of the usability concerns, and use string comparison to check and 
compare.

 — Justin

> On Jul 22, 2020, at 5:02 PM, Torsten Lodderstedt 
>  wrote:
> 
> 
> 
>> On 22. Jul 2020, at 22:16, Vladimir Dzhuvinov  
>> wrote:
>> 
>> 
>> On 21/07/2020 18:43, Torsten Lodderstedt wrote:
>>> 
>>>> On 21. Jul 2020, at 17:40, Vladimir Dzhuvinov  
>>>> wrote:
>>>> 
>>>> 
>>>> 
>>>> On 21/07/2020 17:47, Justin Richer wrote:
>>>>>> On Jul 19, 2020, at 1:04 PM, Vladimir Dzhuvinov 
>>>>>>  wrote:
>>>>>> 
>>>>>> On 18/07/2020 17:12, Justin Richer wrote:
>>>>>>> I think publishing supported “type” parameters isn’t a bad idea, and it 
>>>>>>> aligns with publishing supported scopes and claims in discovery.
>>>>>> If you are a developer, would you like to be able to find out if the 
>>>>>> authorization_details for a given "type" has a JSON schema and what it 
>>>>>> looks like?
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> I think that would be a nice thing for an AS/API to offer, but I don’t 
>>>>> think it should be expected or required here. That might be a good note 
>>>>> in the guidance, say that if you use a URI for your “type” field then it 
>>>>> would be nice if it resolved to something either human or machine 
>>>>> readable. What I don’t want is for us to require every AS to have to 
>>>>> resolve these URIs in order to process and understand them. That’s why 
>>>>> I’m taking the position of it being a string, and the URI can provide 
>>>>> disambiguation in the way you’re talking about below.
>>>> We've been thinking about giving developers the possibility to discover 
>>>> the authorization_details JSON schema (if one is supplied) for a given 
>>>> type via a separate AS metadata parameter. Not by making the type a 
>>>> dereferceable URL, which will overload things too much.
>>>> 
>>>> authorization_details_json_schemas : {
>>>>   "" : "",
>>>>   "" : "",
>>>>  ...
>>>> 
>>>> }
>>>> The rationale -- to minimise the number of potential support calls for 
>>>> providers arising from "Oh dear, why do I get this invalid_request now..." 
>>>> with complex RAR JSON objects.
>>> We could borrow the "$schema” element. 
>> 
>> Could you elaborate?
> 
> I mean we could use this element in addition to the “type” element to specify 
> the corresponding schema in each authorization details object.  
> 
>> 
>>> However, I’m on the fence regarding introducing a separate parameter for 
>>> the schema simply because it also introduce a new error cause if type and 
>>> schema are inconsistent. 
>> 
>> Another idea was to still let the AS be configured with optional JSON
>> schemas for each type, and if the schema check of the
>> authorization_details fails, to include a meaningful message in the
>> invalid_request error_description and the schema URL in the error_uri.
>> 
>> The downside of that is the schema cannot be discovered or retrieve

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-07.txt

[Justin Richer]

An RS is not considered an OAuth 2 client, though there’s enough overlap in the 
structure that I know several implementations that store RS records in the same 
table as the client records with a special flag set on them to differentiate.

The RS <-> AS communication channel has never really gotten a formal definition 
in OAuth 2. The closest we’ve come is Token Introspection, which is RFC7662, 
and even there we didn’t define a set of authentication and discovery 
mechanisms. Instead, we piggybacked off of the token endpoint. This has proven 
to be problematic in practice and has lead to an explosion of the kind of 
additional metadata fields like you list below.

 — Justin

> On Jul 20, 2020, at 4:23 PM, Tangui Le Pense 
>  wrote:
> 
> Hello,
> 
> A few late remarks and questions about this version of the draft. Sorry if it 
> was already answered, but I haven't found answers in the previous emails.
> 
> Section 2.1: in case the JWT is signed then encrypted, which jwt should 
> include the "typ" parameter with the "at+jwt" value? The outer encrypted JWT 
> (JWE), the inner signed JWT (JWS) or both?
> 
> Section 3: the example is missing the "iat" and "jti" fields that are 
> mandatory per section 2.2:
> 
>   {"typ":"at+JWT","alg":"RS256","kid":"RjEwOwOA"}
>   {
> "iss": "https://authorization-server.example.com/";,
> "sub": " 5ba552d67",
> "aud":   "https://rs.example.com/";,
> "exp": 1544645174,
> "client_id": "s6BhdRkqt3_",
> "scope": "openid profile reademail"
>   }
> 
> Section 4 "Validating JWT Access Tokens":
> 
>   o  If the JWT access token is encrypted, decrypt it using the keys
>  and algorithms that the resource server specified during
>  registration.  If encryption was negotiated with the authorization
>  server at registration time and the incoming JWT access token is
>  not encrypted, the resource server SHOULD reject it.
> 
> The registration details are not documented. As an RS seems to be a special 
> case of an OAuth2 client (without any grant type granted, except, possibily, 
> "client_credentials") I was expecting registration of dynamic client 
> registration metadata similar to those for ID tokens (something like 
> "access_token_signed_response_alg", "access_token_encrypted_response_alg" and 
> "access_token_encrypted_response_enc"), and same for discovery metadata.
> 
> Is the rationale for the absence of the registration of these fields that 
> RSes are not considered as OAuth2 clients?
> 
> Also, in the same section, nothing is said about the validation of "iat" and 
> "jti".
> 
> Regards,
> 
> -- 
> 
> Tangui
> 
> 
> 27.04.2020 21:27, internet-dra...@ietf.org пишет:
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>> 
>> Title   : JSON Web Token (JWT) Profile for OAuth 2.0 Access 
>> Tokens
>> Author  : Vittorio Bertocci
>>  Filename: draft-ietf-oauth-access-token-jwt-07.txt
>>  Pages   : 19
>>  Date: 2020-04-27
>> 
>> Abstract:
>>This specification defines a profile for issuing OAuth 2.0 access
>>tokens in JSON web token (JWT) format.  Authorization servers and
>>resource servers from different vendors can leverage this profile to
>>issue and consume access tokens in interoperable manner.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-07
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-07
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> 
>> ___
>> 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] Namespacing "type" in RAR

[Justin Richer]

I’m suggesting that API designers avoid using such glyphs in their “type” 
values if they want to avoid such human-copy errors, like they would need to do 
for most other strings in their system. If that means they stick to ASCII or 
put a note on the developer page that says “hey copy and paste this value, 
don’t try to re-type it” or whatever, that’s up to the AS. 

You’d have the same kind of issue around “similar-looking” characters, like the 
semicolon vs. the greek question mark. Should the AS look for those and try to 
“fix” the inputs? I would argue not: the AS should be strict in matching these 
values because it could have security implications. 

This isn’t a problem unique to RAR, or OAuth for that matter. We can, and I 
think should, add guidance to the RAR document for all of these points. 

 — Justin

> On Jul 21, 2020, at 1:55 PM, Dick Hardt  wrote:
> 
> In unicode, a glyph can be represented by more than one code point. When 
> reading the docs and entering a value, the developer will not know which code 
> point the AS intended. 
> 
> Are you suggesting that AS documentation would have the bytes rather than 
> glyphs? Or not use glyphs that have multiple code points? Or that they only 
> use english?
> 
> 
> 
> On Tue, Jul 21, 2020 at 10:34 AM Justin Richer  <mailto:jric...@mit.edu>> wrote:
> Right, and I’m saying that all three of those would be DIFFERENT “type” 
> values, because they’re different strings. The fact that when treated as URIs 
> they would be equivalent is irrelevant. Just like “foo”, “Foo”, and “FOO” 
> would be different “type” values, per the spec. Nothing is stopping an AS 
> from treating them as equivalent internally, but that seems a bit dangerous 
> to me. I’d love to see a formal breakdown of that, though.
> 
> As for the unicode example, if we define things as using byte comparisons, 
> then that becomes an issue for proper documentation and configuration — and 
> again, probably a good place to have recommendations for picking type value 
> strings so as to avoid such problems.
> 
> In short, I don’t think we should have any requirements on canonicalization 
> for these values.
> 
>  — Justin
> 
>> On Jul 21, 2020, at 1:03 PM, Dick Hardt > <mailto:dick.ha...@gmail.com>> wrote:
>> 
>> 
>> The following are the same URI, but are different strings:
>> 
>>  “https://schema.example.org/v1 <https://schema.example.org/v1>”
>>  “HTTPS://schema.example.org/v1 <https://schema.example.org/v1>”
>>  “https://SCHEMA.EXAMPLE.ORG/v1 <https://schema.example.org/v1>”
>> 
>> Before comparing them to each other, they must be canonicalized so that they 
>> become the same string.
>> 
>> From earlier in this thread, I am NOT suggesting that it must be a URI, nor 
>> that it is required:
>> 
>> Since the type represents a much more complex object then a JWT claim, a 
>> client developer's tooling could pull down the JSON Schema (or some such) 
>> for a type used in their source code, and provide autocompletion and 
>> validation which would improve productivity and reduce errors. An AS that is 
>> using a defined type could use the schema for input validation. Neither of 
>> these would be at run time. JSON Schema allows comments and examples.
>> 
>> What is the harm in non-normative language around a retrievable URI?
>> 
>> On Tue, Jul 21, 2020 at 9:58 AM Justin Richer > <mailto:jric...@mit.edu>> wrote:
>> String comparison works just fine when the strings happen to be URIs, and 
>> you aren’t treating them as URIs:
>> 
>>  “https://schema.example.org/v1 <https://schema.example.org/v1>”
>> 
>> Is different from 
>> 
>>  “https://schema.example.org/v2 <https://schema.example.org/v2>”
>> 
>> And both are different from
>> 
>>  “https://schema.example.org:443/v1 <https://schema.example.org/v1>/“
>> 
>> All of these are strings, and the strings happen to be URIs but that’s 
>> irrelevant to the comparison process. Can you please help me understand why 
>> doing a string comparison on these values does not work in exactly the same 
>> way it would for “foo”, “bar”, and “baz” values? Why would these need to be 
>> canonicalized to be compared? The definition of a JSON string is an ordered 
>> set of unicode code points, and this can be compared byte-wise. (Or 
>> code-point-wise, whatever’s most correct here.) Can you give me 
>> counter-examples as to where string comparison doesn’t work? And can you 
>> help me understand how this same worry doesn’t apply to all of the rest of 
>> the values in the RAR specification

Re: [OAUTH-WG] Namespacing "type" in RAR

[Justin Richer]

Right, and I’m saying that all three of those would be DIFFERENT “type” values, 
because they’re different strings. The fact that when treated as URIs they 
would be equivalent is irrelevant. Just like “foo”, “Foo”, and “FOO” would be 
different “type” values, per the spec. Nothing is stopping an AS from treating 
them as equivalent internally, but that seems a bit dangerous to me. I’d love 
to see a formal breakdown of that, though.

As for the unicode example, if we define things as using byte comparisons, then 
that becomes an issue for proper documentation and configuration — and again, 
probably a good place to have recommendations for picking type value strings so 
as to avoid such problems.

In short, I don’t think we should have any requirements on canonicalization for 
these values.

 — Justin

> On Jul 21, 2020, at 1:03 PM, Dick Hardt  wrote:
> 
> 
> The following are the same URI, but are different strings:
> 
>   “https://schema.example.org/v1 <https://schema.example.org/v1>”
>   “HTTPS://schema.example.org/v1 <https://schema.example.org/v1>”
>   “https://SCHEMA.EXAMPLE.ORG/v1 <https://schema.example.org/v1>”
> 
> Before comparing them to each other, they must be canonicalized so that they 
> become the same string.
> 
> From earlier in this thread, I am NOT suggesting that it must be a URI, nor 
> that it is required:
> 
> Since the type represents a much more complex object then a JWT claim, a 
> client developer's tooling could pull down the JSON Schema (or some such) for 
> a type used in their source code, and provide autocompletion and validation 
> which would improve productivity and reduce errors. An AS that is using a 
> defined type could use the schema for input validation. Neither of these 
> would be at run time. JSON Schema allows comments and examples.
> 
> What is the harm in non-normative language around a retrievable URI?
> 
> On Tue, Jul 21, 2020 at 9:58 AM Justin Richer  <mailto:jric...@mit.edu>> wrote:
> String comparison works just fine when the strings happen to be URIs, and you 
> aren’t treating them as URIs:
> 
>   “https://schema.example.org/v1 <https://schema.example.org/v1>”
> 
> Is different from 
> 
>   “https://schema.example.org/v2 <https://schema.example.org/v2>”
> 
> And both are different from
> 
>   “https://schema.example.org:443/v1 <https://schema.example.org/v1>/“
> 
> All of these are strings, and the strings happen to be URIs but that’s 
> irrelevant to the comparison process. Can you please help me understand why 
> doing a string comparison on these values does not work in exactly the same 
> way it would for “foo”, “bar”, and “baz” values? Why would these need to be 
> canonicalized to be compared? The definition of a JSON string is an ordered 
> set of unicode code points, and this can be compared byte-wise. (Or 
> code-point-wise, whatever’s most correct here.) Can you give me 
> counter-examples as to where string comparison doesn’t work? And can you help 
> me understand how this same worry doesn’t apply to all of the rest of the 
> values in the RAR specification, which are also strings and will need to be 
> compared?
> 
> I’m still very confused as to the URI retrieval issue here, if there even is 
> one. It sounds like we’re both saying that it could be useful if type values 
> are retrievable when they’re URIs, but that would be something to augment a 
> process and not required for the RAR spec. I’m against requiring the value to 
> be a URI and against requiring the AS to process that URI as a URI at 
> runtime. Anything that an AS wants to do with the “type” value, including 
> providing additional tooling and validation, is up to the AS and outside of 
> the spec.
> 
>  — Justin
> 
>> On Jul 21, 2020, at 12:35 PM, Dick Hardt > <mailto:dick.ha...@gmail.com>> wrote:
>> 
>> This statement:
>> 
>> “compare two strings so that they’re exact”
>> 
>> does not work for either Unicode or URIs. A string, and a canonicalized 
>> Unicode string are not the same thing. Similar for a URI. I have assumed you 
>> understand the canonicalization requirement, but it does not sound like you 
>> do. Would you like examples?
>> 
>> 
>> wrt. the AS and URI, *you* keep saying that *I* said the AS would retrieve 
>> the URI. I HAVE NOT SAID THAT!
>> 
>> I am suggesting that the URI MAY be retrievable, and I gave examples on how 
>> that would be useful for tooling for client developers, and for an AS in 
>> doing input validation. The URI would NOT be retrieved at run time.
>> 
>> 
>> On Tue, Jul 21, 2020 at 7:35 AM Justin Richer > <mailto:jric...@mit.edu>>

Re: [OAUTH-WG] Namespacing "type" in RAR

[Justin Richer]

String comparison works just fine when the strings happen to be URIs, and you 
aren’t treating them as URIs:

“https://schema.example.org/v1”

Is different from 

“https://schema.example.org/v2”

And both are different from

“https://schema.example.org:443/v1/“

All of these are strings, and the strings happen to be URIs but that’s 
irrelevant to the comparison process. Can you please help me understand why 
doing a string comparison on these values does not work in exactly the same way 
it would for “foo”, “bar”, and “baz” values? Why would these need to be 
canonicalized to be compared? The definition of a JSON string is an ordered set 
of unicode code points, and this can be compared byte-wise. (Or 
code-point-wise, whatever’s most correct here.) Can you give me 
counter-examples as to where string comparison doesn’t work? And can you help 
me understand how this same worry doesn’t apply to all of the rest of the 
values in the RAR specification, which are also strings and will need to be 
compared?

I’m still very confused as to the URI retrieval issue here, if there even is 
one. It sounds like we’re both saying that it could be useful if type values 
are retrievable when they’re URIs, but that would be something to augment a 
process and not required for the RAR spec. I’m against requiring the value to 
be a URI and against requiring the AS to process that URI as a URI at runtime. 
Anything that an AS wants to do with the “type” value, including providing 
additional tooling and validation, is up to the AS and outside of the spec.

 — Justin

> On Jul 21, 2020, at 12:35 PM, Dick Hardt  wrote:
> 
> This statement:
> 
> “compare two strings so that they’re exact”
> 
> does not work for either Unicode or URIs. A string, and a canonicalized 
> Unicode string are not the same thing. Similar for a URI. I have assumed you 
> understand the canonicalization requirement, but it does not sound like you 
> do. Would you like examples?
> 
> 
> wrt. the AS and URI, *you* keep saying that *I* said the AS would retrieve 
> the URI. I HAVE NOT SAID THAT!
> 
> I am suggesting that the URI MAY be retrievable, and I gave examples on how 
> that would be useful for tooling for client developers, and for an AS in 
> doing input validation. The URI would NOT be retrieved at run time.
> 
> 
> On Tue, Jul 21, 2020 at 7:35 AM Justin Richer  <mailto:jric...@mit.edu>> wrote:
> If we treat all the strings as just strings, without any special internal 
> format to be specified or detected, then comparing the strings is a 
> well-understood and well-documented process. I also think that we shouldn’t 
> invent anything here, so if there’s a better way to say “compare two strings 
> so that they’re exact” then that’s what I mean. Sorry if that was unclear.
> 
> I’m saying the AS should not retrieve the URI passed in the “type” value. You 
> brought that up and then described the process that the AS would take to do 
> so. I have said from the start that the use of a URI is for name spacing and 
> not for addressing content to be fetched, so I’m confused why you think I 
> intend otherwise.
> 
>  — Justin
> 
>> On Jul 20, 2020, at 2:59 PM, Dick Hardt > <mailto:dick.ha...@gmail.com>> wrote:
>> 
>> Canonicalization of URIs and unicode is fairly well specified. I was not 
>> suggesting we invent anything there.
>> 
>> A byte comparison, as you suggested earlier, will be problematic, as I have 
>> pointed out.
>> 
>> I'm confused why you are still talking about the AS retrieving a URI.
>> 
>> ᐧ
>> 
>> On Mon, Jul 20, 2020 at 4:42 AM Justin Richer > <mailto:jric...@mit.edu>> wrote:
>> Since this is a recommendation for namespace, we could also just say 
>> collision-resistant like JWT, and any of those examples are fine. But that 
>> said, I think there’s something particularly compelling about URIs since 
>> they have somewhat-human-readable portions. But again, I’m saying it should 
>> be a recommendation to API developers and not a requirement in the spec. In 
>> the spec, I argue that “type” should be a string, full stop.
>> 
>> If documentation is so confusing that developers are typing in the wrong 
>> strings, then that’s bad documentation. And likely a bad choice for the 
>> “type” string on the part of the AS. You’d have the same problem with any 
>> other value the developer’s supposed to copy over.  :)
>> 
>> I agree that we should call out explicitly how they should be compared, and 
>> I propose we use one of the handful of existing string-comparison RFC’s here 
>> instead of defining our own rules.
>> 
>> While the type could be a dereferenceable URI, requiring action on

Re: [OAUTH-WG] Namespacing "type" in RAR

[Justin Richer]

> On Jul 19, 2020, at 1:04 PM, Vladimir Dzhuvinov  
> wrote:
> 
> On 18/07/2020 17:12, Justin Richer wrote:
>> I think publishing supported “type” parameters isn’t a bad idea, and it 
>> aligns with publishing supported scopes and claims in discovery.
> If you are a developer, would you like to be able to find out if the 
> authorization_details for a given "type" has a JSON schema and what it looks 
> like?
> 
> 
> 
I think that would be a nice thing for an AS/API to offer, but I don’t think it 
should be expected or required here. That might be a good note in the guidance, 
say that if you use a URI for your “type” field then it would be nice if it 
resolved to something either human or machine readable. What I don’t want is 
for us to require every AS to have to resolve these URIs in order to process 
and understand them. That’s why I’m taking the position of it being a string, 
and the URI can provide disambiguation in the way you’re talking about below.

>> I have always seen the resource indicators work as providing a more specific 
>> dimension to the requests that scopes didn’t allow to be described very 
>> well, pointing at a specific RS instead of just “some kind of access”, so 
>> I’m not sure how they’re a testament to name spacing issues with scopes. Can 
>> you help me understand here?
> Putting the scopes for each RS in a unique name space, for example by giving 
> them a URI prefix which identifies the RS, can make the resource indication 
> redundant.
> 
> RS: https://some-rs.example.com/ <https://some-rs.example.com/>
> 
> RS scopes: read, update, delete
> 
> ->
> 
> https://some-rs.example.com/read <https://some-rs.example.com/read>
> https://some-rs.example.com/update <https://some-rs.example.com/update>
> https://some-rs.example.com/delete <https://some-rs.example.com/delete>
> This will not work if the chosen name spacing pattern can produce 
> ambiguities, e.g. if https://rs.example.com/accounts 
> <https://rs.example.com/accounts> and https://rs.example.com/accounts/v1 
> <https://rs.example.com/accounts/v1> are two different RSes.
> 
> 
> 
> I have witnessed situations when an AS is given some application to deal 
> with, with hard-wired scope values that have no name spacing, and to prevent 
> potential collisions with other applications, Resource Indicators had to come 
> to the rescue.
> 
That only really works if you are asking for multiple tokens for different 
resources. With RAR we can at least group things together, and so things like 
the read/update/delete can now be under the “actions” field with 
“https://some-rs.example.com/ <https://some-rs.example.com/>“ be the “type” 
field. Or even better, “https://some-rs-example.com/ 
<https://some-rs-example.com/>“ is the “locations” value and the “type” is 
something like “https://rs.example.com/accounts 
<https://rs.example.com/accounts>”. Since things get combined inside an object 
with distinct fields, and not as substrings and prefixes, we don’t have the 
ambiguity with “https://rs.example.com/accounts/v1 
<https://rs.example.com/accounts/v1>” anymore. As a note we would also treat 
“https://rs.example.com/accounts/ <https://rs.example.com/accounts/>“ (with a 
trailing slash) as a distinct “type” value under this logic.
> I also remember one case with an application having a scope name which is 
> also used for the OIDC userinfo endpoint.
> 
> 
> 
This is exactly the kind of thing that I think we can do better to avoid here. 
So I would expect a protocol like OIDC to use something like 
“https://openid.net/specs/connect/ <https://openid.net/specs/connect/>userinfo“ 
as its “type” field, since it’s coming from a standards body and is meant to be 
used by many different systems. But if I’ve also got some custom internal 
timecard API I would just use “timecard” as the “type” there, since it’s 
internal to just that one AS. And if both of these have an “email” value for, 
say, “datatype”, then they don’t overlap with each other.
>> I do think that if nothing else we can give better guidance in RAR as to 
>> what the “type” field is. 
> +1
> 
> 
> 
>> I do think it should still just be a string, but we can help people make 
>> better decisions about what to put in that string.
> I'm still on the fence with that but I do see your argument.
> 
> 
> 

Thanks for the feedback!

 — Justin

> Vladimir
> 
> 
> 
>>  — Justin
>> 
>>> On Jul 17, 2020, at 2:13 PM, Vladimir Dzhuvinov  
>>> <mailto:vladi...@connect2id.com> wrote:
>>> 
>>> 
>>> On 17/07/2020 17:38, Justin Richer wrote:
>>>> And all that brings me to my proposal: 
>>>> 
>>

Re: [OAUTH-WG] Namespacing "type" in RAR

[Justin Richer]

If we treat all the strings as just strings, without any special internal 
format to be specified or detected, then comparing the strings is a 
well-understood and well-documented process. I also think that we shouldn’t 
invent anything here, so if there’s a better way to say “compare two strings so 
that they’re exact” then that’s what I mean. Sorry if that was unclear.

I’m saying the AS should not retrieve the URI passed in the “type” value. You 
brought that up and then described the process that the AS would take to do so. 
I have said from the start that the use of a URI is for name spacing and not 
for addressing content to be fetched, so I’m confused why you think I intend 
otherwise.

 — Justin

> On Jul 20, 2020, at 2:59 PM, Dick Hardt  wrote:
> 
> Canonicalization of URIs and unicode is fairly well specified. I was not 
> suggesting we invent anything there.
> 
> A byte comparison, as you suggested earlier, will be problematic, as I have 
> pointed out.
> 
> I'm confused why you are still talking about the AS retrieving a URI.
> 
> ᐧ
> 
> On Mon, Jul 20, 2020 at 4:42 AM Justin Richer  <mailto:jric...@mit.edu>> wrote:
> Since this is a recommendation for namespace, we could also just say 
> collision-resistant like JWT, and any of those examples are fine. But that 
> said, I think there’s something particularly compelling about URIs since they 
> have somewhat-human-readable portions. But again, I’m saying it should be a 
> recommendation to API developers and not a requirement in the spec. In the 
> spec, I argue that “type” should be a string, full stop.
> 
> If documentation is so confusing that developers are typing in the wrong 
> strings, then that’s bad documentation. And likely a bad choice for the 
> “type” string on the part of the AS. You’d have the same problem with any 
> other value the developer’s supposed to copy over.  :)
> 
> I agree that we should call out explicitly how they should be compared, and I 
> propose we use one of the handful of existing string-comparison RFC’s here 
> instead of defining our own rules.
> 
> While the type could be a dereferenceable URI, requiring action on the AS is 
> really getting into distributed authorization policies. We tried doing that 
> with UMA1’s scope structures and it didn’t work very well in practice (in my 
> memory and experience). Someone could profile “type" on top of this if they 
> wanted to do so, with support at the AS for that, but I don’t see a 
> compelling reason for that to be a requirement as that’s a lot of complexity 
> and a lot more error states (the fetch fails, or it doesn’t have a policy, or 
> the policy’s in a format the AS doesn’t understand, or the AS doesn’t like 
> the policy, etc). 
> 
> And AS is always free to implement its types in such a fashion, and that 
> could make plenty of sense in a smaller ecosystem. And this is yet another 
> reason that we define “type” as being a string to be interpreted and 
> understood by the AS — so that an AS that wants to work this way can do so.
> 
>  — Justin
> 
> PS: thanks for pointing out the error in the example in XYZ, I’ll fix that 
> prior to publication.
> 
>> On Jul 18, 2020, at 8:58 PM, Dick Hardt > <mailto:dick.ha...@gmail.com>> wrote:
>> 
>> Justin: thanks for kindly pointing out which mail list this is.
>> 
>> To clarify, public JWT claims are not just URIs, but any collision-resistant 
>> namespace: 
>> "Examples of collision-resistant namespaces include: Domain Names, Object 
>> Identifiers (OIDs) as defined in the ITU-T X.660 and  X.670 
>> Recommendation series, and Universally Unique IDentifiers (UUIDs) [RFC4122]."
>> 
>> I think letting the "type" be any JSON string and doing a byte-wise 
>> comparison will be problematic. A client developer will be reading 
>> documentation to learn what the types are, and typing it in. Given the wide 
>> set of whitespace characters, and unicode equivalence, different byte 
>> streams will all look the same, and a byte-wise comparison will fail.
>> 
>> Similarly for URIs. If it is a valid URI, then a byte-wise comparison is not 
>> sufficient. Canonicalization is required. 
>> 
>> These are not showstopper issues, but the specification should call out how 
>> type strings are compared, and provide caveats to an AS developer.
>> 
>> I have no idea why you would think the AS would retrieve a URL.
>> 
>> Since the type represents a much more complex object then a JWT claim, a 
>> client developer's tooling could pull down the JSON Schema (or some such) 
>> for a type used in their source code, and provide autocompletion and 
>> validation which

Re: [OAUTH-WG] Namespacing "type" in RAR

[Justin Richer]

I created a pull request with some proposed language here:

https://github.com/oauthstuff/draft-oauth-rar/pull/52 
<https://github.com/oauthstuff/draft-oauth-rar/pull/52>

 — Justin

> On Jul 20, 2020, at 7:42 AM, Justin Richer  wrote:
> 
> Since this is a recommendation for namespace, we could also just say 
> collision-resistant like JWT, and any of those examples are fine. But that 
> said, I think there’s something particularly compelling about URIs since they 
> have somewhat-human-readable portions. But again, I’m saying it should be a 
> recommendation to API developers and not a requirement in the spec. In the 
> spec, I argue that “type” should be a string, full stop.
> 
> If documentation is so confusing that developers are typing in the wrong 
> strings, then that’s bad documentation. And likely a bad choice for the 
> “type” string on the part of the AS. You’d have the same problem with any 
> other value the developer’s supposed to copy over.  :)
> 
> I agree that we should call out explicitly how they should be compared, and I 
> propose we use one of the handful of existing string-comparison RFC’s here 
> instead of defining our own rules.
> 
> While the type could be a dereferenceable URI, requiring action on the AS is 
> really getting into distributed authorization policies. We tried doing that 
> with UMA1’s scope structures and it didn’t work very well in practice (in my 
> memory and experience). Someone could profile “type" on top of this if they 
> wanted to do so, with support at the AS for that, but I don’t see a 
> compelling reason for that to be a requirement as that’s a lot of complexity 
> and a lot more error states (the fetch fails, or it doesn’t have a policy, or 
> the policy’s in a format the AS doesn’t understand, or the AS doesn’t like 
> the policy, etc). 
> 
> And AS is always free to implement its types in such a fashion, and that 
> could make plenty of sense in a smaller ecosystem. And this is yet another 
> reason that we define “type” as being a string to be interpreted and 
> understood by the AS — so that an AS that wants to work this way can do so.
> 
>  — Justin
> 
> PS: thanks for pointing out the error in the example in XYZ, I’ll fix that 
> prior to publication.
> 
>> On Jul 18, 2020, at 8:58 PM, Dick Hardt > <mailto:dick.ha...@gmail.com>> wrote:
>> 
>> Justin: thanks for kindly pointing out which mail list this is.
>> 
>> To clarify, public JWT claims are not just URIs, but any collision-resistant 
>> namespace: 
>> "Examples of collision-resistant namespaces include: Domain Names, Object 
>> Identifiers (OIDs) as defined in the ITU-T X.660 and  X.670 
>> Recommendation series, and Universally Unique IDentifiers (UUIDs) [RFC4122]."
>> 
>> I think letting the "type" be any JSON string and doing a byte-wise 
>> comparison will be problematic. A client developer will be reading 
>> documentation to learn what the types are, and typing it in. Given the wide 
>> set of whitespace characters, and unicode equivalence, different byte 
>> streams will all look the same, and a byte-wise comparison will fail.
>> 
>> Similarly for URIs. If it is a valid URI, then a byte-wise comparison is not 
>> sufficient. Canonicalization is required. 
>> 
>> These are not showstopper issues, but the specification should call out how 
>> type strings are compared, and provide caveats to an AS developer.
>> 
>> I have no idea why you would think the AS would retrieve a URL.
>> 
>> Since the type represents a much more complex object then a JWT claim, a 
>> client developer's tooling could pull down the JSON Schema (or some such) 
>> for a type used in their source code, and provide autocompletion and 
>> validation which would improve productivity and reduce errors. An AS that is 
>> using a defined type could use the schema for input validation. Neither of 
>> these would be at run time. JSON Schema allows comments and examples.
>> 
>> What is the harm in non-normative language around a retrievable URI?
>> 
>> BTW: the example in 
>> https://oauth.xyz/draft-richer-transactional-authz#rfc.section.2 
>> <https://oauth.xyz/draft-richer-transactional-authz#rfc.section.2> has not 
>> been updated with the "type" field.
>> 
>> 
>> 
>> On Sat, Jul 18, 2020 at 8:10 AM Justin Richer > <mailto:jric...@mit.edu>> wrote:
>> Hi Dick,
>> 
>> This is a discussion about the RAR specification on the OAuth list, and 
>> therefore doesn’t have anything to do with alignment with XAuth. In fact, I 
>> believe the alignment is the other wa

Re: [OAUTH-WG] Namespacing "type" in RAR

[Justin Richer]

Since this is a recommendation for namespace, we could also just say 
collision-resistant like JWT, and any of those examples are fine. But that 
said, I think there’s something particularly compelling about URIs since they 
have somewhat-human-readable portions. But again, I’m saying it should be a 
recommendation to API developers and not a requirement in the spec. In the 
spec, I argue that “type” should be a string, full stop.

If documentation is so confusing that developers are typing in the wrong 
strings, then that’s bad documentation. And likely a bad choice for the “type” 
string on the part of the AS. You’d have the same problem with any other value 
the developer’s supposed to copy over.  :)

I agree that we should call out explicitly how they should be compared, and I 
propose we use one of the handful of existing string-comparison RFC’s here 
instead of defining our own rules.

While the type could be a dereferenceable URI, requiring action on the AS is 
really getting into distributed authorization policies. We tried doing that 
with UMA1’s scope structures and it didn’t work very well in practice (in my 
memory and experience). Someone could profile “type" on top of this if they 
wanted to do so, with support at the AS for that, but I don’t see a compelling 
reason for that to be a requirement as that’s a lot of complexity and a lot 
more error states (the fetch fails, or it doesn’t have a policy, or the 
policy’s in a format the AS doesn’t understand, or the AS doesn’t like the 
policy, etc). 

And AS is always free to implement its types in such a fashion, and that could 
make plenty of sense in a smaller ecosystem. And this is yet another reason 
that we define “type” as being a string to be interpreted and understood by the 
AS — so that an AS that wants to work this way can do so.

 — Justin

PS: thanks for pointing out the error in the example in XYZ, I’ll fix that 
prior to publication.

> On Jul 18, 2020, at 8:58 PM, Dick Hardt  wrote:
> 
> Justin: thanks for kindly pointing out which mail list this is.
> 
> To clarify, public JWT claims are not just URIs, but any collision-resistant 
> namespace: 
> "Examples of collision-resistant namespaces include: Domain Names, Object 
> Identifiers (OIDs) as defined in the ITU-T X.660 and  X.670 
> Recommendation series, and Universally Unique IDentifiers (UUIDs) [RFC4122]."
> 
> I think letting the "type" be any JSON string and doing a byte-wise 
> comparison will be problematic. A client developer will be reading 
> documentation to learn what the types are, and typing it in. Given the wide 
> set of whitespace characters, and unicode equivalence, different byte streams 
> will all look the same, and a byte-wise comparison will fail.
> 
> Similarly for URIs. If it is a valid URI, then a byte-wise comparison is not 
> sufficient. Canonicalization is required. 
> 
> These are not showstopper issues, but the specification should call out how 
> type strings are compared, and provide caveats to an AS developer.
> 
> I have no idea why you would think the AS would retrieve a URL.
> 
> Since the type represents a much more complex object then a JWT claim, a 
> client developer's tooling could pull down the JSON Schema (or some such) for 
> a type used in their source code, and provide autocompletion and validation 
> which would improve productivity and reduce errors. An AS that is using a 
> defined type could use the schema for input validation. Neither of these 
> would be at run time. JSON Schema allows comments and examples.
> 
> What is the harm in non-normative language around a retrievable URI?
> 
> BTW: the example in 
> https://oauth.xyz/draft-richer-transactional-authz#rfc.section.2 
> <https://oauth.xyz/draft-richer-transactional-authz#rfc.section.2> has not 
> been updated with the "type" field.
> 
> 
> 
> On Sat, Jul 18, 2020 at 8:10 AM Justin Richer  <mailto:jric...@mit.edu>> wrote:
> Hi Dick,
> 
> This is a discussion about the RAR specification on the OAuth list, and 
> therefore doesn’t have anything to do with alignment with XAuth. In fact, I 
> believe the alignment is the other way around, as doesn’t Xauth normatively 
> reference RAR at this point? Even though, last I saw, it uses a different 
> top-level structure for conveying things, I believe it does say to use the 
> internal object structures. I am also a co-author on RAR and we had already 
> defined a “type” field in RAR quite some time ago. You did notice that XYZ’s 
> latest draft added this field to keep the two in alignment with each other, 
> which has always been the goal since the initial proposal of the RAR work, 
> but that’s a time lag and not a display of new intent. 
> 
> In any event, even though I think the decision has bearing in b

Re: [OAUTH-WG] Namespacing "type" in RAR

[Justin Richer]

I think publishing supported “type” parameters isn’t a bad idea, and it aligns 
with publishing supported scopes and claims in discovery.

I have always seen the resource indicators work as providing a more specific 
dimension to the requests that scopes didn’t allow to be described very well, 
pointing at a specific RS instead of just “some kind of access”, so I’m not 
sure how they’re a testament to name spacing issues with scopes. Can you help 
me understand here?

I do think that if nothing else we can give better guidance in RAR as to what 
the “type” field is. I do think it should still just be a string, but we can 
help people make better decisions about what to put in that string.

 — Justin

> On Jul 17, 2020, at 2:13 PM, Vladimir Dzhuvinov  
> wrote:
> 
> 
> On 17/07/2020 17:38, Justin Richer wrote:
>> And all that brings me to my proposal: 
>> 
>> 4) Require all values to be defined by the AS, and encourage specification 
>> developers to use URIs for collision resistance.
>> 
>> So officially in RAR, the AS would decide what “type” means, and nobody 
>> else. But we can also guide people who are developing general-purpose 
>> interoperable APIs to use URIs for their RAR “type” definitions. This would 
>> keep those interoperable APIs from stepping on each other, and from stepping 
>> on any locally-defined special “type” structure. But at the end of the day, 
>> the URI carries no more weight than just any other string, and the AS 
>> decides what it means and how it applies.
> 
> Define, but not publish in AS metadata?
> 
> 
>> My argument is that this seems to have worked very, very well for scopes, 
>> and the RAR “type” is cut from similar descriptive cloth.
> 
> I would argue that it didn't work so well for scopes - the OAuth
> Resource Indicators spec is a testament to that.
> 
> But one could also argue that scopes were not defined along the lines of
> your proposal for "type" in RAR. In fact, RFC 6749 has no mention of
> collision resistance or name spacing for scope values.
> 
> 
> Vladimir
> 
> 
> ___
> 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] Namespacing "type" in RAR

[Justin Richer]

Hi Dick,

This is a discussion about the RAR specification on the OAuth list, and 
therefore doesn’t have anything to do with alignment with XAuth. In fact, I 
believe the alignment is the other way around, as doesn’t Xauth normatively 
reference RAR at this point? Even though, last I saw, it uses a different 
top-level structure for conveying things, I believe it does say to use the 
internal object structures. I am also a co-author on RAR and we had already 
defined a “type” field in RAR quite some time ago. You did notice that XYZ’s 
latest draft added this field to keep the two in alignment with each other, 
which has always been the goal since the initial proposal of the RAR work, but 
that’s a time lag and not a display of new intent. 

In any event, even though I think the decision has bearing in both places, this 
isn’t about GNAP. Working on RAR’s requirements has brought up this interesting 
issue of what should be in the type field for RAR in OAuth 2.

I think that it should be defined as a string, and therefore compared as a byte 
value in all cases, regardless of what the content of the string is. I don’t 
think the AS should be expected to fetch a URI for anything. I don’t think the 
AS should normalize any of the inputs. I think that any JSON-friendly character 
set should be allowed (including spaces and unicodes), and since RAR already 
requires the JSON objects to be form-encoded, this shouldn’t cause additional 
trouble when adding them in to OAuth 2’s request structures.

The idea of using a URI would be to get people out of each other’s namespaces. 
It’s similar to the concept of “public” vs “private” claims in JWT:

https://tools.ietf.org/html/rfc7519#section-4.2 
<https://tools.ietf.org/html/rfc7519#section-4.2>

What I’m proposing is that if you think it’s going to be a general-purpose type 
name, then we recommend you use a URI as your string. And beyond that, that’s 
it. It’s up to the AS to figure out what to do with it, and RAR stays out of it.

 — Justin

> On Jul 17, 2020, at 1:25 PM, Dick Hardt  wrote:
> 
> Hey Justin, glad to see that you have aligned with the latest XAuth draft on 
> a type property being required.
> 
> I like the idea that the value of the type property is fully defined by the 
> AS, which could delegate it to a common URI for reuse. This gets GNAP out of 
> specifying access requests, and enables other parties to define access 
> without any required coordination with IETF or IANA.
> 
> A complication in mixing plain strings and URIs is the canonicalization. A 
> plain string can be a fixed byte representation, but a URI requires 
> canonicalization for comparison. Mixing the two requires URI detection at the 
> AS before canonicalization, and an AS MUST do canonicalization of URIs.
> 
> The URI is retrievable, it can provide machine and/or human readable 
> documentation in JSON schema or some such, or any other content type. Once 
> again, the details are out of scope of GNAP, but we can provide examples to 
> guide implementers.
> 
> Are you still thinking that bare strings are allowed in GNAP, and are defined 
> by the AS?
> 
> 
> 
> On Fri, Jul 17, 2020 at 8:39 AM Justin Richer  <mailto:jric...@mit.edu>> wrote:
> The “type” field in the RAR spec serves an important purpose: it defines what 
> goes in the rest of the object, including what other fields are available and 
> what values are allowed for those fields. It provides an API-level definition 
> for requesting access based on multiple dimensions, and that’s really 
> powerful and flexible. Each type can use any of the general-purpose fields 
> like “actions” and/or add its own fields as necessary, and the “type” 
> parameter keeps everything well-defined.
> 
> The question, then, is what defines what’s allowed to go into the “type” 
> field itself? And what defines how that value maps to the requirements for 
> the rest of the object? The draft doesn’t say anything about it at the 
> moment, but we should choose the direction we want to go. On the surface, 
> there are three main options:
> 
> 1) Require all values to be registered. 
> 2) Require all values to be collision-resistant (eg, URIs).
> 3) Require all values to be defined by the AS (and/or the RS’s that it 
> protects).
> 
> Are there any other options?
> 
> Here are my thoughts on each approach:
> 
> 1) While it usually makes sense to register things for interoperability, this 
> is a case where I think that a registry would actually hurt interoperability 
> and adoption. Like a “scope” value, the RAR “type” is ultimately up to the AS 
> and RS to interpret in their own context. We :want: people to define rich 
> objects for their APIs and enable fine-grained access for their systems, and 
> if they have to register something every time they come up with a

[OAUTH-WG] Namespacing "type" in RAR

[Justin Richer]

The “type” field in the RAR spec serves an important purpose: it defines what 
goes in the rest of the object, including what other fields are available and 
what values are allowed for those fields. It provides an API-level definition 
for requesting access based on multiple dimensions, and that’s really powerful 
and flexible. Each type can use any of the general-purpose fields like 
“actions” and/or add its own fields as necessary, and the “type” parameter 
keeps everything well-defined.

The question, then, is what defines what’s allowed to go into the “type” field 
itself? And what defines how that value maps to the requirements for the rest 
of the object? The draft doesn’t say anything about it at the moment, but we 
should choose the direction we want to go. On the surface, there are three main 
options:

1) Require all values to be registered. 
2) Require all values to be collision-resistant (eg, URIs).
3) Require all values to be defined by the AS (and/or the RS’s that it 
protects).

Are there any other options?

Here are my thoughts on each approach:

1) While it usually makes sense to register things for interoperability, this 
is a case where I think that a registry would actually hurt interoperability 
and adoption. Like a “scope” value, the RAR “type” is ultimately up to the AS 
and RS to interpret in their own context. We :want: people to define rich 
objects for their APIs and enable fine-grained access for their systems, and if 
they have to register something every time they come up with a new API to 
protect, it’s going to be an unmaintainable mess. I genuinely don’t think this 
would scale, and that most developers would just ignore the registry and do 
what they want anyway. And since many of these systems are inside domains, it’s 
completely unenforceable in practice.

2) This seems reasonable, but it’s a bit of a nuisance to require everything to 
be a URI here. It’s long and ugly, and a lot of APIs are going to be internal 
to a given group, deployment, or ecosystem anyway. This makes sense when you’ve 
got something reusable across many deployments, like OIDC, but it’s overhead 
when what you’re doing is tied to your environment.

3) This allows the AS and RS to define the request parameters for their APIs 
just like they do today with scopes. Since it’s always the combination of “this 
type :AT: this AS/RS”, name spacing is less of an issue across systems. We 
haven’t seen huge problems in scope value overlap in the wild, though it does 
occur from time to time it’s more than manageable. A client isn’t going to just 
“speak RAR”, it’s going to be speaking RAR so that it can access something in 
particular.

And all that brings me to my proposal: 

4) Require all values to be defined by the AS, and encourage specification 
developers to use URIs for collision resistance.

So officially in RAR, the AS would decide what “type” means, and nobody else. 
But we can also guide people who are developing general-purpose interoperable 
APIs to use URIs for their RAR “type” definitions. This would keep those 
interoperable APIs from stepping on each other, and from stepping on any 
locally-defined special “type” structure. But at the end of the day, the URI 
carries no more weight than just any other string, and the AS decides what it 
means and how it applies.

My argument is that this seems to have worked very, very well for scopes, and 
the RAR “type” is cut from similar descriptive cloth.

What does the rest of the group think? How should we manage the RAR “type” 
values and what they mean?

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

Re: [OAUTH-WG] OAuth Request JSON Encoding

[Justin Richer]

It’s all good, I wrote it relatively quickly and I haven’t actually built it 
out. The idea struck me this week, as I was working on something for a client, 
that it would be a fairly simple translation from the map structure of form 
encoding to a JSON-based map structure for the same key-value pairs, and you 
could skip all the form encoding for the values and occasionally make use of a 
more native encoding method for some values like scope.

For aligning request and response, it could say that there’s an alternate 
response encoding as well but only if the client uses this request format. 
That’s a lot for the AS to track, but it would let clients speak only one 
dialect natively. It might be squirrely but then again it might just make sense 
for the AS to track it all.

Ultimately it’s a back-patch because all OAuth values are going to have to 
define form encodings and an extension couldn’t take full advantage of this 
unless it was written to be JSON-only, which would be a bit weird and limiting. 
For example, I didn’t look at applying it to PAR because the PAR values are 
defined in terms of query parameters already, and are therefore beholden to 
those rules and not the token endpoint rules. It might work there, too, but 
probably not even as smoothly as this!

I appreciate the read through and the comments! I’d be curious if there’s any 
energy in the group to pick it up.

 — Justin

> On Jul 13, 2020, at 1:00 PM, Filip Skokan  wrote:
> 
> Apologies Justin, i read it in a rush. 
> 
> But, even more so after your clarification, if the ID means responses are 
> unmodified it’s just confusing - as you say - at odds with each other, since 
> i’d send in scope as array and get it back as a string from the token 
> response. 
> 
> Odesláno z iPhonu
> 
>> 13. 7. 2020 v 18:09, Justin Richer :
>> 
>> The intent was to only affect the request, not the response, though I can 
>> see the confusion that would arise in having those be at odds with each 
>> other. 
>> 
>>  — Justin
>> 
>>> On Jul 13, 2020, at 11:47 AM, Filip Skokan >> <mailto:panva...@gmail.com>> wrote:
>>> 
>>> Hello Justin, 
>>> 
>>> Your ID changes both how a client sends a request as well as how the, 
>>> already a json, token response is structured (as far as i can see it 
>>> changes scope from a space separated value to an array). 
>>> 
>>> The response morphing will be confusing to clients.
>>> 
>>> I don’t think there’s much to explore here, apart from 
>>> authorization_details param sent to the token endpoint form encoded i don’t 
>>> find much unnatural about the existing oauth interface. 
>>> 
>>> Filip
>>> 
>>> Odesláno z iPhonu
>>> 
>>>> 9. 7. 2020 v 21:29, Justin Richer >>> <mailto:jric...@mit.edu>>:
>>>> 
>>>> 
>>>> In the ten years since OAuth started, we’ve seen a huge shift away from 
>>>> form encoding to JSON encoding for sending data to a server. And yet, 
>>>> OAuth is stuck with form encoding. So I thought, why can’t we change that?
>>>> 
>>>> I put together a quick proposal for how this would work.
>>>> 
>>>> https://www.ietf.org/id/draft-richer-oauth-json-request-00.html 
>>>> <https://www.ietf.org/id/draft-richer-oauth-json-request-00.html>
>>>> 
>>>> The basic idea is that you take the map of form inputs and make it into a 
>>>> JSON object. For some fields, like scope and authorization_details, you 
>>>> can define a JSON-specific encoding to make use of object and array 
>>>> structures native to JSON. You also don’t have to url-encode values inside 
>>>> the JSON strings. 
>>>> 
>>>> Caveat, I haven’t tried implementing this yet, but I think it’s not likely 
>>>> to be that difficult for either the client or server side of things. At 
>>>> worst it seems like it’d be a pretty simple middleware function. 
>>>> Functionality can be detected at the AS by the content negotiation in HTTP 
>>>> (client sends content-type of JSON), and can be advertised as an option in 
>>>> the metadata (or in an OPTIONS call to the token endpoint, to be more 
>>>> HTTP-friendly).
>>>> 
>>>>  — 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

Re: [OAUTH-WG] OAuth Request JSON Encoding

[Justin Richer]

The intent was to only affect the request, not the response, though I can see 
the confusion that would arise in having those be at odds with each other. 

 — Justin

> On Jul 13, 2020, at 11:47 AM, Filip Skokan  wrote:
> 
> Hello Justin, 
> 
> Your ID changes both how a client sends a request as well as how the, already 
> a json, token response is structured (as far as i can see it changes scope 
> from a space separated value to an array). 
> 
> The response morphing will be confusing to clients.
> 
> I don’t think there’s much to explore here, apart from authorization_details 
> param sent to the token endpoint form encoded i don’t find much unnatural 
> about the existing oauth interface. 
> 
> Filip
> 
> Odesláno z iPhonu
> 
>> 9. 7. 2020 v 21:29, Justin Richer :
>> 
>> 
>> In the ten years since OAuth started, we’ve seen a huge shift away from form 
>> encoding to JSON encoding for sending data to a server. And yet, OAuth is 
>> stuck with form encoding. So I thought, why can’t we change that?
>> 
>> I put together a quick proposal for how this would work.
>> 
>> https://www.ietf.org/id/draft-richer-oauth-json-request-00.html 
>> <https://www.ietf.org/id/draft-richer-oauth-json-request-00.html>
>> 
>> The basic idea is that you take the map of form inputs and make it into a 
>> JSON object. For some fields, like scope and authorization_details, you can 
>> define a JSON-specific encoding to make use of object and array structures 
>> native to JSON. You also don’t have to url-encode values inside the JSON 
>> strings. 
>> 
>> Caveat, I haven’t tried implementing this yet, but I think it’s not likely 
>> to be that difficult for either the client or server side of things. At 
>> worst it seems like it’d be a pretty simple middleware function. 
>> Functionality can be detected at the AS by the content negotiation in HTTP 
>> (client sends content-type of JSON), and can be advertised as an option in 
>> the metadata (or in an OPTIONS call to the token endpoint, to be more 
>> HTTP-friendly).
>> 
>>  — 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] OAuth Request JSON Encoding

[Justin Richer]

In the ten years since OAuth started, we’ve seen a huge shift away from form 
encoding to JSON encoding for sending data to a server. And yet, OAuth is stuck 
with form encoding. So I thought, why can’t we change that?

I put together a quick proposal for how this would work.

https://www.ietf.org/id/draft-richer-oauth-json-request-00.html 


The basic idea is that you take the map of form inputs and make it into a JSON 
object. For some fields, like scope and authorization_details, you can define a 
JSON-specific encoding to make use of object and array structures native to 
JSON. You also don’t have to url-encode values inside the JSON strings. 

Caveat, I haven’t tried implementing this yet, but I think it’s not likely to 
be that difficult for either the client or server side of things. At worst it 
seems like it’d be a pretty simple middleware function. Functionality can be 
detected at the AS by the content negotiation in HTTP (client sends 
content-type of JSON), and can be advertised as an option in the metadata (or 
in an OPTIONS call to the token endpoint, to be more HTTP-friendly).

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

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

[Justin Richer]

The two-phase approach is exactly what OBUK does, where you get one access 
token using client credentials before getting a more specific one in context of 
the user’s consent. This ends up being awkward to implement at best, since 
OAuth involves the user too early in the process to allow for this kind of 
thing. PAR might help address this dichotomy, but RAR can provide places for 
this to fill in.

With XYZ, I tried to design for that kind of multi-stage transaction pattern 
more explicitly, with the idea that you could continue your request in context 
and vary it over time, or even start a new request in the context of an 
existing one. This is something that I intend to continue with the 
soon-to-be-formed GNAP working group, if you want to bring this use case there.

 — Justin

> On Jul 6, 2020, at 12:32 PM, Neil Madden  wrote:
> 
> I’m reading draft-ietf-oauth-rar-01 in a bit more detail now I have some 
> time, and I have a few comments.
> 
> An assumption in the draft appears to be that the client knows ahead of time 
> what it wants to gain access to and can describe it in detail. For example, 
> the last example in section 2.1 is a client requesting access to particular 
> files, which assumes that the client already knows the paths of the files it 
> wants to access. This in turn seems to imply that the client already has some 
> level of access to be able to determine this, e.g. to list directories, which 
> may not be desirable. In many cases like this I think it’s more natural for 
> the client to not know exactly what it is asking for but instead to want 
> access to *some* file, chosen by the user. An example of this is the Dropbox 
> Chooser [1] and Saver [2] APIs, which notably are not built on top of OAuth. 
> In these cases it would be more natural for the client to send a more generic 
> request and for the details to be filled in by the user as part of the 
> consent process.
> 
> Another issue is that as far as I can see in the current draft, any client 
> can initiate a rich authorization request at any time without any kind of 
> prior approval. This seems problematic for the main example in the draft, 
> i.e. payment initiation. As an attacker, if I can get a consent screen up on 
> a user’s device requesting to move money around then it seems like half my 
> job is already done - some fraction of users will probably approve such a 
> transaction without properly checking it. It feels like the ability to ask 
> for transaction approval should already be a privileged operation that should 
> require consent and approval.
> 
> A related issue is that each approval is in effect a completely isolated 
> incident. In a normal OAuth2 interaction I would grant an app some 
> longish-term access to data and it would get an access token and optionally a 
> refresh token. At some later point I can go to the AS and see that I have 
> granted this access and revoke it if I choose. With RAR there is no 
> representation of a long-term relationship between the RO and the client and 
> each transaction starts from fresh. Again, this seems potentially problematic 
> and not quite in keeping with how OAuth currently operates. Each grant of 
> access is ephemeral. (Do refresh tokens make sense in the context of RAR?)
> 
> I think a better approach would be a two-phase authorization process:
> 
> 1. In step 1 an app gets a normal long-lived access and/or refresh token that 
> grants it permissions to ask to initial transactions (RARs) - e.g. with scope 
> initiate_payments
> 2. In step 2 the app requests authorization for individual RARs/transactions 
> using some proof of its grant from step 1
> 
> I have ideas for how this could be achieved, but I’d prefer to see what 
> others think of this general idea rather than getting bogged down in specific 
> details.
> 
> [1]: https://www.dropbox.com/developers/chooser 
> 
> [2]: https://www.dropbox.com/developers/saver 
>  
> 
> — 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

Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

[Justin Richer]

What if we simply declare that refresh tokens are always bound to the DPoP key 
used to request them? Is there value in NOT binding the refresh token?

As for access tokens, the way I read it, all of this is true:

- The AS could still decide to issue a Bearer token, using the token_type 
field, for whatever policy reason.
- A client getting back a Bearer token from a DPoP request would do Bearer 
headers. 
- A client getting a DPoP token from a DPoP request would do DPoP headers.
- An client should never send a DPoP token as a Bearer header.
- An RS should ALWAYS look for a DPoP binding signature from a DPoP scheme 
token. Missing that is an error.

So if we just declare that a refresh token must always be DPoP bound when DPoP 
is used to request it and a refresh token is issued, then we’re in the clear 
here, as best as I can tell, and it allows the AS some flexibility.

Some problems with this:

1) Pretty much every single OAuth client in the world ignores the “token_type” 
field. But clients being updated to support DPoP wouldn’t ignore it, so that’s 
probably ok.
2) If we wanted to make refresh token binding switchable we’d need a 
“refresh_token_type” field or similar, and the client would need to know how to 
understand it and deal with its absence (since most servers won’t send it).
3) This presumes the client will not rotate its key before using the refresh 
token. If it does it’ll have to do a whole new grant.
4) None of this prevents an RS from ignoring the DPoP signature, but I think 
that’s a separate problem.
5) It’s arguable that we’d want a client to be able to bind a NEW DPoP key 
during a refresh, using the old key as proof for the refresh token and the new 
key going forward. Is this a case we want to enable?

 — Justin

> On Jun 7, 2020, at 3:22 AM, Torsten Lodderstedt 
>  wrote:
> 
> That’s correct for confidential clients.
> 
> For a public client, the refresh token is just bound to the client id. DPoP 
> allows binding to an ephemeral key pair for this kind of clients.
> 
>> Am 07.06.2020 um 00:57 schrieb Francis Pouatcha 
>> :
>> 
>> 
>> 
>> > Am 05.06.2020 um 22:17 schrieb George Fletcher 
>> > http://ietf.org/>>:
>> > 
>> > Secondly, I do think we need a way to allow for the refresh_token to be 
>> > bound while leaving the access_tokens as bearer tokens. This adds useful 
>> > security without impacting existing RS deployments.
>> 
>> +1 that’s a very useful 
>> feature___
>> AFAIK a refresh_token is always bound. What am I missing here?
>> -- 
>> Francis Pouatcha
>> Co-Founder and Technical Lead at adorys
>> https://adorsys-platform.de/solutions/ 
>> ___
> 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] carrying oauth authorisation without HTTP

[Justin Richer]

It depends on what protocol you’re using on the socket connection between the 
client (the home router) and the RS/AS. You’ll need :someplace: to put the 
access token. RFC6750 and RFC8705 are explicitly about HTTP so you can’t use 
them directly, but other work (like that done in the ACE group with OSCORE) map 
the OAuth concepts to different underlying protocols.

 — Justin

> On Apr 28, 2020, at 10:13 PM, Daniel Migault  wrote:
> 
> Hi,
> 
> I am completely new to oauth and would like to solicit the WG for advice.
> 
> We are working on the Home Router outsourcing a service in the homenet WG and 
> we are wondering how oauth could be used to improve automation.
> 
> Our scenario is represented in the figure below:
> 
> 1.  The end user connected to the web interface of the Home Router  
> 2. The Home Router redirects the End User to the service provider where the 
> end user register for that service ( AS ).
> 3. The AS providing an authorisation token carried to the RS via the Home 
> Router to the RS.
> 
> The session between the Home router and the RS in our case is not using HTTP 
> but is using TLS. We are wondering if there is a way to carry an 
> authorisation token over a non HTTP session and if RFC8705 "OAuth 2.0 
> Mutual-TLS Client Authentication and Certificate-Bound Access Tokens" heads 
> in to this direction.
> 
> I am happy to hear any feed back or comments!
> 
> Yours,
> Daniel
> 
> 
>   HTTPS+---+
>+-->|AS |<--+
>|   |   |   |
>v   +---+   v
> +-+ HTTPS  +---+TLS+-+
> | User|<-->|Home Router|<->|   RS|
> |(Web Browser)||   |   | |
> +-++---+   +-+
> 
> -- 
> Daniel Migault
> Ericsson
> 8400 boulevard Decarie
> Montreal, QC   H4P 2N2
> Canada
> 
> Phone: +1 514-452-2160
> 
> ___
> 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] PAR - Guidance on the request URI structure needed?

[Justin Richer]

I agree that any URI could be used but that it MUST be understood by the AS to 
be local to the AS (and not something that can be impersonated by an attacker). 
I wouldn’t even go so far as RECOMMENDED, but it’s certainly an option.

 — Justin

> On Apr 27, 2020, at 4:41 AM, Filip Skokan  wrote:
> 
> I believe implementers should be free to devise their own URIs and not be 
> locked down to one by the spec, at the same time, and RFC6755 subnamespace 
> would be good for guidance.
> 
> So, I would suggest it be RECOMMENDED to use e.g. 
> `urn:ietf:params:oauth:request_uri:` (Brian's proposal) but also that 
> any URN or URL will do if the circumstances call for it.
> 
> Best,
> Filip
> 
> 
> On Sun, 26 Apr 2020 at 17:20, Torsten Lodderstedt 
>  > wrote:
> Hi all, 
> 
> another topic from last week’s virtual meeting. 
> 
> Shall there be guidance on the request URI structure? 
> 
> Please state your opinion. 
> 
> thanks in advance, 
> Torsten. 
> ___
> 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] DPoP - new authorization scheme / immediate usability concerns

[Justin Richer]

The idea of “Continuing to work without taking advantage of sender constraints” 
is, I would argue, a security hole. Systems are allowed to fail security checks 
but still offer functionality. This is exactly the pattern behind allowing an 
unsigned JWT because you checked the “alg" header and it was “none” and so 
you’re OK with that. Yes, you shouldn’t do that, but maybe we could’ve also 
made this more explicit within JOSE. By using the ‘DPoP’ auth scheme, we’re 
making a clear syntactic change that says to the RS “either you know to look 
for this or you don’t know what it is”. 

It’s one of the problems I have with how the OAuth MTLS spec was written. By 
re-using the “Bearer” scheme there, I believe we’ve made a mistake that allows 
things to fall through in an insecure fashion. The same argument against it — 
ease of porting existing deployments — was raised there as well, and it won in 
the end. I hope we can do better this time.

 — Justin

> On Apr 16, 2020, at 4:05 AM, Filip Skokan  wrote:
> 
> I'm still somewhat on the fence as to the pros and cons of using a new token 
> type and authorization scheme. But the draft has gone with a new one. Would 
> it have really helped this situation, if it'd stuck with "bearer"? Or would 
> it just be less obvious?
> 
> If we had stuck "bearer" than i wouldn't have raised this topic, since 
> existing RS would most likely ignore the cnf claim and the resource server 
> calls would continue to work, obviously without taking advantage of the 
> available sender check.
> 
> As I wrote the preceding rambling paragraph I am starting to think that more 
> should be said in the draft about working with RSs that don't support DPoP. 
> Which isn't really what you were asking about. But maybe would cover some of 
> the same ground.
> 
> I agree.
> 
>  The AS is the one that does the binding (which includes checking the proof) 
> so I don't see how sending two proofs would really work or help the situation?
> 
> :facepalm: indeed, sorry. 
> 
> S pozdravem,
> Filip Skokan
> 
> 
> On Tue, 14 Apr 2020 at 23:39, Brian Campbell  > wrote:
> Hi Filip, 
> 
> My attempts at responses to your questions/comments are inline:
> 
> On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  > wrote:
> I've wondered about the decision to use a new scheme before 
>  
> but this time i'd like to challenge the immediate usability of the future 
> spec for one specific case - sender constraining public client Refresh Tokens.
> 
> I'm still somewhat on the fence as to the pros and cons of using a new token 
> type and authorization scheme. But the draft has gone with a new one. Would 
> it have really helped this situation, if it'd stuck with "bearer"? Or would 
> it just be less obvious? 
>  
> 
> If at all, it is going to take time for RS implementations to recognize the 
> new `DPoP` authorization scheme, let alone process it properly. In the 
> meantime, i'd still like to have the option to bind issued public client 
> refresh tokens using DPoP without affecting the access tokens. In doing so i 
> get an immediate win in sender constraining the refresh tokens but not 
> introducing a breaking change for the RS.
> 
> Do you see this as something an AS implementation is just free to do since 
> it's both the issuer and recipient of a refresh token?
> That's my first thought, yes. 
>  
> Should this be somehow baked in the draft?
> I'm not sure. Do you think it needs to be? I'm not sure what it would say 
> though. 
> 
> In such a case the AS could bind the RT to the given dpop proof and either 
> not bind the AT while returning token_type=Bearer or bind the AT while 
> returning token_type value DPoP. In the latter case the AT would almost 
> certainly still work as a bearer token at the RS and the client that knew the 
> RS's needs could send it as such with an `Authorization: Bearer `. Or if 
> it didn't know the RS's needs, it could start with `Authorization: DPoP ` 
> which would get a 401 with `WWW-Authenticate: Bearer` at which point it could 
> send `Authorization: Bearer `. 
> 
> As I wrote the preceding rambling paragraph I am starting to think that more 
> should be said in the draft about working with RSs that don't support DPoP. 
> Which isn't really what you were asking about. But maybe would cover some of 
> the same ground. 
>  
>  
> Do you think client registration metadata could be used to signal such intent?
> I think it certainly could. But it seems maybe too specific to warrant 
> metadata. 
>  
> Do you think the protocol should have signals in the messages themselves to 
> say what the client wants to apply DPoP to?
> My initial thought here is no. Take the case of a client working with an AS 
> that supports DPoP and one RS that does and one RS that doesn't. I can't 
> really even think what signaling might look like there or how it could be 

Re: [OAUTH-WG] Direct Grant missing in draft-parecki-oauth-v2-1

[Justin Richer]

We’ve looked at this with XYZ, and one of the patterns that’s possible with the 
backchannel-first flow is to have the server send a challenge back to the 
client which the client can then respond to, for example by signing it with a 
FIDO style device key. Depending on the system, the client could identify the 
user in the first request or the credential could carry the identification 
directly. You need an “extra” round trip compared to OAuth2 style flows, but it 
makes life a whole lot simpler for this kind of user authn.

 — Justin

> On Apr 9, 2020, at 4:09 AM, Daniel Fett  wrote:
> 
> 
> Am 09.04.20 um 09:55 schrieb Rob Otto:
>> I'd imagine you have to pre-register each client and then use HOTP or TOTP 
>> to generate one-time passcodes. 
>> 
> 
> I can come up with a couple of other ways as well, but I'm interested to hear 
> what Francis sees "in the wild".
> 
> -Daniel
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] Dealing with oAuth redirect_uri in draft-parecki-oauth-v2-1 and need for AS back channel initiation endpoint

[Justin Richer]

Francis,

The backchannel-first pattern that you are discussing is one of the key 
components of TxAuth, which we are discussing on the txa...@ietf.org 
 mailing list, and I invite you to join the 
conversation there. I have a project to implement these ideas that’s documented 
at https://oauth.xyz/ , and it’s been submitted as a draft 
to what will hopefully become the TxAuth Working Group in the near future. 

https://tools.ietf.org/html/draft-richer-transactional-authz 


 — Justin

> On Apr 8, 2020, at 6:30 PM, Francis Pouatcha 
>  wrote:
> 
> Hello Aaron,
> As much as I would love to require that all authorization requests are 
> initiated via a back channel, that is unfortunately not something that is in 
> scope of the current OAuth 2.1 document.
> 
> The OAuth 2.0 Security BCP and this document require strict redirect URI 
> matching, which should help simplify the AS, since simple string matching is 
> sufficient now.
> Not sure it is a good idea to limit scope oAuth 2.1 on existing functionality 
> of oAuth 2.0 unless we are planning an oAuth 3.0 soon. 
> -- 
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.de/solutions/ 
> ___
> 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] draft-ietf-oauth-dpop-00 comments

[Justin Richer]

I want to add my perspective to the question of audience restriction, below:

One of the problems with implementing audience restriction of RS’s in the wild 
has actually turned into a problem of audience identification instead. In other 
words, the client needs to know some identifier that the RS will recognize as 
itself, and the RS needs to be configured with that identifier in some way. 
DPoP does a nice side-step of that entire issue by signing some very limited 
aspects of the request itself. This type of check is much easier for an RS (or 
a filter sitting in front of it) to check for consistency, without a lot of 
pre-configuration. The http-signing based PoP draft took the same approach, 
albeit with more expanded coverage, and the HTTP Signatures draft from the HTTP 
WG will do the same. 

I’ll also note that this does not get in the way of DPoP being used with an 
access token that also has additional audience restrictions on it. And RS can 
both check the DPoP signature matches the incoming request as well as checking 
some audience notation on the token itself, just like we’d expect an RS to 
check the scope values bound to the access token as well as the presentation 
mechanism. 

They’re two parts of the puzzle, and they shouldn’t be conflated at the 
presentation layer (DPoP) since they can be mixed in orthogonal ways for 
different use cases and solutions.

 — Justin

> On Apr 6, 2020, at 2:05 PM, Brian Campbell 
>  wrote:
> 
> Hi Mike,
> 
> Thanks for your interest in the work and review of the draft. As one of the 
> too-many authors on the document, I attempt to answer questions and respond 
> to comments inline below. Though I admit to not having necessarily adequate 
> answers to everything at the ready. And also apologize for the slow response, 
> which is somewhat related to not having necessarily adequate answers. 
> 
> On Wed, Apr 1, 2020 at 11:15 AM Peck, Michael A  > wrote:
> Hi,
> 
> Glad to see DPoP moving forward as a working group item.
> I have a couple of comments on the current draft:
> 
> 1.
> I recommend expanding the description of the threat model.
> It's not entirely clear to me what threats DPoP is expected to address, which 
> makes it hard to evaluate whether DPoP meets its objectives.
> 
> Yeah, there's definitely some room for improvement in this area. And you are 
> not the first to note the need. Complicating matters somewhat, however, is 
> that there's some disparity of opinions about the specifics of the threat 
> model and objectives. Despite that I do plan to work on trying to expand and 
> clarify the threat model, objectives, expected applicability, etc. in the 
> next revision of the draft. 
>  
> Section 2 states that the main objective is to prevent an adversary who set 
> up a counterfeit AS or RS from replaying a received refresh token or access 
> token at another server. Would it be possible to expand upon the description 
> of this threat and how it may occur?
> 
> I'm hoping perhaps Daniel can help expand on this as the current text 
> originated with him. Although I think separate consideration of AS and RS 
> would be helpful because I think the factors involved in counterfeiting or 
> confusing them are pretty different.
>  
> Are there other situations where an adversary may be able to capture a 
> refresh token or access token that should be mentioned as objectives to 
> address - e.g. malicious / third-party JavaScript code?
> 
> Probably, yeah. Although any JavaScript code that could exfiltrate tokens 
> could also likely be used to drive an attack directly. And that possibility 
> can devolve into questioning the value of key-binding or preventing 
> exfiltration at all (similarish criticisms have been levied at the HttpOnly 
> cookie flag and HTTP Token Binding). I'm sympathetic to that line of 
> reasoning to the point of finding it somewhat depressing. But I try and avoid 
> falling into full-blown XSS nihilism and (maybe stubbornly/naively) still 
> think there's some value in key constraining tokens. And, to your point, a 
> more detailed look at potential leakage/theft situations would be useful.
> 
>  
> 
> Presumably the counterfeit AS or RS will not have the same hostname (e.g. 
> with an illegitimately issued server certificate) as the legitimate server, 
> as otherwise DPoP wouldn’t provide protection.
> 
> Yeah, an assumption (that admittedly should be made more explicit) is that 
> TLS/HTTPS with server authentication isn't broken.  
> 
>  
> Why would the client send the refresh token to the wrong AS?
> 
>  Daniel maybe has some more ideas here but social engineering is the one 
> reason that I keep hearing. It's not super compelling but is a reason.
> 
>  
> For resource servers, why wouldn’t an access token audience restriction 
> suffice? Is the concern that the access token might not contain an audience 
> restriction, or might contain multiple audiences? (If the concern is that the 
> resource 

Re: [OAUTH-WG] RAR - Example JWT for Payment

[Justin Richer]

The “type” is effectively a schema marker for the content of the authorization 
request object, and so it doesn’t need to be the same domain as the API that’s 
being hosted. Think of it this way: the type defines the API, this could be a 
standard body or some other org, and the location defines the specific hosted 
instance. It’s like defining OpenID Connect at the OIDF and hosting it on your 
company’s domain.

 — Justin

> On Mar 30, 2020, at 9:18 AM, Jared Jennings  wrote:
> 
> I have a question about the example and maybe it's more for clarification 
> than anything.
> 
> The example contains type and also location.
> A couple of things
> 1. Would it add clarity if the domain was the same for both? vs. someorg.com 
>  / example.com 
> 2. While only an example, would it bring clerity to past examples if the type 
> was https://schema.example.com/payment_initiation 
>  and the location was 
> https://api.example.com/payments 
> 
> or am I missing something what the values represent?
> 
> Here's the example I am referring to on page 17.
> {
>   "iss": "https://as.example.com ",
>   "sub": "24400320",
>   "aud": "a7AfcPcsl2",
>   "exp": 1311281970,
>   "acr": "psd2_sca",
>   "txn": "8b4729cc-32e4-4370-8cf0-5796154d1296",
>   "authorization_details": [
>  {
> "type": "https://www.someorg.com/payment_initiation 
> ",
> "actions": [
>"initiate",
>"status",
>"cancel"
> ],
> "locations": [
>"https://example.com/payments "
> ],
> "instructedAmount": {
>"currency": "EUR",
>"amount": "123.50"
> },
> "creditorName": "Merchant123",
> "creditorAccount": {
>"iban": "DE02100100109307118603"
> },
> "remittanceInformationUnstructured": "Ref Number Merchant"
>  }
>   ],
>   "debtorAccount": {
>  "iban": "DE40100100103307118608",
>  "user_role": "owner"
>   }
>]
> 
> -Jared
> Skype:jaredljennings
> Signal:+1 816.730.9540
> WhatsApp: +1 816.678.4152
> ___
> 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] OAuth 2.1 - drop implicit flow?

[Justin Richer]

OpenID Connect is based on OAuth 2.0, not on OAuth 2.1. Therefore, it would not 
be affected at all, whether through the hybrid or implicit flows.

If OIDC pushes a revision to OAuth 2.1, then it would be bound by the features 
of OAuth 2.1 and would need to contend with that. But until that happens, 
everything we do with OAuth 2.1 has literally no effect on OAuth 2.0 systems, 
including OIDC.

 — Justin

> On Mar 18, 2020, at 7:14 AM, Jared Jennings  wrote:
> 
> I agree, but would add that as long as it says "this is being drop", but does 
> not impact "that", then the reader can understand context. "This does not 
> change support for implicit response that OpenID Connect (OIDC) makes use of".
> 
> my two cents.
> 
> -Jared
> Skype:jaredljennings
> Signal:+1 816.730.9540
> WhatsApp: +1 816.678.4152
> 
> 
> On Thu, Mar 12, 2020 at 1:15 PM Vittorio Bertocci 
> mailto:40auth0@dmarc.ietf.org>> 
> wrote:
> Sorry for the delay here.
> From the formal perspective, Torsten's language works for me as well.  Thanks 
> for taking the feedback into account.
> 
> I still worry that without an explicit reference to OIDC implicit+form_post, 
> I will have the conversation "but can we still do this in OIDC now that 
> implicit has been deprecated in OAuth?" countless times with customers, but 
> I'm resigned to that anyway :)
> 
> 
> On Sat, Mar 7, 2020 at 3:36 PM Brian Campbell 
>  > wrote:
> Sorry, was replying i. my phone on the weekend and trying to keep it quick. I 
> meant that I thought Torsten's suggestion was good.
> 
> On Sat, Mar 7, 2020, 4:25 PM Dick Hardt  > wrote:
> Would you clarify what text works Brian?
> 
> On Sat, Mar 7, 2020 at 3:24 PM Brian Campbell  > wrote:
> Yeah, that works for me.. 
> 
> On Sat, Mar 7, 2020, 9:37 AM Dick Hardt  > wrote:
> Brian: does that meet your requirements?
> 
> If not, how about if we refer to OIDC as an example extension without saying 
> it is implicit?
> ᐧ
> 
> On Sat, Mar 7, 2020 at 8:29 AM Torsten Lodderstedt  > wrote:
> I think keeping the response type as extension point and not mentioning 
> implicit at all is sufficient to support Brian’s objective.
> 
>> Am 07.03.2020 um 17:06 schrieb Dick Hardt > >:
>> 
>> 
>> How about if we add in a nonnormative reference to OIDC as an explicit 
>> example of an extension:
>> 
>> "For example, OIDC defines an implicit grant with additional security 
>> features."
>> 
>> or similar language
>> ᐧ
>> 
>> On Sat, Mar 7, 2020 at 5:27 AM Brian Campbell > > wrote:
>> The name implicit grant is unfortunately somewhat misleading/confusing but, 
>> for the case at hand, the extension mechanism isn't grant type so much as 
>> response type and even response mode. 
>> 
>> The perspective shared during the office hours call was, paraphrasing as 
>> best I can, that there are legitimate uses of implicit style flows in OpenID 
>> Connect (that likely won't be updated) and it would be really nice if this 
>> new 2.1 or whatever it's going to be document didn't imply that they were 
>> disallowed or problematic or otherwise create unnecessary FUD or confusion 
>> for the large population of existing deployments.. 
>> 
>> On Fri, Feb 28, 2020 at 1:56 PM Dick Hardt > > wrote:
>> I'm looking to close out this topic. I heard that Brian and Vittorio shared 
>> some points of view in the office hours, and wanted to confirm:
>> 
>> + Remove implicit flow from OAuth 2.1 and continue to highlight that grant 
>> types are an extension mechanism.
>> 
>> For example, if OpenID Connect were to be updated to refer to OAuth 2.1 
>> rather than OAuth 2..0, OIDC could define the implicit grant type with all 
>> the appropriate considerations.
>> 
>> 
>> ᐧ
>> 
>> On Tue, Feb 18, 2020 at 10:49 PM Dominick Baier > > wrote:
>> No - please get rid of it.
>> 
>> ———
>> Dominick Baier
>> 
>> On 18. February 2020 at 21:32:31, Dick Hardt (dick.ha...@gmail.com 
>> ) wrote:
>> 
>>> Hey List 
>>> 
>>> (I'm using the OAuth 2.1 name as a placeholder for the doc that Aaron, 
>>> Torsten, and I are working on)
>>> 
>>> Given the points Aaron brought up in
>>> 
>>> https://mailarchive.ietf.org/arch/msg/oauth/hXEfLXgEqrUQVi7Qy8X_279DCNU 
>>> 
>>> 
>>> 
>>> Does anyone have concerns with dropping the implicit flow from the OAuth 
>>> 2.1 document so that developers don't use it?
>>> 
>>> /Dick
>>> ___ 
>>> OAuth mailing list 
>>> OAuth@ietf.org  
>>> https://www.ietf.org/mailman/listinfo/oauth 
>>>  
>> 
>> CONFIDENTIALITY NOTICE: This email may contain confidential and pr

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

[Justin Richer]

+1

I support adoption of DPoP. I have written an implementation of its current 
state for a client and implemented its signature mechanism in another project 
(without the rest of the protocol, fwiw). 

Now, speaking as the editor of the group’s previous general-purpose http 
signature draft (for use with the general purpose PoP architecture) and 
co-editor of the new HTTP working group http signature draft, I still think 
that there’s room for both of these implementations out there. DPoP is simple 
and focused, it should do one thing and do it well. And the energies that are 
looking for a more general solution should help us make the wider HTTP 
Signature spec work across all those use cases.

 — Justin

> On Mar 17, 2020, at 8:20 AM, Rifaat Shekh-Yusef  wrote:
> 
> All,
> 
> As per the conclusion of the PoP interim meeting, this is a call for adoption 
> for the OAuth 2.0 Demonstration of Proof-of-Possession at the Application 
> Layer (DPoP) document:
> https://datatracker.ietf.org/doc/draft-fett-oauth-dpop/ 
> 
>  
> Please, let us know if you support or object to the adoption of this document 
> as a working group document by March 31st.
> 
> 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] Corona Virus and Vancouver

[Justin Richer]

I plan to be in Vancouver unless the IETF meeting itself is cancelled.

 — Justin

> On Mar 9, 2020, at 2:33 PM, Daniel Fett  wrote:
> 
> Hi all,
> 
> can we do a quick roll call on who is coming or not coming to Vancouver?
> 
> For me, at the current point in time, it depends on whether a significant 
> portion of the working group is attending in-person.
> 
> -Daniel
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

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

[Justin Richer]

I for one appreciate it being a separate draft as I don’t agree with this 
solution but do think we should move forward with DPoP.

 — Justin

> On Mar 10, 2020, at 6:40 AM, Rifaat Shekh-Yusef  wrote:
> 
> Mike,
> 
> What was the reason for creating a separate draft for this?
> Why cannot this be folded into the exiting DPoP draft?
> 
> Regards,
>  Rifaat
> 
> 
> On Mon, Mar 9, 2020 at 8:12 PM Mike Jones 
>  > wrote:
> As I previously described , members of the 
> OAuth working group have developed a simplified approach to providing 
> application-level proof-of-possession protections for OAuth 2.0 access tokens 
> and refresh tokens.  This approach is called OAuth 2.0 Demonstration of 
> Proof-of-Possession at the Application Layer (DPoP).  Among other benefits, 
> it does not require a complicated and error-prone procedure for signing HTTP 
> requests, as some past approaches have.
> 
>  
> 
> However, the DPoP specification to date has assumed that the client is using 
> the OAuth authorization code flow.  As promised at the last IETF meeting, 
> we’ve now published a simple companion specification that describes how DPoP 
> can be used with the OAuth implicit flow – in which access tokens are 
> returned directly from the authorization endpoint.  The specification is 
> mercifully brief because very little had to be added to supplement the 
> existing DPoP spec to enable use of DPoP with the implicit flow.  Thanks to 
> Brian Campbell and John Bradley for whiteboarding this solution with me.
> 
>  
> 
> Finally, in a related development, it was decided during the OAuth virtual 
> interim meeting today to call for working group adoption of the core DPoP 
> draft.  That’s an important step on the journey towards making it a standard.
> 
>  
> 
> The specification is available at:
> 
> https://tools.ietf.org/html/draft-jones-oauth-dpop-implicit-00 
> 
>  
> 
> An HTML-formatted version is also available at:
> 
> https://self-issued.info/docs/draft-jones-oauth-dpop-implicit-00.html 
> 
>  
> 
>-- Mike
> 
>  
> 
> P.S.  This notice was also posted at https://self-issued.info/?p=2063 
>  and as @selfissued 
> .
> 
>  
> 
> ___
> 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] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

[Justin Richer]

Why would the client need to know the refresh token’s expiry? Can’t they just 
use the refresh token and see? Either way it’s a single round trip to the AS 
and the client gets the same answer with the same recovery code path.

 — Justin

> On Mar 4, 2020, at 2:01 PM, Bill Jung 
>  wrote:
> 
> The question started when some RPs (client apps) asked that AS allow 
> introspection endpoint to RPs so that RPs can check their refresh token's 
> expiry. If AS allows this, which the spec is not clear about, then AS needs 
> to know if the request is coming from RP or RS so that AS can allow the 
> Access Token introspection to RS only. But then is that the right thing to do 
> even? 
> 
> Surely some clarification will eliminate the time spent on unnecessary 
> discussion among developers. 
> 
>    
> Bill Jung 
> Manager, Response Engineering 
> bj...@pingidentity.com 
> w: +1 604.697.7037
> Connect with us:   
> 
>     
>    
>  
>   
>  
> 
>   
> 
> 
> On Sun, Mar 1, 2020 at 9:33 PM David Waite 
>  > wrote:
> On Mar 1, 2020, at 10:11 PM, Andrii Deinega  > wrote:
> > 
> > How would the authorization server know who actually uses the
> > introspection endpoint assuming that a protected resource and a client
> > application use the same credentials (client_id and client_secret)?
> 
> In the external context, you have a client accessing a protected resource 
> with an access token. The client should treat the token as opaque, and 
> RFC7662 makes no allowances for that client to introspect its tokens.
> 
> If you control both the client and protected resource, you may decide to 
> short-cut and have them share credentials. However, the client logic still 
> should never be introspecting the tokens.
> 
> The security considerations also say that you must prove the authentication 
> of the protected resource, which I have interpreted to mean that access 
> tokens used to authorize the call to the introspection endpoint must be 
> issued to a confidential client - public clients cannot protect credentials 
> to perform an authentication. You want to limit introspection to prevent 
> denial of service and probing attacks, and to limit the amount of information 
> on viable attacks conveyed if someone steals a token.
> 
> -DW
> 
> > 
> > Regards,
> > Andrii
> > 
> > On Sun, Mar 1, 2020 at 7:38 PM David Waite  > > wrote:
> >> 
> >> I would expect the AS to invalidate the refresh token in this case, which 
> >> would not require a refresh token mode nor necessarily any signaling back 
> >> to the resource.
> >> 
> >> -DW
> >> 
> >>> On Mar 1, 2020, at 12:12 AM, Andrii Deinega  >>> > wrote:
> >>> 
> >>> Hello Bill,
> >>> 
> >>> I'm just thinking out loud about possible scenarios for a protected
> >>> resource here... It may decide to revoke a refresh token if a client
> >>> application tried to use it instead of an access token when the
> >>> protected resource is paranoid about security. In order to do that an
> >>> introspection response should include a non-standard parameter which
> >>> indicates that the requested token is refresh_token.
> >>> 
> >>> A user of the introspection endpoint should rely only on a value of
> >>> the active parameter (which is a boolean indicator) of the endpoint
> >>> response. This applies to both types of tokens. Note, the expiration
> >>> date, as well as other parameters, are defined as optional in the
> >>> specification. Both token types can be revoked before the expiration
> >>> date comes even if this parameter is presented as part of the
> >>> response. In my opinion, there are a number of reasons why this check
> >>> (for a refresh token) can be useful on the client application side.
> >>> 
> >>> --
> >>> Regards,
> >>> Andrii
> >>> 
> >>> 
> >>> On Fri, Feb 28, 2020 at 1:59 AM Bill Jung
> >>>  >>> > wrote:
>  
>  Hello, hopefully I am using the right email address.
>  
>  Simply put, can this spec be enhanced to clarify "Who can use the 
> 

Re: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields

[Justin Richer]

I can see the confusion in interpreting these requirements together. However, 
this is giving a specific semantics to omitted fields such that they’re treated 
as included in a specific way — with a null value. The intent of “include 
everything” is that you don’t leave out values and expect them to not change. 
Instead we define explicitly what happens when you leave out values — they get 
deleted, effectively. 

 — Justin

> On Mar 4, 2020, at 1:20 PM, Filip Skokan  wrote:
> 
> I guess what i meant to call out is that while you and the spec says how 
> omitted fields should be handled, but in the same section earlier it states 
> that all fields must be included.
> 
> S pozdravem,
> Filip Skokan
> 
> 
> On Wed, 4 Mar 2020 at 17:35, Justin Richer  <mailto:jric...@mit.edu>> wrote:
> I’m not sure what you’re asking — the text is not left over from anything and 
> is intentionally included. That text is saying that if I leave out the field 
> then the server treats it just like as if I had sent in a null value. So the 
> following are equivalent:
> 
> {
>   “client_name”: “foo”,
>   “tos_uri”: null
> }
> 
> And 
> 
> {
>   “client_name”: “foo”,
> }
> 
> 
> In both cases, it’s a signal that the client is removing the value from the 
> “tos_uri” field. It does not mean that the AS leaves the “tos_uri” field with 
> the value that it previously was (ie, a PATCH style request). 
> 
> The AS can reject the update request if it doesn’t want to allow the client 
> to blank out that field, for whatever reason. 
> 
>  — Justin
> 
> 
>> On Mar 4, 2020, at 10:42 AM, Filip Skokan > <mailto:panva...@gmail.com>> wrote:
>> 
>> So the following
>> 
>> Omitted fields MUST be treated as null or empty values by the server, 
>> indicating the client's request to delete them from the client's 
>> registration.
>> 
>> Does not mean the server needs to accept requests where fields are omitted? 
>> Is that a left over from previous drafts then?
>> 
>> S pozdravem,
>> Filip Skokan
>> 
>> 
>> On Wed, 4 Mar 2020 at 16:37, Justin Richer > <mailto:jric...@mit.edu>> wrote:
>> Your interpretation was our intent with that. It’s a full replace of the 
>> object. We had debating having PATCH style semantics, but ultimately decided 
>> that that was too complex for the most common update actions that a client 
>> would have.
>> 
>>  — Justin
>> 
>>> On Mar 3, 2020, at 8:42 AM, Filip Skokan >> <mailto:panva...@gmail.com>> wrote:
>>> 
>>> Hello everyone,
>>> 
>>> Section 2.2 of RFC 7592 <https://tools.ietf.org/html/rfc7592#section-2.2> 
>>> (Dynamic Client Registration Management Protocol) has the following two 
>>> statements that oppose one another.
>>> 
>>> This request MUST include all client metadata fields as returned to the 
>>> client from a previous registration, read, or update operation.
>>> 
>>> Omitted fields MUST be treated as null or empty values by the server, 
>>> indicating the client's request to delete them from the client's 
>>> registration.
>>> 
>>> What's the intention here? Should a server be accepting requests that are 
>>> missing client properties it has either on the record or "resolved" or not?
>>> 
>>> Personally I like to always make sure the client submits everything and to 
>>> remove properties it must pass null or empty string as the values. That way 
>>> the request is 100% intentional about the final state of the record it 
>>> wants to update to.
>>> 
>>> What do you think?
>>> 
>>> Best,
>>> Filip
>>> ___
>>> 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] Conflicting definitions in JWT Response for OAuth Token Introspection

[Justin Richer]

Gotcha, thanks. I’d prefer without it, I don’t think the meaning is any more 
“special” than another container field would be. I like this kind of 
encapsulation, though.

And to be honest, I wish we’d done that structure with dynamic registration as 
well. A software statement runs into similar issues but we got lucky that there 
weren’t the same kind of conflicts that we see here.

 — Justin

> On Mar 4, 2020, at 11:49 AM, Torsten Lodderstedt  
> wrote:
> 
> no particular reason, just indicating special meaning. I can live without it.
> 
>> Am 04.03.2020 um 17:29 schrieb Justin Richer :
>> 
>> Why the leading underscore in the name? Why not just “token_data”?
>> 
>> — Justin
>> 
>>> On Mar 4, 2020, at 11:19 AM, Torsten Lodderstedt  
>>> wrote:
>>> 
>>> Hi all, 
>>> 
>>> based on the recent feedback, Vladimir and I propose the following changes 
>>> to draft-ietf-oauth-jwt-introspection-response: 
>>> 
>>> - the token data are encapsulated in a container element “_token_data”
>>> - beyond this, the top-level container only contains meta data pertinent to 
>>> the JWT representing the signed (encrypted) introspection response
>>> - we need to add text to the spec to point out that replay detection must 
>>> be based on the jti in the “_token_data” container not the top level claim
>>> 
>>> That’s example of how it would look like:
>>> 
>>> {
>>> "iss":"https://as.example-bank.com";,
>>> "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>> "iat":1532452100,
>>> "_token_data":{
>>>"active":true,
>>>"iss":"https://as.example-bank.com";,
>>>"aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>>"jti":"53304e8a-a81e-4bc7-95e3-3b298d283512",
>>>"iat":1532452084,
>>>"exp":1532453100,
>>>"client_id":"3630BF72-E979-477A-A8FF-8A338F07C852",
>>>    "cnf":{
>>>   "x5t#S256":"YzEcNvUV3QXA5Bi9IB66b8psyqZBQgW4500ZGvNRdis"
>>>},
>>>"sub":"123456789087632345678"
>>> }
>>> }
>>> 
>>> The response for inactive tokens would look like this:
>>> 
>>> {
>>> "iss":"https://as.example-bank.com";,
>>> "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>> "iat":1532452100,
>>> "_token_data":{
>>>"active":false
>>> }
>>> }
>>> 
>>> What do you think?
>>> 
>>> best regards,
>>> Torsten. 
>>> 
>>>>> On 4. Mar 2020, at 16:37, Justin Richer  wrote:
>>>> 
>>>> +1, this encapsulation is much cleaner.
>>>> 
>>>>> On Mar 2, 2020, at 2:25 AM, Filip Skokan  wrote:
>>>>> 
>>>>> Perhaps we should consider leaving the root level JWT claims as-is per 
>>>>> JWT and push the introspection response unmodified as if it was regular 
>>>>> json response to a JWT claim called "introspection". Since regular 
>>>>> introspection uses the same claim names as JWT this would get around all 
>>>>> the conflicts.
>>>>> 
>>>>> Last time i brought it up the authors didn't want to consider it because 
>>>>> of existing implementations.
>>>>> 
>>>>> S pozdravem,
>>>>> Filip Skokan
>>>>> 
>>>>> 
>>>>> On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki  wrote:
>>>>> Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed the 
>>>>> same concerns in this mailing list about 6 months ago (on Sep. 4, 2019). 
>>>>> RFC 8707 didn't exist then, though.
>>>>> 
>>>>> Re: [OAUTH-WG] Question regarding 
>>>>> draft-ietf-oauth-jwt-introspection-response-05
>>>>> https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/
>>>>> 
>>>>> A JWT puts both (a) information about itself and (b) other data in its 
>>>>> payload part. When the "other data" have the same claim names as are used 
>>>>> to express information about the JWT itself, conflicts happen.
>>>>> 
>>>>> Also, it should be noted that Ben pointed out in other thread 

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

[Justin Richer]

>>>> 
>>>>> So it seems like there's actually something missing from OAuth which is 
>>>>> leading people to find the password grant and use that because it's the 
>>>>> only thing that most closely fits their existing model. It seems like 
>>>>> we'd be better off defining a new extension that captures the use case 
>>>>> people are actually doing, instead of encouraging the continuing use of 
>>>>> the password grant for this purpose.
>>>>> 
>>>>> 
>>>>> Aaron Parecki
>>>>> aaronparecki.com <http://aaronparecki.com/>
>>>>> @aaronpk
>>>>> 
>>>>> 
>>>>> 
>>>>> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
>>>>> >>>> <mailto:40pingidentity@dmarc.ietf.org>> wrote:
>>>>> Concur with the sentiment expressed by Neil here.
>>>>> 
>>>>> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden >>>> <mailto:neil.mad...@forgerock.com>> wrote:
>>>>> I’m not really sure the WG should be telling people what they “ought to 
>>>>> be doing” unless we have concrete security or interoperability reasons 
>>>>> for doing so.
>>>>> 
>>>>> I also don’t agree that people doing this are doing anything wrong. I 
>>>>> don’t always agree with what our customers do, but I’ve learnt over the 
>>>>> years not to second-guess their reasons for doing it.
>>>>> 
>>>>> Are Google wrong for using the JWT bearer grant (not client credentials) 
>>>>> and service accounts? They even go so far as to say “scopes are not a 
>>>>> security mechanism” [1] and tell people to use service account roles 
>>>>> instead. (Precisely because they also support non-OAuth auth methods, 
>>>>> which bypass any scopes).
>>>>> 
>>>>> Are we really going to tell them to rewrite it all to use the client 
>>>>> credentials grant?
>>>>> 
>>>>> [1]: 
>>>>> https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam
>>>>>  
>>>>> <https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam>
>>>>> 
>>>>>> On 21 Feb 2020, at 21:04, Justin Richer >>>>> <mailto:jric...@mit.edu>> wrote:
>>>>>> 
>>>>>> +1. I’ve seen this anti-pattern deployed all over the place, and it’s 
>>>>>> time to get rid of it and send people toward what they really ought to 
>>>>>> be doing.
>>>>>> 
>>>>>> Another thing I’ve seen is using different service accounts to get 
>>>>>> different sets of access for one client — if you’re doing that, you’ve 
>>>>>> got a client pretending to do two different things, or your APIs should 
>>>>>> be using scopes to differentiate access instead of client/user identity.
>>>>>> 
>>>>>> — Justin
>>>>>> 
>>>>>>> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle 
>>>>>>> >>>>>> <mailto:40amazon@dmarc.ietf.org>> wrote:
>>>>>>> 
>>>>>>> The client IDs can still be opaque identifiers provided by the AS, they 
>>>>>>> just happen to be associated with specific service accounts. Or they 
>>>>>>> could be the opaque IDs that the AS already issued for the service 
>>>>>>> account. Either way, the AS could issue a token with the appropriate 
>>>>>>> subject and other claims for the service account.
>>>>>>> 
>>>>>>> If your client identity is bound to a specific service account identity 
>>>>>>> (i.e.., the resource owner), then ROPC reduces down to Client 
>>>>>>> Credentials. What's the point in passing two identifiers and two 
>>>>>>> credentials for the same identity?
>>>>>>> 
>>>>>>> –
>>>>>>> Annabelle Backman (she/her)
>>>>>>> AWS Identity
>>>>>>> https://aws.amazon.com/identity/ <https://aws.amazon.com/identity/>
>>>>>>> 
>>>>>>> 
>>>>>>> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" 
>>>>&g

Re: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields

[Justin Richer]

I’m not sure what you’re asking — the text is not left over from anything and 
is intentionally included. That text is saying that if I leave out the field 
then the server treats it just like as if I had sent in a null value. So the 
following are equivalent:

{
  “client_name”: “foo”,
  “tos_uri”: null
}

And 

{
  “client_name”: “foo”,
}


In both cases, it’s a signal that the client is removing the value from the 
“tos_uri” field. It does not mean that the AS leaves the “tos_uri” field with 
the value that it previously was (ie, a PATCH style request). 

The AS can reject the update request if it doesn’t want to allow the client to 
blank out that field, for whatever reason. 

 — Justin


> On Mar 4, 2020, at 10:42 AM, Filip Skokan  wrote:
> 
> So the following
> 
> Omitted fields MUST be treated as null or empty values by the server, 
> indicating the client's request to delete them from the client's registration.
> 
> Does not mean the server needs to accept requests where fields are omitted? 
> Is that a left over from previous drafts then?
> 
> S pozdravem,
> Filip Skokan
> 
> 
> On Wed, 4 Mar 2020 at 16:37, Justin Richer  <mailto:jric...@mit.edu>> wrote:
> Your interpretation was our intent with that. It’s a full replace of the 
> object. We had debating having PATCH style semantics, but ultimately decided 
> that that was too complex for the most common update actions that a client 
> would have.
> 
>  — Justin
> 
>> On Mar 3, 2020, at 8:42 AM, Filip Skokan > <mailto:panva...@gmail.com>> wrote:
>> 
>> Hello everyone,
>> 
>> Section 2.2 of RFC 7592 <https://tools.ietf.org/html/rfc7592#section-2.2> 
>> (Dynamic Client Registration Management Protocol) has the following two 
>> statements that oppose one another.
>> 
>> This request MUST include all client metadata fields as returned to the 
>> client from a previous registration, read, or update operation.
>> 
>> Omitted fields MUST be treated as null or empty values by the server, 
>> indicating the client's request to delete them from the client's 
>> registration.
>> 
>> What's the intention here? Should a server be accepting requests that are 
>> missing client properties it has either on the record or "resolved" or not?
>> 
>> Personally I like to always make sure the client submits everything and to 
>> remove properties it must pass null or empty string as the values. That way 
>> the request is 100% intentional about the final state of the record it wants 
>> to update to.
>> 
>> What do you think?
>> 
>> Best,
>> Filip
>> ___
>> 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] Conflicting definitions in JWT Response for OAuth Token Introspection

[Justin Richer]

Why the leading underscore in the name? Why not just “token_data”?

 — Justin

> On Mar 4, 2020, at 11:19 AM, Torsten Lodderstedt  
> wrote:
> 
> Hi all, 
> 
> based on the recent feedback, Vladimir and I propose the following changes to 
> draft-ietf-oauth-jwt-introspection-response: 
> 
> - the token data are encapsulated in a container element “_token_data”
> - beyond this, the top-level container only contains meta data pertinent to 
> the JWT representing the signed (encrypted) introspection response
> - we need to add text to the spec to point out that replay detection must be 
> based on the jti in the “_token_data” container not the top level claim
> 
> That’s example of how it would look like:
> 
> {
>   "iss":"https://as.example-bank.com";,
>   "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>   "iat":1532452100,
>   "_token_data":{
>  "active":true,
>  "iss":"https://as.example-bank.com";,
>  "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>  "jti":"53304e8a-a81e-4bc7-95e3-3b298d283512",
>  "iat":1532452084,
>  "exp":1532453100,
>  "client_id":"3630BF72-E979-477A-A8FF-8A338F07C852",
>  "cnf":{
> "x5t#S256":"YzEcNvUV3QXA5Bi9IB66b8psyqZBQgW4500ZGvNRdis"
>  },
>  "sub":"123456789087632345678"
>   }
> }
> 
> The response for inactive tokens would look like this:
> 
> {
>   "iss":"https://as.example-bank.com";,
>   "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>   "iat":1532452100,
>   "_token_data":{
>  "active":false
>   }
> }
> 
> What do you think?
> 
> best regards,
> Torsten. 
> 
>> On 4. Mar 2020, at 16:37, Justin Richer  wrote:
>> 
>> +1, this encapsulation is much cleaner.
>> 
>>> On Mar 2, 2020, at 2:25 AM, Filip Skokan  wrote:
>>> 
>>> Perhaps we should consider leaving the root level JWT claims as-is per JWT 
>>> and push the introspection response unmodified as if it was regular json 
>>> response to a JWT claim called "introspection". Since regular introspection 
>>> uses the same claim names as JWT this would get around all the conflicts.
>>> 
>>> Last time i brought it up the authors didn't want to consider it because of 
>>> existing implementations.
>>> 
>>> S pozdravem,
>>> Filip Skokan
>>> 
>>> 
>>> On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki  wrote:
>>> Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed the 
>>> same concerns in this mailing list about 6 months ago (on Sep. 4, 2019). 
>>> RFC 8707 didn't exist then, though.
>>> 
>>> Re: [OAUTH-WG] Question regarding 
>>> draft-ietf-oauth-jwt-introspection-response-05
>>> https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/
>>> 
>>> A JWT puts both (a) information about itself and (b) other data in its 
>>> payload part. When the "other data" have the same claim names as are used 
>>> to express information about the JWT itself, conflicts happen.
>>> 
>>> Also, it should be noted that Ben pointed out in other thread that the 
>>> requirement for "jti" in draft-ietf-oauth-jwt-introspection-response, which 
>>> says "jti" is a unique identifier for the access token that MUST be stable 
>>> for all introspection calls, contradicts the definition of "jti", which 
>>> should be unique for each JWT.
>>> 
>>> Re: [OAUTH-WG] Benjamin Kaduk's Discuss on 
>>> draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)
>>> https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/
>>> 
>>> draft-ietf-oauth-jwt-introspection-response needs to be modified to solve 
>>> the conflicts.
>>> 
>>> Taka
>>> 
>>> On Sun, Mar 1, 2020 at 4:10 PM Takahiko Kawasaki  wrote:
>>> Hello,
>>> 
>>> I'm wondering if the following conflicts in "JWT Response for OAuth Token 
>>> Introspection" (draft 8) have already been pointed out.
>>> 
>>> RFC 8707 (Resource Indicators for OAuth 2.0) requires that 'aud' in an 
>>> introspection response hold the values of the 'resource' request 
>>> parame

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

[Justin Richer]

+1, this encapsulation is much cleaner.

> On Mar 2, 2020, at 2:25 AM, Filip Skokan  wrote:
> 
> Perhaps we should consider leaving the root level JWT claims as-is per JWT 
> and push the introspection response unmodified as if it was regular json 
> response to a JWT claim called "introspection". Since regular introspection 
> uses the same claim names as JWT this would get around all the conflicts.
> 
> Last time i brought it up the authors didn't want to consider it because of 
> existing implementations.
> 
> S pozdravem,
> Filip Skokan
> 
> 
> On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki  <mailto:t...@authlete.com>> wrote:
> Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed the same 
> concerns in this mailing list about 6 months ago (on Sep. 4, 2019). RFC 8707 
> didn't exist then, though.
> 
> Re: [OAUTH-WG] Question regarding 
> draft-ietf-oauth-jwt-introspection-response-05
> https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/ 
> <https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/>
> 
> A JWT puts both (a) information about itself and (b) other data in its 
> payload part. When the "other data" have the same claim names as are used to 
> express information about the JWT itself, conflicts happen.
> 
> Also, it should be noted that Ben pointed out in other thread that the 
> requirement for "jti" in draft-ietf-oauth-jwt-introspection-response, which 
> says "jti" is a unique identifier for the access token that MUST be stable 
> for all introspection calls, contradicts the definition of "jti", which 
> should be unique for each JWT.
> 
> Re: [OAUTH-WG] Benjamin Kaduk's Discuss on 
> draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)
> https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/ 
> <https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/>
> 
> draft-ietf-oauth-jwt-introspection-response needs to be modified to solve the 
> conflicts.
> 
> Taka
> 
> On Sun, Mar 1, 2020 at 4:10 PM Takahiko Kawasaki  <mailto:t...@authlete.com>> wrote:
> Hello,
> 
> I'm wondering if the following conflicts in "JWT Response for OAuth Token 
> Introspection" (draft 8 
> <https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08>) 
> have already been pointed out.
> 
> RFC 8707 <https://tools.ietf.org/html/rfc8707> (Resource Indicators for OAuth 
> 2.0) requires that 'aud' in an introspection response hold the values of the 
> 'resource' request parameters, whereas "JWT Response for OAuth Token 
> Introspection" says that 'aud' MUST identify the resource server receiving 
> the token introspection response. The definitions conflict.
> 
> RFC 7662 <https://tools.ietf.org/html/rfc7662> (OAuth 2.0 Token 
> Introspection) requires that 'iat' in an introspection response indicate when 
> the access/refresh token was issued, whereas "JWT Response for OAuth Token 
> Introspection" says that 'iat' indicates when the introspection response in 
> JWT format was issued. The definitions conflict.
> 
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
> 
> 
> 
> ___
> 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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields

[Justin Richer]

Your interpretation was our intent with that. It’s a full replace of the 
object. We had debating having PATCH style semantics, but ultimately decided 
that that was too complex for the most common update actions that a client 
would have.

 — Justin

> On Mar 3, 2020, at 8:42 AM, Filip Skokan  wrote:
> 
> Hello everyone,
> 
> Section 2.2 of RFC 7592  
> (Dynamic Client Registration Management Protocol) has the following two 
> statements that oppose one another.
> 
> This request MUST include all client metadata fields as returned to the 
> client from a previous registration, read, or update operation.
> 
> Omitted fields MUST be treated as null or empty values by the server, 
> indicating the client's request to delete them from the client's registration.
> 
> What's the intention here? Should a server be accepting requests that are 
> missing client properties it has either on the record or "resolved" or not?
> 
> Personally I like to always make sure the client submits everything and to 
> remove properties it must pass null or empty string as the values. That way 
> the request is 100% intentional about the final state of the record it wants 
> to update to.
> 
> What do you think?
> 
> Best,
> Filip
> ___
> 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] OAuth 2.1: dropping password grant

[Justin Richer]

; Am 19.02.2020 um 22:03 schrieb Neil Madden 
>>>>>>>>> :
>>>>>>>>> 
>>>>>>>>> I very much agree with this with regards to real users. 
>>>>>>>>> 
>>>>>>>>> The one legitimate use-case for ROPC I’ve seen is for service 
>>>>>>>>> accounts - where you essentially want something like 
>>>>>>>>> client_credentials but for whatever reason you need the RO to be a 
>>>>>>>>> service user rather than an OAuth2 client (typically so that some 
>>>>>>>>> lower layer of the system can still perform its required permission 
>>>>>>>>> checks).
>>>>>>>>> 
>>>>>>>>> There are better grant types for this - e.g. JWT bearer - but they 
>>>>>>>>> are a bit harder to implement. Having recently converted some code 
>>>>>>>>> from ROPC to JWT bearer for exactly this use-case, it went from a 
>>>>>>>>> couple of lines of code to two screens of code. For service to 
>>>>>>>>> service API calls within a datacenter I’m not convinced this resulted 
>>>>>>>>> in a material increase in security for the added complexity.
>>>>>>>>> 
>>>>>>>>> — Neil
>>>>>>>>> 
>>>>>>>>>> On 18 Feb 2020, at 21:57, Hans Zandbelt  
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> I would also seriously look at the original motivation behind ROPC: 
>>>>>>>>>> I know it has been deployed and is used in quite a lot of places but 
>>>>>>>>>> I have never actually come across a use case where it is used for 
>>>>>>>>>> migration purposes and the migration is actually executed (I know 
>>>>>>>>>> that is statistically not a very strong argument but I challenge 
>>>>>>>>>> others to come up with one...)
>>>>>>>>>> In reality it turned out just to be a one off that people used as an 
>>>>>>>>>> easy way out to stick to an anti-pattern and still claim to do OAuth 
>>>>>>>>>> 2.0. It is plain wrong, it is not OAuth and we need to get rid of it.
>>>>>>>>>> 
>>>>>>>>>> Hans.
>>>>>>>>>> 
>>>>>>>>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki  
>>>>>>>>>> wrote:
>>>>>>>>>> Agreed. Plus, the Security BCP is already effectively acting as a 
>>>>>>>>>> grace period since it currently says the password grant MUST NOT be 
>>>>>>>>>> used, so in the OAuth 2.0 world that's already a pretty strong 
>>>>>>>>>> signal..
>>>>>>>>>> 
>>>>>>>>>> Aaron
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer  
>>>>>>>>>> wrote:
>>>>>>>>>> There is no need for a grace period. People using OAuth 2..0 can 
>>>>>>>>>> still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1. 
>>>>>>>>>> 
>>>>>>>>>> — Justin
>>>>>>>>>> 
>>>>>>>>>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin 
>>>>>>>>>>>>  wrote:
>>>>>>>>>>> 
>>>>>>>>>>> I would suggest a SHOULD NOT instead of MUST, there are still sites 
>>>>>>>>>>> using this and a grace period should be provided before a MUST is 
>>>>>>>>>>> pushed out as there are valid use cases out there still.
>>>>>>>>>>> 
>>>>>>>>>>> From: OAuth  On Behalf Of Dick Hardt
>>>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM
>>>>>>>>>>> To: oauth@ietf.org
>>>>>>>>>>> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant
>>>>>>>>>>> 
>>>>>>>>>>> Hey List 
>>>>>>>>>>> 
>>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for the doc 
>>>>>>>>>>> that Aaron, Torsten, and I are working on)
>>>>>>>>>>> 
>>>>>>>>>>> In the security topics doc
>>>>>>>>>>> 
>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.4
>>>>>>>>>>> 
>>>>>>>>>>> The password grant MUST not be used.
>>>>>>>>>>> 
>>>>>>>>>>> Some background for those interested. I added this grant into OAuth 
>>>>>>>>>>> 2.0 to allow applications that had been provided password to 
>>>>>>>>>>> migrate. Even with the caveats in OAuth 2.0, implementors decide 
>>>>>>>>>>> they want to prompt the user to enter their credentials, the 
>>>>>>>>>>> anti-pattern OAuth was created to eliminate. 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Does anyone have concerns with dropping the password grant from the 
>>>>>>>>>>> OAuth 2.1 document so that developers don't use it?
>>>>>>>>>>> 
>>>>>>>>>>> /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
>>>>>>>>>> -- 
>>>>>>>>>> 
>>>>>>>>>> Aaron Parecki
>>>>>>>>>> aaronparecki.com
>>>>>>>>>> @aaronpk
>>>>>>>>>> 
>>>>>>>>>> ___
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> -- 
>>>>>>>>>> hans.zandb...@zmartzone.eu
>>>>>>>>>> ZmartZone IAM - www.zmartzone.eu
>>>>>>>>>> ___
>>>>>>>>>> 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
>>>>>> ___
>>>>>> 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

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

Re: [OAUTH-WG] [EXTERNAL] OAuth 2.1: dropping password grant

[Justin Richer]

There is no need for a grace period. People using OAuth 2.0 can still do OAuth 
2.0. People using OAuth 2.1 will do OAuth 2.1. 

 — Justin

> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin 
>  wrote:
> 
> I would suggest a SHOULD NOT instead of MUST, there are still sites using 
> this and a grace period should be provided before a MUST is pushed out as 
> there are valid use cases out there still.
>  
> From: OAuth  On Behalf Of Dick Hardt
> Sent: Tuesday, February 18, 2020 12:37 PM
> To: oauth@ietf.org
> Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant
>  
> Hey List 
>  
> (Once again using the OAuth 2.1 name as a placeholder for the doc that Aaron, 
> Torsten, and I are working on)
>  
> In the security topics doc
>  
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.4 
> 
>  
> The password grant MUST not be used.
>  
> Some background for those interested. I added this grant into OAuth 2.0 to 
> allow applications that had been provided password to migrate. Even with the 
> caveats in OAuth 2.0, implementors decide they want to prompt the user to 
> enter their credentials, the anti-pattern OAuth was created to eliminate. 
>  
>  
> Does anyone have concerns with dropping the password grant from the OAuth 2.1 
> document so that developers don't use it?
>  
> /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] HTTP Signing

[Justin Richer]

As many of you know, Annabelle and I have put forward a general-purpose HTTP 
Signing specification in the HTTP Working Group, at least initially based on 
the old Cavage signatures spec that’s been used in the wild. We expect a number 
of important changes to happen as it goes through the standards process (which 
is to say, we aren’t approaching this to get a stamp on existing code), 
including some key things that would allow it to be used for more advanced 
OAuth proof of possession work. I would fully expect that a fairly small 
profile of this new signature document would be sufficient for OAuth PoP 
tokens, replacing the expired draft-ietf-http-signatures spec. 

As I said in Singapore, I think that there’s room for this kind of thing 
alongside DPoP, which is much more focused and constrained than this is trying 
to be. 

The new draft is currently going through its call for adoption within the HTTP 
WG, and if you have any interest in this work moving forward, please join the 
thread on the HTTP list to show your support for the draft. The Call For 
Adoption is currently open and runs through Jan 31.

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

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

[Justin Richer]

But that’s also the same for parameters in a signed (non-encrypted) request 
object.

 — Justin

> On Jan 17, 2020, at 11:29 AM, Jim Manico  wrote:
> 
> It’s actually worse. Parameters in a URL leak over bookmarks, browser 
> history, logs everywhere, referrer headers... 
> 
> One of the most primary rules of secure coding on the web is to never put 
> sensitive data in a URL for •any• verb, not just GET.
> 
> --
> Jim Manico
> @Manicode
> Secure Coding Education
> +1 (808) 652-3805
> 
>> On Jan 17, 2020, at 11:24 AM, Richard Backman, Annabelle 
>>  wrote:
>> 
>> 
>> +1 to Justin’s comments. From a security standpoint parameters in the query  
>> string are no different from those in JWT unprotected headers (or protected 
>> if they’re also in the request object). Although I‘d amend Justin’s 
>> suggestion to say that if a parameter is both inside the request object and 
>> outside and they do not match, reject the request as suspicious.
>> 
>>> On Jan 17, 2020, at 5:45 AM, Justin Richer  wrote:
>>> 
>>>  I don’t agree with this stance from a security or implementation 
>>> perspective. 
>>> 
>>> If there’s a clear order of precedence for the information, it’s not 
>>> particularly problematic. Everything inside the request object is to be 
>>> taken over things outside the request object. We have the exact same 
>>> semantics and process with dynamic registration, where the software 
>>> statement is carried alongside plain JSON claims, and the two are mixed 
>>> with a very simple algorithm:
>>> 
>>>  - If a field is inside the signed payload, use that value and ignore any 
>>> copy of it on the outside
>>>  - If a field is not inside the signed payload and is outside the signed 
>>> payload, use the outside value
>>> 
>>> Can someone please point out a concrete security issue with this algorithm? 
>>> This is the extent of the “merge” semantics that we need here, and it would 
>>> solve not only the ability to use this for use cases that call for a more 
>>> static request object (perhaps signed by a third party and not the client) 
>>> along side the plain parameters that can vary, but also the backwards 
>>> compatibility issue that’s been discussed. With this algorithm in place, 
>>> you could have OIDC clients actually be compliant with the spec, since OIDC 
>>> requires replication of the values inside the request object on the outside 
>>> with exact matches. An OIDC server wouldn’t be fully compliant with the new 
>>> spec since it would reject some compliant JAR requests that are missing the 
>>> external parameters, but that’s fairly easy logic to add on the OIDC side. 
>>> And in that case you get a matrix of compatibility like:
>>> 
>>> 
>>>   JAR Server | OIDC Server  |
>>> ++--+
>>> JAR Client  | YES|  NO  |
>>> OIDC Client | YES| YES  |
>>> 
>>> Breaking one out of the four possible combinations in a very predictable 
>>> way is, I think, the best way to handle backwards compatibility here. 
>>> 
>>> But between this issue and JAR’s problematic call for the value of a 
>>> request_uri to always be a JWT and be fetchable by the AS (neither of which 
>>> are true in the case of PAR) makes me think we need to pull this back and 
>>> rework those things, in a push back to the IESG’s comments.
>>> 
>>>  — Justin
>>> 
>>> 
>>>> On Jan 16, 2020, at 7:38 PM, Joseph Heenan >>> <mailto:jos...@authlete.com>> wrote:
>>>> 
>>>> I agree with this, particularly the security concerns of merging. If we 
>>>> merge, we can much guarantee there will eventually be a security issue 
>>>> where an attacker is able to gain an advantage by adding a parameter to 
>>>> the url query (which the server would then happily process if that 
>>>> parameter isn’t found inside the request object). Ruling out that case 
>>>> makes security analysis (particularly when creating new OAuth2 parameters) 
>>>> significantly simpler.
>>>> 
>>>> Putting the iss in the JWE header and having the client_id duplicated 
>>>> outside the request object seem to address all the concerns I’ve seen 
>>>> raised.
>>>> 
>>>> (It seems like it may be unnecessary to have the client_id duplicated 
>>>> outside if the request_uri is a PAR on

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

[Justin Richer]

I don’t agree with this stance from a security or implementation perspective. 

If there’s a clear order of precedence for the information, it’s not 
particularly problematic. Everything inside the request object is to be taken 
over things outside the request object. We have the exact same semantics and 
process with dynamic registration, where the software statement is carried 
alongside plain JSON claims, and the two are mixed with a very simple algorithm:

 - If a field is inside the signed payload, use that value and ignore any copy 
of it on the outside
 - If a field is not inside the signed payload and is outside the signed 
payload, use the outside value

Can someone please point out a concrete security issue with this algorithm? 
This is the extent of the “merge” semantics that we need here, and it would 
solve not only the ability to use this for use cases that call for a more 
static request object (perhaps signed by a third party and not the client) 
along side the plain parameters that can vary, but also the backwards 
compatibility issue that’s been discussed. With this algorithm in place, you 
could have OIDC clients actually be compliant with the spec, since OIDC 
requires replication of the values inside the request object on the outside 
with exact matches. An OIDC server wouldn’t be fully compliant with the new 
spec since it would reject some compliant JAR requests that are missing the 
external parameters, but that’s fairly easy logic to add on the OIDC side. And 
in that case you get a matrix of compatibility like:


  JAR Server | OIDC Server  |
++--+
JAR Client  | YES|  NO  |
OIDC Client | YES| YES  |

Breaking one out of the four possible combinations in a very predictable way 
is, I think, the best way to handle backwards compatibility here. 

But between this issue and JAR’s problematic call for the value of a 
request_uri to always be a JWT and be fetchable by the AS (neither of which are 
true in the case of PAR) makes me think we need to pull this back and rework 
those things, in a push back to the IESG’s comments.

 — Justin


> On Jan 16, 2020, at 7:38 PM, Joseph Heenan  wrote:
> 
> I agree with this, particularly the security concerns of merging. If we 
> merge, we can much guarantee there will eventually be a security issue where 
> an attacker is able to gain an advantage by adding a parameter to the url 
> query (which the server would then happily process if that parameter isn’t 
> found inside the request object). Ruling out that case makes security 
> analysis (particularly when creating new OAuth2 parameters) significantly 
> simpler.
> 
> Putting the iss in the JWE header and having the client_id duplicated outside 
> the request object seem to address all the concerns I’ve seen raised.
> 
> (It seems like it may be unnecessary to have the client_id duplicated outside 
> if the request_uri is a PAR one though.)
> 
> Joseph
> 
> 
> 
>> On 16 Jan 2020, at 22:40, John Bradley  wrote:
>> 
>> I agree with the IESG reasoning that merging is problimatic.  Once we
>> allow that given a unknown list of possible paramaters with diffrent
>> security properties it would be quite difficult to specify safely.
>> 
>> Query paramaters can still be sent outside the JAR, but if they are in
>> the OAuth registry the AS MUST ignore them.
>> 
>> Puting the iss in the JWE headder addresses the encryption issue without
>> merging.
>> 
>> I understand that some existing servers have dependencys on getting the
>> clientID as a query paramater.
>> 
>> Is that the only paramater that people have a issue with as oposed to a
>> nice to have?
>> 
>> Would allowing the AS to not ignore the clientID as a query paramater as
>> long as it matches the one inside the JAR, basicly the same as Connect
>> request object but for just the one paramater make life easier for the
>> servers?
>> 
>> I am not promising a change but gathering info before proposing something.
>> 
>> John B.
>> 
>> 
>> On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:
>>> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote:
 On 14/01/2020 19:20, Takahiko Kawasaki wrote:
> Well, embedding a client_id claim in the JWE header in order to
> achieve "request parameters outside the request object should not be
> referred to" is like "putting the cart before the horse". Why do we
> have to avoid using the traditional client_id request parameter so
> stubbornly?
> 
> The last paragraph of Section 3.2.1
>  of RFC 6749 says
> as follows.
> 
>   /A client MAY use the "client_id" request parameter to identify
>   itself when sending requests to the token endpoint.  In the
>   "authorization_code" "grant_type" request to the token endpoint,
>   *an unauthenticated client MUST send its "client_id" to prevent
>   itself from inadvertently accep

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

[Justin Richer]

What you’ve described is exactly what happens in XYZ:

https://oauth.xyz/interaction/

And this is what we’re discussing as the basis in TxAuth. But in this case 
since you’re stuck with OAuth 2’s authorization endpoint syntax and semantics, 
you’re still limited with what’s happening there and it could come with its own 
security oddities (like maybe a new form of a mixup attack?) that we haven’t 
figured out yet. Like, is the AS allowed to send the client to something other 
than its own authorization endpoint? Is the client supposed to validate the 
syntax of the authorization endpoint URL against its discovery document? It 
deeply changes what OAuth 2 does, and that makes it really hard to add on.

Using request_uri to pass the artifact is clever, but I also like Torsten’s 
idea of using a new field defined by PAR to pass the artifact. Granted, in the 
Authlete implementation of PAR, we were able to re-use a whole bunch of code 
for processing request objects, and that was pretty nice. Still, the issues 
with JAR are non-zero, and so we need to figure out whether we should fully 
decouple or fix the issues. I’m in favor of fixing things and using these 
together, but there’s a lot of inertia against that.

 — Justin

> On Jan 16, 2020, at 11:36 AM, Neil Madden  wrote:
> 
> Why not have the PAR endpoint return a 30x redirect with the full URL to the 
> authorization endpoint in the Location header? That way the AS can decide for 
> itself how to communicate any id from the PAR endpoint to the authorization 
> endpoint.
> 
> This also has the side effect that you can kick off an OAuth2 flow with a 
> simple HTML form pointed at the PAR endpoint (with hidden fields for 
> state/code_challenge etc).
> 
> If actually performing the redirect is a bit problematic then at least the 
> idea of returning a full URL for the authorization endpoint (hyperlink) 
> rather than returning an id/URI and requiring the client to construct one 
> seems reasonable to me and would seem to avoid some of the difficulties being 
> discussed with JAR etc as the exact mechanism of communication becomes an 
> implementation detail that the client needn't know about.
> 
> -- Neil
> 
>> On 16 Jan 2020, at 16:25, Torsten Lodderstedt 
>> > <mailto:torsten=40lodderstedt@dmarc.ietf.org>> wrote:
>> 
>> I just thought about another option. What if we change PAR to not use the 
>> request_uri parameter but a new parameter, e.g. request_id?
>> 
>> That would decouple both specs. The reason why we use request_uri was to 
>> make the life of clients easier since they can use the standard library 
>> function for request objects to pass the PAR reference to the AS. Is this 
>> worth the trouble?
>> 
>>> Am 16.01.2020 um 16:48 schrieb Justin Richer >> <mailto:jric...@mit.edu>>:
>>> 
>>> +1 to this approach, and it sounds like JAR might need to come back to go 
>>> through another round anyway thanks to the breaking changes the IESG pushed 
>>> into it after it left WGLC.
>>> 
>>> I’d rather see us get this right than publish something many of us think is 
>>> broken. 
>>> 
>>> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>>> 
>>>  — Justin
>>> 
>>>> On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle 
>>>> mailto:richa...@amazon.com>> wrote:
>>>> 
>>>> The problem is the JWT requirement in JAR, not how we talk about PAR 
>>>> request_uri values in PAR. We need to either change the language in JAR 
>>>> (see my suggestions elsewhere in this thread), or add text in PAR that 
>>>> explicitly exempts PAR request_uri values (or preferably all AS-provided 
>>>> request_uri values) from this requirement (also see my suggestions 
>>>> elsewhere in this thread).
>>>>  
>>>> My preference remains the former. It strikes me as bad form for one 
>>>> extension to override normative requirements laid out in another document. 
>>>> Granted, the incompatibility scenarios introduced by this retcon are 
>>>> edge-case at best, but that just raises the question of why we can’t fix 
>>>> the draft that hasn’t actually been published yet.
>>>>  
>>>> – 
>>>> Annabelle Richard Backman
>>>> AWS Identity
>>>>  
>>>>  
>>>> From: OAuth mailto:oauth-boun...@ietf.org>> on 
>>>> behalf of Vladimir Dzhuvinov >>> <mailto:vladi...@connect2id.com>>
>>>> Organization: Connect2id Ltd..
>>>> Date: Wednesday, January 15, 2020 at 12:34 PM
&g

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

[Justin Richer]

Well that’s what I’m saying — we could have had restrictions within JWK (and 
maybe even a different syntax) that would guarantee a unique key ID, as well as 
ways to talk about it from the outside. 

 — Justin

> On Jan 15, 2020, at 3:53 PM, Vladimir Dzhuvinov  
> wrote:
> 
> On 14/01/2020 04:25, Justin Richer wrote:
>> It would’ve been nice if JWK could’ve agreed on a URL-based addressing
>> format for individual keys within the set, but that ship’s sailed.
> 
> For querying / selecting JWKs from a set this would have been a useful
> addition to the spec.
> 
> But I don't see how such an URL can help us to identify a single JWK in
> a set, given the possibility to have multiple JWKs with the same "kid".
> 
> I.e. if we do "https://example.com/jwks.json?kid=xyz";, there is no
> guarantee for a single key. Even if we add additional query params, like
> use, alg, etc, none of them guarantees a unique JWK identification.
> 
> I like the utility of that though.
> 
> Vladimir
> 
> 
> ___
> 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] Re: PAR: pushed requests must become JWTs

[Justin Richer]

+1 to this approach, and it sounds like JAR might need to come back to go 
through another round anyway thanks to the breaking changes the IESG pushed 
into it after it left WGLC.

I’d rather see us get this right than publish something many of us think is 
broken. 

Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.

 — Justin

> On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle  
> wrote:
> 
> The problem is the JWT requirement in JAR, not how we talk about PAR 
> request_uri values in PAR. We need to either change the language in JAR (see 
> my suggestions elsewhere in this thread), or add text in PAR that explicitly 
> exempts PAR request_uri values (or preferably all AS-provided request_uri 
> values) from this requirement (also see my suggestions elsewhere in this 
> thread).
>  
> My preference remains the former. It strikes me as bad form for one extension 
> to override normative requirements laid out in another document. Granted, the 
> incompatibility scenarios introduced by this retcon are edge-case at best, 
> but that just raises the question of why we can’t fix the draft that hasn’t 
> actually been published yet.
>  
> – 
> Annabelle Richard Backman
> AWS Identity
>  
>  
> From: OAuth mailto:oauth-boun...@ietf.org>> on 
> behalf of Vladimir Dzhuvinov  <mailto:vladi...@connect2id.com>>
> Organization: Connect2id Ltd.
> Date: Wednesday, January 15, 2020 at 12:34 PM
> To: Justin Richer 
> Cc: oauth , Nat Sakimura , "Richard 
> Backman, Annabelle" 
> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must 
> become JWTs
>  
> On 13/01/2020 19:32, Justin Richer wrote:
>> To be clear, I’m not saying we suggest a particular form, and I agree that 
>> we shouldn’t specify that “it’s a JWT” or something of that nature. But if 
>> we call the result of PAR “thing X” and the target of request_uri “thing X” 
>> in JAR, then we’re compatible without saying what “thing X” needs to be in 
>> all cases. 
> Good, we're on the same page then.
> How about simply saying that the result of PAR is an URI referencing the 
> pushed authZ request; at the authZ endpoint its processing is completed.
> No need is both clear and abstract enough to not require a form to be 
> specified.
>  
>> In cases where you do a remote look up, we want “thing X” to be formatted as 
>> a JWT.
> But why?
> Both PAR and authZ endpoints belong to the AS, which makes that impl 
> specific. The URI is the contract, between client and AS.
> The AS, if uService based, could choose to implement that as CBOR Web Token, 
> or some other verifiable blob, resulting in the same essential function, and 
> this isn't affecting the client <-> AS contract in any way.
>  
>> We had a case of similarly unintentional limiting in JAR previously, saying 
>> that you had to do an HTTP lookup on the request_uri, but I believe that’s 
>> been backed off now and made conditional.
> That was precisely my point.
> Vladimir
>  
>  
>>  — Justin
>> 
>> 
>>> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov >> <mailto:vladi...@connect2id.com>> wrote:
>>>  
>>> My suggestion is to abstain from specifying the concrete form of the 
>>> resource pointed to by the PAR URI. Regardless of URI type (URN, 
>>> downloadable https URL or something else), and even if the PAR endpoint and 
>>> the authZ endpoint are managed by two different entities (microservice or 
>>> other scenario).
>>> In the Connect2id implementation of PAR the returned URI doesn't point to a 
>>> request object and it doesn't point to a JWT either. It points to an 
>>> internally stored "pre-processed" authZ request, which the authZ endpoint 
>>> then picks up to complete the authZ.
>>> Even if we eventually end up in microservice world, or allow the PAR 
>>> endpoint to be managed by some external entity, the PAR URI - its 
>>> interpretation, validation and potentially resource retrieval (JWT or other 
>>> blob), is an "internal contract" on the AS side. This doesn't concern the 
>>> client, and in OAuth 2.0 the role of AS is indivisible.
>>>  
>>> I see PAR request + authZ request as one logical OAuth 2.0 authZ request: 
>>> the client submits an authZ request and gets an authZ response at the end. 
>>> The URI is necessary for the client to proceed from the 1st to the 2nd 
>>> step. If we manage to frame / word the PAR URI in this logical way, without 
>>> getting stuck in the JAR definition / framing of what the request_uri / 
>>> object i

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

[Justin Richer]

I would rather see extensions define a key ID than a new key set URI. Otherwise 
what’s the point of having more than one key in the set, with unique 
identifiers?

It would’ve been nice if JWK could’ve agreed on a URL-based addressing format 
for individual keys within the set, but that ship’s sailed.

 — Justin

> On Jan 10, 2020, at 9:34 PM, Dick Hardt  wrote:
> 
> I was not saying that there was anything special about keys, nor that we 
> needed to change OAuth.
> 
> While using one key and controlling where it us used via access control 
> works, it is not ideal.
> 
> OAuth could have had just one endpoint, and done access control for different 
> roles -- but it did not. We enabled flexibility by separating the 
> authorization endpoint and the token endpoint. The dynamic client 
> registration extension defined a new endpoint, the registration endpoint.
> 
> I don't think we can change what has been deployed today -- but NEW 
> extensions that use keys for new purposes SHOULD define their own URI.
> ᐧ
> 
> On Fri, Jan 10, 2020 at 11:31 AM Neil Madden  > wrote:
> Sure, but we know how to run resilient services. My point is that there’s 
> nothing particularly special about cryptographic keys: if you want to control 
> how they are used there is a whole range of normal access control methods you 
> can apply to them without needing to change anything in OAuth. 
> 
> Neil
> 
>> On 10 Jan 2020, at 18:50, Dick Hardt > > wrote:
>> 
>> 
>> There are many other factors to resiliency than multiple instances. 
>> 
>> On Fri, Jan 10, 2020 at 10:30 AM Neil Madden > > wrote:
>> 
>> 
>> > On 10 Jan 2020, at 17:22, Dick Hardt > > > wrote:
>> [...]
>> > 
>> > As to the suggestion of using a JWT-decryption-microservice, another goal 
>> > would be increased resiliency of the components. If the 
>> > JWT-decryption-microservice is unavailable, the whole system is 
>> > unavailable. If there are separate keys, then a failure in one component 
>> > does not fail the entire system. 
>> 
>> Well you can run more than one instance - it’s a completely stateless 
>> service. You can also run a separate instance (or set of instances) per key 
>> if you like. 
>> 
>> Neil

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

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

[Justin Richer]

Multiple access tokens are outside the scope of RAR. The request is intended to 
describe the access for a single returned access token. If semantics for 
multiple access tokens are agreed upon, then it can use the RAR structure, the 
Resources parameter, and the Scope parameter all in parallel again.

 — Justin

> On Jan 13, 2020, at 8:31 PM, Dick Hardt  wrote:
> 
> Torsten / Justin / Brian
> 
> In my reading of the ID, it appears that there is a request for just one 
> access token, and the authorization_details array lists one or more resources 
> that the one access token will provide access to. Correct?
> 
> I have heard anecdotally that there is interest in granting access to 
> multiple resources, and having multiple access tokens, which would enable 
> different components of a client to have different access tokens. 
> 
> Do you consider multiple access tokens out of scope of RAR?
> 
> /Dick

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

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

[Justin Richer]

To be clear, I’m not saying we suggest a particular form, and I agree that we 
shouldn’t specify that “it’s a JWT” or something of that nature. But if we call 
the result of PAR “thing X” and the target of request_uri “thing X” in JAR, 
then we’re compatible without saying what “thing X” needs to be in all cases. 

In cases where you do a remote look up, we want “thing X” to be formatted as a 
JWT. 

We had a case of similarly unintentional limiting in JAR previously, saying 
that you had to do an HTTP lookup on the request_uri, but I believe that’s been 
backed off now and made conditional.

 — Justin

> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov  
> wrote:
> 
> My suggestion is to abstain from specifying the concrete form of the resource 
> pointed to by the PAR URI. Regardless of URI type (URN, downloadable https 
> URL or something else), and even if the PAR endpoint and the authZ endpoint 
> are managed by two different entities (microservice or other scenario).
> 
> In the Connect2id implementation of PAR the returned URI doesn't point to a 
> request object and it doesn't point to a JWT either. It points to an 
> internally stored "pre-processed" authZ request, which the authZ endpoint 
> then picks up to complete the authZ.
> 
> Even if we eventually end up in microservice world, or allow the PAR endpoint 
> to be managed by some external entity, the PAR URI - its interpretation, 
> validation and potentially resource retrieval (JWT or other blob), is an 
> "internal contract" on the AS side. This doesn't concern the client, and in 
> OAuth 2.0 the role of AS is indivisible.
> 
> 
> 
> I see PAR request + authZ request as one logical OAuth 2.0 authZ request: the 
> client submits an authZ request and gets an authZ response at the end. The 
> URI is necessary for the client to proceed from the 1st to the 2nd step. If 
> we manage to frame / word the PAR URI in this logical way, without getting 
> stuck in the JAR definition / framing of what the request_uri / object is, it 
> would be great.
> 
> 
> 
> The normative language I think should focus on maintaining the OAuth 2.0 
> contract for the entire logical authZ request, together with the basic 
> contracts of 1) JAR and the 2) authZ endpoint.
> 
> 
> 
> Vladimir
> 
> 
> 
> On 10/01/2020 22:55, Justin Richer wrote:
>> So we could solve this by saying the resulting data object of a PAR is a 
>> request object. Which might also contain a request object internally as 
>> well. In that case JAR should back off from saying it’s a JWT and instead 
>> say it’s a request object. Or we define a new term for this authorization 
>> request blob thing.
>> 
>> Or PAR could at least say that if it’s dereferenced over a remote protocol 
>> then it MUST be a JWT, but otherwise it can be whatever you want. That’s 
>> where the real interop concerns come in.
>> 
>>  — Justin
>> 
>>> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle 
>>> >> <mailto:richanna=40amazon@dmarc.ietf.org>> wrote:
>>> 
>>> Correct. The problem becomes pretty clear in the context of PAR, where the 
>>> AS is generating and vending out the URI at the PAR endpoint, and consuming 
>>> it at the authorization endpoint. From an interoperability standpoint, it’s 
>>> analogous to the AS vending an authorization code at the authorization 
>>> endpoint and consuming it at the token endpoint.
>>> – 
>>> Annabelle Richard Backman
>>> AWS Identity
>>>  
>>>  
>>> From: John Bradley mailto:ve7...@ve7jtb.com>>
>>> Date: Friday, January 10, 2020 at 12:29 PM
>>> To: Brian Campbell >> <mailto:bcampb...@pingidentity.com>>
>>> Cc: Torsten Lodderstedt >> <mailto:tors...@lodderstedt.net>>, Nat Sakimura >> <mailto:n...@sakimura.org>>, "Richard Backman, Annabelle" 
>>> mailto:richa...@amazon.com>>, oauth >> <mailto:oauth@ietf.org>>
>>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests must 
>>> become JWTs
>>>  
>>> If we assume the client posts a JAR and gets back a reference.  Then the 
>>> reference is to a JAR. 
>>>  
>>> I think I see the problem.  If the server providing the reference is 
>>> associated with the AS then the server dosen't need to dereference the 
>>> object via HTTP, so it could be a URN as an example. 
>>>  
>>> So yes it is not a interoperability issue for the client.  
>>>  
>>> I will think about how I can finesse that. 
>>>  
>>> I 

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

[Justin Richer]

So we could solve this by saying the resulting data object of a PAR is a 
request object. Which might also contain a request object internally as well. 
In that case JAR should back off from saying it’s a JWT and instead say it’s a 
request object. Or we define a new term for this authorization request blob 
thing.

Or PAR could at least say that if it’s dereferenced over a remote protocol then 
it MUST be a JWT, but otherwise it can be whatever you want. That’s where the 
real interop concerns come in.

 — Justin

> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle 
>  wrote:
> 
> Correct. The problem becomes pretty clear in the context of PAR, where the AS 
> is generating and vending out the URI at the PAR endpoint, and consuming it 
> at the authorization endpoint. From an interoperability standpoint, it’s 
> analogous to the AS vending an authorization code at the authorization 
> endpoint and consuming it at the token endpoint.
> – 
> Annabelle Richard Backman
> AWS Identity
>  
>  
> From: John Bradley 
> Date: Friday, January 10, 2020 at 12:29 PM
> To: Brian Campbell 
> Cc: Torsten Lodderstedt , Nat Sakimura 
> , "Richard Backman, Annabelle" , 
> oauth 
> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests must become 
> JWTs
>  
> If we assume the client posts a JAR and gets back a reference.  Then the 
> reference is to a JAR. 
>  
> I think I see the problem.  If the server providing the reference is 
> associated with the AS then the server dosen't need to dereference the object 
> via HTTP, so it could be a URN as an example. 
>  
> So yes it is not a interoperability issue for the client.  
>  
> I will think about how I can finesse that. 
>  
> I agree it is not a change in intent. 
>  
> I will see if I can get our AD to accept that.
>  
> John B. 
>  
>  
>  
>  
> On Fri, Jan 10, 2020, 4:57 PM Brian Campbell  > wrote:
>> Sure but the text proposed (or something like it) qualifies it such that 
>> there aren't interoperability questions because it's only an implementation 
>> detail to the AS who both produces the URI and consumes its content.
>>  
>> On Fri, Jan 10, 2020 at 12:48 PM John Bradley > > wrote:
>>> It may be a challenge to change text saying that the contents of the 
>>> resource could be something other than a request object. 
>>>  
>>> If not a request object then what and how is that interoperable are likely 
>>> AD questions. 
>>>  
>>> I could perhaps see changing it to must be a request object, or other 
>>> format defined by a profile.
>>> 
>>> John B.  
>>>  
>>>  
>>> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell >> > wrote:
 Agree and agree. But given that the change suggested by Annabelle has no 
 impact on the client or interoperability, perhaps Nat or John could work 
 the change into the draft during the edits that happen during the final 
 stages of things?
  
 On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt 
 >>> > wrote:
> I would assume given the status of JAR, we don’t want to change it. And 
> as I said, this difference does not impact interoperability from client 
> perspective.
> 
> 
>> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle 
>> > >:
>> 
>> It would be more appropriate to add the text to JAR rather than PAR. It 
>> doesn't seem right for PAR to retcon rules in JAR. Moving the text to 
>> JAR also highlights the weirdness of giving PAR special treatment.
>>  
>> What if we changed this sentence in Section 5.2 of JAR:
>> The contents of the resource referenced by the URI MUST be a Request
>> 
>> Object.
>> 
>>  
>> To: 
>> The contents of the resource referenced by the URI MUST be a Request
>> 
>> Object, unless the URI was provided to the client by the Authorization
>> 
>> Server.
>> 
>>  
>> This would allow for use cases such as an AS that provides pre-defined 
>> request URIs, or vends request URIs via a client management console, or 
>> bakes them into their client apps.
>>  
>> – 
>> Annabelle Richard Backman
>> AWS Identity
>>  
>> On 1/8/20, 2:50 PM, "Torsten Lodderstedt" 
>> > > wrote:
>>  
>> Hi, 
>> 
>> you are right, PAR does not require the AS to represent the request 
>> as a JWT-based request object. The URI is used as internal reference 
>> only. That why the draft states
>> 
>> "There is no need to make the
>>   authorization request data available to other parties via this
>>   URI.”
>> 
>> This difference matters from an AS implementation perspective, it 
>> doesn't matter from a client's (interop) perspective.
>> 

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

[Justin Richer]

I would argue that the AS being monolithic, as seen by outside parties, is a 
core assumption in OAuth 2. While there are deployments that, for example, 
split the authorization and token endpoints into different domains and servers, 
the client still sees them as a single entity. 

I think it’s fair for any extension to OAuth 2 to rest on that assumption. Any 
effort to split the endpoints into parts should be seen as a deployment detail 
requiring some extra work on the deployer’s side. For example, take PKCE: you 
need to communicate the client’s challenge at the authorization endpoint back 
to the token endpoint in order to verify the verifier. Or even just the 
authorization code itself. OAuth doesn’t tell you how to do that at all because 
it assumes that’s your problem to solve and it’s internal to the box drawn by 
the protocol.

We do have a chance with the next generation work that we’re trying to start 
over in TxAuth to change these assumptions, but I think it’s too late to impose 
that requirement on OAuth 2.

 — Justin

> On Jan 10, 2020, at 10:50 AM, Neil Madden  wrote:
> 
> This is an interesting point.
> 
> I think OAuth has historically assumed that the AS is a monolithic system, or 
> at least can be treated like one by clients. I think we might have to revisit 
> quite a lot if we drop this assumption and adopt a threat model in which the 
> AS is itself composed of a collection of mutually distrusting entities. 
> Especially as different ASes might decide to divide up the trust boundaries 
> in different ways.
> 
> At least partially this feels like an internal implementation detail of the 
> AS that can also be solved internally to that AS. For example, rather than 
> providing microservices direct access to private keys you could implement a 
> JWT-decryption-microservice that other microservices call. It can then check 
> if the calling microservice is allowed to decrypt that type of JWT before 
> returning the response (e.g., by checking the "typ" header). The same can be 
> done for signing JWTs. Of course, that's not a perfect solution, but it 
> illustrates that we don't necessarily need to solve these problems in the WG.
> 
> If we go down the path of separate keys, then it might be simpler to 
> introduce new metadata elements to list the kids of valid key ids for a given 
> purpose rather than having multiple JWK Set endpoints. e.g. 
> "id_token_hint_encryption_kids": ["rsa-key-1", "ec-key-2"]. That avoids the 
> client having to fetch multiple sets of keys.
> 
> -- Neil
> 
>> On 10 Jan 2020, at 00:25, Richard Backman, Annabelle 
>> > > wrote:
>> 
>> The “typ” field helps prevent misrepresentation of a legitimately issued 
>> JWT, but it doesn’t address the issue I am trying to draw attention to, 
>> which is that the current model forces broader distribution and reuse of 
>> keys than is necessary, resulting in a greater blast radius for compromised 
>> keys or systems.
>>  
>> For many cases, this is not a significant concern, as the AS is a monolithic 
>> system with no internal trust boundaries. However, in cases where the AS is 
>> composed of multiple microservices performing different tasks, the need to 
>> share keys between different microservices undermines efforts to create 
>> trust boundaries between them. I gave one example of this in my original 
>> email, where ID Token generation and access token generation are relegated 
>> to independent systems, each with separate private keys for signing tokens. 
>> Suppose a malicious party compromised the ID Token generator, or gained 
>> access to its private key, and issued fraudulent access tokens signed using 
>> that key. Since verifiers of both token types will look to the same metadata 
>> file and thus the same JWK set, they have no way to recognize that these 
>> access tokens are fraudulent.
>>  
>> Note that while “typ” would help a verifier distinguish between an ID Token 
>> and an access token, it does not help in this case because the malicious 
>> party is generating well-formed access token JWTs, signed with a key that is 
>> legitimate for the AS but not for this purpose.
>>  
>> The case for this being a concern on the encryption side is fuzzier, 
>> primarily because we simply don’t have many use cases where different kinds 
>> of content gets encrypted and sent to the AS in different contexts. However, 
>> I gave one example on the PAR thread 
>> , 
>> where a PAR endpoint that decrypts request object JWTs will also be able to 
>> decrypt id_token_hint JWTs.
>>  
>> – 
>> Annabelle Richard Backman
>> AWS Identity
>>  
>>  
>> From: Mike Jones > >
>> Date: Thursday, January 9, 2020 at 11:34 AM
>> To: "Richard Backman, Annabelle" > >, oauth mailto:oauth@ietf.org>>
>> Subject: [UNVERIFIED SENDER] RE: Crypto

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: PAR metadata

[Justin Richer]

+1 to this being a security consideration

 — Justin

> On Jan 8, 2020, at 3:46 PM, Richard Backman, Annabelle 
>  wrote:
> 
> I almost included text to that effect, but thought it was getting too wordy. 
> However your suggestion is simple and concise. +1
> 
> Given all of this discussion, we should include a section on request 
> validation in Security Considerations, to provide some context on what might 
> be validated when and where, what kinds of problems deployments need to 
> consider, etc. I think this is useful to have in the document, but would be 
> too much clutter in the main body. We should keep that focused on the precise 
> normative requirements.
> 
> – 
> Annabelle Richard Backman
> AWS Identity
> 
> 
> On 1/8/20, 2:11 AM, "Torsten Lodderstedt" 
>  wrote:
> 
>Hi Annabelle, 
> 
>thanks for your proposal, which reads reasonable to me. 
> 
>I suggest to extend “and that the request has not been modified in a way 
> that would affect the outcome of the omitted steps.” a bit to also consider 
> policy changes that may have occurred between push and authorization request 
> processing. 
> 
>"and that the request or the authorization server’s policy has not been 
> modified in a way that would affect the outcome of the omitted steps."
> 
>best regards,
>Torsten. 
> 
>> On 8. Jan 2020, at 03:25, Richard Backman, Annabelle 
>>  wrote:
>> 
>> I think it’s clearer if we split out the requirements for the PAR endpoint 
>> and the requirements for the authorization endpoint, given that they are 
>> each covered in different sections of the doc (2 and 4, respectively). With 
>> that in mind, here are a couple suggestions:
>> 
>> For the text in Section 2.1:
>> 
>> 3.  The AS MUST validate the pushed request as it would an authorization
>> 
>>request sent to the authorization endpoint, however the AS MAY omit
>> 
>>validation steps that it is unable to perform when processing the
>> 
>>pushed request.
>> 
>> 
>> 
>> Additional text for Section 4 (note that this section pertains to the 
>> authorization endpoint):
>> 
>> The AS MUST validate authorization requests arising from a pushed request as
>> 
>> it would any other authorization request.  The AS MAY omit validation steps
>> 
>> that it performed when the request was pushed, provided that it can validate
>> 
>> that the request was a pushed request, and that the request has not been
>> 
>> modified in a way that would affect the outcome of the omitted steps.
>> 
>> 
>> 
>> This is longer than the current text and the other proposals, but it adds a 
>> few important points:
>>  • Turns the 2.1 SHOULD back into a MUST, with an explicit exception for 
>> validation that can’t be done yet.
>>  • Reinforces the fact that the authorization endpoint still needs to do 
>> validation.
>>  • Clearly states requirements for when an AS can trust that validation 
>> happened at the PAR endpoint.
>> 
>> – 
>> Annabelle Richard Backman
>> AWS Identity
>> 
>> 
>> From: Brian Campbell 
>> Date: Tuesday, January 7, 2020 at 2:54 PM
>> To: Vladimir Dzhuvinov 
>> Cc: Filip Skokan , "Richard Backman, Annabelle" 
>> , Dave Tonge , oauth 
>> , Nat Sakimura 
>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR 
>> metadata
>> 
>> A little more context about that proposed wording is in a github issue at
>>> 
>   •
>   •
>   •
>   •
>   •
>https://github.com/oauthstuff/draft-oauth-par/issues/38, which is 
> different driver than allowing a PAR endpoint to stash the encrypted request 
> object rather than decrypting/validating it. But it's kind of the same 
> concept at some level too - that there are some things that can't or won't be 
> validated at the PAR endpoint and those then have to be validated at the 
> authorization endpoint..
> 
>I rather like your suggested text, Vladimir, and have mentioned it in a 
> comment on the aforementioned issue.
> 
> 
>On Tue, Jan 7, 2020 at 6:58 AM Vladimir Dzhuvinov 
>  wrote:
>On 07/01/2020 00:22, Filip Skokan wrote:
>We've been discussing making the following change to the language
> 
>The AS SHOULD validate the request in the same way as at the authorization 
> endpoint. The AS MUST ensure that all parameters to the authorization request 
> are still valid at the time when the request URI is used.
>Could you expand a bit on the second sentence?
>Alternative suggestion:
>The AS MUST validate the request in the same way as at the authorization 
> endpoint, or complete the request validation at the authorization endpoint.
>Vladimir
> 
>This would allow the PAR endpoint to simply stash the encrypted request 
> object instead of decrypting and validating it. All within the bounds of 
> "SHOULD - We’d like you to do this, but we can’t always require it". This 
> supports "light weight PAR" implementation rather than introducing the 
> unnecessary complexity in the form of a second JWKS.
> 
>Best,
>  

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

[Justin Richer]

But merge gives us the ability, which has been stated here before, to have a 
fixed core set of parameters inside the JAR and a mixed set of variable 
parameters outside the JAR. 

What if by “merge” we really mean “you can’t repeat things in both places but 
you can have fields in either”.

— Justin

> On Jan 10, 2020, at 9:49 AM, John Bradley  wrote:
> 
> I haven't seen any real use of merge.   It happens with Connect as a side 
> effect of OAuths current requirement to have some of the parameters outside 
> the JAR. 
> 
> Nothing stops servers from ignoring parameters outside JAR or acting on query 
> parameters outside the JAR if they are not in the OAuth registry.   A server 
> can merge but that would not be JAR compliant if they care. 
> 
> If the AS returned an error for parameters values that differ between the JAR 
> and the query that is not required but I don't think that is prohibited.  I 
> need to look at that. 
> 
> JAR dosen't say your server can't do something else, but that is not JAR. 
> 
> Clients should be updated to have all the parameters in the JAR.  That should 
> be the case for most of not all clients now.   
> 
> For older servers they need to continue to include the required OAuth 
> parameters outside. 
> 
> Servers need to migrate and eventually move to returning a warning or error 
> when a registry parameter is outside the JAR if JAR is used. 
> 
> Especially if PAR is used (I suspect that will become the prefers pattern) 
> then merging won't really make sense. 
> 
> John B. 
> 
> On Tue, Jan 7, 2020, 6:19 AM Torsten Lodderstedt  > wrote:
> 
> 
>> Am 06.01.2020 um 23:50 schrieb John Bradley > >:
>> 
>> A client could duplicate those outside the request object for some sort of 
>> backwards compatability but they will be ignored.
>> 
> Is this used for backward compatibility with the OIDC servers?
>> What we have lost is the merge capability.  There are some use cases that 
>> could use that to have a presigned object that some paramaters like state 
>> are outside.  
>> 
> 
> Is this option used in the wild? As far as I understand the main use case is 
> a 3rd party signing the request object that way entitling the client for 
> something. I‘m asking since in my experience any kind of entitlement by a 3rd 
> party is handled behind the scene using registries.
> ___
> 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] Re: PAR metadata

[Justin Richer]

I just want to add that the requirement to validate the request at PAR the same 
way as you would at the auth endpoint is something that I want to see relaxed, 
and I hope it doesn’t make it through to the final standard. 

Also keep in mind that this is barely started as a WG document so any 
requirement is soft at best. When discussing things like this, we should keep 
this in mind by discussing the consequences of having a phrase in there, not 
behaving as if things are unchangeable. 

 — Justin

> On Jan 6, 2020, at 4:59 PM, Richard Backman, Annabelle 
>  wrote:
> 
> The issue isn’t that the PAR endpoint needs access to one specific request 
> object decryption key that could reasonably be shared across AS endpoints, 
> but that it actually needs access to the private keys for all encryption 
> public keys in the JWK set pointed to by the AS’s jwks_uri metadata property. 
> Since there is no way to designate one particular key as the one to use for 
> encrypting request objects, clients may reasonably use any encryption public 
> key in the JWK set to encrypt a request object. As one example of how this 
> could expose sensitive data to the PAR endpoint, if the PAR endpoint has all 
> the decryption keys for the keys in the AS’s JWK set, it would be able to 
> decrypt ID Tokens sent in id_token_hint request parameters. As more and more 
> use cases develop for encrypting blobs for the AS, this issue will only get 
> worse.
>  
> The PAR endpoint can’t simply stash the encrypted request object, as it is 
> required to verify the request, according to §2.1:
>  
> The AS MUST process the request as follows:
>  
> ...
>  
> 3.  The AS MUST validate the request in the same way as at the
>   authorization endpoint. ...
>  
> This language needs to be more flexible, IMHO, to allow for lightweight PAR 
> endpoints that may not have the information or authority needed to perform 
> all the validation that happens at the authorization endpoint. I need to 
> think about this more before I can say if it would adequately address my 
> concerns, but it’d be a good start and makes sense in its own right.
>  
> I think it’s pretty risky for us to base decision on an assumption that no 
> one is going to need or want to encrypt pushed request objects, particularly 
> when they’re JWTs, and JWTs have well established support for encryption, and 
> encrypted JWTs are supported by pass-by-value in OIDC and 
> draft-ietf-oauth-jwsreq. But if you insist, here are a few examples for why 
> someone might want to do this:
> The request object is passed by reference, and accessible on the public 
> Internet.
> The request object contains sensitive transaction-related data in RAR 
> parameters that the client’s authN/authZ stack doesn’t need to have access to.
> The AS requires request object encryption to minimize exposure to the hosted 
> PAR endpoint service it uses.
> #2, but the threat vector is gaps in end-to-end TLS.
> Any of the above, but the concern is message integrity, and the AS requires 
> requested objects to be encrypted for confidentiality and integrity 
> protection and does not support signed request objects.
>  
> – 
> Annabelle Richard Backman
> AWS Identity
>  
>  
> From: Neil Madden  >
> Date: Monday, January 6, 2020 at 6:29 AM
> To: Brian Campbell  >
> Cc: "Richard Backman, Annabelle"  >, Nat Sakimura  >, Dave Tonge  >, Torsten Lodderstedt 
> mailto:tors...@lodderstedt.net>>, oauth 
> mailto:oauth@ietf.org>>
> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata
>  
> Agreed. 
>  
> In addition, I'm not sure why the PAR endpoint would need access to the 
> decryption keys at all. If you're using encrypted request objects then the 
> PAR endpoint receives an encrypted JWT and then later makes the same (still 
> encrypted) JWT available to the authorization endpoint. If the PAR endpoint 
> is doing any kind of decryption or validation on behalf of the authorization 
> endpoint then they are clearly not in separate trust boundaries.
>  
> -- Neil
>  
> 
> 
>> On 6 Jan 2020, at 13:57, Brian Campbell 
>> > > wrote:
>>  
>> I really struggle to see the assumption that an entity be able to use the 
>> same key to decrypt the same type of message ultimately intended for the 
>> same purpose as an artificial limit. The same general assumption   underlies 
>> everything else in OAuth/OIDC (Vladimir's post points to some but not all 
>> examples of such). There's no reason for PAR to make a one-off exception. 
>> And should there be some deployment specific reason that truly requires that 
>> kind of isolation, there are certainly implementation options that aren't 
>> compatibility-breaking. And having said all that, I'm honestly a little 
>> surprised anyone is thinking much about encrypted request

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests

[Justin Richer]

+1

With the comment that there’s going to be a lot of coordination between this 
and other components already in OAuth 2 (scope, resource, aud/audience, JAR 
stuff) and anything that might come out of TxAuth. Those are two of my main 
goals as co-author of this work.

 — Justin

> On Jan 6, 2020, at 2:37 PM, Rifaat Shekh-Yusef  wrote:
> 
> All,
> 
> This is a call for adoption for the OAuth 2.0 Rich Authorization Requests 
> document.
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ 
>  
>  
> Please, let us know if you support or object to the adoption of this document 
> as a working group document by Jan 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] JWT Secured Authorization Request (JAR) vs OIDC request object

[Justin Richer]

I believe the IESG was incorrect in their review and what’s in the text now is 
not what the WG agreed to.

Question is, what’s our next step, then?

 — Justin

> On Jan 6, 2020, at 5:50 PM, John Bradley  wrote:
> 
> My take would be that any paramater in the OAuth registy is a OAuth 
> paramater. 
> 
> A client could duplicate those outside the request object for some sort of 
> backwards compatability but they will be ignored.
> 
> What we have lost is the merge capability.  There are some use cases that 
> could use that to have a presigned object that some paramaters like state are 
> outside.   
> 
> That was not popular with the IESG.  
> 
> John B.
> 
> On 1/6/2020 3:04 AM, n-sakimura wrote:
>> Up until -12 (Feb 13, 2017), it was using merge + JAR precedence if 
>> duplicated.
>> As of -13 (Mar 30, 2017), it was changed that the server does not have to do 
>> the merge, at least for OAuth Authorization request parameters. It says 
>> nothing about other parameters.
>> As of -14 (Jul 21, 2017), the wording was further strengthened by adding
>>  
>> The Authorization Server MUST only use the parameters in the Request Object 
>> even if the same parameter is provided in the query parameter.
>>  
>> So, the entire 6.3 now became
>>  <>6.3 <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-6.3>. 
>>  Request Parameter Assembly and Validation
>> 
>>The Authorization Server MUST extract the set of Authorization
>>Request parameters from the Request Object value.  The Authorization
>>Server MUST only use the parameters in the Request Object even if the
>>same parameter is provided in the query parameter.  The Authorization
>>Server then validates the request as specified in OAuth 2.0
>>[RFC6749 <https://tools.ietf.org/html/rfc6749>].
>>  
>> It says nothing on the non-OAuth parameters that came with the authorization 
>> request.
>> My take on the text is that all OAuth Authorization Request parameters MUST 
>> be in the request object.
>> Behaviors towards other parameters that happens to have come together with 
>> the authorization request outside of request object will be treated as 
>> non-OAuth parameters.
>>  
>> Nat Sakimura
>> Research Fellow, Nomura Research Institute
>> E: n-sakim...@nri.co.jp <mailto:n-sakim...@nri.co.jp>
>> T: +81(90)60136276
>> ---------
>> PLEASE READ:This  e-mail is confidential and intended for the 
>> named recipient only.
>> If you are not an intended recipient, please notify the sender and delete 
>> this e-mail.
>>  
>> From: OAuth  <mailto:oauth-boun...@ietf.org> On 
>> Behalf Of Justin Richer
>> Sent: Friday, January 3, 2020 2:35 AM
>> To: Takahiko Kawasaki  <mailto:t...@authlete.com>
>> Cc: Brian Campbell  
>> <mailto:bcampbell=40pingidentity@dmarc.ietf.org>; oauth  
>> <mailto:oauth@ietf.org>; Nat Sakimura  
>> <mailto:nat.sakim...@oidf.org>
>> Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC 
>> request object
>>  
>> For solution [2], this is the behavior that’s required for OIDC today, so I 
>> would say that’s the New Client behaving like an Old Client in order to talk 
>> to an Old Server. So in reality, (2) causes the request to be rejected, and 
>> that’s OK.
>>  
>> I don’t think it’s viable to require parameters to exist inside the request 
>> object at all times. Nor should we try to enumerate which parameters go 
>> inside and outside at all times — at least from the JAR/OAuth level of 
>> things. I think there are too many things that are application and 
>> deployment specific for us to make this call. The very nature of the request 
>> object changes for people — some have a static object that’s deployed with 
>> clients and some have something that the client creates at runtime for each 
>> request. 
>>  
>> If the instead the New Server requires that any parameters duplicated 
>> between the two places have to match (the OIDC method) or that in a conflict 
>> the request object values take precedence (the merge method), then problems 
>> 3-1 and 3-2 go away. 
>>  
>> With the merge-and-precedence behavior, which is what I thought that JAR had 
>> during WGLC, [3-1] is well-defined. The request is processed the same way 
>> every time because this is a New Server. The client is going to do OIDC’s 
>> “duplicate” method, so “merge with precedence” is effectively a no-op.
>>  
>> With the merge

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

[Justin Richer]

 JAR seems a good compromise (as I told before)
> 
> shall require that all parameters are present inside the signed request 
> object passed in the request or request_uri parameter;
> 
> instead of just saying "the authorization server supporting this 
> specification MUST only use the parameters included in the request object." 
> which will bring about [Problem 3-1]. That is, how about adding a rule like 
> "if request parameters exist outside the request object, they must exist 
> inside the request object, too."?
> 
> Any thoughts?
> 
> Best,
> Taka
> 
> 
> On Fri, Jan 3, 2020 at 12:48 AM Justin Richer  <mailto:jric...@mit.edu>> wrote:
> I think the nature of the backwards incompatibility is important here. The 
> way that things are now, using merge-with-precedence, you have the following 
> matrix of compatibility:
> 
> 
>  New Server  |  Old Server  |
> ---+-+--+
> New Client |  YES|  NO  |
> Old Client |  YES| YES  |
> 
> 
> If you ask me, this is the right balance for a breaking change. Old clients, 
> where the vast majority of the code is, don’t have to change. New clients can 
> only talk to servers with the new features, which is the ability to drop 
> parameters from the external request. This would apply to both OIDC and plain 
> OAuth.
> 
> I think we should follow this kind of pattern in the discussions on OAuth 
> 2.1, which I think JAR should be a part of/
> 
>  — Justin
> 
> 
> 
>> On Jan 2, 2020, at 3:40 AM, Takahiko Kawasaki > <mailto:t...@authlete.com>> wrote:
>> 
>> Breaking backward compatibility in this part would mean that OpenID 
>> Certification given to AS implementations with request_uri support will be 
>> invalidated once they support JAR. It also would mean that test cases in the 
>> official conformance suite need to be changed in a backward-incompatible 
>> manner, which would implicitly encourage that all certified implementations 
>> should re-try to get certification.
>> 
>> Changing the spec now might need more three to six months, but it would be 
>> worth considering what we get and lose by saving the months and breaking 
>> backward compatibility.
>> 
>> Best Regards,
>> Taka
>> 
>> On Wed, Dec 18, 2019 at 4:14 PM Nat Sakimura > <mailto:sakim...@gmail.com>> wrote:
>> So, no change is OK? 
>> 
>> On Wed, Dec 11, 2019 at 10:01 PM John Bradley > <mailto:ve7...@ve7jtb.com>> wrote:
>> I also slightly prefer the merge approach. 
>> 
>> There are plusses and minuses to both. 
>> 
>> Changing again now that it is past ISEG review and backing out a Discuss 
>> will add another three to six months at this point, if we can get them to 
>> agree to the change. 
>> 
>> John B. 
>> 
>> On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura > <mailto:sakim...@gmail.com>> wrote:
>> Correct. The WG supported the precedence approach and even merge just like 
>> OIDC as it is very useful from the implementation point of view and helps 
>> with a bunch of deployment patter. 
>> 
>> The push back came in from the Ben Campbell’s DISCUSS. 
>> See 
>> https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-actually-specifies-the
>>  
>> <https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-actually-specifies-the>
>> 
>> I am willing to go either way as long as people agree. My slight preference 
>> is to the original approach. 
>> 
>> Best, 
>> 
>> Nat Sakimura
>> 
>> 2019年8月29日(木) 6:56 Brian Campbell 
>> > <mailto:40pingidentity@dmarc.ietf.org>>:
>> FWIW, as best I can remember the change in question came as I result of 
>> directorate/IESG review rather than a WG decision/discussion. Which is 
>> likely why you can't find the "why" anywhere in the mailing list archive. 
>> 
>> On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan > <mailto:panva...@gmail.com>> wrote:
>> Well it kind of blows, doesn't it? I wasn't able to find the "why" anywhere 
>> in the mailing list archive around the time this was changed.
>> 
>> My take on satisfying both worlds looks like this
>> 
>> - allow just JAR - no other params when possible.
>> (which btw isn't possible to do with request_uri when enforcing client 
>> based uri whitelist and the jwsreq 5.2.2 shows as much)
>> - enforce the "dupe behaviours" defined in OIDC (if response_type or 
>> client_id is

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

[Justin Richer]

I think the nature of the backwards incompatibility is important here. The way 
that things are now, using merge-with-precedence, you have the following matrix 
of compatibility:


 New Server  |  Old Server  |
---+-+--+
New Client |  YES|  NO  |
Old Client |  YES| YES  |


If you ask me, this is the right balance for a breaking change. Old clients, 
where the vast majority of the code is, don’t have to change. New clients can 
only talk to servers with the new features, which is the ability to drop 
parameters from the external request. This would apply to both OIDC and plain 
OAuth.

I think we should follow this kind of pattern in the discussions on OAuth 2.1, 
which I think JAR should be a part of/

 — Justin



> On Jan 2, 2020, at 3:40 AM, Takahiko Kawasaki  wrote:
> 
> Breaking backward compatibility in this part would mean that OpenID 
> Certification given to AS implementations with request_uri support will be 
> invalidated once they support JAR. It also would mean that test cases in the 
> official conformance suite need to be changed in a backward-incompatible 
> manner, which would implicitly encourage that all certified implementations 
> should re-try to get certification.
> 
> Changing the spec now might need more three to six months, but it would be 
> worth considering what we get and lose by saving the months and breaking 
> backward compatibility.
> 
> Best Regards,
> Taka
> 
> On Wed, Dec 18, 2019 at 4:14 PM Nat Sakimura  > wrote:
> So, no change is OK? 
> 
> On Wed, Dec 11, 2019 at 10:01 PM John Bradley  > wrote:
> I also slightly prefer the merge approach. 
> 
> There are plusses and minuses to both. 
> 
> Changing again now that it is past ISEG review and backing out a Discuss will 
> add another three to six months at this point, if we can get them to agree to 
> the change. 
> 
> John B. 
> 
> On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura  > wrote:
> Correct. The WG supported the precedence approach and even merge just like 
> OIDC as it is very useful from the implementation point of view and helps 
> with a bunch of deployment patter. 
> 
> The push back came in from the Ben Campbell’s DISCUSS. 
> See 
> https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-actually-specifies-the
>  
> 
> 
> I am willing to go either way as long as people agree. My slight preference 
> is to the original approach. 
> 
> Best, 
> 
> Nat Sakimura
> 
> 2019年8月29日(木) 6:56 Brian Campbell 
>  >:
> FWIW, as best I can remember the change in question came as I result of 
> directorate/IESG review rather than a WG decision/discussion. Which is likely 
> why you can't find the "why" anywhere in the mailing list archive. 
> 
> On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan  > wrote:
> Well it kind of blows, doesn't it? I wasn't able to find the "why" anywhere 
> in the mailing list archive around the time this was changed.
> 
> My take on satisfying both worlds looks like this
> 
> - allow just JAR - no other params when possible.
> (which btw isn't possible to do with request_uri when enforcing client 
> based uri whitelist and the jwsreq 5.2.2 shows as much)
> - enforce the "dupe behaviours" defined in OIDC (if response_type or 
> client_id is in request object it must either be missing or the same in 
> regular request).
> - allows merging request object and regular parameters with request object 
> taking precedence since it is a very useful feature when having pre-signed 
> request object that's not one time use and clients using it wish to vary 
> state/nonce per-request.
> 
> I wish the group reconsidered making this breaking change from OIDC's take on 
> request objects - allow combination of parameters from the request object 
> with ones from regular parameters (if not present in request object).
> 
> S pozdravem,
> Filip Skokan
> 
> 
> On Wed, 28 Aug 2019 at 23:02, Brian Campbell  > wrote:
> Filip, for better or worse, I believe your assessment of the situation is 
> correct. I know of one AS that didn't choose which of the two to follow but 
> rather implemented a bit of a hybrid where it basically ignores everything 
> outside of the request object per JAR but also checks for and enforces the 
> presence and value of the few regular parameters (client_id, response_type) 
> that OIDC mandates. 
> 
> On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan  > wrote:
> Hello everyone,
> 
> in an earlier thread I've posed the following question that might have gotten 
> missed, this might have consequences for the existing implementations of 
> Request Objects in OIDC implementations - its making pure JAR requests 
> inco

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: I-D Action: draft-ietf-oauth-access-token-jwt-03.txt

[Justin Richer]

Vectors of Trust was meant to be used in place of things like 
AuthenticationContextReference (acr) and its kin, so this is a fair assessment. 

It does still require a shared understanding of what a given vector means by 
processing it in the context of its trust mark.

 — Justin

> On Dec 23, 2019, at 2:13 PM, Benjamin Kaduk  wrote:
> 
> On Tue, Dec 17, 2019 at 09:12:26PM +, Richard Backman, Annabelle wrote:
>>> That's a pretty strong statement :)
>> 
>> One I should’ve clarified. 😃 I don’t mean that the one-RS-per-AT model is 
>> not used at all, just that it is not universal and comes with real, 
>> practical tradeoffs that may not be appropriate for all use cases. 
>> Consequently, we should not design fundamental specs that mandate its 
>> adoption.
>> 
>> 
>>> …knowledge of that level isn't necessary.
>> 
>> Either the RS and AS have a shared understanding of that level, or the RS is 
>> trusting the AS to decide what “AuthenticatedClient” means, and set it 
>> accordingly. The latter requires that the RS only supports ASes that have a 
>> shared (or substantially similar) understanding of what that level is, which 
>> is unlikely outside of a closed system. In that case, there isn’t a lot of 
>> value in providing a standard claim, as the closed system could just as 
>> easily define a proprietary one.
> 
> Talk of the different potential levels of authentication calls to mind RFC
> 8485's "Vectors of Trust" idiom, though, IIUC, it would require some
> adaptation to be useful here.
> 
> -Ben
> 
> ___
> 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 2.0 Pushed Authorization Requests

[Justin Richer]

I support adoption of PAR and have already implemented the draft specification.

 - Justin

> On Dec 17, 2019, at 7:59 AM, Rifaat Shekh-Yusef  wrote:
> 
> All,
> 
> This is a call for adoption of for the OAuth 2.0 Pushed Authorization 
> Requests document.
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ 
>  
> 
> There was a good support for this document during the Singapore meeting, and 
> on the mailing list in the Meeting Minutes thread.
> 
> Please, let us know if you support or object to adopting this document as a 
> working group document by Dec 27th.
> 
> If you have already indicated your support on the Meeting Minutes thread, you 
> do not need to do it again on this thread.
> 
> 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] Meeting Minutes

[Justin Richer]

+1 to this. My take away was that PAR was pretty clear for adoption right now, 
RAR had interest but more question/debate. 

FWIW I’m in favor of both of them.

 — Justin

> On Dec 16, 2019, at 11:26 AM, Brian Campbell 
>  wrote:
> 
> With respect to the Pushed Authorization Requests (PAR) draft the minutes do 
> capture an individual comment that it's a "no brainer to adopt this work" but 
> as I recall there was also a hum to gauge the room's interest in adoption, 
> which was largely in favor of such. Of course, one hum in Singapore isn't the 
> final word but, following from that, I was hoping/expecting to see a call for 
> adoption go out to the mailing list? 
> 
> On Tue, Dec 3, 2019 at 1:26 AM Hannes Tschofenig  > wrote:
> Here are the meeting minutes from the Singapore IETF meeting:
> 
> https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03 
> 
>  
> 
> Tony was our scribe. Thanks!
> 
>  
> 
>  
> 
> 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 
> 
> 
> 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] New Version Notification for draft-fett-oauth-dpop-03.txt

[Justin Richer]

I’m going to +1 Dick and Annabelle’s question about the scope here. That was 
the one major thing that struck me during the DPoP discussions in Singapore 
yesterday: we don’t seem to agree on what DPoP is for. Some (including the 
authors, it seems) see it as a quick point-solution to a specific use case. 
Others see it as a general PoP mechanism. 

If it’s the former, then it should be explicitly tied to one specific set of 
things. If it’s the latter, then it needs to be expanded. 

I’ll repeat what I said at the mic line: My take is that we should explicitly 
narrow down DPoP so that it does exactly one thing and solves one narrow use 
case. And for a general solution? Let’s move that discussion into the next 
major revision of the protocol where we’ll have a bit more running room to 
figure things out.

 — Justin

> On Nov 22, 2019, at 3:13 PM, Dick Hardt  wrote:
> 
> 
> 
> On Fri, Nov 22, 2019 at 3:08 PM Neil Madden  > wrote:
> On 22 Nov 2019, at 01:42, Richard Backman, Annabelle  > wrote:
>> There are key distribution challenges with that if you are doing validation 
>> at the RS, but validation at the RS using either approach means you’ve lost 
>> protection against replay by the RS. This brings us back to a core question: 
>> what threats are in scope for DPoP, and in what contexts?
> 
> 
> Agreed, but validation at the RS is premature optimisation in many cases. And 
> if you do need protection against that the client can even append a 
> confirmation key as a caveat and retrospectively upgrade a bearer token to a 
> pop token. They can even do transfer of ownership by creating copies of the 
> original token bound to other certificates/public keys. 
> 
> While validation at the RS may be an optimization in many cases, it is still 
> a requirement for deployments.
> 
> I echo Annabelle's last question: what threats are in scope (and out of 
> scope) for DPoP?
> 
> 
> ___
> 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 "OAuth 2.0 Security Best Current Practice"

[Justin Richer]

1. Normative MUST/REQUIRED is fine in a BCP. 

2. This is not the definitive list, but instead the best list of things that we 
have at this time. There will be more attacks, and more mitigations for those 
attacks.

 — Justin

> On Nov 6, 2019, at 3:16 PM, Jared Jennings  wrote:
> 
> Hi,
> 
> This is my first time reviewing a document or responding to the group. So, 
> with that introduction feel free to guide me along the way.
> 
> Reading through the document, I had a few high-level questions first. I will 
> have more detailed comments later, once I know I'm on the right track and I 
> assume those comments I should just share with the mailing list?
> 
> 1. Since the document is a "Best Practices" document, are the words "MUST" 
> and "REQUIRED" and other definitive terms? Would instead SHOULD and 
> RECOMMENDED be used?
> 
> 2. Should other possible threats and vulnerabilities be included? Meaning, is 
> the list the definitive known list?
> 
> Thanks!
> -Jared
> Skype:jaredljennings
> Signal:+1 816.730.9540
> WhatsApp: +1 816.678.4152
> 
> 
> 
> On Wed, Nov 6, 2019 at 2:27 AM Hannes Tschofenig  > wrote:
> Hi all,
> 
> this is a working group last call for "OAuth 2.0 Security Best Current 
> Practice".
> 
> Here is the document:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13 
> 
> 
> Please send you comments to the OAuth mailing list by Nov. 27, 2019.
> (We use a three week WGLC because of the IETF meeting.)
> 
> Ciao
> Hannes & Rifaat
> 
> 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

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

Re: [OAUTH-WG] oauth - New Meeting Session Request for IETF 106

[Justin Richer]

I’d like to present a readout of the TXAuth BoF, which is happening earlier in 
the week. 

 — Justin

> On Oct 4, 2019, at 2:08 PM, IETF Meeting Session Request Tool 
>  wrote:
> 
> 
> 
> A new meeting session request has just been submitted by Hannes Tschofenig, a 
> Chair of the oauth working group.
> 
> 
> -
> Working Group Name: Web Authorization Protocol
> Area Name: Security Area
> Session Requester: Hannes Tschofenig
> 
> Number of Sessions: 2
> Length of Session(s):  1.5 Hours, 1.5 Hours
> Number of Attendees: 50
> Conflicts to Avoid: 
> Chair Conflict: acme tls rats sipcore anima
> Technology Overlap: ace secevent teep suit core tokbind saag
> 
> 
> 
> People who must be present:
>  Roman Danyliw
>  Hannes Tschofenig
>  Rifaat Shekh-Yusef
> 
> Resources Requested:
> 
> Special Requests:
> 
> -
> 
> ___
> 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] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)

[Justin Richer]

All of these problems can be solved, and I think solved better, by securing the 
connection between the proxy and the back-end. That way the back end will be 
able look not only for a specific header, but verify that the header came from 
the proxy itself. An obscure header name is one way to do that, but it has a 
lot of issues with it, especially since it’s likely to be selected once during 
set-up and never changed throughout the lifetime of the deployment. I think 
there are likely much better solutions here, and they’d address this issue 
without things getting weird.

And one of the best things about a standard is that you’re still free to 
completely ignore it if you want to, so people can and will keep following 
whatever proprietary patterns they want to. But at least a standard mechanism 
would give us a way to say to newcomers and veterans alike “No really, here’s a 
way that we all agree works and has these properties”. 

 — Justin

> On Oct 30, 2019, at 3:43 AM, Neil Madden  wrote:
> 
> Replies below.
> 
>> On 29 Oct 2019, at 19:13, Justin Richer  wrote:
>> 
>> I would argue that making this standard would actually increase the 
>> likelihood of developers getting this right, as now instead of following 
>> some copy-pasted recipe for NGINX or Apache that they found on the web, they 
>> could turn on a standard setting that would take care of both stripping out 
>> incoming headers and injecting the appropriate values. And all of that can 
>> be covered in the security considerations with a bunch of normative text on 
>> top to make sure inbound headers are stripped. What you’re describing below 
>> is clever, but ultimately it’s just a small bit of obscurity more than 
>> anything real. 
> 
> Not really. If the header is cryptographically unguessable (eg includes a 
> 128-bit base32-encoded string) then it provides a real security improvement. 
> The header name becomes a bearer token effectively. There are many ways that 
> a reverse proxy can be misconfigured in a way that compromises the security 
> of trusted headers:
> 
> 1. There is the simple misconfiguration where you fail to strip trusted 
> headers from incoming requests. For example in HAProxy this is the difference 
> between set-header and add-header directives (and the add-header docs list 
> passing a client cert to the backend as an example use case [1] despite this 
> being insecure). Naive functional testing will still pass, but fairly basic 
> adversarial tests would catch this. A standard header/config option might 
> help with this simple case. 
> 
> 2. Scoping issues cause rules to not be applied where you expect them to. For 
> example, nginx has multiple levels of scope that you can define header rules 
> (http, server, location). But if you define *any* proxy_set_header directive 
> at the location level (for example) it will ignore *all* such directives at 
> the server or http levels, which can cause header-stripping rules to be 
> silently disabled. 
> 
> 3. More advanced attacks exploit differences in how individual reverse 
> proxies and application servers parse headers to smuggle headers or even 
> whole requests past the RP [2]. 
> 
> Using unguessable header names for transmitting security-critical information 
> between the RP and the app server provides an effective defense in depth 
> against all of these attacks. (They are all forms of confused deputy attack 
> and the unguessable header acts in the same way as an anti-CSRF token to 
> prevent these systematically). 
> 
> (I had thought the random header name pattern was widely known, as I’ve heard 
> it mentioned in conversations several times. But now I come to look for a 
> definitive reference to it I can only find it mentioned in our own docs [3] 
> and connect2id’s [4]). 
> 
> [1]: 
> http://cbonte.github.io/haproxy-dconv/2.1/configuration.html#4.2-http-request%20add-header
>  
> <http://cbonte.github.io/haproxy-dconv/2.1/configuration.html#4.2-http-request%20add-header>
> [2]: https://portswigger.net/web-security/request-smuggling 
> <https://portswigger.net/web-security/request-smuggling>
> [3]: 
> https://backstage.forgerock.com/docs/am/6.5/oauth2-guide/#provide-mtls-certs 
> <https://backstage.forgerock.com/docs/am/6.5/oauth2-guide/#provide-mtls-certs>[4]:
>  https://connect2id.com/products/server/docs/guides/tls-proxy 
> <https://connect2id.com/products/server/docs/guides/tls-proxy> 
> 
>> 
>> The way things are today, you’ve got to not only pick a header and figure 
>> out its format, but also do the injection protection step yourself. Since 
>> all of these are disconnected, there are a lot more places that it could 
>> fall over. Even a typo where you throw out 

Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)

[Justin Richer]

I would argue that making this standard would actually increase the likelihood 
of developers getting this right, as now instead of following some copy-pasted 
recipe for NGINX or Apache that they found on the web, they could turn on a 
standard setting that would take care of both stripping out incoming headers 
and injecting the appropriate values. And all of that can be covered in the 
security considerations with a bunch of normative text on top to make sure 
inbound headers are stripped. What you’re describing below is clever, but 
ultimately it’s just a small bit of obscurity more than anything real. 

The way things are today, you’ve got to not only pick a header and figure out 
its format, but also do the injection protection step yourself. Since all of 
these are disconnected, there are a lot more places that it could fall over. 
Even a typo where you throw out incoming “CLIENT_CERT” but inject 
“CLIENT_CERTS” or something like that would be disastrous. 

All in all, I am in favor of this being defined in one standard way, in 
addition to secure communication between proxies and backends being 
standardized — but this latter bit really seems like a separate problem.

 — Justin

> On Oct 28, 2019, at 12:32 PM, Neil Madden  wrote:
> 
> While there are some benefits to standardizing headers for this kind of 
> communication, there are some significant downsides - particularly when using 
> headers to communicate critical security information like certs. It is *very* 
> easy to misconfigure a reverse proxy to not strip Forwarded (or whatever) 
> headers from incoming requests, allowing a client to simply supply a 
> certificate as a header without authenticating the TLS connection with the 
> corresponding private key. One good practice to prevent this is to pick a 
> random and unguessable header name (configurable per installation) to be used 
> for communicating the certificate, rather than using something fixed and 
> standard. That way even if you misconfigure the proxy an attacker still has 
> to try and guess the correct header name.
> 
> I suppose the same thing could be accomplished by having an extension for 
> including a shared secret (or HMAC tag) in the header to authenticate it.
> 
> -- Neil
> 
>> On 28 Oct 2019, at 15:32, Brian Campbell 
>> > > wrote:
>> 
>> I don't think there's anything beyond defining something to carry the client 
>> certificate information (including the format and encoding). And it could 
>> well be a new RFC7239 parameter. Or it might just be a new HTTP header on 
>> its own.  
>> 
>> On Mon, Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef > > wrote:
>> Thanks Brian,
>> 
>> I guess my question is: given RFC7239 and the fact that it is 
>> straightforward to secure the channel between the terminating reverse proxy 
>> and the backend service in a cluster, is there anything, from a standard 
>> perspective, that we need to do beyond defining a new parameter to carry the 
>> client certificate information?
>> You seem suggest that the answer is yes. If so, can you please elaborate on 
>> why is that?
>> 
>> Regards,
>>  Rifaat
>> 
>> 
>> 
>> On Mon, Oct 28, 2019 at 8:42 AM Brian Campbell > > wrote:
>> 
>> 
>> On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef > > wrote:
>> 
>> On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell > > wrote:
>> 
>> I did look at RFC7239 when doing that and it could have been made to work 
>> but felt the fit wasn't quite right and would have been more cumbersome to 
>> use than not.  
>> 
>> 
>> Can you elaborate on this?
>> These days, with the zero trust model in mind, there are orchestration 
>> tools, e.g. Istio, that easily allows you to establish an MTLS channel 
>> between the reverse proxy/load balancer/API GW and the backend servers.
>> Why is that not sufficient? 
>> Which part is cumbersome?
>> 
>> What I meant was only that in the course of writing 
>> https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09 
>> , which aims to 
>> define HTTP header fields that enable a TLS terminating reverse proxy to 
>> convey information to a backend server about the validated Token Binding 
>> Message received from a client, it seemed more straightforward and 
>> sufficient for the use-case to use new HTTP headers to carry the information 
>> rather than to use new fields in the Forwarded header framework from 
>> RFC7239.
>>  
>> 
>> 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

Re: [OAUTH-WG] Tx Auth BOF agenda items

[Justin Richer]

I would like to discuss XYZ, to give a quick background and update to the 
project. I project that to take about 20 min if we dive right into the gritty 
details. I can also do a level-set for the BoF, like 10min.

 — Justin

> On Oct 28, 2019, at 11:39 AM, Dick Hardt  wrote:
> 
> Hey OAuthers
> 
> As chair of the Tx BOF coming up in Singapore on Nov 18 @ 5:30-7:30PM Monday 
> Afternoon, I'm gathering who would be interested in making presentations, and 
> how much time you would like.
> 
> /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] [Txauth] Tx Auth BOF agenda items

[Justin Richer]

The intended scope is to provide a transactional model for doing authorization 
delegation, not for authenticating a transaction itself. I can understand the 
confusion! Naming things is hard. 

 — Justin

> On Oct 28, 2019, at 1:55 PM, Kyle Rose  wrote:
> 
> On Mon, Oct 28, 2019 at 11:39 AM Dick Hardt  > wrote:
> Hey OAuthers
> 
> As chair of the Tx BOF coming up in Singapore on Nov 18 @ 5:30-7:30PM Monday 
> Afternoon, I'm gathering who would be interested in making presentations, and 
> how much time you would like. 
> 
> Is this BoF limited to authorization, or would something like end-to-end 
> authentication of transaction request/response via a less trusted 
> intermediary (e.g., an API gateway or CDN) for purposes of limiting 
> transitive trust be in scope? I'm thinking of something akin to OSCORE-style 
> transactions, but more general (e.g., not specific to constrained computing 
> environments, not forcing the use of CBOR).
> 
> Thanks,
> Kyle
> -- 
> Txauth mailing list
> txa...@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth

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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt

[Justin Richer]

I also agree. Would it be possible to get this pushed to http or tls? It would 
be more appropriate there, and very helpful to have a general spec for this.

— Justin

On Oct 23, 2019, at 2:10 PM, Brian Campbell 
mailto:bcampbell=40pingidentity@dmarc.ietf.org>>
 wrote:

I agree with Ben here that it's not at all clear that the OAuth MTLS document 
should have defined a protocol from proxy to backend. I'd go so far as to say 
it's well outside the scope of the document and even the working group. 
Admittedly It would be nice if such a thing existed but it would have much 
wider applicability than one narrow profile of OAuth.

On Sun, Oct 20, 2019 at 8:06 PM Benjamin Kaduk 
mailto:ka...@mit.edu>> wrote:
Just on one narrow point:

On Wed, Oct 16, 2019 at 04:23:56PM +0200, Travis Spencer wrote:
> On Sun, Oct 6, 2019 at 3:31 PM Torsten Lodderstedt
> > Open: How would one implement sender constrained access tokens in that 
> > case? I’m asking since the receiving RS obviously has no access to the 
> > information from the TLS handshake since TLS termination happens at the 
> > proxy (or even in before the request hits the proxy). The RS would need to 
> > get provided with the cert fingerprint via a trustworthy header, i.e.. the 
> > RS must be aware of the fact it sits behind a proxy.
>
> This is unfortunately the typical case even with the mTLS draft. This
> is because SSL is almost never terminated by the AS; in my experience,
> TLS termination is instead handled by some very fast proxy.[1] In such
> cases, the proxy will pass the cert through to the AS in some
> undefined HTTP header with some undefined encoding. The mTLS spec
> should have defined this IMO, as it prevents interop for a primary use
> case -- sender constrained tokens.

It's not clear to me that mTLS should have defined a protocol from proxy to
backend; that seems like it could be a fairly generic thing and I know of
several people that are working on similar things, to one degree or
another.  draft-schwartz-tls-lb is the example that I can most easily find
in my archives; though it's working with non-TLS-terminating cases, there
is probably some commonality with TLS-terminating cases as well.

-Ben

___
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] New Version Notification for draft-lodderstedt-oauth-par-00.txt

[Justin Richer]

In a related note, JAR currently allows “client_id” to be optional for exactly 
the reason of it being included in the request object. However, it falls into 
the same issue where you can’t decrypt the request object without knowing which 
client’s keys to use, and you can’t know which client you’re dealing with 
without decrypting the object. I think that probably needs to be addressed in 
JAR.

— Justin

On Oct 10, 2019, at 12:59 PM, Justin Richer 
mailto:jric...@mit.edu>> wrote:

Thanks for the response. My concern is that interpretation of the requirement 
to “authenticate the client” could be interpreted in the FAPI draft’s sense, 
which is to say validating the signature on the request object and not doing 
anything else.

The problem comes from the fact that we’re effectively smashing together the 
conditions and assumptions of both the authorization endpoint and token 
endpoint into a new endpoint. It’s going to be messy, and we need to be very 
pedantic about what we mean if this draft is going to be implementable.

— Justin

On Oct 10, 2019, at 3:07 AM, Filip Skokan 
mailto:panva...@gmail.com>> wrote:

> If several of these are sent, they need to be consistent.

Given that client authentication precedes processing the rest of the request, 
if several client authentication methods are provided (header + secret or 
secret + assertion, etc) you generally reject the request, don't you?

Then there's the requirement for the client_id given by authentication method 
(none is still an "authentication" method - client_id in the body) to match the 
`iss` and `client_id` in the request object. That's already required by JAR 
processing rules and also PAR.

> But because JAR allows you to send in a request that is only a request 
> object, it also seems like you could pass in just the request object with no 
> other parameters, if I’m reading this right, which would imply that you could 
> be expected to glean the client ID from the request object itself without it 
> being in either a parameter or in another part of the request that’s easily 
> accessed.

It was only in the original FAPI revision of PAR that allowed the request 
object's signature to substitute client authentication, in the individual draft 
published to IETF that's not the case anymore - hence if "only" a request 
object is passed - with no client authentication (header, client_id in body, 
mtls) you fail the request.

As far as requiring client_id, here's what my implementation does

> When providing form-encoded parameters - client_id must be present in the 
> form.
> When providing signed/encrypted request object - client_id must be present in 
> the request object.

I wouldn't mind always requiring client_id, and i'm not worried about it not 
matching e.g. the authorization header because the client authentication 
middleware in place already takes care of that.

S pozdravem,
Filip Skokan


On Thu, 10 Oct 2019 at 03:13, Justin Richer 
mailto:jric...@mit.edu>> wrote:
So in doing an implementation of this, I ran into this problem as well. 
Specifically, we need to know which client we’re dealing with to fully validate 
the encrypted request object as well as perform the authentication. Currently, 
things are a little underspecified, and part of that comes from the history of 
this document: in the previous FAPI spec, the (required) signature of the 
request object acted as de-facto authentication for the client. In PAR, we not 
only can’t rely on the request itself being signed, we also require handling of 
client authentication in its many forms. That means the client ID could show up 
in any combination of:

 - Form parameter
 - Authorization header
 - Client assertion’s “iss" field
 - Request object’s “client_id” (and “iss”) field

If several of these are sent, they need to be consistent. And whatever value 
comes out needs to be consistent with the client’s authentication method.

But because JAR allows you to send in a request that is only a request object, 
it also seems like you could pass in just the request object with no other 
parameters, if I’m reading this right, which would imply that you could be 
expected to glean the client ID from the request object itself without it being 
in either a parameter or in another part of the request that’s easily accessed.

So herein lies the problem. In order to properly process the request object, 
you need to know which client you’re dealing with so you can validate the 
signing algs, keys, and all that. For signed requests that’s simple enough — 
parse in one step, then authenticate the client, then validate the signatures. 
But for encrypted JWTs it’s less clear: some methods would use only the 
server’s public key, but symmetric encryption algorithm/encoding pairs would 
use the client secret as the pairwise secret for the encryption. Which means 
that we need to 

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

[Justin Richer]

Thanks for the response. My concern is that interpretation of the requirement 
to “authenticate the client” could be interpreted in the FAPI draft’s sense, 
which is to say validating the signature on the request object and not doing 
anything else.

The problem comes from the fact that we’re effectively smashing together the 
conditions and assumptions of both the authorization endpoint and token 
endpoint into a new endpoint. It’s going to be messy, and we need to be very 
pedantic about what we mean if this draft is going to be implementable.

— Justin

On Oct 10, 2019, at 3:07 AM, Filip Skokan 
mailto:panva...@gmail.com>> wrote:

> If several of these are sent, they need to be consistent.

Given that client authentication precedes processing the rest of the request, 
if several client authentication methods are provided (header + secret or 
secret + assertion, etc) you generally reject the request, don't you?

Then there's the requirement for the client_id given by authentication method 
(none is still an "authentication" method - client_id in the body) to match the 
`iss` and `client_id` in the request object. That's already required by JAR 
processing rules and also PAR.

> But because JAR allows you to send in a request that is only a request 
> object, it also seems like you could pass in just the request object with no 
> other parameters, if I’m reading this right, which would imply that you could 
> be expected to glean the client ID from the request object itself without it 
> being in either a parameter or in another part of the request that’s easily 
> accessed.

It was only in the original FAPI revision of PAR that allowed the request 
object's signature to substitute client authentication, in the individual draft 
published to IETF that's not the case anymore - hence if "only" a request 
object is passed - with no client authentication (header, client_id in body, 
mtls) you fail the request.

As far as requiring client_id, here's what my implementation does

> When providing form-encoded parameters - client_id must be present in the 
> form.
> When providing signed/encrypted request object - client_id must be present in 
> the request object.

I wouldn't mind always requiring client_id, and i'm not worried about it not 
matching e.g. the authorization header because the client authentication 
middleware in place already takes care of that.

S pozdravem,
Filip Skokan


On Thu, 10 Oct 2019 at 03:13, Justin Richer 
mailto:jric...@mit.edu>> wrote:
So in doing an implementation of this, I ran into this problem as well. 
Specifically, we need to know which client we’re dealing with to fully validate 
the encrypted request object as well as perform the authentication. Currently, 
things are a little underspecified, and part of that comes from the history of 
this document: in the previous FAPI spec, the (required) signature of the 
request object acted as de-facto authentication for the client. In PAR, we not 
only can’t rely on the request itself being signed, we also require handling of 
client authentication in its many forms. That means the client ID could show up 
in any combination of:

 - Form parameter
 - Authorization header
 - Client assertion’s “iss" field
 - Request object’s “client_id” (and “iss”) field

If several of these are sent, they need to be consistent. And whatever value 
comes out needs to be consistent with the client’s authentication method.

But because JAR allows you to send in a request that is only a request object, 
it also seems like you could pass in just the request object with no other 
parameters, if I’m reading this right, which would imply that you could be 
expected to glean the client ID from the request object itself without it being 
in either a parameter or in another part of the request that’s easily accessed.

So herein lies the problem. In order to properly process the request object, 
you need to know which client you’re dealing with so you can validate the 
signing algs, keys, and all that. For signed requests that’s simple enough — 
parse in one step, then authenticate the client, then validate the signatures. 
But for encrypted JWTs it’s less clear: some methods would use only the 
server’s public key, but symmetric encryption algorithm/encoding pairs would 
use the client secret as the pairwise secret for the encryption. Which means 
that we need to know which client sent the request before the decryption 
happens.

Which in turn implies one of two things are true:

 - You can’t do a request object when it’s encrypted using a symmetric algorithm
 - You have to require the client ID from some other part of the request, such 
as a form parameter, auth header, or client assertion; the client_id in the 
request object cannot be counted on as being sufficient

In our current draft implementation of PAR, I’m turning off support for 
symmetric en

Re: [OAUTH-WG] IANA registry for error codes of RFC6749 section 5.2?

[Justin Richer]

They are in that registry as the “token endpoint response” error codes. RFC8628 
adds new ones.

I think that 6749 failed to put in the base ones.

— Justin

On Oct 10, 2019, at 5:15 AM, Ludwig Seitz 
mailto:ludwig.se...@ri.se>> wrote:

Hello OAuth WG,

while addressing some AD review comments on draft-ietf-ace-oauth-authz, I've 
come across a question I think you can help me with:

I was previously laboring under the misconception that the error codes defined 
in

https://tools.ietf.org/html/rfc6749#section-5.2

are registered here:

https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#extensions-error

Which is apparently not the case. Is there another registry that one should use 
(e.g. if one needs to add new error codes)?

If there is none (which seems to be the case), should we create one?

Regards,

Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
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] New Version Notification for draft-lodderstedt-oauth-rar-02.txt

[Justin Richer]

+1, that’s the idea — schema by fiat at the very least. This structure should 
be a flexible JSON object that can take whatever shape its attendant API would 
need it to have. The goal of the “common data elements” is to provide just 
enough structure to be generally useful, and it’s based on what dimensions I’ve 
seen “scope” used for in the wild most often. If you’ve got your own fields and 
dimensions, then those definitely should be their own space and not crammed 
into the existing ones. But if you’ve got something that feels like an 
“action”? Use that space.


— Justin

On Oct 8, 2019, at 10:49 AM, George Fletcher 
mailto:gffle...@aol.com>> wrote:

In general, it's difficult to determine how to extend for new types or if they 
should be wrapped up in "data" somehow.


{
"type":"https://example.com/my_field";<https://example.com/my_field>,
"actions":[
"read"
],
"my_field": {
"id": ""
}
}

I'm assuming the above is perfectly legit and the intended way for the spec to 
be extended? If not, what is the expected extension mechanism?

Thanks,
George

On 10/2/19 11:45 AM, Brian Campbell wrote:
I guess we differ in our opinion of how remiss that would be. But given what 
you've got in there now, the more narrow point I was trying to make was to say 
that I don't think "data" is defined or explained well enough to be helpful.

On Tue, Oct 1, 2019 at 4:33 PM Justin Richer 
mailto:jric...@mit.edu>> wrote:
I think that we need to define :some: common set to data elements in this spec, 
in order to help people who are using this and trying to apply it to their APIs 
do so in vaguely consistent ways. The details of which parts we standardize on 
are still, I think, up for grabs. I’d be happy to have a better name than 
“data” for this aspect, but I think there’s value in defining this kind of 
thing. Like in the financial space, it’s the difference between “transactions” 
and “accounts”. Or in the medical space, there’s “demographics” and 
“appointments” and “testResults”. This is a very, very, very common way to 
slice up OAuth-protected resources, and we’d be remiss to leave it undefined 
and just have every API developer need to come up with their own version of the 
same thing.

— Justin

On Oct 1, 2019, at 2:40 PM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:

I'm not entirely sold on the draft attempting to define this set of common data 
elements in the first place. But that said, I think (similar to George?) I'm 
struggling with "data" more than the others. The definition in the -02 draft is 
an "array of strings representing the kinds of data being requested from the 
resource" and I'm honestly having a hard time understanding what that actually 
means or how it would be used in practice. And I'm not sure roughly equating it 
to “what kind of thing I want” helped me understand any better.

On Tue, Sep 24, 2019 at 5:34 PM Justin Richer 
mailto:jus...@bspk.io>> wrote:
The idea behind the “locations”, “actions”, “data”, and “identifier” data 
element types mirrors what I’ve seen “scope” used for in the wild. They roughly 
equate to “where something is”, “what I want to do with it”, “what kind of 
thing I want”, and “the exact thing I want”, respectively. I’m completely open 
for better names, and have even been thinking “datatype” might be better than 
just “data” for the third one.

As for encoding, I think that form encoding makes sense because it’s the 
simplest possible encoding that will work. I personally don’t see a need to 
armor this part of the request with base64, as it is in JOSE, and doing so 
would make it one more step removed from easy developer understanding.

-- Justin Richer

Bespoke Engineering
+1 (617) 564-3801
https://bspk.io/



On Sep 24, 2019, at 1:45 PM, George Fletcher 
mailto:gffle...@aol.com>> wrote:

Just two questions...

1. What is the rationale that 'data' is really an array of arbitrary top-level 
claims? I find looking at the spec and not finding a 'data' section a little 
confusing.

2. What is the rationale for sending the JSON object as a urlencoded JSON 
string rather than a base64url encoded JSON string? The later would likely be 
smaller and easier to read:)

Thanks,
George

On 9/21/19 1:51 PM, Torsten Lodderstedt wrote:
Hi all,??

I just published a draft about ???OAuth 2.0 Rich Authorization Requests??? 
(formerly known as ???structured scopes???).??

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

It specifies a new parameter?authorization_details"??that is used to carry 
fine grained authorization data in the OAuth authorization request. This 
mechanisms was designed based on experiences gathered in the field of open 
banking, e.g. PSD2, and is intended to make the implementation of r

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

[Justin Richer]

So in doing an implementation of this, I ran into this problem as well. 
Specifically, we need to know which client we’re dealing with to fully validate 
the encrypted request object as well as perform the authentication. Currently, 
things are a little underspecified, and part of that comes from the history of 
this document: in the previous FAPI spec, the (required) signature of the 
request object acted as de-facto authentication for the client. In PAR, we not 
only can’t rely on the request itself being signed, we also require handling of 
client authentication in its many forms. That means the client ID could show up 
in any combination of:

 - Form parameter
 - Authorization header
 - Client assertion’s “iss" field
 - Request object’s “client_id” (and “iss”) field

If several of these are sent, they need to be consistent. And whatever value 
comes out needs to be consistent with the client’s authentication method.

But because JAR allows you to send in a request that is only a request object, 
it also seems like you could pass in just the request object with no other 
parameters, if I’m reading this right, which would imply that you could be 
expected to glean the client ID from the request object itself without it being 
in either a parameter or in another part of the request that’s easily accessed.

So herein lies the problem. In order to properly process the request object, 
you need to know which client you’re dealing with so you can validate the 
signing algs, keys, and all that. For signed requests that’s simple enough — 
parse in one step, then authenticate the client, then validate the signatures. 
But for encrypted JWTs it’s less clear: some methods would use only the 
server’s public key, but symmetric encryption algorithm/encoding pairs would 
use the client secret as the pairwise secret for the encryption. Which means 
that we need to know which client sent the request before the decryption 
happens.

Which in turn implies one of two things are true:

 - You can’t do a request object when it’s encrypted using a symmetric algorithm
 - You have to require the client ID from some other part of the request, such 
as a form parameter, auth header, or client assertion; the client_id in the 
request object cannot be counted on as being sufficient

In our current draft implementation of PAR, I’m turning off support for 
symmetric encryption in this one code path. If we can somehow count on being 
able to find a client_id every time, then we can refactor our implementation to 
parse and handle all the client stuff :before: handling the request object 
itself. In other words, if I always have to send something that identifies the 
client in addition to the request object, then I can count on that.

Thoughts?

— Justin

On Sep 30, 2019, at 11:21 AM, Brian Campbell 
mailto:bcampbell=40pingidentity@dmarc.ietf.org>>
 wrote:



On Thu, Sep 26, 2019 at 9:30 AM Aaron Parecki 
mailto:aa...@parecki.com>> wrote:
> Depending on client type and authentication method, the request might
>   also include the "client_id" parameter.

I assume this is hinting at the difference between public clients
sending only the "client_id" parameter and confidential clients
sending only the HTTP Basic Authorization header which includes both
the client ID and secret? It would probably be helpful to call out
these two common examples if I am understanding this correctly,
otherwise it seems pretty vague.

What this is trying to convey is that because client authentication at this 
Pushed Authorization Request Endpoint happens the same way as at the token 
endpoint (and other endpoints called directly by the client) the client_id 
parameter will sometimes be present but not necessarily as some types of client 
auth use the client_id parameter (none, client_secret_post, tls_client_auth, 
self_signed_tls_client_auth) and some don't (client_secret_basic, 
client_secret_jwt, private_key_jwt).

Although the draft does later say "The AS MUST validate the request the same 
way as at the authorization endpoint" which I think could reasonably be 
interpreted as requiring client_id.  e.g., 
https://tools.ietf.org/html/rfc6749?#section-4..1.1
 & https://tools.ietf.org/html/rfc6749?#section-4.2.1

So perhaps the sentence in question should be removed and have client_id be a 
required parameter at the PAR endpoint.


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] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt

[Justin Richer]

I stand with Ben’s contention that introspection should be about getting 
information :about: a token, and not about getting a new token. In fact, this 
was one of the core issues that I had with the draft as originally proposed.

If there are problems with token exchange, they should be fixed with token 
exchange and not piggybacked as an after-thought on this work.

— Justin

On Sep 27, 2019, at 3:51 PM, Benjamin Kaduk 
mailto:ka...@mit.edu>> wrote:

On Thu, Sep 26, 2019 at 11:26:31AM +0200, Travis Spencer wrote:
* Last but certainly not least is the restriction that the current
version places on disallowing of the introspection JWT response as an
access token. This is done in numerous places (the note in section 5,
8.1, etc.). I understand that there are some objection to this usage,
but we have had this protocol deployed for years, and it's running in
dozens of customer's facilities. This will break real applications of
this specification without a clear alternative. As we discussed in
London last year at the IETF meeting, token exchange isn't a viable
alternative (even still in its current draft form to the best of my
knowledge). Without a workable alternative to move to, I emphatically
but humbly request that this specification remove this restriction.

I don't think I was in the London session, so would you mind saying a bit
more about why token exchange isn't viable for your scenario?
As an AD, I support the efforts to be explicit about what token flow/usage
is being defined, which in effect means keeping introspection just
introspection and not "producing new tokens".

Thanks,

Ben

___
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] New Version Notification for draft-lodderstedt-oauth-par-00.txt

[Justin Richer]

To be clear, PAR is not the same as XYZ. Both are going to be inputs into the 
conversation under txauth, and there are similarities, but they shouldn’t be 
conflated.

In PAR, the result has to be a URI because that’s what JAR defines as the 
input. With XYZ, you get returned two things: a transaction handle and an 
interaction URI. These are both opaque to the client.

— Justin

On Sep 30, 2019, at 8:33 AM, Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:

I can understand the request URI being a URI that the client is providing the 
AS, but why would the client's request URI be at the AS?

As Justin has explained it in the past, the AS is returning a handle to the 
transaction. The only party that understands that handle as far as I know is 
the AS. It is meaningless to the client. Perhaps I am missing something else?
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=1389dd2f-e62a-4fac-a19a-a53f3277aa24]ᐧ

On Mon, Sep 30, 2019 at 2:53 AM Dave Tonge 
mailto:dave.to...@momentumft.co.uk>> wrote:
So although for this spec, request_uri is just an opaque string, it is defined 
more generally in 
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.2 as an:

 Absolute URI from which the Request Object (Section 2.1) can be obtained

And in section 5.2 as:

The "request_uri" value MUST be either URN as defined in
   RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230
   [RFC7230] .  The "request_uri" value MUST be reachable by the
   Authorization Server.

So this is why in the spec we have example of a URN and we have an ongoing 
discussion as to whether we should have a standard urn namespace that we 
recommend implementers use.

In the interest of keeping the specs in sync I think it makes sense to keep it 
a URN for this spec, but with more of an explanation as to why?

Dave

On Fri, 27 Sep 2019 at 19:22, Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:
If I understand the proposal correctly, the request URI is opaque to the 
client. Correct?

If so, why not just treat it as an opaque string?

If I were implementing the protocol, I would have the blob be a signed token so 
that I could verify the integrity before making a database call. It much easier 
to throw compute at a DDOS attack to verify a signature, than DB capacity.

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=432ca2fb-c1d5-411f-aa84-23542ebab7e1]ᐧ

On Thu, Sep 26, 2019 at 2:24 PM Justin Richer 
mailto:jric...@mit.edu>> wrote:
Yes, the request object is JWT-based, but the request URI is not. In other 
words, you can post a JWT but what you get back is a URI, not the JWT itself.  
The request URI was always meant to be a reference, and originally it was 
explicitly a reference to a signed request object.

— Justin

On Sep 26, 2019, at 10:03 AM, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:

The URI is intended to be a reference not a value.. If the client could send a 
JWT it would just send a request object instead of a request URI in the first 
place. So the intent is that it’s random, and maybe we should just say that 
explicitly.

I thought this language was explicitly to allow the use of structured
values for the request_uri? From the introduction:

but it also allows clients requiring an even
higher security level, especially cryptographically confirmed non-
repudiation, to explicitly adopt JWT-based request objects.


Aaron Parecki
aaronparecki.com<http://aaronparecki.com/>

On Thu, Sep 26, 2019 at 6:49 PM Justin Richer 
mailto:jric...@mit.edu>> wrote:

Aaron, some comments inline.

— Justin

On Sep 26, 2019, at 8:30 AM, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:

Hi Torsten,

I'm very glad to see this draft, I think it's definitely needed in
this space. Here are some of my thoughts on the draft.

"request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2"


Is it acceptable for the AS to return just an opaque string, rather
than something prefixed with "uri:*"? I don't think anyone would be
confused about copypasting the exact string from the "request_uri"
response into the "request_uri" parameter even if it didn't start with
"urn:". If, for whatever reason, it is required that this value is
actually a URI, is there some expected namespace to use other than
"example"? I worry that if all the examples in the spec are just
"urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will end up
using the text "example" because they don't understand why it's there,
and then it serves no purpose really.’


This field must be a URI, as per JAR:

  request_uri  The absolute URI as defined by RFC3986 [RFC3986] that
 points to the Request Object (Section 2.1) that holds
 authorization request paramet

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-rar-02.txt

[Justin Richer]

I think that we need to define :some: common set to data elements in this spec, 
in order to help people who are using this and trying to apply it to their APIs 
do so in vaguely consistent ways. The details of which parts we standardize on 
are still, I think, up for grabs. I’d be happy to have a better name than 
“data” for this aspect, but I think there’s value in defining this kind of 
thing. Like in the financial space, it’s the difference between “transactions” 
and “accounts”. Or in the medical space, there’s “demographics” and 
“appointments” and “testResults”. This is a very, very, very common way to 
slice up OAuth-protected resources, and we’d be remiss to leave it undefined 
and just have every API developer need to come up with their own version of the 
same thing.

— Justin

On Oct 1, 2019, at 2:40 PM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:

I'm not entirely sold on the draft attempting to define this set of common data 
elements in the first place. But that said, I think (similar to George?) I'm 
struggling with "data" more than the others. The definition in the -02 draft is 
an "array of strings representing the kinds of data being requested from the 
resource" and I'm honestly having a hard time understanding what that actually 
means or how it would be used in practice. And I'm not sure roughly equating it 
to “what kind of thing I want” helped me understand any better.

On Tue, Sep 24, 2019 at 5:34 PM Justin Richer 
mailto:jus...@bspk.io>> wrote:
The idea behind the “locations”, “actions”, “data”, and “identifier” data 
element types mirrors what I’ve seen “scope” used for in the wild. They roughly 
equate to “where something is”, “what I want to do with it”, “what kind of 
thing I want”, and “the exact thing I want”, respectively. I’m completely open 
for better names, and have even been thinking “datatype” might be better than 
just “data” for the third one.

As for encoding, I think that form encoding makes sense because it’s the 
simplest possible encoding that will work. I personally don’t see a need to 
armor this part of the request with base64, as it is in JOSE, and doing so 
would make it one more step removed from easy developer understanding.

-- Justin Richer

Bespoke Engineering
+1 (617) 564-3801
https://bspk.io/



On Sep 24, 2019, at 1:45 PM, George Fletcher 
mailto:gffle...@aol.com>> wrote:

Just two questions...

1. What is the rationale that 'data' is really an array of arbitrary top-level 
claims? I find looking at the spec and not finding a 'data' section a little 
confusing.

2. What is the rationale for sending the JSON object as a urlencoded JSON 
string rather than a base64url encoded JSON string? The later would likely be 
smaller and easier to read:)

Thanks,
George

On 9/21/19 1:51 PM, Torsten Lodderstedt wrote:
Hi all,??

I just published a draft about ???OAuth 2.0 Rich Authorization Requests??? 
(formerly known as ???structured scopes???).??

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

It specifies a new parameter?authorization_details"??that is used to carry 
fine grained authorization data in the OAuth authorization request. This 
mechanisms was designed based on experiences gathered in the field of open 
banking, e.g. PSD2, and is intended to make the implementation of rich and 
transaction oriented authorization requests much easier than with current OAuth 
2.0.

I???m happy that Justin Richer and Brian Campbell joined me as authors of this 
draft. We would would like to thank Daniel Fett, Sebastian Ebling, Dave Tonge, 
Mike Jones, Nat Sakimura, and Rob Otto for their valuable feedback during the 
preparation of this draft.

We look forward to getting your feedback.??

kind regards,
Torsten.??

Begin forwarded message:

From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>
Subject: New Version Notification for draft-lodderstedt-oauth-rar-02.txt
Date: 21. September 2019 at 16:10:48 CEST
To: "Justin Richer" mailto:i...@justin.richer.org>>, 
"Torsten Lodderstedt" 
mailto:tors...@lodderstedt.net>>, "Brian Campbell" 
mailto:bcampb...@pingidentity.com>>


A new version of I-D, draft-lodderstedt-oauth-rar-02.txt
has been successfully submitted by Torsten Lodderstedt and posted to the
IETF repository.

Name: draft-lodderstedt-oauth-rar
Revision: 02
Title: OAuth 2.0 Rich Authorization Requests
Document date: 2019-09-20
Group: Individual Submission
Pages: 16
URL: 
??https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
Htmlized: https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-lodde

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

[Justin Richer]

Yes, the request object is JWT-based, but the request URI is not. In other 
words, you can post a JWT but what you get back is a URI, not the JWT itself.  
The request URI was always meant to be a reference, and originally it was 
explicitly a reference to a signed request object.

— Justin

On Sep 26, 2019, at 10:03 AM, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:

The URI is intended to be a reference not a value. If the client could send a 
JWT it would just send a request object instead of a request URI in the first 
place. So the intent is that it’s random, and maybe we should just say that 
explicitly.

I thought this language was explicitly to allow the use of structured
values for the request_uri? From the introduction:

but it also allows clients requiring an even
higher security level, especially cryptographically confirmed non-
repudiation, to explicitly adopt JWT-based request objects.


Aaron Parecki
aaronparecki.com<http://aaronparecki.com>

On Thu, Sep 26, 2019 at 6:49 PM Justin Richer  wrote:

Aaron, some comments inline.

— Justin

On Sep 26, 2019, at 8:30 AM, Aaron Parecki  wrote:

Hi Torsten,

I'm very glad to see this draft, I think it's definitely needed in
this space. Here are some of my thoughts on the draft.

"request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2"


Is it acceptable for the AS to return just an opaque string, rather
than something prefixed with "uri:*"? I don't think anyone would be
confused about copypasting the exact string from the "request_uri"
response into the "request_uri" parameter even if it didn't start with
"urn:". If, for whatever reason, it is required that this value is
actually a URI, is there some expected namespace to use other than
"example"? I worry that if all the examples in the spec are just
"urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will end up
using the text "example" because they don't understand why it's there,
and then it serves no purpose really.’


This field must be a URI, as per JAR:

  request_uri  The absolute URI as defined by RFC3986 [RFC3986] that
 points to the Request Object (Section 2.1) that holds
 authorization request parameters stated in section 4 of OAuth 2.0
 [RFC6749].

Somewhat awkwardly, the JAR spec currently states that the AS has to do an HTTP 
GET on the request URI, so that will need to be fixed in JAR before it goes 
forward. I don’t think that was always the case though, and I’m not sure how 
that changed.

As for the namespace, “example” is ok for an example URN. The problem with URNs 
is that nobody really understands how to do domain-safe fully compliant URNs. 
So perhaps we should instead use “urn:fdc:example.com:….” Instead (as per 
https://tools.ietf.org/html/rfc4198).


The pushed authorization request endpoint shall be a RESTful API


I would drop the term RESTful and just say "HTTP API", as this
description is arguably RESTful at best.

Depending on client type and authentication method, the request might
also include the "client_id" parameter.


I assume this is hinting at the difference between public clients
sending only the "client_id" parameter and confidential clients
sending only the HTTP Basic Authorization header which includes both
the client ID and secret? It would probably be helpful to call out
these two common examples if I am understanding this correctly,
otherwise it seems pretty vague.


Not quite, those differences are for the token endpoint, and this is capturing 
things from the authorization endpoint. I don’t quite understand the 
differentiation listed here either, though.


The "request_uri" value MUST be generated using a cryptographically
strong pseudorandom algorithm


I assume this includes the use of a random number inside of a JWT, in
case the AS wants to use JWTs as the "request_uri" parameter"? If so,
it's probably worth spelling that out as it kind of reads like it has
to be literally a random string at first glance.


The URI is intended to be a reference not a value. If the client could send a 
JWT it would just send a request object instead of a request URI in the first 
place. So the intent is that it’s random, and maybe we should just say that 
explicitly.


That's all for now, thanks!


Aaron Parecki
aaronparecki.com
@aaronpk

On Sat, Sep 21, 2019 at 1:02 PM Torsten Lodderstedt
 wrote:


Hi all,

I just published a new draft that Brian Campbell, Dave Tonge, Filip Skokan, Nat 
Sakimura and I wrote.

https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00

It proposes a new endpoint, called "pushed authorization request endpoint”, 
that allows the client to push the Authorization Request payload with the AS on 
a backchannel connection instead of a front channel interaction. The AS 
provides the client with a request URI (ac

[OAUTH-WG] Transactional Authorization: TXAuth Mailing List and BoF

[Justin Richer]

Following up from the discussion in Montreal, we’ve created the 
non-working-group mailing list TXAuth to start discussion of transactional 
authorization work. Please join the list here:

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

We’ve also proposed a BoF for Singapore. The details of the agenda are still 
being discussed, and the description follows:

The OAuth protocol and its extensions have provided a powerful set of security 
capabilities for the internet over the last decade. A transactional model for 
collecting user consent, describing authorization requests, and delegating 
authority to another party could provide additional flexibility and power in 
ways that extending the existing OAuth 2.0 framework does not allow. 
Additionally, OAuth 2’s many extensions provide point solutions to similar 
problems that could be better addressed by a unified underlying design. The 
goal of this BoF is to discuss the additional needs in delegated authorization 
protocols, gauge the current thinking on how to address them, and to examine 
how some current and proposed efforts approach such problems. The goal of this 
BoF is not to discuss how to extend the OAuth 2 protocol itself.

We’ll be talking about use cases that are driving extensions and OAuth-adjacent 
work, and how this transactional model differs from the OAuth model we’ve all 
gotten used to. I’ll be presenting the current state of XYZ, but this isn’t 
just a meeting to adopt XYZ as a solution, and I invite others to present their 
related work. From this meeting we should have a good sense of where we want to 
go with this kind of work in the future, including whether this is new work in 
the OAuth WG or if we should be starting a new WG. I hope to see you all on the 
new list and in the room for the BoF!

— Justin

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

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

[Justin Richer]

Aaron, some comments inline.

— Justin

On Sep 26, 2019, at 8:30 AM, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:

Hi Torsten,

I'm very glad to see this draft, I think it's definitely needed in
this space. Here are some of my thoughts on the draft.

"request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2"

Is it acceptable for the AS to return just an opaque string, rather
than something prefixed with "uri:*"? I don't think anyone would be
confused about copypasting the exact string from the "request_uri"
response into the "request_uri" parameter even if it didn't start with
"urn:". If, for whatever reason, it is required that this value is
actually a URI, is there some expected namespace to use other than
"example"? I worry that if all the examples in the spec are just
"urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will end up
using the text "example" because they don't understand why it's there,
and then it serves no purpose really.’

This field must be a URI, as per JAR:


   request_uri  The absolute URI as defined by 
RFC3986 
[RFC3986] that
  points to the Request Object (Section 
2.1) that 
holds
  authorization request parameters stated in section 
4 of OAuth 2.0
  [RFC6749].


Somewhat awkwardly, the JAR spec currently states that the AS has to do an HTTP 
GET on the request URI, so that will need to be fixed in JAR before it goes 
forward. I don’t think that was always the case though, and I’m not sure how 
that changed.

As for the namespace, “example” is ok for an example URN. The problem with URNs 
is that nobody really understands how to do domain-safe fully compliant URNs. 
So perhaps we should instead use “urn:fdc:example.com:….” 
Instead (as per https://tools.ietf.org/html/rfc4198).


The pushed authorization request endpoint shall be a RESTful API

I would drop the term RESTful and just say "HTTP API", as this
description is arguably RESTful at best.

Depending on client type and authentication method, the request might
 also include the "client_id" parameter.

I assume this is hinting at the difference between public clients
sending only the "client_id" parameter and confidential clients
sending only the HTTP Basic Authorization header which includes both
the client ID and secret? It would probably be helpful to call out
these two common examples if I am understanding this correctly,
otherwise it seems pretty vague.

Not quite, those differences are for the token endpoint, and this is capturing 
things from the authorization endpoint. I don’t quite understand the 
differentiation listed here either, though.


The "request_uri" value MUST be generated using a cryptographically
 strong pseudorandom algorithm

I assume this includes the use of a random number inside of a JWT, in
case the AS wants to use JWTs as the "request_uri" parameter"? If so,
it's probably worth spelling that out as it kind of reads like it has
to be literally a random string at first glance.

The URI is intended to be a reference not a value. If the client could send a 
JWT it would just send a request object instead of a request URI in the first 
place. So the intent is that it’s random, and maybe we should just say that 
explicitly.


That's all for now, thanks!


Aaron Parecki
aaronparecki.com
@aaronpk

On Sat, Sep 21, 2019 at 1:02 PM Torsten Lodderstedt
 wrote:

Hi all,

I just published a new draft that Brian Campbell, Dave Tonge, Filip Skokan, Nat 
Sakimura and I wrote.

https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00

It proposes a new endpoint, called "pushed authorization request endpoint”, 
that allows the client to push the Authorization Request payload with the AS on 
a backchannel connection instead of a front channel interaction. The AS 
provides the client with a request URI (according to draft-ietf-oauth-jwsreq) 
that the client uses in a subsequent authorization requests to refer to the 
pushed request data.

We believe this simple mechanism will significantly increase OAuth security and 
robustness since any application can use it by just sending the parameters in 
the same encoding as used at the authorisation endpoint over a HTTPS-protected 
and (for confidential clients) mutually authenticated connection to the AS. It 
can also be used to push signed and encrypted request objects to the AS, i.e. 
it provides an interoperable way to use request objects managed at the AS for 
use cases requiring an even higher security level.

We look forward to getting your feedback.

kind regards,
Torsten.

Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-lodderstedt-oauth-par-00.txt
Date: 21. September 2019 at 12:47:28 CEST
To: "Nat Sa

Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt

[Justin Richer]

I agree with George that this is a good fit for a security consideration, not a 
normative requirement. While it’s best to always protect the request data, this 
isn’t all that much different from having scopes that might leak personal 
information. Like for example, asking for access to HIV information for a 
health record. It’s made more explicit and potentially worse by RAR, but it’s 
far from unique.

This combination of issues is part of why XYZ effectively requires a 
combination of PAR and RAR for all requests.

— Justin

On Sep 26, 2019, at 9:18 AM, George Fletcher 
mailto:gffle...@aol.com>> wrote:

This is a great point about personal information. However, there are uses for 
authorization_details that don't specifically relate to personal information. 
Think an enhancement that has language preference, maybe a device identifier. 
Maybe we can add more text in the security considerations section stating that 
it's best practice to use PAR for any authorization_details that are considered 
personal information (PI) or personally identifying information (PII) ?

On 9/26/19 11:02 AM, Aaron Parecki wrote:

Hi Torsten,

Overall I am a fan of a way to provide more structure in authorization
requests, and I'm excited to see this draft, so thanks for that.

I do have some concerns about one aspect of this. Given its clear
intended use as a way to create authorization requests to do things
like transfer money between bank accounts, I don't think it's
appropriate for that kind of data to be sent in the front channel at
all. By encoding a rich authorization request with bank account
numbers and account names in a query string, that opens up several new
opportunities for an attacker to steal private/sensitive information
(browser extensions, proxy servers, etc).

This differs from the plain OAuth authorization request because
traditionally the request does not include any identifying information
about any user or even about the particular transaction. At most, the
request identifies the client and combination of coarse-grained scopes
the client is requesting, none of which can identify a user. However
with the examples provided in this document, as well as many
additional uses of this mechanism, it includes potentially a lot of
identifying information about users including their name, bank account
numbers, and even relationships to other parties (e.g. creditorName).
When the authorization request is sent to the AS in a URL, regardless
of whether it's in plaintext like the simple example here, or signed
as a JWT request, that data is visible to anything that can access the
URL between the user's device and the AS. This seems like a huge
potential for a privacy leak.

I realize this draft currently points to JWT Secured Authorization
Requests (JAR) in several places where these concerns come up. The
problem is that JAR doesn't actually *require* an encrypted JWT, so
the privacy implications aren't accounted for here.

I would much rather see this document require your other recent
submission, Pushed Authorization Requests. Given the privacy
implications, it makes sense to limit the use of rich authorization
requests to pushed authorization requests, so that this rich data is
never made available to intermediaries in the front channel.

If there is a good reason to continue allowing authorization requests
as a GET without the new pushed request step, then at least I would
want to see RAR require encrypted JWTs as described by JAR.

Thanks for considering this!


Aaron Parecki
aaronparecki.com<http://aaronparecki.com>



On Sat, Sep 21, 2019 at 7:51 PM Torsten Lodderstedt
<mailto:tors...@lodderstedt.net> wrote:


Hi all,

I just published a draft about ???OAuth 2.0 Rich Authorization Requests??? 
(formerly known as ???structured scopes???).

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

It specifies a new parameter ???authorization_details" that is used to carry 
fine grained authorization data in the OAuth authorization request. This 
mechanisms was designed based on experiences gathered in the field of open 
banking, e.g. PSD2, and is intended to make the implementation of rich and 
transaction oriented authorization requests much easier than with current OAuth 
2.0.

I???m happy that Justin Richer and Brian Campbell joined me as authors of this 
draft. We would would like to thank Daniel Fett, Sebastian Ebling, Dave Tonge, 
Mike Jones, Nat Sakimura, and Rob Otto for their valuable feedback during the 
preparation of this draft.

We look forward to getting your feedback.

kind regards,
Torsten.

Begin forwarded message:

From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>
Subject: New Version Notification for draft-lodderstedt-oauth-rar-02.txt
Date: 21. September 2019 at 16:10:48 CEST
To: "Justin Richer" <mailto:i...@justin.richer.org>, 
"Torsten Lodderstedt" 
<mailto:tors..

Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt

[Justin Richer]

The idea behind the “locations”, “actions”, “data”, and “identifier” data 
element types mirrors what I’ve seen “scope” used for in the wild. They roughly 
equate to “where something is”, “what I want to do with it”, “what kind of 
thing I want”, and “the exact thing I want”, respectively. I’m completely open 
for better names, and have even been thinking “datatype” might be better than 
just “data” for the third one.

As for encoding, I think that form encoding makes sense because it’s the 
simplest possible encoding that will work. I personally don’t see a need to 
armor this part of the request with base64, as it is in JOSE, and doing so 
would make it one more step removed from easy developer understanding. 

-- Justin Richer

Bespoke Engineering
+1 (617) 564-3801
https://bspk.io/



> On Sep 24, 2019, at 1:45 PM, George Fletcher  wrote:
> 
> Just two questions...
> 
> 1. What is the rationale that 'data' is really an array of arbitrary 
> top-level claims? I find looking at the spec and not finding a 'data' section 
> a little confusing.
> 
> 2. What is the rationale for sending the JSON object as a urlencoded JSON 
> string rather than a base64url encoded JSON string? The later would likely be 
> smaller and easier to read:)
> 
> Thanks,
> George
> 
> On 9/21/19 1:51 PM, Torsten Lodderstedt wrote:
>> Hi all,??
>> 
>> I just published a draft about ???OAuth 2.0 Rich Authorization Requests??? 
>> (formerly known as ???structured scopes???).??
>> 
>> https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 
>> <https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02>
>> 
>> It specifies a new parameter?authorization_details"??that is used to 
>> carry fine grained authorization data in the OAuth authorization request. 
>> This mechanisms was designed based on experiences gathered in the field of 
>> open banking, e.g. PSD2, and is intended to make the implementation of rich 
>> and transaction oriented authorization requests much easier than with 
>> current OAuth 2.0.
>> 
>> I???m happy that Justin Richer and Brian Campbell joined me as authors of 
>> this draft. We would would like to thank Daniel Fett, Sebastian Ebling, Dave 
>> Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their valuable feedback 
>> during the preparation of this draft.
>> 
>> We look forward to getting your feedback.??
>> 
>> kind regards,
>> Torsten.??
>> 
>>> Begin forwarded message:
>>> 
>>> From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
>>> Subject: New Version Notification for draft-lodderstedt-oauth-rar-02.txt
>>> Date: 21. September 2019 at 16:10:48 CEST
>>> To: "Justin Richer" >> <mailto:i...@justin.richer.org>>, "Torsten Lodderstedt" 
>>> mailto:tors...@lodderstedt.net>>, "Brian 
>>> Campbell" mailto:bcampb...@pingidentity.com>>
>>> 
>>> 
>>> A new version of I-D, draft-lodderstedt-oauth-rar-02.txt
>>> has been successfully submitted by Torsten Lodderstedt and posted to the
>>> IETF repository.
>>> 
>>> Name:   draft-lodderstedt-oauth-rar
>>> Revision:   02
>>> Title:  OAuth 2.0 Rich Authorization Requests
>>> Document date:  2019-09-20
>>> Group:  Individual Submission
>>> Pages:  16
>>> URL: 
>>> ??https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt
>>>  <https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt>
>>> Status: 
>>> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
>>>  <https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/>
>>> Htmlized: 
>>> https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 
>>> <https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02>
>>> Htmlized: 
>>> https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar
>>>  <https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar>
>>> Diff: 
>>> https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-rar-02
>>>  <https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-rar-02>
>>> 
>>> Abstract:
>>> This document specifies a new parameter "authorization_details" that
>>> is used to carry fine grained authorization data in the OAuth
>>> authorization request.
>>> 
>>> 
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org 
>>> <http://tools.ietf.org/>.
>>> 
>>> The IETF Secretariat
>>> 
>> 
>> 
>> 
>> ___
>> 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] Question regarding RFC 7592

[Justin Richer]

I think this is where we disagree about the nature of “resource”, as I would 
classify a management API as a resource. Specifically, the client’s own records 
at the AS.

The “IF” in your statement is a big if, and one that is uncommon even today. 
Also, I want to note that if the client can’t "manage an access token” very 
well, then it’s going to have a very hard time being an OAuth client once it’s 
done registering. In other words, the goal was to take a piece of universal 
functionality that all OAuth clients would be guaranteed to have.

I’ll agree that it’s a bit weird having an access token issued as part of a 
response, but the alternative was to invent a new flow to force a client to go 
through another round trip to the token endpoint to get its management token. 
If you’re already directly giving the client a temporary credential that it can 
use at the AS, then just give the client the final token to do the job directly 
instead. At least, that was the thinking, and I still agree with that line of 
thought today even with its quirks.

— Justin

On Sep 17, 2019, at 12:40 AM, Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:

The registration supports the client having a jwks, so if the client provides 
jwks, then using them to sign an authentication request seems easier than 
trying to manage an access token.

The token endpoint is an API as well. We would agree that it is not a resource, 
but a management API. Similarly, I see the client's management of its 
registration to not be a resource operation, but a management API.
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=2f153226-16c8-47cf-917d-a04714e9a474]ᐧ

On Mon, Sep 16, 2019 at 7:36 PM Justin Richer 
mailto:jric...@mit.edu>> wrote:
I don’t see a reason to use an assertion here. JWT authentication would require 
at least a secret if not a key of some type for authentication for all clients, 
and it was determined that dynamic registration shouldn’t require the clients 
(even public clients) to support things they weren’t already capable of doing. 
Besides, the management endpoint isn’t a token endpoint (though I’m curious to 
hear why you’d say that) — it’s an API you can call to manage a client’s 
registration data over time. Sounds like an RS, if you ask me.

— Justin

On Sep 15, 2019, at 1:05 AM, Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:

Curious why the client management API uses bearer tokens rather than JWTs per 
RFC 7523 for the client to authenticate. The client management API seems more 
similar to a token endpoint than a resource.
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=5c4bbc80-1f00-4351-9a9b-954805e3d560]ᐧ

On Fri, Sep 13, 2019 at 12:08 PM Justin Richer 
mailto:jric...@mit.edu>> wrote:
Travis has this correct — the “registration access token” is passed to the 
client for the express purpose of accessing the client management API, and is 
not the same as, or entangled with, any access tokens that the client requests 
through the OAuth process after the registration has occurred. The reasons for 
this separation are many, but at the core it comes down to the client always 
acting on its own behalf when it does registration, and acting on behalf of 
some other party (usually a user) when it’s doing OAuth. Additionally, 
registration management is a function of the AS, whereas the protected APIs are 
a function of the RS — note this is a logical separation and there’s nothing 
stopping AS and RS functions from being deployed in any number of patterns.

A few common questions we got asked when writing this functionality into the 
spec:

Why use an access token at all? Because it’s a credential for a specific API 
issued by the AS and handed to the client in a programmatic manner. This is 
exactly what OAuth tokens were made for.

Why not use the client’s credentials? Because not all clients are set up to 
have credentials, plus we’d be spreading the requirement to support different 
kinds of client credentials to another endpoint.

Why not issue an authorization code? Because then the client would need to make 
yet another round trip, and not all clients are authorization-code-grant 
clients to begin with.

Why not make a new grant type? Because then the client would need to make yet 
another round trip, and we’d have to invent a whole new grant type with a new 
temporary credential when we could just use that temporary credential directly 
instead.

— Justin

On Sep 13, 2019, at 8:23 AM, Robache Hervé 
mailto:herve.roba...@stet.eu>> wrote:

Thanks Travis

I understand that, once the client has retrieved its [client_id] through 
RFC7591 initial registration, it is then able to ask for an access token that 
will be used for accessing the RFC7592 entry-points. Am I right?

Best regards

Hervé

De : Travis Spencer [mailto:travis.spen...@curity.io]
Envoyé : ven. 13 

Re: [OAUTH-WG] Question regarding RFC 7592

[Justin Richer]

I don’t see a reason to use an assertion here. JWT authentication would require 
at least a secret if not a key of some type for authentication for all clients, 
and it was determined that dynamic registration shouldn’t require the clients 
(even public clients) to support things they weren’t already capable of doing. 
Besides, the management endpoint isn’t a token endpoint (though I’m curious to 
hear why you’d say that) — it’s an API you can call to manage a client’s 
registration data over time. Sounds like an RS, if you ask me.

— Justin

On Sep 15, 2019, at 1:05 AM, Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:

Curious why the client management API uses bearer tokens rather than JWTs per 
RFC 7523 for the client to authenticate. The client management API seems more 
similar to a token endpoint than a resource.
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=5c4bbc80-1f00-4351-9a9b-954805e3d560]ᐧ

On Fri, Sep 13, 2019 at 12:08 PM Justin Richer 
mailto:jric...@mit.edu>> wrote:
Travis has this correct — the “registration access token” is passed to the 
client for the express purpose of accessing the client management API, and is 
not the same as, or entangled with, any access tokens that the client requests 
through the OAuth process after the registration has occurred. The reasons for 
this separation are many, but at the core it comes down to the client always 
acting on its own behalf when it does registration, and acting on behalf of 
some other party (usually a user) when it’s doing OAuth. Additionally, 
registration management is a function of the AS, whereas the protected APIs are 
a function of the RS — note this is a logical separation and there’s nothing 
stopping AS and RS functions from being deployed in any number of patterns.

A few common questions we got asked when writing this functionality into the 
spec:

Why use an access token at all? Because it’s a credential for a specific API 
issued by the AS and handed to the client in a programmatic manner. This is 
exactly what OAuth tokens were made for.

Why not use the client’s credentials? Because not all clients are set up to 
have credentials, plus we’d be spreading the requirement to support different 
kinds of client credentials to another endpoint.

Why not issue an authorization code? Because then the client would need to make 
yet another round trip, and not all clients are authorization-code-grant 
clients to begin with.

Why not make a new grant type? Because then the client would need to make yet 
another round trip, and we’d have to invent a whole new grant type with a new 
temporary credential when we could just use that temporary credential directly 
instead.

— Justin

On Sep 13, 2019, at 8:23 AM, Robache Hervé 
mailto:herve.roba...@stet.eu>> wrote:

Thanks Travis

I understand that, once the client has retrieved its [client_id] through 
RFC7591 initial registration, it is then able to ask for an access token that 
will be used for accessing the RFC7592 entry-points. Am I right?

Best regards

Hervé

De : Travis Spencer [mailto:travis.spen...@curity.io]
Envoyé : ven. 13 13:30
À : Robache Hervé
Cc : oauth@ietf.org<mailto:oauth@ietf.org>
Objet : Re: [OAUTH-WG] Question regarding RFC 7592

No. The initial access token is issued by the AS when registration is protected 
(appendix 1.2 in RFC 7591). As stated in section 1.2, the method and means by 
which this is obtained can vary. The registration access token in RFC 7592 is 
used to protect the registration management API and allow updates to the client 
after it is registered. You might have one (the registration access token) but 
not the other (initial access token) when open registration is allowed 
(appendix 1.1 in RFC 7591).

HTH!

On Fri, Sep 13, 2019 at 7:37 AM Robache Hervé 
mailto:herve.roba...@stet.eu>> wrote:
Hi

RFC 7592 introduces a « Registration Access Token ». Are this token and the way 
to get it similar to what is specified as “Initial Access Token” in RFC 
7591/Appendix A ?

If so, can the Open Dynamic Client Registration (RFC7591/A.1.1) be extrapolated 
to RFC7592 as the same way?

Thanks in advance for your clarification.

Hervé ROBACHE
Direction Marketing et Développement

LIGNE DIRECTE
T. +33(0)1 55 23 55 45
herve.roba...@stet.eu<mailto:herve.roba...@stet.eu>










STET (SIEGE SOCIAL)
100, Esplanade du Général de Gaulle
Cœur Défense – Tour B
92932 La Défense cedex

www.stet.eu<http://www.stet.eu/>



Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destiné, merci de 
le détruire ainsi que toute copie de votre système et d'en avertir 
immédiatement l'expéditeur.
Toute lecture non autorisée, toute utilisation de ce message qui n'est pas 
conforme à sa destination, toute diffusion ou toute pub

Re: [OAUTH-WG] Public client cloning

[Justin Richer]

If the phone is compromised, it doesn’t matter if the client is public or 
confidential. In the latter case, an attacker could exfiltrate or capture the 
client’s own credentials and use them maliciously.

— Justin

On Sep 10, 2019, at 3:27 PM, Masakazu OHTSUKA 
mailto:o.masak...@gmail.com>> wrote:

I see.

Then is this understandable to think from the Authorization Server's point of 
view ...

If phone being compromised is a threat that the Client cares,
AS might be interested in NOT supporting public Clients,
and forcing the Client to have a server side, do client authentication, and 
have some way to hold a session between the native app and it's server side.

Because if phone is compromised, when AS supports public Clients and 
access_token leaks, it's kind of AS's fault (well depending on the terms...),
but if whatever the means that the phone app and it's server side keeps a 
session leaks, it's NOT the AS's fault.


On Tue, Sep 10, 2019 at 8:23 PM Marius Scurtescu 
mailto:marius.scurte...@coinbase.com>> wrote:
If the phone is compromised, original app replaced by malicious app, then 
RFC8252 will not help. The assumption is that the phone is not compromised.

On Tue, Sep 10, 2019 at 9:58 AM Masakazu OHTSUKA 
mailto:o.masak...@gmail.com>> wrote:
Hi,

I've read rfc8252 and have questions about native apps, that I couldn't find 
answers on Internet.

Imagine an attacker doing:
1. original app and authorization server conforms to rfc8252 4.1.  
Authorization Flow for Native Apps Using the Browser
2. clone the original app, name it malicious app and install on the target phone
3. remove the original app from the target phone
4. use the malicious app and authorize, OS will invoke malicious app using 
custom URL scheme
5. now malicious app has access to the access token

How should we think about this?
What am I missing?

___
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] Question regarding RFC 7592

[Justin Richer]

Travis has this correct — the “registration access token” is passed to the 
client for the express purpose of accessing the client management API, and is 
not the same as, or entangled with, any access tokens that the client requests 
through the OAuth process after the registration has occurred. The reasons for 
this separation are many, but at the core it comes down to the client always 
acting on its own behalf when it does registration, and acting on behalf of 
some other party (usually a user) when it’s doing OAuth. Additionally, 
registration management is a function of the AS, whereas the protected APIs are 
a function of the RS — note this is a logical separation and there’s nothing 
stopping AS and RS functions from being deployed in any number of patterns.

A few common questions we got asked when writing this functionality into the 
spec:

Why use an access token at all? Because it’s a credential for a specific API 
issued by the AS and handed to the client in a programmatic manner. This is 
exactly what OAuth tokens were made for.

Why not use the client’s credentials? Because not all clients are set up to 
have credentials, plus we’d be spreading the requirement to support different 
kinds of client credentials to another endpoint.

Why not issue an authorization code? Because then the client would need to make 
yet another round trip, and not all clients are authorization-code-grant 
clients to begin with.

Why not make a new grant type? Because then the client would need to make yet 
another round trip, and we’d have to invent a whole new grant type with a new 
temporary credential when we could just use that temporary credential directly 
instead.

— Justin

On Sep 13, 2019, at 8:23 AM, Robache Hervé 
mailto:herve.roba...@stet.eu>> wrote:

Thanks Travis

I understand that, once the client has retrieved its [client_id] through 
RFC7591 initial registration, it is then able to ask for an access token that 
will be used for accessing the RFC7592 entry-points. Am I right?

Best regards

Hervé

De : Travis Spencer [mailto:travis.spen...@curity.io]
Envoyé : ven. 13 13:30
À : Robache Hervé
Cc : oauth@ietf.org
Objet : Re: [OAUTH-WG] Question regarding RFC 7592

No. The initial access token is issued by the AS when registration is protected 
(appendix 1.2 in RFC 7591). As stated in section 1.2, the method and means by 
which this is obtained can vary. The registration access token in RFC 7592 is 
used to protect the registration management API and allow updates to the client 
after it is registered. You might have one (the registration access token) but 
not the other (initial access token) when open registration is allowed 
(appendix 1.1 in RFC 7591).

HTH!

On Fri, Sep 13, 2019 at 7:37 AM Robache Hervé 
mailto:herve.roba...@stet.eu>> wrote:
Hi

RFC 7592 introduces a « Registration Access Token ». Are this token and the way 
to get it similar to what is specified as “Initial Access Token” in RFC 
7591/Appendix A ?

If so, can the Open Dynamic Client Registration (RFC7591/A.1.1) be extrapolated 
to RFC7592 as the same way?

Thanks in advance for your clarification.

Hervé ROBACHE
Direction Marketing et Développement

LIGNE DIRECTE
T. +33(0)1 55 23 55 45
herve.roba...@stet.eu










STET (SIEGE SOCIAL)
100, Esplanade du Général de Gaulle
Cœur Défense – Tour B
92932 La Défense cedex

www.stet.eu



Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destiné, merci de 
le détruire ainsi que toute copie de votre système et d'en avertir 
immédiatement l'expéditeur.
Toute lecture non autorisée, toute utilisation de ce message qui n'est pas 
conforme à sa destination, toute diffusion ou toute publication, totale ou 
partielle, est interdite.
L'Internet ne permettant pas d'assurer l'intégrité de ce message électronique 
susceptible d'altération, STET décline toute responsabilité au titre de ce 
message dans l'hypothèse où il aurait été modifié, déformé ou falsifié.
N'imprimez ce message que si nécessaire, pensez à l'environnement.

This message and any attachments is intended solely for the intended addressees 
and is confidential.
If you receive this message in error, or are not the intended recipient(s), 
please delete it and any copies from your systems and immediately notify the 
sender.
Any unauthorized view, use that does not comply with its purpose, dissemination 
or disclosure, either whole or partial, is prohibited.
Since the internet cannot guarantee the integrity of this message which may not 
be reliable, STET shall not be liable for the message if modified, changed or 
falsified.
Do not print this message unless it is necessary, please consider the 
environment.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai

Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05

[Justin Richer]

To be clear, I am in no way suggesting we should leverage SET for this draft. 
That would be a terrible idea. I am saying that the solution might be a similar 
pattern that SET used for grouping the claims under a top level claim. It’s a 
pattern I wish more applications of JWT would use, but JWT suffers from having 
been invented for a very specific purpose and then being made generic. 
Hopefully we can learn from some of the mistakes in SET as well, and not just 
define a top-level claim and stay out of it.

— Justin

On Sep 4, 2019, at 4:09 PM, Phil Idm Hunt 
mailto:phil.h...@oracle.com>> wrote:

+1

This feels like it has similar requirements and concerns as for SET and may be 
should leverage it to avoid confusion and inconsistencies down the road.

Phil

On Sep 4, 2019, at 12:49 PM, Justin Richer 
mailto:jric...@mit.edu>> wrote:

As I’ve said in the past, I think there is and should be a clear difference 
between a JWT access token and a JWT-formatted response from any endpoint. It 
gets extra fuzzy here because the response from the endpoint represents the 
token being introspected.

However, I think they are still two very different things because the 
introspection response by definition represents what the token was at the time 
of introspection. That’s why the “active” claim is important here, along with 
the timestamp information in the JWT container — you can say that the token 
*was* active at the time of introspection, but you can’t say it’s still active 
without introspecting the token again to check. This leads to exactly the kind 
of collision that’s being discussed here. It’s confusing for developers of both 
the AS and the RS, and I fear it’s going to lead to an AS choosing one 
interpretation and an RS choosing another, and therefore leaving open a door to 
security issues down the road.

Also, remember one of the main reasons that we require some form of RS 
authentication to the token endpoint is that different RS’s can get different 
answers for the same token. The AS can tailor its response based on what scopes 
the RS is supposed to know about, or which RS’s can know a user’s identifier 
(or even use pairwise identifiers), or even which RS is supposed to know about 
a given token at all. In each of these cases, using this draft, you’ll get a 
different JWT out for the same token on the way in. You’re not simply 
translating an access token to another access token here — if you want to do 
that, use token exchange and do it properly with an OAuth grant. Instead, 
you’re getting information about the token itself at the time of the request 
and from the perspective of the requestor, and you happen to be wrapping the 
response in a container that is also widely used to format access tokens.

The separation that Torsten points out below brings up one of the biggest 
problems with JWTs as a data container format — all the information about the 
JWT itself is mixed in with the thing it’s carrying information about. We see 
this issue with JAR, where the “aud” parameter can mean the audience of the 
authorization request and the audience of the JWT used to carry the 
authorization request. We also see this a little bit in dynamic client 
registration’s software statement. Root-level JWT claims are a poor mechanism 
for this.

In retrospect, what I wish we’d done with all of them using a named payload 
like with SET’s “event” claim. Even there, we had a lot of argument about a 
“sub” claim inside the “event” object vs. one at the root of the JWT container, 
but at least in these cases  we now had an opportunity to write clear language 
about what each meant in each circumstance. I realize this draft is already 
well along in its process, and I haven’t put in the review time or comments to 
date myself, but I think it’s unfortunate that the draft doesn’t define a 
sub-claim like “access_token” or “token_information” to carry inside the JWT 
payload. This would solve the problem of differentiating the “iat” for the 
token itself vs. the JWT container of the response.

The group may also recall that I originally said that this draft should not be 
done in light of only introspection, and instead should be a generic mechanism 
across OAuth’s various endpoints. Weird combinations like the “iat” claim here 
are a driver for having a solid generic mechanism instead of a handful of 
slightly different definitions.

So what should we do here? If we are to keep the current practice of putting 
everything in the root of the JWT, we should have different claim names to 
differentiate the envelope and the token. The problem here is that “iat” is 
already defined in RFC7662 as referring to the token and in RFC7519 as 
referring to the JWT (which is not a token, but the container for the token 
information). I’m not sure which is worse, defining an “iat” for the 
introspection response or one for the JWT but only in this instance. Both feel 
really messy, and in cases like Torsten’s they

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-07: (with DISCUSS and COMMENT)

[Justin Richer]

One of the issues I have with the current structure aligns with Ben’s comments 
below — we have two things that feel token-ish, the input token and the 
resulting JWT response. However, the JWT in the response is not actually a 
:token: in the OAuth sense. Instead, it’s an assertion that carries payload 
information :about: a token. The response itself isn’t a token and shouldn’t be 
treated as a token unto itself.

— Justin

On Sep 2, 2019, at 6:44 PM, Benjamin Kaduk via Datatracker 
mailto:nore...@ietf.org>> wrote:

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwt-introspection-response-07: Discuss

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


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


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



--
DISCUSS:
--

Per the ongoing discussion on the WG list, it's unclear that we can
retain the behaviors we describe and still comply with the requirements
of RFC 7519 requirements for being a JWT (e.g., regarding "jti", "iat",
etc.).  That is, in the present formulation, there are two "token"s
involved -- the input that is being introspected, and the "token" that
is the introspection response.  We are claiming that certain fields are
describing the input token, when they are defined to be statements about
the current (response) token.
Relaxing our statements to say that we merely use JWS as opposed to JWT
may be a workaround, though I have thought about it hard enough to have
an opinion on whether it is the best workaround.

I also think we need more clarity about the use of dynamic client
registration by a resource server as outlined in Section 4 (where it's
mentioned as "with a resource server posing as the client", without
reference to RFC 7591.  As far as I can tell this document/section is
introducing this use of dynamic client registration by an RS for the
first time, so we cannot easily just refer to some other document.
Specifically, are there any fields that MUST NOT be supplied?  Is a
human-readable client_name useful?  How does the supplied client_uri
need to relate to any existing AS representation of a resource in
audience, scope, etc. (e.g., for the "resource" request parameter from
draft-ietf-oauth-resource-indicators)?

Is this usage considered to be a "new use of JWTs"?  If so, it seems
that we should follow the recommendation of draft-ietf-oauth-jwt-bcp and
use explicit typing.

I think there are some missing links in the document between a RS
registring client policy and the resulting AS enforcement of encryption
of introspection reponses.  I think the intent is roughly that the
policy will be applied based on the audience of the token being
presented for introspection (as opposed to the identity of the
RS-as-client making the introspection request), but we don't seem to
explicitly say that.  Also, we'd need to say something about the
interaction of multiple RSs' policy when a given token has multiple
valid audiences.  There is a very brief discussion in Section 6.5, but
it seems to be more of a description of what is possible than mandating
particular forms of enforcement.

I think we should discuss whether we want some statement from the OpenID
Foundation or related bodies before we register claims that point to
their documents with the IESG listed as change controller.


--
COMMENT:
--

idnits notes that RFC 5646 is mentioned but not present in the
references section.

Section 1

We probably need to move the 7519 reference up here to where JWT is
first used.

  OAuth 2.0 Token Introspection [RFC7662] specifies a method for a
  protected resource to query an OAuth 2.0 authorization server to
  determine the state of an access token and obtain data associated
  with the access token.  This allows deployments to implement
  identifier-based access tokens in an interoperable way.

Does "identifier-based access tokens" mean "tokens that are opaque keys
to a (central) database lookup" or "access tokens that convey user
identity information" (or something else)?  We may want to tweak the
wording.

Section 3

Can we double-check the base64 form of the response in this example?  I
am seeing output that backslash-escapes the '/' characters in URLs,
which I did not think was needed in this context.
I also see an "extension_field" claim in the base64 but not the decoded
form of the example, and "given_name"/"family_name"/"birthdate" in the
de

Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05

[Justin Richer]

As I’ve said in the past, I think there is and should be a clear difference 
between a JWT access token and a JWT-formatted response from any endpoint. It 
gets extra fuzzy here because the response from the endpoint represents the 
token being introspected.

However, I think they are still two very different things because the 
introspection response by definition represents what the token was at the time 
of introspection. That’s why the “active” claim is important here, along with 
the timestamp information in the JWT container — you can say that the token 
*was* active at the time of introspection, but you can’t say it’s still active 
without introspecting the token again to check. This leads to exactly the kind 
of collision that’s being discussed here. It’s confusing for developers of both 
the AS and the RS, and I fear it’s going to lead to an AS choosing one 
interpretation and an RS choosing another, and therefore leaving open a door to 
security issues down the road.

Also, remember one of the main reasons that we require some form of RS 
authentication to the token endpoint is that different RS’s can get different 
answers for the same token. The AS can tailor its response based on what scopes 
the RS is supposed to know about, or which RS’s can know a user’s identifier 
(or even use pairwise identifiers), or even which RS is supposed to know about 
a given token at all. In each of these cases, using this draft, you’ll get a 
different JWT out for the same token on the way in. You’re not simply 
translating an access token to another access token here — if you want to do 
that, use token exchange and do it properly with an OAuth grant. Instead, 
you’re getting information about the token itself at the time of the request 
and from the perspective of the requestor, and you happen to be wrapping the 
response in a container that is also widely used to format access tokens.

The separation that Torsten points out below brings up one of the biggest 
problems with JWTs as a data container format — all the information about the 
JWT itself is mixed in with the thing it’s carrying information about. We see 
this issue with JAR, where the “aud” parameter can mean the audience of the 
authorization request and the audience of the JWT used to carry the 
authorization request. We also see this a little bit in dynamic client 
registration’s software statement. Root-level JWT claims are a poor mechanism 
for this.

In retrospect, what I wish we’d done with all of them using a named payload 
like with SET’s “event” claim. Even there, we had a lot of argument about a 
“sub” claim inside the “event” object vs. one at the root of the JWT container, 
but at least in these cases  we now had an opportunity to write clear language 
about what each meant in each circumstance. I realize this draft is already 
well along in its process, and I haven’t put in the review time or comments to 
date myself, but I think it’s unfortunate that the draft doesn’t define a 
sub-claim like “access_token” or “token_information” to carry inside the JWT 
payload. This would solve the problem of differentiating the “iat” for the 
token itself vs. the JWT container of the response.

The group may also recall that I originally said that this draft should not be 
done in light of only introspection, and instead should be a generic mechanism 
across OAuth’s various endpoints. Weird combinations like the “iat” claim here 
are a driver for having a solid generic mechanism instead of a handful of 
slightly different definitions.

So what should we do here? If we are to keep the current practice of putting 
everything in the root of the JWT, we should have different claim names to 
differentiate the envelope and the token. The problem here is that “iat” is 
already defined in RFC7662 as referring to the token and in RFC7519 as 
referring to the JWT (which is not a token, but the container for the token 
information). I’m not sure which is worse, defining an “iat” for the 
introspection response or one for the JWT but only in this instance. Both feel 
really messy, and in cases like Torsten’s they collapse to the same value.

If however we put the introspection response in its own sub-section of the JWT 
payload, then we could avoid the namespace collision entirely. We would need 
normative rules like in SET to define how these fields relate to each other, 
but I see that as a tractable problem with a reasonable (if imperfect) 
precedent.

Either path means redoing WGLC and the associated reviews, I’m afraid. Leaving 
it as-is works for the driving use case where the information is all the same, 
but I don’t find it to be a particularly clean representation of the 
information in question.

— Justin

On Sep 4, 2019, at 5:21 AM, Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:

Hi Remco,

On 31. Aug 2019, at 21:27, Schaar, R.M. (Remco) - Logius 
mailto:remco.sch...@logius.nl>> wrote:

Hello Torsten,

(my apologies for making a typo p

[OAUTH-WG] Use cases for XYZ

[Justin Richer]

As promised in Montreal, I have started to pull together use cases that fit 
XYZ’s model better than they fit traditional OAuth. While I’ve been able to 
work out how XYZ works for the most common OAuth deployments and extensions, I 
think the real interest is in the new spaces where OAuth doesn’t work out as 
well. The list here is far from comprehensive, of course, and I’d like to keep 
building this out. I plan on putting things into a more formal structure and 
getting them onto the https://oauth.xyz/ website in the near future alongside 
any others that I gather.


Ephemeral Clients. The OAuth model puts the notion of a “client” application 
front and center, and this makes sense from OAuth’s roots as a way to connect 
two web servers together. We’ve seen that this breaks down in different ways 
when we have SPA’s, mobile app instances, etc. Dynamic Registration helps, but 
with truly ephemeral clients you end up with having a lot of orphaned 
applications registered into the AS. In the last few years, OAuth has been 
trending away from pre-registration of all trust material into enabling more 
runtime keys and secrets. Extensions like PKCE, DPoP, OAuth-MTLS, and Token 
Binding are all based on this notion. In XYZ, the “transaction” is the core 
component of the model, and everything hangs off from that. As such, a client 
application that identifies itself to a new AS, gets a token, then disappears 
with its tokens is a reasonable model that leaves no trace behind.

Distributed RS’s. In highly distributed spaces with common APIs, such as a 
distributed social network, the RS’s all need to recognize not only the token 
but also who the token represents. OAuth has some pieces that let you tie 
something like this together, such as a JWT with key discovery based on the 
issuer of the token, but this doesn’t lend itself to use with ephemeral clients 
and bound tokens where the RS would need a way to figure out how to get to the 
keys. This kind of thinking extends to APIs deployed as micro services behind 
gateways, or lambda functions on an elastic cloud. What serves an “API” 
endpoint isn’t what it used to be, and I think we’ve got a better starting 
place with XYZ to make the lives of RS developers easier by having clearer 
mechanisms to bind tokens to both the rights they represent and the 
presentation mechanisms they need.

Bound Access Tokens. Everything is bearer tokens in OAuth2. Yes, we’re getting 
better about this with DPoP and OAuth-MTLS, and I support this work extending 
OAuth 2. But that’s far from complete or widely used. And what’s really weird, 
when you look at these, is that we’re not even using some of the half-baked 
extension points that we :do: have in OAuth 2, such as token types. We really 
shouldn’t be calling things “Bearer” tokens anymore when they require you to do 
other things on top of presenting the token, like using MTLS with a specific 
cert. Plus we’ve got a lot of conflation between people who want to pack keys 
into the tokens themselves vs. having the keys referenced by the token, which 
leads to confusion around what things like RFC7800 actually provide and define. 
XYZ gives us an opportunity to have a much clearer model for what an access 
token is, and how it gets bound to a key and presentation mechanism of various 
types. Bearer tokens still work here, too, but they become one among many 
citizens, like we always intended OAuth2 to have.

Multiple Parties. OAuth assumes that the Resource Owner is the person operating 
the client application. UMA extends this to allowing the Requesting Party to be 
the one using the client, but it generally doesn’t collapse cleanly into the 
cases where the RO :is: the party using the client since the claims gathering 
endpoint and the authorization endpoint aren’t quite the same in concept. UMA’s 
also arguably pretty complex, but I think it :had: to be in order to fit into 
the OAuth2 world. And then we have extensions in the identity space like CIBA 
which have multiple channels of interaction with potentially multiple users. 
We’ve also got the Device Flow which allows multiple channels connected by a 
real-world artifact (the user code), and I know of at least one deployment 
where the interactive page where the code is entered is under the control of 
someone other than the resource owner, since it’s a transitive trust model at 
play. This is an off-label use, which XYZ can make much more explicitly 
built-in. By separating the notion of the nature of the software from the 
nature of the user’s interaction, we can address a wider array of multi-party 
configurations without OAuth’s same core assumptions. Nat’s already talked 
about this kind of thing here on the list, and I think flexibility around who 
does what is going to be a key difference.

Known User. When the client knows something about the user, it should be able 
to express that to the AS as part of the transaction request. OAuth doesn’t 
have any place for t

Re: [OAUTH-WG] IETF Meetup for XYZ

[Justin Richer]

FWIW: We are meeting in the main lobby outside of Centre-Ville.

— Justin

On Jul 24, 2019, at 7:41 PM, Justin Richer 
mailto:jric...@mit.edu>> wrote:

Hi all,

I was talking with Hannes, and we’d like to propose a dinner meetup tomorrow 
(Thursday) for anyone who wants to discuss XYZ in more detail while we’re here 
in Montreal. We’ll meet right after the ACE working group session and find a 
place nearby, so that some of us can get back in time for the lightning talks 
in the evening.

If you’re interested, either come find us tomorrow or let us know some other 
way.
— Justin

___
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] Feedback on OAuth for browser-based Apps

[Justin Richer]

I also think it would be useful, but a problem is that things like “application 
type” are usually a stand in for a whole bunch of different attributes that we 
actually care about. That’s what happened with web/native and why, to my 
knowledge, nobody really uses those in lieu of things like public/confidential 
and redirect URI locations instead for policy decisions. If we do enumerate 
these, we would also need to enumerate all of the things it means.

I tried to shy away from “application type” style switches in XYZ’s straw man, 
and instead opt for recipes of applying the different options to different 
kinds of clients. I don’t know how long that will hold up though.

— Justin

On Jul 25, 2019, at 8:11 AM, Filip Skokan 
mailto:panva...@gmail.com>> wrote:

Obviously it can do it on a per-client basis still, but now an AS is going to 
have to know a bit more about the app itself. Perhaps we finally need a few 
more entries in the “application_type” metadata parameter from OIDC’s extension 
RFC7591 beyond “native” and “web”? But we at least probably want to point out 
to AS implementors that this is something they want to consider tracking in 
their data model for clients.

I would very much like to see that. native/web possibly in combination with 
token_endpoint_auth_method and the client being DCR or "static" is far from 
being enough to make a policy decision.

S pozdravem,
Filip Skokan


On Thu, 25 Jul 2019 at 13:45, Justin Richer 
mailto:jric...@mit.edu>> wrote:
This raises an interesting question that I don’t think we’ve addressed yet: how 
to appropriately vary token lifetimes and access for different clients.

Previously, an AS could see that a client was using the implicit flow and 
decide to limit token lifetimes or scopes based on that alone. Similarly, I 
know of at least some AS implementations that let you limit what scopes you 
allow under the client credentials grant. The key issue is that if all your 
clients are using the auth code flow (which I agree they should), then how does 
an AS tell the difference in capabilities between incoming clients?

Obviously it can do it on a per-client basis still, but now an AS is going to 
have to know a bit more about the app itself. Perhaps we finally need a few 
more entries in the “application_type” metadata parameter from OIDC’s extension 
RFC7591 beyond “native” and “web”? But we at least probably want to point out 
to AS implementors that this is something they want to consider tracking in 
their data model for clients.

— Justin

On Jul 25, 2019, at 4:04 AM, David Waite 
mailto:da...@alkaline-solutions.com>> wrote:




On Jul 24, 2019, at 3:03 PM, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:

On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
mailto:dba...@leastprivilege.com>> wrote:



I would rather say that ANY JS app should use CSP to lock down the browser 
features to a minimal attack surface. In addition, if refresh or access tokens 
are involved - further settings like disabling inline scripting (unsafe inline) 
and eval should be disabled.

I'm not sure what to do with this suggestion. It feels like a blanket
recommendation of enabling CSP will likely be ignored since it's too
broad, and recommending disabling inline scripts is overreaching
unless backed up by a specific threat it's protecting against. Did you
have a particular threat in mind?

I would say that browser applications should take measures to harden their 
applications again code injection and arbitrary code execution. Examples 
include eliminating inline script (and limiting embeddable objects as much as 
possible) via CSP, and versioning third party resources via techniques like 
subresource integrity.  Mechanisms such as augmenting the codebase to make sure 
all appropriate user input, data storage, and output properly sanitize data may 
be used - although they may be more expensive to implement and audit.

The AS should likewise take into account an application’s overall security 
posture when deciding appropriate policies around delegated authorization 
scopes and token lifetimes.

Best current practices include turning the screws tightly around CSP. But it is 
(theoretically) possible to accomplish the same with brute-force sanitization, 
which has been made simpler with framework support. It is still ultimately the 
AS job to decide which clients have which capabilities.

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

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

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