Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt

[William Denniss]

t_m works for me, I just think we should have some indication that it's
the name of the transform. Will you also update where it is referenced in
the description below Figure 2?



On Tue, Jul 7, 2015 at 6:28 PM, John Bradley  wrote:

> Thanks, I fixed my finger dyslexia for the next draft.
>
> I changed it to t_m rather than “t”  I think that is clearer.  If I were
> to do it the other way XML2RFC would have double quotes in the text version.
>
> John B.
>
> On Jul 7, 2015, at 9:38 PM, William Denniss  wrote:
>
> In version 14, there's a typo on this line ("deso") in Section 7.2:
>
> `"plain" method deso not protect`
>
> Also, in the 1.1 Protocol Flow diagram, regarding the text:
>
> `+ t(code_verifier), t`
>
> I wonder if it makes more sense to represent as `+ t(code_verifier), "t"`
> (note the quotes on the second 't') given that it's a string representation
> of the method that's being sent?
>
>
> On Mon, Jul 6, 2015 at 4:05 PM,  wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>  This draft is a work item of the Web Authorization Protocol Working
>> Group of the IETF.
>>
>> Title   : Proof Key for Code Exchange by OAuth Public
>> Clients
>> Authors : Nat Sakimura
>>   John Bradley
>>   Naveen Agarwal
>> Filename: draft-ietf-oauth-spop-14.txt
>> Pages   : 20
>> Date: 2015-07-06
>>
>> Abstract:
>>OAuth 2.0 public clients utilizing the Authorization Code Grant are
>>susceptible to the authorization code interception attack.  This
>>specification describes the attack as well as a technique to mitigate
>>against the threat through the use of Proof Key for Code Exchange
>>(PKCE, pronounced "pixy").
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-oauth-spop-14
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-14
>>
>>
>> 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] I-D Action: draft-ietf-oauth-spop-14.txt

[John Bradley]

Thanks, I fixed my finger dyslexia for the next draft.

I changed it to t_m rather than “t”  I think that is clearer.  If I were to do 
it the other way XML2RFC would have double quotes in the text version.

John B. 
> On Jul 7, 2015, at 9:38 PM, William Denniss  wrote:
> 
> In version 14, there's a typo on this line ("deso") in Section 7.2:
> 
> `"plain" method deso not protect`
> 
> Also, in the 1.1 Protocol Flow diagram, regarding the text:
> 
> `+ t(code_verifier), t`
> 
> I wonder if it makes more sense to represent as `+ t(code_verifier), "t"` 
> (note the quotes on the second 't') given that it's a string representation 
> of the method that's being sent?
> 
> 
> On Mon, Jul 6, 2015 at 4:05 PM,  > wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>  This draft is a work item of the Web Authorization Protocol Working Group of 
> the IETF.
> 
> Title   : Proof Key for Code Exchange by OAuth Public Clients
> Authors : Nat Sakimura
>   John Bradley
>   Naveen Agarwal
> Filename: draft-ietf-oauth-spop-14.txt
> Pages   : 20
> Date: 2015-07-06
> 
> Abstract:
>OAuth 2.0 public clients utilizing the Authorization Code Grant are
>susceptible to the authorization code interception attack.  This
>specification describes the attack as well as a technique to mitigate
>against the threat through the use of Proof Key for Code Exchange
>(PKCE, pronounced "pixy").
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ 
> 
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-spop-14 
> 
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-14 
> 
> 
> 
> 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] Token Chaining Use Case

[Mike Jones]

I’ll start by saying that if you compare 
https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and 
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, unsurprisingly, 
you’ll find a lot in common.  Both have requests and responses formatted using 
JSON objects, both have input and output tokens, both have security token type 
parameters describing their corresponding inputs and outputs.  Both can convey 
act_as and on_behalf_of tokens.  And despite what was written below, both 
define a new grant_type value that is used to make this new kind of request at 
the Token Endpoint.

The primary thing that Brian’s draft is missing semantically is the ability for 
the requester to sign the set of input parameters.  This is critical to 
establishing proper trust to enable the exchange to occur in many use cases.  
That’s why the WG draft uses a JWT as the request – so a signature can be 
applied to the request, when appropriate.  (And when it’s not needed, “alg”: 
“none” can be used.)

Justin, you’re right that the current WG draft doesn’t have a separate “input 
token” request parameter.  In the current draft, the (optionally) signed 
request *is* the input token.  Thinking some more about the token chaining use 
case you’re interested in, I see why you want to have that token to be a 
separate element in the request.  I believe the best way to accomplish that is 
to add an optional claim to the request that would contain that token.  (I 
think the closest equivalent in Brian’s draft is the possibility of using an 
access token or assertion as the client authentication mechanism, possibly 
passing it as defined in RFC 6750, although the draft doesn’t say that.)  
Passing the input token as a claim lets it be part of the signed request.

It’s completely up to us when using a different grant_type to define what the 
input and output parameters when using that grant_type are.  (RFC 6749 already 
has different sets, depending upon the grant_type used.)  I personally find it 
cleaner to return the output security token that may not be an access token in 
a “security_token” parameter rather than repurposing the “access_token” 
parameter to hold something that’s not an access token, but now we’re more 
discussing syntax than semantics.  Still, if something is different, it’s 
probably less error prone to use a different syntax for it.

I’m sympathetic to your comment about Nat’s signed requests draft, except that 
the requests that draft specifies are requests to the interactive Authorization 
Endpoint, whereas the requests we’re dealing with here are requests to the 
non-interactive Token Endpoint.  Still, thinking of the Token Exchange requests 
as signed requests to the Token Endpoint, just like Nat’s draft makes signed 
requests to the Authorization Endpoint, is probably a good unifying mental 
framework for all of us to consider applying to this problem space.

Best wishes,
-- Mike

From: Justin Richer [mailto:jric...@mit.edu]
Sent: Tuesday, July 07, 2015 4:47 PM
To: Mike Jones
Cc: Brian Campbell; 
Subject: Re: [OAUTH-WG] Token Chaining Use Case

This approach is not a good fit for my use cases, and it’s still not  OAuth-y 
at all. It requires a specially-formed security assertion on the way in, which 
the client must understand and generate. I still can’t take an arbitrary token 
I’ve been handed by someone else and pass it off to be pushed forward. The new 
“*_type” parameters seem to merely kick the can down the road instead of 
addressing the problems with the current specification.

I think that Brian’s approach works much better. It unrolls important 
parameters, properly uses the token endpoint, and allows for arbitrarily 
formatted input tokens.

When combined with Nat’s draft that specifies how to perform all generic OAuth 
requests as JWTs (or even some of the upcoming PoP work if we ever do that), 
you’ve pretty much got the draft below but with much more flexibility and power.

 — Justin

On Jul 7, 2015, at 6:51 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:

As just updated, I believe that the working 
group token exchange draft 
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 can now also 
serve the “OAuthy” token exchange use cases, such as Justin and Phil’s token 
chaining use case, as well as support general token exchange, including 
exchange of JWT and SAML tokens.  The mechanism would be the same one that 
Brian suggested below – defining security token type values for OAuth 2.0 
access tokens and refresh tokens – enabling them to be used as inputs and 
outputs in any of the token exchanges.

For instance, by using “access token” as the input security token type, 
providing new scope values, and using “access token” as the output security 
token type, token chaining is achieved.

Now, a question

Re: [OAUTH-WG] Token Chaining Use Case

[Anthony Nadalin]

I’m not sure how Brian’s approach solves the basic generic token exchange use 
case that we have

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Tuesday, July 7, 2015 4:47 PM
To: Mike Jones 
Cc:  
Subject: Re: [OAUTH-WG] Token Chaining Use Case

This approach is not a good fit for my use cases, and it’s still not  OAuth-y 
at all. It requires a specially-formed security assertion on the way in, which 
the client must understand and generate. I still can’t take an arbitrary token 
I’ve been handed by someone else and pass it off to be pushed forward. The new 
“*_type” parameters seem to merely kick the can down the road instead of 
addressing the problems with the current specification.

I think that Brian’s approach works much better. It unrolls important 
parameters, properly uses the token endpoint, and allows for arbitrarily 
formatted input tokens.

When combined with Nat’s draft that specifies how to perform all generic OAuth 
requests as JWTs (or even some of the upcoming PoP work if we ever do that), 
you’ve pretty much got the draft below but with much more flexibility and power.

 — Justin

On Jul 7, 2015, at 6:51 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:

As just updated, I believe that the working 
group token exchange draft 
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 can now also 
serve the “OAuthy” token exchange use cases, such as Justin and Phil’s token 
chaining use case, as well as support general token exchange, including 
exchange of JWT and SAML tokens.  The mechanism would be the same one that 
Brian suggested below – defining security token type values for OAuth 2.0 
access tokens and refresh tokens – enabling them to be used as inputs and 
outputs in any of the token exchanges.

For instance, by using “access token” as the input security token type, 
providing new scope values, and using “access token” as the output security 
token type, token chaining is achieved.

Now, a question for the working group…  What should the security token type 
values for access token and refresh token be?  Two different choices seem to 
make sense.
(1)  Use the values “access_token” and “refresh_token”, which are used in RFC 
6749 token response values.
(2)  Define new URNs for this usage, such as 
urn:ietf:params:oauth:token-type:access-token and 
urn:ietf:params:oauth:token-type:refresh-token.

I’d personally be fine just using the short names in (1).

If people agree with this approach, we can document this usage in the -03 draft 
and publish it as soon as the submission tool reopens Monday morning during 
IETF 93.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, March 26, 2015 3:15 PM
To: Justin Richer
Cc: mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Token Chaining Use Case

This kind of token exchange might involve exchanges other than swapping an AT 
for another AT (and downscoping it). It might be an AT for a structured JWT 
specifically targeted at one of the the particular services that the original 
RS needs to call. Or an AT might be exchanged for a SAML assertion to use with 
legacy SOAP serveries.  A good general token exchange mechanism enables lots of 
variations of cases like the one Justin mentioned. And more. In fact, I think 
downscoping might be a minority use case where what token exchange is often 
need for is translating tokens from what you have into what the resource you 
need to call can deal with.
There need to be ways for the caller to tell the AS about the token it's asking 
for - by type or by the address/identifier of where it'll be used. There needs 
to be ways for the caller to authenticate to the AS. And there needs to be some 
way of expressing this delegation thing (though I'm still not totally convinced 
it couldn't be just the token is about the user/principal and the caller/client 
of the exchange is who is being delegated to).
I realize few (approaching zero) people have or are going to read it but I have 
endeavored to cover all these things in the 
http://tools.ietf.org/html/draft-campbell-oauth-sts-02 draft. It's an early 
draft so not without it some rough edges but can provide some guidance on what 
is needed and offers some protocol syntax for expressing it. I believe Justin's 
use case would be covered by it (defining a specific token type URI for an 
OAuth access token issued by the AS in question might be needed) as are many 
others.

On Thu, Mar 26, 2015 at 1:31 PM, Justin Richer 
mailto:jric...@mit.edu>> wrote:
As requested after last night’s informal meeting, here is the token chaining 
use case that I want to see represented in the token swap draft.


[ Client ]  ->   [ A ] -> [ B ] -> [ C ]

An OAuth client gets an access token AT1, just like it always would, with 
scopes [A, B, C] in order to call service A, which requires all three sc

Re: [OAUTH-WG] Token Chaining Use Case

[Justin Richer]

This approach is not a good fit for my use cases, and it’s still not  OAuth-y 
at all. It requires a specially-formed security assertion on the way in, which 
the client must understand and generate. I still can’t take an arbitrary token 
I’ve been handed by someone else and pass it off to be pushed forward. The new 
“*_type” parameters seem to merely kick the can down the road instead of 
addressing the problems with the current specification.

I think that Brian’s approach works much better. It unrolls important 
parameters, properly uses the token endpoint, and allows for arbitrarily 
formatted input tokens. 

When combined with Nat’s draft that specifies how to perform all generic OAuth 
requests as JWTs (or even some of the upcoming PoP work if we ever do that), 
you’ve pretty much got the draft below but with much more flexibility and 
power. 

 — Justin

> On Jul 7, 2015, at 6:51 PM, Mike Jones  wrote:
> 
> As just updated , I believe that the working 
> group token exchange draft 
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 
>  can now also 
> serve the “OAuthy” token exchange use cases, such as Justin and Phil’s token 
> chaining use case, as well as support general token exchange, including 
> exchange of JWT and SAML tokens.  The mechanism would be the same one that 
> Brian suggested below – defining security token type values for OAuth 2.0 
> access tokens and refresh tokens – enabling them to be used as inputs and 
> outputs in any of the token exchanges.
>  
> For instance, by using “access token” as the input security token type, 
> providing new scope values, and using “access token” as the output security 
> token type, token chaining is achieved.
>  
> Now, a question for the working group…  What should the security token type 
> values for access token and refresh token be?  Two different choices seem to 
> make sense.
> (1)  Use the values “access_token” and “refresh_token”, which are used in RFC 
> 6749 token response values.
> (2)  Define new URNs for this usage, such as 
> urn:ietf:params:oauth:token-type:access-token and 
> urn:ietf:params:oauth:token-type:refresh-token.
>  
> I’d personally be fine just using the short names in (1).
>  
> If people agree with this approach, we can document this usage in the -03 
> draft and publish it as soon as the submission tool reopens Monday morning 
> during IETF 93.
>  
> -- Mike
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
> Sent: Thursday, March 26, 2015 3:15 PM
> To: Justin Richer
> Cc: 
> Subject: Re: [OAUTH-WG] Token Chaining Use Case
>  
> This kind of token exchange might involve exchanges other than swapping an AT 
> for another AT (and downscoping it). It might be an AT for a structured JWT 
> specifically targeted at one of the the particular services that the original 
> RS needs to call. Or an AT might be exchanged for a SAML assertion to use 
> with legacy SOAP serveries.  A good general token exchange mechanism enables 
> lots of variations of cases like the one Justin mentioned. And more. In fact, 
> I think downscoping might be a minority use case where what token exchange is 
> often need for is translating tokens from what you have into what the 
> resource you need to call can deal with.
> 
> There need to be ways for the caller to tell the AS about the token it's 
> asking for - by type or by the address/identifier of where it'll be used. 
> There needs to be ways for the caller to authenticate to the AS. And there 
> needs to be some way of expressing this delegation thing (though I'm still 
> not totally convinced it couldn't be just the token is about the 
> user/principal and the caller/client of the exchange is who is being 
> delegated to).
> 
> I realize few (approaching zero) people have or are going to read it but I 
> have endeavored to cover all these things in the 
> http://tools.ietf.org/html/draft-campbell-oauth-sts-02 
>  draft. It's an early 
> draft so not without it some rough edges but can provide some guidance on 
> what is needed and offers some protocol syntax for expressing it. I believe 
> Justin's use case would be covered by it (defining a specific token type URI 
> for an OAuth access token issued by the AS in question might be needed) as 
> are many others.
>  
> On Thu, Mar 26, 2015 at 1:31 PM, Justin Richer  > wrote:
> As requested after last night’s informal meeting, here is the token chaining 
> use case that I want to see represented in the token swap draft.
> 
> 
> [ Client ]  ->   [ A ] -> [ B ] -> [ C ]
> 
> An OAuth client gets an access token AT1, just like it always would, with 
> scopes [A, B, C] in order to call service A, which requires all three scopes. 
> Service A (an RS) accepts this to

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT)

[Barry Leiba]

> In JWS we used ASCII(string) to indicate that the output is a sequence of
> octets, strings are not necessarily 8 characters bits and may have null
> termination etc.
>
> However as Brian states other changes may have removed the need for that.
>
> I admit saying "where STRING is a sequence of zero or more ASCII
> characters.” looks a bit circular.   How about saying "where STRING is a
> sequence of zero or more characters”
>
> The ABNF in Sec 4.1 should keep people from going too wrong on its own.
>
> I think it is OK the way it is, but am willing to change it if people feel
> strongly.

As I've said, that one is the least important of all my comments, and
you folks should do what you think best there.  If you prefer to leave
the "ASCII(x)" notation for consistency, clarity, or whatever else,
I'm not going to say any more about it.

And many thanks for dealing with the other changes I've suggested.

Barry

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

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT)

[John Bradley]

I have a draft with Barry’s edits less the removal of ASCII(string) ready to go.

In JWS we used ASCII(string) to indicate that the output is a sequence of 
octets, strings are not necessarily 8 characters bits and may have null 
termination etc.

However as Brian states other changes may have removed the need for that.

I admit saying "where STRING is a sequence of zero or more ASCII characters.” 
looks a bit circular.   How about saying "where STRING is a sequence of zero or 
more characters”

The ABNF in Sec 4.1 should keep people from going too wrong on its own.

I think it is OK the way it is, but am willing to change it if people feel 
strongly.

Let me know if I should make that change or publish a draft without it, 
addressing the other comments.

John B.




> On Jul 7, 2015, at 5:40 PM, Kathleen Moriarty 
>  wrote:
> 
> Thanks for your responses on these comments.
> 
> I can approve an updated draft to make this change and the one for IANA if 
> that is the easiest path.  The other option is to write this all up in an RFC 
> editor note and I can send that with the approval.  Making the direct updates 
> may be simpler to avoid mistakes.
> 
> Can you submit a new version?
> 
> Thank you,
> Kathleen
> 
> On Tue, Jul 7, 2015 at 12:35 PM, Brian Campbell  > wrote:
> Regarding the comment on Section 2, I had originally argued for the inclusion 
> of ASCII(xxx) as I felt it was important to avoid potential ambiguity that 
> was in the draft at the time (it wasn't 100% clear to me at the time if the 
> code_verifier was to be base64url decoded as input into the hash or if the 
> ASCII bytes were to be used). However, other content (particularly §4.1 
> ) has since 
> changed and removed the potential for the ambiguity I thought might be there. 
> 
> Which is a long way of explaining that I'm okay with Barry's proposed change 
> to Section 2, and occurrences of ASCII(...) throughout, despite it undoing 
> something I'd previously requested.  
> 
> On Tue, Jul 7, 2015 at 10:09 AM, Nat Sakimura  > wrote:
> Thanks Barry, 
> 
> 
> These are the issues that I wanted to discuss with John before making change. 
> 
> -- Section 6.2 -- John has partly addressed your IANA comment already. I 
> needed 
> to check if there was any reason for just doing partly. 
> 
> -- Section 7.2 -- is probably just my oversight. I will deal with it. 
> 
> -- Section 2 -- : I agree with you and I wanted to confirm it with John and 
> other people to commit the change. 
> 
> Cheers, 
> 
> Nat
> 
> 2015-07-07 11:49 GMT+09:00 Barry Leiba  >:
> Barry Leiba has entered the following ballot position for
> draft-ietf-oauth-spop-14: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html 
> 
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ 
> 
> 
> 
> 
> --
> COMMENT:
> --
> 
> Version -14 resolves my DISCUSS (and also some of my non-blocking
> comments).  Thanks very much for considering these and working with me on
> them!
> 
>   =
> My comment about the IANA Considerations remains.  While it's
> non-blocking, I still hope you will accept the change I suggest:
> 
> -- Section 6.2 --
> I have the same comment here as in the other OAuth document: please shift
> the focus away from telling IANA how to handle tracking of the expert
> review, and make the mailing list something that the designated expert(s)
> keep track of.  Also, please give more instructions to the DEs about what
> they should consider when they're evaluating a request (for example,
> should they approve all requests, or are there criteria they should
> apply?).
> 
> For the first, here's a text change that I suggest we move toward for
> this sort of thing:
> 
> OLD
> 
> 
> NEW
>Additional code_challenge_method types for use with the authorization
>endpoint are registered using the Specification Required policy
>[RFC5226], which includes review of the request by one or more
>Designated Experts.  The DEs will ensure there is at least a two-week
>review of the request on the oauth-ext-rev...@ietf.org 
>  mailing list,
>and that any discussion on that list converges before they respond to
>the request.  To

Re: [OAUTH-WG] Token Chaining Use Case

[Mike Jones]

As just updated, I believe that the working 
group token exchange draft 
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 can now also 
serve the “OAuthy” token exchange use cases, such as Justin and Phil’s token 
chaining use case, as well as support general token exchange, including 
exchange of JWT and SAML tokens.  The mechanism would be the same one that 
Brian suggested below – defining security token type values for OAuth 2.0 
access tokens and refresh tokens – enabling them to be used as inputs and 
outputs in any of the token exchanges.

For instance, by using “access token” as the input security token type, 
providing new scope values, and using “access token” as the output security 
token type, token chaining is achieved.

Now, a question for the working group…  What should the security token type 
values for access token and refresh token be?  Two different choices seem to 
make sense.
(1)  Use the values “access_token” and “refresh_token”, which are used in RFC 
6749 token response values.
(2)  Define new URNs for this usage, such as 
urn:ietf:params:oauth:token-type:access-token and 
urn:ietf:params:oauth:token-type:refresh-token.

I’d personally be fine just using the short names in (1).

If people agree with this approach, we can document this usage in the -03 draft 
and publish it as soon as the submission tool reopens Monday morning during 
IETF 93.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, March 26, 2015 3:15 PM
To: Justin Richer
Cc: 
Subject: Re: [OAUTH-WG] Token Chaining Use Case

This kind of token exchange might involve exchanges other than swapping an AT 
for another AT (and downscoping it). It might be an AT for a structured JWT 
specifically targeted at one of the the particular services that the original 
RS needs to call. Or an AT might be exchanged for a SAML assertion to use with 
legacy SOAP serveries.  A good general token exchange mechanism enables lots of 
variations of cases like the one Justin mentioned. And more. In fact, I think 
downscoping might be a minority use case where what token exchange is often 
need for is translating tokens from what you have into what the resource you 
need to call can deal with.
There need to be ways for the caller to tell the AS about the token it's asking 
for - by type or by the address/identifier of where it'll be used. There needs 
to be ways for the caller to authenticate to the AS. And there needs to be some 
way of expressing this delegation thing (though I'm still not totally convinced 
it couldn't be just the token is about the user/principal and the caller/client 
of the exchange is who is being delegated to).
I realize few (approaching zero) people have or are going to read it but I have 
endeavored to cover all these things in the 
http://tools.ietf.org/html/draft-campbell-oauth-sts-02 draft. It's an early 
draft so not without it some rough edges but can provide some guidance on what 
is needed and offers some protocol syntax for expressing it. I believe Justin's 
use case would be covered by it (defining a specific token type URI for an 
OAuth access token issued by the AS in question might be needed) as are many 
others.

On Thu, Mar 26, 2015 at 1:31 PM, Justin Richer 
mailto:jric...@mit.edu>> wrote:
As requested after last night’s informal meeting, here is the token chaining 
use case that I want to see represented in the token swap draft.


[ Client ]  ->   [ A ] -> [ B ] -> [ C ]

An OAuth client gets an access token AT1, just like it always would, with 
scopes [A, B, C] in order to call service A, which requires all three scopes. 
Service A (an RS) accepts this token since it has its scope, and then needs to 
call service B in turn, which requires scopes [B, C]. It could just re-send the 
token it got in, AT1, but that would give the downstream RS the ability to call 
services with scope [ A ] and it should not be allowed to do that. To limit 
exposure, service A calls a token swap at the AS to create AT2 with scopes [ B, 
C ], effectively acting as an OAuth client requesting a downscoped token based 
on AT1. Service A then acts as an OAuth client to call service B, now acting as 
an RS to service A’s client, and can fulfill the request. And it’s turtles all 
the way down: Service B can also call service C, and now B acts as a client, 
requesting AT3 with scope [ C ] based on AT2, and sending AT3 to service C. 
This prevents C from being able to call B or A, both of which would have been 
available if AT1 had been passed around. Note that service A or the Client can 
also request a downscoped token with [ C ] to call service C directly as well, 
and C doesn’t have to care how it got there.


In other words, it lets the client software be very, very dumb. It doesn’t have 
to do any special processing, doesn’t have to know what’s in the token, it just 
foll

[OAUTH-WG] OAuth 2.0 Token Exchange -02 enabling use of any token type

[Mike Jones]

Draft -02 of the OAuth 2.0 Token Exchange specification has been published, 
making the functionality token type independent.  Formerly, only JSON Web 
Tokens (JWTs) could be used in some contexts.  This was a change requested by 
working group participants during IETF 92 in Dallas.

The specification is available at:

* https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02

An HTML formatted version is also available at:

* http://self-issued.info/docs/draft-ietf-oauth-token-exchange-02.html

-- Mike

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

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

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT)

[Kathleen Moriarty]

Thanks for your responses on these comments.

I can approve an updated draft to make this change and the one for IANA if
that is the easiest path.  The other option is to write this all up in an
RFC editor note and I can send that with the approval.  Making the direct
updates may be simpler to avoid mistakes.

Can you submit a new version?

Thank you,
Kathleen

On Tue, Jul 7, 2015 at 12:35 PM, Brian Campbell 
wrote:

> Regarding the comment on Section 2, I had originally argued for the
> inclusion of ASCII(xxx) as I felt it was important to avoid potential
> ambiguity that was in the draft at the time (it wasn't 100% clear to me at
> the time if the code_verifier was to be base64url decoded as input into the
> hash or if the ASCII bytes were to be used). However, other content
> (particularly §4.1
> ) has
> since changed and removed the potential for the ambiguity I thought might
> be there.
>
> Which is a long way of explaining that I'm okay with Barry's proposed
> change to Section 2, and occurrences of ASCII(...) throughout, despite it
> undoing something I'd previously requested.
>
> On Tue, Jul 7, 2015 at 10:09 AM, Nat Sakimura  wrote:
>
>> Thanks Barry,
>>
>>
>> These are the issues that I wanted to discuss with John before making
>> change.
>>
>> -- Section 6.2 -- John has partly addressed your IANA comment already. I
>> needed
>> to check if there was any reason for just doing partly.
>>
>> -- Section 7.2 -- is probably just my oversight. I will deal with it.
>>
>> -- Section 2 -- : I agree with you and I wanted to confirm it with John
>> and other people to commit the change.
>>
>> Cheers,
>>
>> Nat
>>
>> 2015-07-07 11:49 GMT+09:00 Barry Leiba :
>>
>>> Barry Leiba has entered the following ballot position for
>>> draft-ietf-oauth-spop-14: No Objection
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to
>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/
>>>
>>>
>>>
>>> --
>>> COMMENT:
>>> --
>>>
>>> Version -14 resolves my DISCUSS (and also some of my non-blocking
>>> comments).  Thanks very much for considering these and working with me on
>>> them!
>>>
>>>   =
>>> My comment about the IANA Considerations remains.  While it's
>>> non-blocking, I still hope you will accept the change I suggest:
>>>
>>> -- Section 6.2 --
>>> I have the same comment here as in the other OAuth document: please shift
>>> the focus away from telling IANA how to handle tracking of the expert
>>> review, and make the mailing list something that the designated expert(s)
>>> keep track of.  Also, please give more instructions to the DEs about what
>>> they should consider when they're evaluating a request (for example,
>>> should they approve all requests, or are there criteria they should
>>> apply?).
>>>
>>> For the first, here's a text change that I suggest we move toward for
>>> this sort of thing:
>>>
>>> OLD
>>> 
>>>
>>> NEW
>>>Additional code_challenge_method types for use with the authorization
>>>endpoint are registered using the Specification Required policy
>>>[RFC5226], which includes review of the request by one or more
>>>Designated Experts.  The DEs will ensure there is at least a two-week
>>>review of the request on the oauth-ext-rev...@ietf.org mailing list,
>>>and that any discussion on that list converges before they respond to
>>>the request.  To allow for the allocation of values prior to
>>>publication, the Designated Expert(s) may approve registration once
>>>they are satisfied that an acceptable specification will be
>>> published.
>>>
>>>Discussion on the oauth-ext-rev...@ietf.org mailing list should use
>>>an appropriate subject, such as "Request for PKCE
>>>code_challenge_method: example").
>>>
>>>The Designated Expert(s) should consider the discussion on the
>>>mailing list, as well as <> when evaluating
>>>registration requests.  Denials should include an explanation
>>>and, if applicable, suggestions as to how to make the request
>>>successful.
>>> END
>>>
>>>   =
>>> -- Section 7.2 --
>>> I find the first first paragraph confusingly worded, and after discussion
>>> with the author I suggest this:
>>>
>>> NEW
>>> Clients MUST NOT downgrade to "plain" after trying the S256 method.
>>> Because servers are required to support S256, an error when S256 is
>>> presented can only

[OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing WGLC comments

[Mike Jones]

The editors have published 
draft-ietf-oauth-proof-of-possession-03,
 which addresses the working group last call comments received.  Thanks to all 
of you who provided feedback.  The changes were:

* Separated the jwk and jwe confirmation members; the former represents 
a public key as a JWK and the latter represents a symmetric key as a JWE 
encrypted JWK.

* Changed the title to indicate that a proof-of-possession key is being 
communicated.

* Updated language that formerly assumed that the issuer was an OAuth 
2.0 authorization server.

* Described ways that applications can choose to identify the 
presenter, including use of the iss, sub, and azp claims.

* Harmonized the registry language with that used in JWT [RFC 
7519].

* Addressed other issues identified during working group last call.

* Referenced the JWT and JOSE RFCs.

The updated specification is available at:

* https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-03

An HTML formatted version is also available at:

* 
http://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-03.html

-- Mike

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

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

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Mike Jones]

I’ll write a note later today describing how the just-published update that 
makes the Token Exchange draft token-type agnostic also enables it to be used 
in fully “OAuthy” cases – where some of the tokens used are OAuth access tokens 
or refresh tokens.

(Right now I’m writing up the changes made to 
draft-ietf-oauth-proof-of-possession, then will get to the JWK Thumbprint and 
Token Exchange write-ups…)

Cheers,
-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Tuesday, July 07, 2015 12:52 PM
To: Kathleen Moriarty
Cc: 
Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case

Kathleen,

I agree that Brian’s approach covers the use case that drove my original draft 
and effectively subsumes my approach.

My standing contention with the document as it stands is and has always been 
that it’s lacking a general syntactical approach and it isn’t very OAuth-y. I 
would love to see a productive conversation on this front.

 — Justin

On Jul 7, 2015, at 3:43 PM, Kathleen Moriarty 
mailto:kathleen.moriarty.i...@gmail.com>> 
wrote:

I'm just catching up on this tread, but would appreciate an in-room discussion 
on this topic that doesn't assume the adopted draft has the agreed upon 
approach as I am not reading that there is consensus on that approach in this 
thread at all.

Could we see presentations on Mike's draft and Brian's?  Justin, do you agree 
that Brian's draft covers the use case in our draft as was implied in this 
thread?

I'd like to see a discussion guided by the chairs to see if we can find a 
go-forward plan.  There seems to be differing opinions and maybe a pull towards 
simpler approaches that extend Oauth.

Thank you.

On Tue, Jul 7, 2015 at 3:18 PM, Sam Hartman 
mailto:hartmans-i...@mit.edu>> wrote:
Speaking as someone who is reasonably familiar with Kerberos and the
general concepts involved, I find both Microsoft/Kerberos technology
((constrained delegation/protocol transition) and the ws-trust text
horribly confusing and would recommend against all of the above as
examples of clarity.
After several years I've finally gotten to a point where I understand
the Kerberos terms, but that's simply by using them regularly, not
because there was clarity.


This may be a case where new terminology is worthwhile if you can find
something that multiple people (especially new readers not overly
familiar with the concepts) find to be clear.

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



--

Best regards,
Kathleen

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

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Justin Richer]

Kathleen,

I agree that Brian’s approach covers the use case that drove my original draft 
and effectively subsumes my approach.

My standing contention with the document as it stands is and has always been 
that it’s lacking a general syntactical approach and it isn’t very OAuth-y. I 
would love to see a productive conversation on this front.

 — Justin

> On Jul 7, 2015, at 3:43 PM, Kathleen Moriarty 
>  wrote:
> 
> I'm just catching up on this tread, but would appreciate an in-room 
> discussion on this topic that doesn't assume the adopted draft has the agreed 
> upon approach as I am not reading that there is consensus on that approach in 
> this thread at all.
> 
> Could we see presentations on Mike's draft and Brian's?  Justin, do you agree 
> that Brian's draft covers the use case in our draft as was implied in this 
> thread?  
> 
> I'd like to see a discussion guided by the chairs to see if we can find a 
> go-forward plan.  There seems to be differing opinions and maybe a pull 
> towards simpler approaches that extend Oauth.
> 
> Thank you.
> 
> On Tue, Jul 7, 2015 at 3:18 PM, Sam Hartman  > wrote:
> Speaking as someone who is reasonably familiar with Kerberos and the
> general concepts involved, I find both Microsoft/Kerberos technology
> ((constrained delegation/protocol transition) and the ws-trust text
> horribly confusing and would recommend against all of the above as
> examples of clarity.
> After several years I've finally gotten to a point where I understand
> the Kerberos terms, but that's simply by using them regularly, not
> because there was clarity.
> 
> 
> This may be a case where new terminology is worthwhile if you can find
> something that multiple people (especially new readers not overly
> familiar with the concepts) find to be clear.
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen

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

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Kathleen Moriarty]

On Tue, Jul 7, 2015 at 3:43 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> I'm just catching up on this tread, but would appreciate an in-room
> discussion on this topic that doesn't assume the adopted draft has the
> agreed upon approach as I am not reading that there is consensus on that
> approach in this thread at all.
>
> Could we see presentations on Mike's draft and Brian's?  Justin, do you
> agree that Brian's draft covers the use case in our draft as was implied in
> this thread?
>
s/our/your/ :-)

>
> I'd like to see a discussion guided by the chairs to see if we can find a
> go-forward plan.  There seems to be differing opinions and maybe a pull
> towards simpler approaches that extend Oauth.
>
> Thank you.
>
> On Tue, Jul 7, 2015 at 3:18 PM, Sam Hartman  wrote:
>
>> Speaking as someone who is reasonably familiar with Kerberos and the
>> general concepts involved, I find both Microsoft/Kerberos technology
>> ((constrained delegation/protocol transition) and the ws-trust text
>> horribly confusing and would recommend against all of the above as
>> examples of clarity.
>> After several years I've finally gotten to a point where I understand
>> the Kerberos terms, but that's simply by using them regularly, not
>> because there was clarity.
>>
>>
>> This may be a case where new terminology is worthwhile if you can find
>> something that multiple people (especially new readers not overly
>> familiar with the concepts) find to be clear.
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
>
> --
>
> Best regards,
> Kathleen
>



-- 

Best regards,
Kathleen
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Kathleen Moriarty]

I'm just catching up on this tread, but would appreciate an in-room
discussion on this topic that doesn't assume the adopted draft has the
agreed upon approach as I am not reading that there is consensus on that
approach in this thread at all.

Could we see presentations on Mike's draft and Brian's?  Justin, do you
agree that Brian's draft covers the use case in our draft as was implied in
this thread?

I'd like to see a discussion guided by the chairs to see if we can find a
go-forward plan.  There seems to be differing opinions and maybe a pull
towards simpler approaches that extend Oauth.

Thank you.

On Tue, Jul 7, 2015 at 3:18 PM, Sam Hartman  wrote:

> Speaking as someone who is reasonably familiar with Kerberos and the
> general concepts involved, I find both Microsoft/Kerberos technology
> ((constrained delegation/protocol transition) and the ws-trust text
> horribly confusing and would recommend against all of the above as
> examples of clarity.
> After several years I've finally gotten to a point where I understand
> the Kerberos terms, but that's simply by using them regularly, not
> because there was clarity.
>
>
> This may be a case where new terminology is worthwhile if you can find
> something that multiple people (especially new readers not overly
> familiar with the concepts) find to be clear.
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



-- 

Best regards,
Kathleen
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWT Token on-behalf of Use case

[Sam Hartman]

Speaking as someone who is reasonably familiar with Kerberos and the
general concepts involved, I find both Microsoft/Kerberos technology
((constrained delegation/protocol transition) and the ws-trust text
horribly confusing and would recommend against all of the above as
examples of clarity.
After several years I've finally gotten to a point where I understand
the Kerberos terms, but that's simply by using them regularly, not
because there was clarity.


This may be a case where new terminology is worthwhile if you can find
something that multiple people (especially new readers not overly
familiar with the concepts) find to be clear.

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

Re: [OAUTH-WG] Same Origin Method Execution (SOME)

[Kim, William G]

Sorry to dig this back up but am I naive to wonder why anyone would even use 
JSONP. Sounds like the hackiest legitimate thing I've ever seen, and asking for 
trouble to use it.

-William

From: Justin Richer mailto:jric...@mit.edu>>
Date: Monday, June 29, 2015 at 11:36 AM
To: Nat Sakimura mailto:sakim...@gmail.com>>
Cc: "mailto:oauth@ietf.org>>" 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Same Origin Method Execution (SOME)

Right, even though it’s not an OAuth problem, it’s a problem that is more 
likely to come up and cause damage in situations that OAuth brings about (the 
pop-up redirect page that Nat mentions). So, just like the advice to use the 
system browser on mobile platforms, I think it’d be good to have actual advice 
for developers so that they can avoid doing this.

 — Justin

On Jun 29, 2015, at 11:22 AM, Nat Sakimura 
mailto:sakim...@gmail.com>> wrote:

s/Year/Yeah/

2015-06-30 0:22 GMT+09:00 Nat Sakimura 
mailto:sakim...@gmail.com>>:
Year, from my skimming of the paper, it requires a page that executes arbitrary 
callback function given as a parameter.
It is absolutely stupid to do it, but apparently there are such pages.
Prime candidate happens to be OAuth Redirection Endpoint.
By itself, it probably will not do much harm because you cannot do much things 
in that window itself,
but if the window is a pop-up and keeps a parent context, it will essentially 
be able to
remote control the parent window to do much more harm.

So, it is not OAuth problem per se.

However, it may be worthwhile to tell the developers to make sure that 
redirection endpoint
accepts only valid oauth payload, and do not execute anything in the parameter.

Nat

2015-06-25 19:48 GMT+09:00 Antonio Sanso 
mailto:asa...@adobe.com>>:
hi John

On Jun 25, 2015, at 1:42 AM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:

Thanks for the info,

As I read it, this is an attack on Java Script callbacks.

The information tying it to OAuth is not clear.

Is the issue relating to JS people using the implicit flow and the JS loaded 
from the client somehow being vulnerable?

Or is this happening in the JS after authorization in calls to other resources 
from the same origin, and it is just coincidence that people are using OAuth.

is more the second one :) Extrapolating from the white paper [0]

"The most common technique tasked with ful lling
the above described need is OAuth. In order to gain access to third-party 
resources
using OAuth, the service shall utilize a third-party endpoint (OAuth dialog) 
that will
ask for the resource owner's approval. The problem with this process is that 
redirecting
the service to an OAuth dialog means losing the content of the currently open 
service
document. For overcoming this problem, developers open a pop-up window to 
display
the dialog in a singular browsing context. Once the user permits or denies 
access to
the service, the OAuth dialog pop-up will be redirected to render a callback 
endpoint
hosted on the service domain. This document should eventually notify the 
service that
the process has been completed.
For the new pop-up window to notify the service window upon approval, denial or 
for
it to transfer access tokens or similar data, developers may implement callback 
endpoints
that use a script referencing the "opener" window for executing a callback 
method of the
service. When developers also opted for providing the service with the decision 
on how
to "call it back" through a callback parameter, the entire domain becomes 
vulnerable to
SOME."

regards

antonio

[0] http://files.benhayak.com/Same_Origin_Method_Execution__paper.pdf


Understanding if there is any Oauth specific advice to give would be helpful.   
I see there are ways to prevent the SOME exploit.

Regards
John B.


On Jun 24, 2015, at 4:18 PM, Antonio Sanso 
mailto:asa...@adobe.com>> wrote:

hi *, just sharing.

Not directly related to OAuth per se but it exploits several OAuth client 
endpoints due to some common developers pattern 
http://www.benhayak.com/2015/06/same-origin-method-execution-some.html 
(concrete example in 
http://www.benhayak.com/2015/05/stealing-private-photo-albums-from-Google.html)

regards

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




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
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] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT)

[Brian Campbell]

Regarding the comment on Section 2, I had originally argued for the
inclusion of ASCII(xxx) as I felt it was important to avoid potential
ambiguity that was in the draft at the time (it wasn't 100% clear to me at
the time if the code_verifier was to be base64url decoded as input into the
hash or if the ASCII bytes were to be used). However, other content
(particularly §4.1
) has
since changed and removed the potential for the ambiguity I thought might
be there.

Which is a long way of explaining that I'm okay with Barry's proposed
change to Section 2, and occurrences of ASCII(...) throughout, despite it
undoing something I'd previously requested.

On Tue, Jul 7, 2015 at 10:09 AM, Nat Sakimura  wrote:

> Thanks Barry,
>
>
> These are the issues that I wanted to discuss with John before making
> change.
>
> -- Section 6.2 -- John has partly addressed your IANA comment already. I
> needed
> to check if there was any reason for just doing partly.
>
> -- Section 7.2 -- is probably just my oversight. I will deal with it.
>
> -- Section 2 -- : I agree with you and I wanted to confirm it with John
> and other people to commit the change.
>
> Cheers,
>
> Nat
>
> 2015-07-07 11:49 GMT+09:00 Barry Leiba :
>
>> Barry Leiba has entered the following ballot position for
>> draft-ietf-oauth-spop-14: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/
>>
>>
>>
>> --
>> COMMENT:
>> --
>>
>> Version -14 resolves my DISCUSS (and also some of my non-blocking
>> comments).  Thanks very much for considering these and working with me on
>> them!
>>
>>   =
>> My comment about the IANA Considerations remains.  While it's
>> non-blocking, I still hope you will accept the change I suggest:
>>
>> -- Section 6.2 --
>> I have the same comment here as in the other OAuth document: please shift
>> the focus away from telling IANA how to handle tracking of the expert
>> review, and make the mailing list something that the designated expert(s)
>> keep track of.  Also, please give more instructions to the DEs about what
>> they should consider when they're evaluating a request (for example,
>> should they approve all requests, or are there criteria they should
>> apply?).
>>
>> For the first, here's a text change that I suggest we move toward for
>> this sort of thing:
>>
>> OLD
>> 
>>
>> NEW
>>Additional code_challenge_method types for use with the authorization
>>endpoint are registered using the Specification Required policy
>>[RFC5226], which includes review of the request by one or more
>>Designated Experts.  The DEs will ensure there is at least a two-week
>>review of the request on the oauth-ext-rev...@ietf.org mailing list,
>>and that any discussion on that list converges before they respond to
>>the request.  To allow for the allocation of values prior to
>>publication, the Designated Expert(s) may approve registration once
>>they are satisfied that an acceptable specification will be
>> published.
>>
>>Discussion on the oauth-ext-rev...@ietf.org mailing list should use
>>an appropriate subject, such as "Request for PKCE
>>code_challenge_method: example").
>>
>>The Designated Expert(s) should consider the discussion on the
>>mailing list, as well as <> when evaluating
>>registration requests.  Denials should include an explanation
>>and, if applicable, suggestions as to how to make the request
>>successful.
>> END
>>
>>   =
>> -- Section 7.2 --
>> I find the first first paragraph confusingly worded, and after discussion
>> with the author I suggest this:
>>
>> NEW
>> Clients MUST NOT downgrade to "plain" after trying the S256 method.
>> Because servers are required to support S256, an error when S256 is
>> presented can only mean that the server does not support PKCE at all.
>> Otherwise, such an error could be indicative of a MITM attacker trying
>> a downgrade attack.
>> END
>>
>>   =
>> Finally, there is this comment, which is not a big deal and you should
>> proceed as you think best:
>>
>> -- Section 2 --
>> There is no real distinction between STRING and ASCII(STRING), because
>> STRING is already defined to be ASCII.  Using "ASCII(xxx)" only adds
>> clutter, and a suggest removing it.
>>
>> So, for example, that would 

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT)

[Nat Sakimura]

Thanks Barry,


These are the issues that I wanted to discuss with John before making
change.

-- Section 6.2 -- John has partly addressed your IANA comment already. I
needed
to check if there was any reason for just doing partly.

-- Section 7.2 -- is probably just my oversight. I will deal with it.

-- Section 2 -- : I agree with you and I wanted to confirm it with John and
other people to commit the change.

Cheers,

Nat

2015-07-07 11:49 GMT+09:00 Barry Leiba :

> Barry Leiba has entered the following ballot position for
> draft-ietf-oauth-spop-14: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/
>
>
>
> --
> COMMENT:
> --
>
> Version -14 resolves my DISCUSS (and also some of my non-blocking
> comments).  Thanks very much for considering these and working with me on
> them!
>
>   =
> My comment about the IANA Considerations remains.  While it's
> non-blocking, I still hope you will accept the change I suggest:
>
> -- Section 6.2 --
> I have the same comment here as in the other OAuth document: please shift
> the focus away from telling IANA how to handle tracking of the expert
> review, and make the mailing list something that the designated expert(s)
> keep track of.  Also, please give more instructions to the DEs about what
> they should consider when they're evaluating a request (for example,
> should they approve all requests, or are there criteria they should
> apply?).
>
> For the first, here's a text change that I suggest we move toward for
> this sort of thing:
>
> OLD
> 
>
> NEW
>Additional code_challenge_method types for use with the authorization
>endpoint are registered using the Specification Required policy
>[RFC5226], which includes review of the request by one or more
>Designated Experts.  The DEs will ensure there is at least a two-week
>review of the request on the oauth-ext-rev...@ietf.org mailing list,
>and that any discussion on that list converges before they respond to
>the request.  To allow for the allocation of values prior to
>publication, the Designated Expert(s) may approve registration once
>they are satisfied that an acceptable specification will be
> published.
>
>Discussion on the oauth-ext-rev...@ietf.org mailing list should use
>an appropriate subject, such as "Request for PKCE
>code_challenge_method: example").
>
>The Designated Expert(s) should consider the discussion on the
>mailing list, as well as <> when evaluating
>registration requests.  Denials should include an explanation
>and, if applicable, suggestions as to how to make the request
>successful.
> END
>
>   =
> -- Section 7.2 --
> I find the first first paragraph confusingly worded, and after discussion
> with the author I suggest this:
>
> NEW
> Clients MUST NOT downgrade to "plain" after trying the S256 method.
> Because servers are required to support S256, an error when S256 is
> presented can only mean that the server does not support PKCE at all.
> Otherwise, such an error could be indicative of a MITM attacker trying
> a downgrade attack.
> END
>
>   =
> Finally, there is this comment, which is not a big deal and you should
> proceed as you think best:
>
> -- Section 2 --
> There is no real distinction between STRING and ASCII(STRING), because
> STRING is already defined to be ASCII.  Using "ASCII(xxx)" only adds
> clutter, and a suggest removing it.
>
> So, for example, that would result in changes such as this:
>
> OLD
> BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) == code_challenge
> NEW
> BASE64URL-ENCODE(SHA256(code_verifier)) == code_challenge
> END
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] invalid_scope in access token request

[Aaron Parecki]

Thanks, the refresh grant was the case I was missing.


Aaron Parecki
aaronparecki.com
@aaronpk 


On Tue, Jul 7, 2015 at 8:13 AM, John Bradley  wrote:

> In sec 6 you can send scope to down scope a refresh token.
>
> In that case if the client asks for a scope that was not part of the
> original code grant then you would  return invalid_scope.
>
> It is not an error in the spec.
>
> Regards
> John B.
>
> On Jul 7, 2015, at 11:42 AM, Aaron Parecki  wrote:
>
> Section 4.1.1 describes the parameters of the *authorization* request, not
> the token request. After the user approves the scope in the authorization
> request, the client exchanges the code for the access token. I'm talking
> about the token request, where there is no scope parameter listed, section
> 4.1.3 https://tools.ietf.org/html/rfc6749#section-4.1.3
>
> 
> Aaron Parecki
> aaronparecki.com
> @aaronpk 
>
>
> On Tue, Jul 7, 2015 at 1:08 AM, Antonio Sanso  wrote:
>
>>  hi Aaron
>>
>>  On Jul 7, 2015, at 6:23 AM, Aaron Parecki  wrote:
>>
>>  Section 5.2 lists the possible errors the authorization server can
>> return for an access token request. In the list is "invalid_scope", which
>> as I understand it, can only be returned for a "password" or
>> "client_credentials" grant, since scope is not a parameter of an
>> "authorization_code" grant.
>>
>>
>>  why not :) ? From https://tools.ietf.org/html/rfc6749#section-4.1.1
>>
>>   scope
>>  OPTIONAL.  The scope of the access request as described by
>>  Section 3.3 .
>>
>> regards
>>
>>  antonio
>>
>>
>>  Because of this, I believe the phrase "or exceeds the scope granted by
>> the resource owner." is unnecessary, since there is no initial grant by the
>> resource owner. Am I reading this correctly, or is there some situation I
>> am not thinking of? Thanks!
>>
>>  
>> Aaron Parecki
>> aaronparecki.com
>> @aaronpk 
>>
>>   ___
>> 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] invalid_scope in access token request

[John Bradley]

In sec 6 you can send scope to down scope a refresh token.

In that case if the client asks for a scope that was not part of the original 
code grant then you would  return invalid_scope.

It is not an error in the spec.

Regards
John B.

> On Jul 7, 2015, at 11:42 AM, Aaron Parecki  wrote:
> 
> Section 4.1.1 describes the parameters of the *authorization* request, not 
> the token request. After the user approves the scope in the authorization 
> request, the client exchanges the code for the access token. I'm talking 
> about the token request, where there is no scope parameter listed, section 
> 4.1.3 https://tools.ietf.org/html/rfc6749#section-4.1.3 
> 
> 
> 
> Aaron Parecki
> aaronparecki.com 
> @aaronpk 
> 
> 
> On Tue, Jul 7, 2015 at 1:08 AM, Antonio Sanso  > wrote:
> hi Aaron
> 
> On Jul 7, 2015, at 6:23 AM, Aaron Parecki  > wrote:
> 
>> Section 5.2 lists the possible errors the authorization server can return 
>> for an access token request. In the list is "invalid_scope", which as I 
>> understand it, can only be returned for a "password" or "client_credentials" 
>> grant, since scope is not a parameter of an "authorization_code" grant. 
> 
> why not :) ? From https://tools.ietf.org/html/rfc6749#section-4.1.1 
>  
> 
>  scope
>  OPTIONAL.  The scope of the access request as described by
>  Section 3.3 .
> regards
> 
> antonio
> 
>> 
>> Because of this, I believe the phrase "or exceeds the scope granted by the 
>> resource owner." is unnecessary, since there is no initial grant by the 
>> resource owner. Am I reading this correctly, or is there some situation I am 
>> not thinking of? Thanks!
>> 
>> 
>> Aaron Parecki
>> aaronparecki.com 
>> @aaronpk 
>> 
>> ___
>> 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] invalid_scope in access token request

[Aaron Parecki]

Section 4.1.1 describes the parameters of the *authorization* request, not
the token request. After the user approves the scope in the authorization
request, the client exchanges the code for the access token. I'm talking
about the token request, where there is no scope parameter listed, section
4.1.3 https://tools.ietf.org/html/rfc6749#section-4.1.3


Aaron Parecki
aaronparecki.com
@aaronpk 


On Tue, Jul 7, 2015 at 1:08 AM, Antonio Sanso  wrote:

>  hi Aaron
>
>  On Jul 7, 2015, at 6:23 AM, Aaron Parecki  wrote:
>
>  Section 5.2 lists the possible errors the authorization server can
> return for an access token request. In the list is "invalid_scope", which
> as I understand it, can only be returned for a "password" or
> "client_credentials" grant, since scope is not a parameter of an
> "authorization_code" grant.
>
>
>  why not :) ? From https://tools.ietf.org/html/rfc6749#section-4.1.1
>
>   scope
>  OPTIONAL.  The scope of the access request as described by
>  Section 3.3 .
>
> regards
>
>  antonio
>
>
>  Because of this, I believe the phrase "or exceeds the scope granted by
> the resource owner." is unnecessary, since there is no initial grant by the
> resource owner. Am I reading this correctly, or is there some situation I
> am not thinking of? Thanks!
>
>  
> Aaron Parecki
> aaronparecki.com
> @aaronpk 
>
>   ___
> 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] invalid_scope in access token request

[Antonio Sanso]

hi Aaron

On Jul 7, 2015, at 6:23 AM, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:

Section 5.2 lists the possible errors the authorization server can return for 
an access token request. In the list is "invalid_scope", which as I understand 
it, can only be returned for a "password" or "client_credentials" grant, since 
scope is not a parameter of an "authorization_code" grant.

why not :) ? From https://tools.ietf.org/html/rfc6749#section-4.1.1


 scope
 OPTIONAL.  The scope of the access request as described by
 Section 3.3.

regards

antonio


Because of this, I believe the phrase "or exceeds the scope granted by the 
resource owner." is unnecessary, since there is no initial grant by the 
resource owner. Am I reading this correctly, or is there some situation I am 
not thinking of? Thanks!


Aaron Parecki
aaronparecki.com
@aaronpk

___
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