Re: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation

[Bill Mills]

Maybe this has been covered elsewhere, but one can see the case where "iss" in 
an example is set to "my_auth_server" and that cut/paste gets re-used.   That's 
also possible even in the OpenID Discovery mechanism, it requires the 
implementer to actually pick a unique value.  It would be better if this were 
not dependent on by-hand configuration.
-bill 

On Tuesday, January 12, 2016 8:03 PM, Justin Richer  wrote:
 

 +1 to Brian’s point, and points to Mike for promising to address this. I 
wasn’t able to attend the meeting in Darmstadt, but I’ve been following the 
discussion and original papers. Let’s take this one piece at a time and not 
overreach with a solution.
In particular, the whole “late binding discovery” bit would cause huge problems 
on its own. There’s good reason that OpenID Connect mandates that the “iss” 
value returned from the discovery endpoint MUST be the same as the “iss” value 
coming back from the ID Token, so let’s not ignore that.
 — Justin

On Jan 12, 2016, at 5:53 PM, Mike Jones  wrote:

John Bradley and I went over this today and I'm already planning on simplifying 
the draft along the lines described. I would have written this earlier but I've 
been busy at a NIST meeting today.

John has also stated writing a note about how cut-and-paste does and doesn't 
apply here but hasn't finished it yet because he's been similarly occupied.  
He's also started writing up the state_hash token request parameter, as he 
agreed to do.

Watch this space for the new draft...

Best wishes,
-- MikeFrom:Brian Campbell
Sent:‎1/‎12/‎2016 5:24 PM
To:oauth
Subject:[OAUTH-WG] Mix-Up About The Mix-Up Mitigation

The "IdP Mix-Up" and "Malicious Endpoint" attacks (as well as variations on 
them) take advantage of the fact that there's nothing in the OAuth 
authorization response to the client's redirect_uri that identifies the 
authorization server. As a result, a variety of techniques can be used to trick 
the client into sending the code (or token in some cases) to the wrong endpoint.

To the best of my recollection the general consensus coming out of the meetings 
in Darmstadt (which Hannes mentioned inOAuth Security Advisory: Authorization 
Server Mix-Up) was to put forth an I-D as a simple extension to OAuth, which 
described how to return an issuer identifier for the authorization server and 
client identifier as authorization response parameters from the authorization 
endpoint. Doing so enables the client to know which AS the response came from 
and thus avoid sending the code to a different AS. Also, it doesn't introduce 
application/message level cryptography requirements on client implementations.

The mitigation draft that was posted yesterday diverges considerably from that 
with a significantly expanded scope that introduces OpenID Connect ID Tokens 
(sort of anyway) to regular OAuth and the retrieval of a metadata/discovery 
document in-between the authorization request and the access token request.

It is possible that my recollection from Darmstadt is wrong. But I expect 
others who were there could corroborate my account of what transpired. Of 
course, the agreements out of the Darmstadt meeting were never intended to be 
the final word - the whole WG would have the opportunity to weigh, as is now 
the case. However, a goal of meeting face-to-face was to come away with a good 
consensus towards a proposed solution that could (hopefully) be implementable 
in the very near term and move thought the IETF process in an expedited manner. 
I believe we'd reached consensus but the content of -00 draft does not reflect 
it.

I've made the plea off-list several times to simplify the draft to reflect the 
simple solution and now I'm doing the same on-list. Simplify the response 
validation to just say not to send the code/token back to an AS entity other 
that the one identified by the 'iss' in the response. And remove the id_token 
and JWT parts that . 

If this WG and/or the larger community believes that OAuth needs signed 
responses, let's develop a proper singed response mechanism. I don't know if 
it's needed or not but I do know that it's a decent chunk of work that should 
be conscientiously undertaken independent of what can and should be a simple to 
understand and implement fix for the idp mix-up problem.


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

[Bill Mills]

I think it is more likely that the flow for the user will be that they know an 
RS and the RS provides some reference to the AS.  The RS might well consume a 
generic lookup flow though.  We do need the "updated webfinger thing" for users 
as a generic though.

The WF type thing for a generic user lookup in a domain might be used for 
discovering the SMTP/IMAP/webmail entrypoints for a user along with the AS and 
that's another possible useful thing.  User specific rather than apparently 
server/service specific. 


On Sunday, December 13, 2015 12:59 PM, Torsten Lodderstedt 
 wrote:
 

  Hi Mike, Nat, John,
 
 thanks for starting this work. 
 
 It seems you assume the AS can always be discoverd using the user id of the 
resource owner. I think the underlying assumption is resource servers accept 
access token of different (any?) user specific AS (and OP)? From my 
perspective, RSs nowadays typically trust _the_ AS of their security 
domain/ecosystem and all resource owners need to have an user account with this 
particular AS. So I would assume the process to start at the RS. We potentially 
need to cover for both cases. 
 
 What do you think?
 
 best regards,
 Torsten.
 
 Am 26.11.2015 um 00:37 schrieb Mike Jones:
  
 
#yiv5368577927 #yiv5368577927 -- _filtered #yiv5368577927 
{font-family:Wingdings;panose-1:5 0 0 0 0 0 0 0 0 0;} _filtered #yiv5368577927 
{panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv5368577927 
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv5368577927 
{panose-1:2 11 5 2 4 2 4 2 2 3;}#yiv5368577927 #yiv5368577927 
p.yiv5368577927MsoNormal, #yiv5368577927 li.yiv5368577927MsoNormal, 
#yiv5368577927 div.yiv5368577927MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:11.0pt;}#yiv5368577927 a:link, 
#yiv5368577927 span.yiv5368577927MsoHyperlink 
{color:#0563C1;text-decoration:underline;}#yiv5368577927 a:visited, 
#yiv5368577927 span.yiv5368577927MsoHyperlinkFollowed 
{color:#954F72;text-decoration:underline;}#yiv5368577927 pre 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv5368577927 
p.yiv5368577927MsoListParagraph, #yiv5368577927 
li.yiv5368577927MsoListParagraph, #yiv5368577927 
div.yiv5368577927MsoListParagraph 
{margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;font-size:11.0pt;}#yiv5368577927
 span.yiv5368577927EmailStyle17 {color:windowtext;}#yiv5368577927 
span.yiv5368577927HTMLPreformattedChar {}#yiv5368577927 span.yiv5368577927grey 
{}#yiv5368577927 .yiv5368577927MsoChpDefault {} _filtered #yiv5368577927 
{margin:1.0in 1.0in 1.0in 1.0in;}#yiv5368577927 div.yiv5368577927WordSection1 
{}#yiv5368577927 _filtered #yiv5368577927 {} _filtered #yiv5368577927 
{font-family:Symbol;} _filtered #yiv5368577927 {} _filtered #yiv5368577927 
{font-family:Wingdings;} _filtered #yiv5368577927 {font-family:Symbol;} 
_filtered #yiv5368577927 {} _filtered #yiv5368577927 {font-family:Wingdings;} 
_filtered #yiv5368577927 {font-family:Symbol;} _filtered #yiv5368577927 {} 
_filtered #yiv5368577927 {font-family:Wingdings;}#yiv5368577927 ol 
{margin-bottom:0in;}#yiv5368577927 ul {margin-bottom:0in;}#yiv5368577927  I’m 
pleased to announce that Nat Sakimura, John Bradley, and I have created an 
OAuth 2.0 Discovery specification.  This fills a hole in the current OAuth 
specification set that is necessary to achieve interoperability.  Indeed, the 
Interoperability section of OAuth 2.0 states: In addition, this specification 
leaves a few required components partially or fully undefined (e.g., client 
registration, authorization server capabilities, endpoint discovery).  Without 
these components, clients must be manually and specifically configured against 
a specific authorization server and resource server in order to interoperate.   
 This framework was designed with the clear expectation that future work will 
define prescriptive profiles and extensions necessary to achieve full web-scale 
interoperability.    This specification enables discovery of both endpoint 
locations and authorization server capabilities.    This specification is based 
upon the already widely deployed OpenID Connect Discovery 1.0 specification and 
is compatible with it, by design.  The OAuth Discovery spec removes the 
portions of OpenID Connect Discovery that are OpenID specific and adds metadata 
values for Revocation and  Introspection endpoints.  It also maps OpenID 
concepts, such as OpenID Provider, Relying Party, End-User, and Issuer to their 
OAuth underpinnings, respectively Authorization  Server, Client, Resource 
Owner, and the newly introduced Configuration Information Location.  Some 
identifiers with names that appear to be OpenID specific were retained for 
compatibility purposes; despite the reuse of these identifiers that appear to 
be OpenID specific, their usage in this specification is actually referring to 
general OAuth 2.0 features that are not specific to OpenID Connect.    The 
specification is available at: · 
http://too

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

[Bill Mills]

> It is fair to say that the threats and mitigations from bearer tokens also 
> apply to PoP tokens.> PoP tokens add additional key information that must 
> also be protected along with the other > information in a access token.
 THis doesn't really work because for example transport security to protect the 
token itself is part of the Bearer security considerations and PoP tokens are 
making that much less of a problem.  I don't know if there's more but that 
doesn't work.  Referencing specific things from Bearer and not the whole 
secuiryt considerations section could work.

On Wednesday, November 25, 2015 12:55 PM, John Bradley  
wrote:
 

 I have been assuming that security considerations from RFC 6750 would be 
applied to “PoP” tokens as well when the tokens presentment/confirmation specs 
are done.
Sec 5.2 of RFC 6750 covers mitigations for modification and manufacture for by 
value and by reference tokens.
Do we want to keep repeating this information in all documents or reference it?
It is fair to say that the threats and mitigations from bearer tokens also 
apply to PoP tokens.PoP tokens add additional key information that must also be 
protected along with the other information in a access token.
John B.


On Nov 25, 2015, at 5:39 PM, Kathleen Moriarty 
 wrote:
Hi,

Sent from my iPhone
On Nov 25, 2015, at 3:20 PM, John Bradley  wrote:


Tokens are signed or the information is otherwise integrity protected between 
the AS and the RS.  
I suspect Kathleen is concerned about the key getting modified in transit.   
That needs to be protected against, but there is more than one way to do that.

Phil is correct.  I was looking for consistency between the sections since they 
related to each other.  If there is a security risk or consideration, that 
needs to be explicitly called out as a concern such as a key being modified in 
transit.  If there are options to protect against that, those would ideally be 
required or would have warnings.


So sending the public key in a unsigned JWT access token would be immensely 
stupid,  not just for PoP but for scopes and everything else.

Good, easy to require then.
Thanks,Kathleen 


In OAuth 2 all tokens need to be integrity protected between the AS and RS.  
That can be via signature,  by having a reference with sufficient entropy and 
secure introspection or database lookup.
I think that is a OAuth 2 security consideration.   We are adding a additional 
confirmation claim to the existing information that needs to be protected the 
same as the rest.
John B.


On Nov 25, 2015, at 4:38 PM, Phil Hunt  wrote:
If there is agreement that tokens are opaque then the requirement 
that tokens be signed must be removed from the threat mitigation requirements. 
And the paragraph in sec 5 that brian was concerned about be restored. 
Phil
On Nov 25, 2015, at 11:24, Justin Richer  wrote:


It is still end to end authentication with opaque tokens — since all OAuth 
tokens, including PoP tokens, have always been intended to be opaque to the 
client. That hasn’t changed and that isn’t the intent of this document. If 
that’s how people are reading it then we need to pull it back and rewrite it so 
that’s not the case.
The client gets a token that has two parts: the token and the key. The token is 
analogous to the access_token we have today and would come out of the server in 
the same field. The key is handed to the client alongside the token or 
registered by the client during the token request. Either way there’s an 
association between the two but it’s not the same association as a 
public/private keypair. 
It’s possible to sign the token itself, but the client doesn’t care. It sends 
the token and signs the HTTP request to the RS whether the token is signed, 
unsigned, hex blob, encrypted, or anything else. The same series of options are 
available as with bearer tokens. PoP tokens have never, ever been intended to 
be anything but opaque to the client.
The token can’t be opaque to the RS, which has to figure out what key to use to 
check the message signature. But we’ve got options there, like the embedded key 
in a JWT from Mike’s draft, or doing introspection to get the key (from an 
extension that hasn’t been written yet), or simply looking it up in the same 
database because the RS and the AS are in the same box. Does this 
structure/service/database choice sound familiar? It should, it’s the same as 
bearer tokens. This is also how the RS gets information like which scopes are 
associated with the token, if it’s expired, and all that. 



So here’s how I see it going on the wire:





(I just wrote this up so there are probably holes. Here’s the source if anyone 
wants to tweak it: 
http://www.websequencediagrams.com/?lz=cGFydGljaXBhbnQgQ2xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEh

Re: [OAUTH-WG] OAuth Discovery

[Bill Mills]

Can you elaborate on the advantage of having a separate parallel spec to OpenID 
Discovery? 


On Wednesday, November 25, 2015 3:37 PM, Mike Jones 
 wrote:
 

  I’m pleased to announce that Nat Sakimura, John Bradley, 
and I have created an OAuth 2.0 Discovery specification.  This fills a hole in 
the current OAuth specification set that is necessary to achieve 
interoperability.  Indeed, theInteroperability section of OAuth 2.0states: In 
addition, this specification leaves a few required components partially or 
fully undefined (e.g., client registration, authorization server capabilities, 
endpoint discovery).  Without these components, clients must be manually and 
specifically configured against a specific authorization server and resource 
server in order to interoperate.    This framework was designed with the clear 
expectation that future work will define prescriptive profiles and extensions 
necessary to achieve full web-scale interoperability.    This specification 
enables discovery of both endpoint locations and authorization server 
capabilities.    This specification is based upon the already widely 
deployedOpenID Connect Discovery 1.0 specification and is compatible with it, 
by design.  The OAuth Discovery spec removes the portions of OpenID Connect 
Discovery that are OpenID specific and adds metadata values for Revocation and 
Introspection endpoints.  It also maps OpenID concepts, such as OpenID 
Provider, Relying Party, End-User, and Issuer to their OAuth underpinnings, 
respectively Authorization Server, Client, Resource Owner, and the newly 
introduced Configuration Information Location.  Some identifiers with names 
that appear to be OpenID specific were retained for compatibility purposes; 
despite the reuse of these identifiers that appear to be OpenID specific, their 
usage in this specification is actually referring to general OAuth 2.0 features 
that are not specific to OpenID Connect.    The specification is available at: 
·http://tools.ietf.org/html/draft-jones-oauth-discovery-00    An 
HTML-formatted version is also available at: ·
http://self-issued.info/docs/draft-jones-oauth-discovery-00.html    
        -- Mike    P.S.  This note 
was also posted at http://self-issued.info/?p=1496 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

Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT)

[Bill Mills]

Is a data type mapping form JWT to CBOR sufficient then?


 On Monday, November 16, 2015 11:26 PM, Hannes Tschofenig 
 wrote:
   

 #yiv5390846737 #yiv5390846737 -- _filtered #yiv5390846737 
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv5390846737 
{font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv5390846737 
#yiv5390846737 p.yiv5390846737MsoNormal, #yiv5390846737 
li.yiv5390846737MsoNormal, #yiv5390846737 div.yiv5390846737MsoNormal 
{margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;}#yiv5390846737 a:link, 
#yiv5390846737 span.yiv5390846737MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv5390846737 a:visited, #yiv5390846737 
span.yiv5390846737MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv5390846737 
p.yiv5390846737MsoAcetate, #yiv5390846737 li.yiv5390846737MsoAcetate, 
#yiv5390846737 div.yiv5390846737MsoAcetate 
{margin:0cm;margin-bottom:.0001pt;font-size:8.0pt;}#yiv5390846737 
span.yiv5390846737EmailStyle17 {color:#1F497D;}#yiv5390846737 
span.yiv5390846737BalloonTextChar {}#yiv5390846737 .yiv5390846737MsoChpDefault 
{} _filtered #yiv5390846737 {margin:72.0pt 72.0pt 72.0pt 72.0pt;}#yiv5390846737 
div.yiv5390846737WordSection1 {}#yiv5390846737 Hi William,    You are indeed 
correct that the current document contains a list of one-by-one copies of 
claims from the JWT. The only difference is the data type. Probably it would 
have been better to just reference the semantic from the JWT spec and then 
state the new data type.    I fully understand the concern of defining CWT 
claims that have the same name as JWT claims but then different semantic. This 
would be terribly confusing.    Ciao Hannes    From: William Denniss 
[mailto:wdenn...@google.com]
Sent: 16 November 2015 22:32
To: Hannes Tschofenig
Cc: Erik Wahlström neXus; Carsten Bormann; Mike Jones; 
Subject: Re: [COSE] A draft on CBOR Web Tokens (CWT)    You raise some good 
points, and perhaps that is relevant to future claims. The spec as drafted, is 
a one-for-one copy of the standard JWT claims, which is why I raised this 
point.    Is the goal a CBOR representation of a JWT? If so, can it be defined 
in terms of a JWT?  Would the CNF claim then inherit that representation 
(treating the JWE and JWK as their CBOR equivalents)?    Perhaps if you go the 
separate registry route, those claims that *are* defined the same should at 
least normatively reference JWT?  I want to avoid the whole "on behalf of" / 
"act as" fiasco where things can get re-defined, and muddled.    On Mon, Nov 
16, 2015 at 7:09 AM, Hannes Tschofenig  wrote: Hi 
William,   I have been trying to do a document update to see how well a 
combined registry works and I have been wondering whether it is really worth 
the effort.  To make a good judgment I looked at the CNF claim defined in 
draft-ietf-oauth-proof-of-possession. The CNF claim may contain sub-elements, 
such as a JWE or a JWK.   If we translate the same mechanisms to the CWT (which 
makes sense) then we need to point to the respective COSE structures instead. 
Those do not only use a different encoding but also the functionality does not 
match the JOSE structures 100%. So, there are potentially differences. I am 
also not sure whether we really want to translate the full functionality of all 
the claims from JWT over to the CWT equivalent. It basically puts the burden on 
someone defining new claims (either in JWT or in CWT) to create the 
corresponding structures in a format they may not necessarily be familiar with 
or even care about. I have seen that happening in the RADIUS world protocol 
designers had to also define the equivalent structures for use with Diameter 
and, guess what, most of the definitions were wrong (since the authors did not 
care about Diameter when working on RADIUS).   Ciao
Hannes     From: William Denniss [mailto:wdenn...@google.com]
Sent: 12 November 2015 19:19
To: Erik Wahlström neXus
Cc: Carsten Bormann; Hannes Tschofenig; Mike Jones; c...@ietf.org; 
;a...@ietf.org
Subject: Re: [COSE] A draft on CBOR Web Tokens (CWT)   Regarding the draft 
itself, a few comments:   1.  Can we unify the claim registry with JWT? I'm 
worried about having the same claims defined twice in CWT and JWT with possibly 
conflicting meanings (and needless confusion even when they do match).    
Comparing 
https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#section-3.1.2
 and https://tools.ietf.org/html/rfc7519#section-4.1.2 which are nearly 
identical, I just don't see the value in re-defining it.   We may add new 
standard claims to JWT in the future (I proposed one in Yokohama on the 
id-event list), it would be good if this didn't need a separate entry in CWT 
too, but could just apply directly (separately, I think you should consider 
this claim, as it helps prevent tokens from being re-used in the wrong 
context).   2. Is Section 4 "Summary of CBOR major types used by defined 
claims" normative 
(https://tools.ietf.org/html/draft-wahlstr

Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT)

[Bill Mills]

If there are structural differences in what CBOR can support it would be 
worthwhile to note that.  Examples of things supported in JWT that you can't do 
in CBOR could be very helpful to implementers.
 


 On Monday, November 16, 2015 1:32 PM, William Denniss 
 wrote:
   

 You raise some good points, and perhaps that is relevant to future claims. The 
spec as drafted, is a one-for-one copy of the standard JWT claims, which is why 
I raised this point.
Is the goal a CBOR representation of a JWT? If so, can it be defined in terms 
of a JWT?  Would the CNF claim then inherit that representation (treating the 
JWE and JWK as their CBOR equivalents)?
Perhaps if you go the separate registry route, those claims that *are* defined 
the same should at least normatively reference JWT?  I want to avoid the whole 
"on behalf of" / "act as" fiasco where things can get re-defined, and muddled.
On Mon, Nov 16, 2015 at 7:09 AM, Hannes Tschofenig  
wrote:

Hi William, I have been trying to do a document update to see how well a 
combined registry works and I have been wondering whether it is really worth 
the effort.To make a good judgment I looked at the CNF claim defined in 
draft-ietf-oauth-proof-of-possession. The CNF claim may contain sub-elements, 
such as a JWE or a JWK. If we translate the same mechanisms to the CWT (which 
makes sense) then we need to point to the respective COSE structures instead. 
Those do not only use a different encoding but also the functionality does not 
match the JOSE structures 100%. So, there are potentially differences. I am 
also not sure whether we really want to translate the full functionality of all 
the claims from JWT over to the CWT equivalent. It basically puts the burden on 
someone defining new claims (either in JWT or in CWT) to create the 
corresponding structures in a format they may not necessarily be familiar with 
or even care about. I have seen that happening in the RADIUS world protocol 
designers had to also define the equivalent structures for use with Diameter 
and, guess what, most of the definitions were wrong (since the authors did not 
care about Diameter when working on RADIUS). Ciao
Hannes  From: William Denniss [mailto:wdenn...@google.com]
Sent: 12 November 2015 19:19
To: Erik Wahlström neXus
Cc: Carsten Bormann; Hannes Tschofenig; Mike Jones; c...@ietf.org; 
; a...@ietf.org
Subject: Re: [COSE] A draft on CBOR Web Tokens (CWT) Regarding the draft 
itself, a few comments: 1. Can we unify the claim registry with JWT? I'm 
worried about having the same claims defined twice in CWT and JWT with possibly 
conflicting meanings (and needless confusion even when they do match).  
Comparing 
https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#section-3.1.2
 and https://tools.ietf.org/html/rfc7519#section-4.1.2 which are nearly 
identical, I just don't see the value in re-defining it. We may add new 
standard claims to JWT in the future (I proposed one in Yokohama on the 
id-event list), it would be good if this didn't need a separate entry in CWT 
too, but could just apply directly (separately, I think you should consider 
this claim, as it helps prevent tokens from being re-used in the wrong 
context). 2.Is Section 4 "Summary of CBOR major types used by defined claims" 
normative 
(https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#section-4)?
 What is the intention of this section? I feel like it could probably be 
fleshed out a bit. 3. Add a xref to draft COSE spec in section 6Add xref to 
RFC7519 On Thu, Nov 12, 2015 at 12:01 PM, Erik Wahlström neXus 
 wrote:Hi Carsten,

Thanks, and I agree. I’ve heard arguments for all three work groups.

Borrowed some of your words to define the content of the draft :)
It’s it essentially a JWT, phrased in and profiled for CBOR to address ACE 
needs, where OAuth needs COSE functionality, for object security.

I’m open for letting the AD’s move it around, but having it right next to JWT 
seems right to me. Also open for the ACE WG. Feel it has less place in COSE for 
the same reasons JWT is not in the JOSE WG.

/ Erik

> On 12 Nov 2015, at 20:45, Carsten Bormann  wrote:
>
> Hi Erik,
>
> having this draft is a good thing.
>
> One thing I'm still wondering is what WG is the best place to progress
> this.  We probably don't need to spend too much time on this because,
> regardless of the WG chosen, the people in another WG can look at it.
> Still, getting this right might provide some efficiencies.
>
> What is the technical content of this draft?  Is it a new token that
> OAuth needs specifically for the new COSE-based applications of OAuth?
> Is it a new token that is specifically there for addressing ACE needs?
> Or is it essentially the same substance as JWT, but phrased in and
> profiled for CBOR?
>
> Depending on the answer, CWT should be done in OAuth, ACE, or COSE.
> (I'd rather hear the answer from the authors than venture a guess myself.)
>
> Grüße, Carsten
>
>
>
> Erik Wahlström ne

Re: [OAUTH-WG] PoP Architecture - IPR Confirmation

[Bill Mills]

Further, not version specific.  I am aware of now IPR related to this document 
in any version. 


 On Tuesday, October 20, 2015 10:01 AM, Bill Mills  
wrote:
   

 I am still aware of no IPR related to 
https://www.ietf.org/id/draft-ietf-oauth-pop-architecture-02.txt 


 On Tuesday, October 20, 2015 12:37 AM, Hannes Tschofenig 
 wrote:
   

 Hi Bill,

sorry to bother you again regarding this IPR issue but when I search
through the OAuth mailing list archive then I cannot find a response
from you to this mail from Kepeng:
http://www.ietf.org/mail-archive/web/oauth/current/msg14980.html

Ciao
Hannes

PS: I only see a single response from you on the list
http://www.ietf.org/mail-archive/web/oauth/current/maillist.html, namely
this email:
http://www.ietf.org/mail-archive/web/oauth/current/msg15002.html

Unfortunately, that mail was a call for IPR confirmation to the
'Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)' specification
(draft-ietf-oauth-proof-of-possession-04) and not to the architecture
draft.

On 10/09/2015 02:55 AM, Bill Mills wrote:
> I responded correctly Thursday.
> 
> 
> 
> On Thursday, October 8, 2015 5:48 PM, Hannes Tschofenig
>  wrote:
> 
> 
> Hi Bill,
> 
> you have unfortunately responded to the wrong mail ;-)
> 
> Please respond to this one:
> http://www.ietf.org/mail-archive/web/oauth/current/msg14980.html
> (which is about the PoP architecture
> ).
> 
> Sorry to bother you with these issues.
> 
> Ciao
> Hannes
> 
> On 09/30/2015 04:10 PM, Bill Mills wrote:
>> I am aware of no IPR issues for this document.
>>
>> Regards,
>>
>> -bill
>>
>>
>>
>> On Wednesday, September 30, 2015 3:53 AM, John Bradley
>> mailto:ve7...@ve7jtb.com>> wrote:
>>
>>
>> I confirm that I know of no IPR that reads on this specification.
>>
>> John Bradley’
>>
>>> On Sep 30, 2015, at 7:03 AM, Kepeng Li  <mailto:kepeng@alibaba-inc.com>
>>> <mailto:kepeng@alibaba-inc.com
> <mailto:kepeng@alibaba-inc.com>>> wrote:
>>>
>>> Hi Mike, John and Hannes,
>>> I am working on the shepherd writeup for the PoP document:
>>> http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04
>>> <https://www.ietf.org/id/draft-ietf-oauth-pop-architecture-02.txt>
>>> One item in the template requires me to indicate whether each document
>>> author has confirmed that any and all appropriate IPR disclosures
>>> required for full conformance with the provisions of BCP 78 and BCP 79
>>> have already been filed. Could you please confirm? Kind Regards
>>> Kepeng
>>>
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org
> <mailto:OAuth@ietf.org>>
> 
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> 
> 


   

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

Re: [OAUTH-WG] PoP Architecture - IPR Confirmation

[Bill Mills]

I am still aware of no IPR related to 
https://www.ietf.org/id/draft-ietf-oauth-pop-architecture-02.txt 


 On Tuesday, October 20, 2015 12:37 AM, Hannes Tschofenig 
 wrote:
   

 Hi Bill,

sorry to bother you again regarding this IPR issue but when I search
through the OAuth mailing list archive then I cannot find a response
from you to this mail from Kepeng:
http://www.ietf.org/mail-archive/web/oauth/current/msg14980.html

Ciao
Hannes

PS: I only see a single response from you on the list
http://www.ietf.org/mail-archive/web/oauth/current/maillist.html, namely
this email:
http://www.ietf.org/mail-archive/web/oauth/current/msg15002.html

Unfortunately, that mail was a call for IPR confirmation to the
'Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)' specification
(draft-ietf-oauth-proof-of-possession-04) and not to the architecture
draft.

On 10/09/2015 02:55 AM, Bill Mills wrote:
> I responded correctly Thursday.
> 
> 
> 
> On Thursday, October 8, 2015 5:48 PM, Hannes Tschofenig
>  wrote:
> 
> 
> Hi Bill,
> 
> you have unfortunately responded to the wrong mail ;-)
> 
> Please respond to this one:
> http://www.ietf.org/mail-archive/web/oauth/current/msg14980.html
> (which is about the PoP architecture
> ).
> 
> Sorry to bother you with these issues.
> 
> Ciao
> Hannes
> 
> On 09/30/2015 04:10 PM, Bill Mills wrote:
>> I am aware of no IPR issues for this document.
>>
>> Regards,
>>
>> -bill
>>
>>
>>
>> On Wednesday, September 30, 2015 3:53 AM, John Bradley
>> mailto:ve7...@ve7jtb.com>> wrote:
>>
>>
>> I confirm that I know of no IPR that reads on this specification.
>>
>> John Bradley’
>>
>>> On Sep 30, 2015, at 7:03 AM, Kepeng Li  <mailto:kepeng@alibaba-inc.com>
>>> <mailto:kepeng@alibaba-inc.com
> <mailto:kepeng@alibaba-inc.com>>> wrote:
>>>
>>> Hi Mike, John and Hannes,
>>> I am working on the shepherd writeup for the PoP document:
>>> http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04
>>> <https://www.ietf.org/id/draft-ietf-oauth-pop-architecture-02.txt>
>>> One item in the template requires me to indicate whether each document
>>> author has confirmed that any and all appropriate IPR disclosures
>>> required for full conformance with the provisions of BCP 78 and BCP 79
>>> have already been filed. Could you please confirm? Kind Regards
>>> Kepeng
>>>
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org
> <mailto:OAuth@ietf.org>>
> 
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> 
> 


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

Re: [OAUTH-WG] Auth Server / Resource Server Coordination

[Bill Mills]

Centralizing the user auth yes, it doesn't even have to be multiple types of RS 
for this to win.  It reduces your attack surface and allows your auth stack to 
be separate from your app stack are two of the good things.  Auth is a 
specialized thing and hard to do right, and pulling it down to a much smaller 
pool of machines than your main application servers lets you more easily see 
and deal with abuse. 


 On Monday, October 12, 2015 9:36 PM, Jim Manico  wrote:
   

 This seems like a reasonable approach. Isn't the whole idea of the auth 
server/resource server separation in OAuth 2.0 so that one auth server can 
govern multiple resource servers?

--
Jim Manico
@Manicode

> On Oct 13, 2015, at 6:13 AM, Ofer Nave  wrote:
> 
> I know the OAuth 2.0 RFC doesn't specify any standards for coordination 
> between the Authorization Server and the Resource Server, as it's generally 
> assumed that both will be owned or operated by the same entity.
> 
> However, I'm building an OAuth 2.0 Auth Server, and I'd like to add a feature 
> to make it easy for other API developers to delegate to me the responsibility 
> of handling the auth grant process and issuing access tokens.
> 
> It seems to me that a simple version of this could be easily done by:
> 
> 1) Defining an Access Token format that contains within it everything a 
> Resource Server will need to validate it and determine the level of access 
> granted (list of scopes, expiration datetime, HMAC signature using a shared 
> secret).
> 
> 2) Providing a means (basic web UI) for Resource Server owners to register a 
> set of scopes for their service, along with user-understandable descriptions 
> of each to display when they arrive at my Authorization Endpoint.
> 
> While I've read the relevant RFCs, I'm new to the OAuth domain, and would 
> appreciate any feedback. Is this a stupid idea?  Is this a good idea, but 
> redundant with another standard I'm not aware of?
> 
> -ofer
> ___
> 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] Auth Server / Resource Server Coordination

[Bill Mills]

You're generally right on track.  The RS needs to understand the token format 
and needs to trust the AS.  You bring in all the "hwo do 2 entities maintain a 
trust relationship in computing thing" here, because the RS needs to trust the 
AS.  You can use a JWT (a common choice) as your token format which makes that 
part fairly easy.  You do have decisions to make on whether you use symmetric 
crypto or PK there. 


 On Monday, October 12, 2015 9:14 PM, Ofer Nave  wrote:
   

 I know the OAuth 2.0 RFC doesn't specify any standards for coordination 
between the Authorization Server and the Resource Server, as it's generally 
assumed that both will be owned or operated by the same entity.

However, I'm building an OAuth 2.0 Auth Server, and I'd like to add a feature 
to make it easy for other API developers to delegate to me the responsibility 
of handling the auth grant process and issuing access tokens.

It seems to me that a simple version of this could be easily done by:

1) Defining an Access Token format that contains within it everything a 
Resource Server will need to validate it and determine the level of access 
granted (list of scopes, expiration datetime, HMAC signature using a shared 
secret).

2) Providing a means (basic web UI) for Resource Server owners to register a 
set of scopes for their service, along with user-understandable descriptions of 
each to display when they arrive at my Authorization Endpoint.

While I've read the relevant RFCs, I'm new to the OAuth domain, and would 
appreciate any feedback. Is this a stupid idea?  Is this a good idea, but 
redundant with another standard I'm not aware of?

-ofer

___
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] PoP document: IPR Confirmation

[Bill Mills]

I am aware of no IPR issues for this document.
Regards,
-bill 


 On Wednesday, September 30, 2015 3:53 AM, John Bradley  
wrote:
   

 I confirm that I know of no IPR that reads on this specification.
John Bradley’

On Sep 30, 2015, at 7:03 AM, Kepeng Li  wrote:
Hi Mike, John and Hannes,I am working on the shepherd writeup for the PoP 
document:http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-04One 
item in the template requires me to indicate whether
each document author has confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.

Could you please confirm?

Kind RegardsKepeng



___
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] Fwd: RFC 7628 on A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth

[Bill Mills]

And thank you Hannes for all the guidance and being a great collaborator on 
this!

And to the WG, chairs, and shepherds, we did something good here.  Thank you 
all for the review, attention, time, and your help as well.

-bill

-Original Message-
From: Mike Jones 
Sent: Tuesday, September 1, 2015 8:44 AM
To: Bill Mills ; Phil Hunt ; 
Hannes Tschofenig 
Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and 
Security Layer (SASL) Mechanisms for OAuth

Congratulations, Bill!

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
Sent: Tuesday, September 01, 2015 8:14 AM
To: Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and 
Security Layer (SASL) Mechanisms for OAuth

+1 !

Phil

> On Aug 31, 2015, at 23:24, Hannes Tschofenig  
> wrote:
> 
> FYI: Thanks to Bill for the hard work!
> 
>  Forwarded Message 
> Subject: RFC 7628 on A Set of Simple Authentication and Security Layer
> (SASL) Mechanisms for OAuth
> Date: Mon, 31 Aug 2015 21:56:17 -0700 (PDT)
> From: rfc-edi...@rfc-editor.org
> Reply-To: i...@ietf.org
> To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
> CC: kit...@ietf.org, drafts-update-...@iana.org, 
> rfc-edi...@rfc-editor.org
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
>RFC 7628
> 
>Title:  A Set of Simple Authentication
>and Security Layer (SASL) Mechanisms
>for OAuth
>Author: W. Mills, T. Showalter, H. Tschofenig
>Status: Standards Track
>Stream: IETF
>Date:   August 2015
>Mailbox:wmills_92...@yahoo.com,
>t...@psaux.com,
>hannes.tschofe...@gmx.net
>Pages:  21
>Characters: 46408
>Updates/Obsoletes/SeeAlso:   None
> 
>I-D Tag:draft-ietf-kitten-sasl-oauth-23.txt
> 
>URL:
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.rfc-editor.org%2finfo%2frfc7628&data=01%7c01%7cMichael.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=J1hIDrCTw8Xi1hMvg3ZaZ1xvdEFhol3BqHt2q6u6VWg%3d
> 
>DOI:
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdx.doi.org%2f10.17487%2fRFC7628&data=01%7c01%7cMichael.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fQVXZSXwbGDS7YVQ446RDFuPUxHNoLLwedzfrx0xKUE%3d
> 
> OAuth enables a third-party application to obtain limited access to a 
> protected resource, either on behalf of a resource owner by 
> orchestrating an approval interaction or by allowing the third-party 
> application to obtain access on its own behalf.
> 
> This document defines how an application client uses credentials 
> obtained via OAuth over the Simple Authentication and Security Layer
> (SASL) to access a protected resource at a resource server.  Thereby, 
> it enables schemes defined within the OAuth framework for 
> non-HTTP-based application protocols.
> 
> Clients typically store the user's long-term credential.  This does, 
> however, lead to significant security vulnerabilities, for example, 
> when such a credential leaks.  A significant benefit of OAuth for 
> usage in those clients is that the password is replaced by a shared 
> secret with higher entropy, i.e., the token.  Tokens typically provide 
> limited access rights and can be managed and revoked separately from 
> the user's long-term password.
> 
> This document is a product of the Common Authentication Technology 
> Next Generation Working Group of the IETF.
> 
> This is now a Proposed Standard.
> 
> STANDARDS TRACK: This document specifies an Internet Standards Track 
> protocol for the Internet community, and requests discussion and 
> suggestions for improvements.  Please refer to the current edition of 
> the Official Internet Protocol Standards 
> (https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.
> rfc-editor.org%2fstandards&data=01%7c01%7cMichael.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7JPZiamj4nhqHgthEPDIzgpqkvR%2fAA6bj4Ck5vijFPU%3d)
>  for the standardization state and status of this protocol.  Distribution of 
> this memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>  
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
> etf.org%2fmailman%2flistinfo%2fietf-announce&data=01%7c01%7cMichael.Jo
> nes%40micro

Re: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth

[Bill Mills]

And thank you Hannes for all the guidance and being agreat collaborator on this!


 
And to the WG, chairs, and shepherds, we did somethinggood here.  Thank you all 
for the review,attention, time, and your help as well.


 
-bill

 


 On Tuesday, September 1, 2015 9:04 AM, Torsten Lodderstedt 
 wrote:
   

 +1

Am 1. September 2015 17:44:12 MESZ, schrieb Mike Jones 
:
Congratulations, Bill!

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
Sent: Tuesday, September 01, 2015 8:14 AM
To: Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and 
Security Layer (SASL) Mechanisms for OAuth

+1 !

Phil


 On Aug 31, 2015, at 23:24, Hannes Tschofenig  wrote:
 
 FYI: Thanks to Bill for the hard work!
 
  Forwarded Message 
 Subject: RFC 7628 on A Set of Simple Authentication and Security Layer
 (SASL) Mechanisms for OAuth
 Date: Mon, 31 Aug 2015 21:56:17 -0700 (PDT)
 From: rfc-edi...@rfc-editor.org
 Reply-To: i...@ietf.org
 To: ietf-annou...@ietf.org,rfc-d...@rfc-editor.org
 CC: kit...@ietf.org, drafts-update-...@iana.org, 
 rfc-edi...@rfc-editor.org
 
 A new Request for Comments is now available in online RFC libraries.
 
 
 RFC 7628
 
 Title: A Set of Simple Authentication
 and Security Layer (SASL) Mechanisms
 for OAuth
 Author: W. Mills, T. Showalter, H. Tschofenig
 Status: Standards Track
 Stream: IETF
 Date: August 2015
 Mailbox: wmills_92...@yahoo.com,
 t...@psaux.com,
 hannes.tschofe...@gmx.net
 Pages: 21
 Characters: 46408
 Updates/Obsoletes/SeeAlso: None
 
 I-D Tag: draft-ietf-kitten-sasl-oauth-23.txt
 
 URL: 
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.rfc-editor.org%2finfo%2frfc7628&data=01%7c01%7cMichael.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=J1hIDrCTw8Xi1hMvg3ZaZ1xvdEFhol3BqHt2q6u6VWg%3d
 
 DOI: 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdx.doi.org%2f10.17487%2fRFC7628&data=01%7c01%7cMichael.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fQVXZSXwbGDS7YVQ446RDFuPUxHNoLLwedzfrx0xKUE%3d
 
 OAuth enables a third-party application to obtain limited access to a 
 protected resource, either on behalf of a resource owner by 
 orchestrating an approval interaction or by allowing the third-party 
 application to obtain access on its own behalf.
 
 This document defines how an application client uses credentials 
 obtained via OAuth over the Simple Authentication and SecurityLayer
 (SASL) to access a protected resource at a resource server. Thereby, 
 it enables schemes defined within the OAuth framework for 
 non-HTTP-based application protocols.
 
 Clients typically store the user's long-term credential. This does, 
 however, lead to significant security vulnerabilities, for example, 
 when such a credential leaks. A significant benefit of OAuth for 
 usage in those clients is that the password is replaced by a shared 
 secret with higher entropy, i.e., the token. Tokens typically provide 
 limited access rights and can be managed and revoked separately from 
 the user's long-term password.
 
 This document is a product of the Common Authentication Technology 
 Next Generation Working Group of the IETF.
 
 This is now a Proposed Standard.
 
 STANDARDS TRACK: This document specifies an Internet Standards Track 
 protocol for the Internet community, andrequests discussion and 
 suggestions for improvements. Please refer to the current edition of 
 the Official Internet Protocol Standards 
 (https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.
 
rfc-editor.org%2fstandards&data=01%7c01%7cMichael.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7JPZiamj4nhqHgthEPDIzgpqkvR%2fAA6bj4Ck5vijFPU%3d)
 for the standardization state and status of this protocol. Distribution of 
this memo is unlimited.
 
 This announcement is sent to the IETF-Announce and rfc-dist lists.
 To subscribe or unsubscribe, see
 
 https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
 etf.org%2fmailman%2flistinfo%2fietf-announce&data=01%7c01%7cMichael.Jo
 nes%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f14
 1af91ab2d7cd011db47%7c1&sdata=aGciLH4fsxKJ6MUO%2fPp6BMj3JFJ37oTjdaSJ5t
 WbEkg%3d 
 https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmailm
 an.rfc-editor.org%2fmailman%2flistinfo%2frfc-dist&data=01%7c01%7cMicha
 el.Jones%40microsoft.com%7c9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf
 86f141af91ab2d7cd011db47%7c1&sdata=agec9juMh0Zzn1mrY6avpBrLPlFfCs8zsyx
 8bSLgDdc%3d
 
 For searching the RFC series, see 
 https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.r
 fc-editor.org%2fsearch&data=01%7c01%7cMichael.Jones%40microsoft.com%7c
 9f19ef0544aa4990d83f08d2b2dff4a3%7c72f988bf86f141af91ab2d7cd011db47%7c
 1&sdata=veVw3wrA9Wz6CWTUfVT

Re: [OAUTH-WG] Lifetime of refresh token

[Bill Mills]

You don't need to put an expiration on the refresh token.  You get to see that 
refresh token every 5 minutes anyway.  If you ever want to force the client to 
re-auth just use policy on the AS.  Nothing will be broken with what you are 
doing though. 


 On Friday, August 28, 2015 7:21 AM, Donghwan Kim 
 wrote:
   

 I'm sorry to introduce a common topic.
As John has suggested, I'm going to design that 
* An access token should be short lived e.g. 5 minutes (not to hit the AS to 
verify the token or 1 hour (to hit the AS to verify the token). I'm inclined to 
5 minutes for stateless architecture of RSs.* A refresh token should have 1 
month of expiration time by default. If it turns out that some access token 
expired, its refresh token should refresh the token. Then, so called persistent 
login can be implemented regardless of the form of authentication. Only if it 
fails for some reason e.g. token revocation or inactivity for 1 month, a user 
is logged out automatically and should log in again.* A refresh token should be 
able to be revoked somehow. With 5 minutes approach, it will invalidate only 
the refresh token (Yes the attacker can have 5 minutes at most), and with 1 
hour approach, it will invalidate the refresh token as well as the 
corresponding access token.

Thanks,

-- Donghwan
On Fri, Aug 28, 2015 at 5:43 PM, Torsten Lodderstedt  
wrote:

Refresh tokens are also used by public clients, e.g. native apps. OIDC allows 
to acquire a new id token from a refresh token as well. Note: this does not 
mean a fresh authentication but a refreshed id token containing the data of the 
original authentication transaction. 

Am 24. August 2015 17:08:21 MESZ, schrieb John Bradley :
I think Nat’s diagram about the problems of doing pseudo authentication with 
OAuth is being taken out of context.
The refresh token dosen’t expire, it is revoked by the user or system.  In some 
cases refresh tokens are automatically revoked if the users session to the AS 
ends.  I think AOL typically revokes refresh tokens when sessions terminate.
OpenID Connect provides a separate id_token with a independent lifetime from 
the refresh token.  A client may keep a refresh token for a much longer time 
than the user has a login session with the AS.
Refresh tokens are typically used by confidential clients that are using a 
client secret in combination with the refresh token for getting a new access 
token.
By design access tokens should be short lived as the AS isexpected to have a 
way of revoking refresh tokens but not access tokens.A access token that 
dosen't expire , and can’t be revoked is not a good idea.
John B.


On Aug 24, 2015, at 2:41 AM, Donghwan Kim  wrote:
Hi,

According to Figure 2 from http://tools.ietf.org/html/rfc6749#section-1.5, 
refresh token can be used to refresh an expired access token without requesting 
resource owner to sign in again (uncomfortable experience). However, if it's 
true,isn't it that refresh token might be used to request a new access token 
even years later? and then isn't refresh token the same with access token which 
never expires?
I intended to use refresh token to implement persistent login by sending a 
refresh request before issued access token expires (expires_in runs out). But 
if refresh token works even if access token expired already, sending a refresh 
request on application start up would be enough.
So I'm not sure what I'm missing about refresh token as well as how to 
implement persistent login using it (you can regard authentication here 
pseudo-authentication illustrated in 
https://upload.wikimedia.org/wikipedia/commons/3/32/OpenIDvs.Pseudo-AuthenticationusingOAuth.svg).
 What is the lifetime of refreshtoken?
Thanks,
-- Donghwan___
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] Lifetime of refresh token

[Bill Mills]

You could have a refresh token that never expires.  Having to use the refresh 
token to get a new access token gives you a single control point to allow 
checking whether that refresh token should still be valid.  Means the RS 
doesn't have to do that stuff. 


 On Monday, August 24, 2015 8:09 AM, John Bradley  wrote:
   

 I think Nat’s diagram about the problems of doing pseudo authentication with 
OAuth is being taken out of context.
The refresh token dosen’t expire, it is revoked by the user or system.  In some 
cases refresh tokens are automatically revoked if the users session to the AS 
ends.  I think AOL typically revokes refresh tokens when sessions terminate.
OpenID Connect provides a separate id_token with a independent lifetime from 
the refresh token.  A client may keep a refresh token for a much longer time 
than the user has a login session with the AS.
Refresh tokens are typically used by confidential clients that are using a 
client secret in combination with the refresh token for getting a new access 
token.
By design access tokens should be short lived as the AS is expected to have a 
way of revoking refresh tokens but not access tokens.A access token that 
dosen't expire , and can’t be revoked is not a good idea.
John B.


On Aug 24, 2015, at 2:41 AM, Donghwan Kim  wrote:
Hi,

According to Figure 2 from http://tools.ietf.org/html/rfc6749#section-1.5, 
refresh token can be used to refresh an expired access token without requesting 
resource owner to sign in again (uncomfortable experience). However, if it's 
true, isn't it that refresh token might be used to request a new access token 
even years later? and then isn't refresh token the same with access token which 
never expires?
I intended to use refresh token to implement persistent login by sending a 
refresh request before issued access token expires (expires_in runs out). But 
if refresh token works even if access token expired already, sending a refresh 
request on application start up would be enough.
So I'm not sure what I'm missing about refresh token as well as how to 
implement persistent login using it (you can regard authentication here 
pseudo-authentication illustrated in 
https://upload.wikimedia.org/wikipedia/commons/3/32/OpenIDvs.Pseudo-AuthenticationusingOAuth.svg).
 What is the lifetime of refresh token?
Thanks,
-- Donghwan___
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] Is it allow to add custom attribute to access token response?

[Bill Mills]

And as John said, if you are doing user authentication use OpenID instead. 


 On Friday, August 21, 2015 9:38 AM, John Bradley  wrote:
   

 Yes going the unregistered route it is probably best to use a name in you 
namespace eg “com.example:username”.


On Aug 21, 2015, at 1:34 PM, William Denniss  wrote:
You can add additional parameters.
"The client MUST ignore unrecognized value names in the response" is there so 
that other clients who don't understand your parameters will ignore them. That 
line basically enables the behavior you wanted (if it said the client must 
*error* on unrecognized values, that would be a problem).

It would be best if you tried to name your params to be hardened against 
collision with any future extensions to OAuth/OpenID Connect (e.g., adding a 
vendor prefix)
On Thu, Aug 20, 2015 at 7:15 AM, Donghwan Kim  
wrote:

Hi,

I would like to add a custom property representing the account who just 
authenticated to the access token response for the sake of convenience like 
login request's response. Then, an exchange of request and response will look 
like this:

POST /tokens HTTP/1.1Host: api.example.comContent-Type: application/json
{"grant_type":"password","username":"${username}","password":"${password}"}


HTTP/1.1 200 OKContent-Type: application/jsonCache-Control: no-storePragma: 
no-cache
{  "access_token":"${JSON web token}",  "token_type":"Bearer",  "account": 
{"username":"donghwan", ...}}

However http://tools.ietf.org/html/rfc6749#section-5.1 says that
> The client MUST ignore unrecognized value names in the response.
Does it mean that I shouldn't add such property, 'account'? Though, I saw 
Instagram API adds such custom property to access token response for the same 
purpose from https://instagram.com/developer/authentication/ (Please find 
'snoopdogg' to see that token response.) If it's not allowed or desirable, how 
should I add such information to the access token response?
BTW, I have some questions on usage of JSON web token with OAuth. Can I post 
them here? If not, where should I do that?
Thanks,

-- Donghawn
___
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] Is it allow to add custom attribute to access token response?

[Bill Mills]

You can do your own extension in your own app, just don't expect anyone else to 
use it.   Not understanding why you want this though, because you already had a 
username in the request so the client should know.
Take a look at the Token Introspection stuff, it might solve this for you a 
different way if I am guessing right on what you're trying to do. 


 On Friday, August 21, 2015 8:43 AM, Donghwan Kim 
 wrote:
   

 Hi,

I would like to add a custom property representing the account who just 
authenticated to the access token response for the sake of convenience like 
login request's response. Then, an exchange of request and response will look 
like this:

POST /tokens HTTP/1.1Host: api.example.comContent-Type: application/json
{"grant_type":"password","username":"${username}","password":"${password}"}


HTTP/1.1 200 OKContent-Type: application/jsonCache-Control: no-storePragma: 
no-cache
{  "access_token":"${JSON web token}",  "token_type":"Bearer",  "account": 
{"username":"donghwan", ...}}

However http://tools.ietf.org/html/rfc6749#section-5.1 says that
> The client MUST ignore unrecognized value names in the response.
Does it mean that I shouldn't add such property, 'account'? Though, I saw 
Instagram API adds such custom property to access token response for the same 
purpose from https://instagram.com/developer/authentication/ (Please find 
'snoopdogg' to see that token response.) If it's not allowed or desirable, how 
should I add such information to the access token response?
BTW, I have some questions on usage of JSON web token with OAuth. Can I post 
them here? If not, where should I do that?
Thanks,

-- Donghawn
___
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 about usage of OAuth between servers

[Bill Mills]

Using Bearer tokens with refresh tokens is a valid use case for 
server-to-server and has the same nice properties that is does for users, in 
that it applies a single control point for revoking access.  Using Bearer 
tokens has very different security properties than OAuth 1.0a and you should 
carefully consider this.  Look at the proof-of-posession work rather than 
simple Bearer tokens. 


 On Thursday, July 2, 2015 9:10 AM, Lisa Li1  wrote:
   

 Hi All  
This is Lisa. Our project is adopting OAuth 2 as authentication specification. 
For the client-server communication, OAuth token works fine. But we have some 
cases of server to server communication, usually it will be multiple tasks 
running in parallel or sequence or even in multiple threads. In this case, we 
are not sure we should reuse the access token grant by end user or create 
another token? Moreover, if token is expired in 30 min, we are able to do 
refresh but may meet some issue on the token consistency between each task, 
thus it might be refreshed again and again…  But with OAuth 1.0, since it will 
not expired and we don’t have to do refresh, it will work fine.  So for OAuth 
2.0, what’s your consideration for server to server communication scenario? Or 
do you have any suggestion here?  Thanks.    Lisa LiPrincipal Software 
EngineerSymantec Corporation  Office: (010) 6272 5127  /  Mobile: 189 1057 
2219lisa_...@symantec.com      This message (including any attachments) is 
intended only for the use of the individual or entity to which it is addressed 
and may contain information that is non-public, proprietary, privileged, 
confidential, and exempt from disclosure under applicable law or may constitute 
as attorney work product. If you are not the intended recipient, you are hereby 
notified that any use, dissemination, distribution, or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, notify us immediately by telephone and (i) destroy this message if a 
facsimile or (ii) delete this message immediately if this is an electronic 
communication.  
___
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] XARA vulnerability Paper and PKCE

[Bill Mills]

There are other bits of sensitive info that might pass via redirect and be 
intercepted due to the scheme handler insecurity.  It's not just OAuth or other 
such tokens, although they are significant. 


 On Thursday, June 18, 2015 10:25 AM, John Bradley  
wrote:
   

 Passing the FB token between apps on the device is not a real use of the 
implicit flow, Facebook may be reusing the pattern in an insecure way.
The NAPPS WG at the OIDF recognized that was insecure a long time ago.  We are 
looking to use the S256 pkce transform to secure similar sorts of on device 
communication of code between a Oauth proxy on the device and a app.
John B.

On Jun 18, 2015, at 12:25 PM, Nat Sakimura  wrote:
Yup. Obviously, PKCE is for Code Flow and do not deal with Implicit flow. The 
best bet probably is stop using Implicit flow for passing tokens around among 
apps, unless token is capable of being sender confirmed. 
Nat
2015-06-18 23:47 GMT+09:00 Bill Mills :

PKCE solves a subset of this, but not the general case.  It doesn't solve the 
FB example in the paper where the FB token is passed between apps locally.
It is a clear win for the OAuth code flow for example though. 


 On Thursday, June 18, 2015 7:31 AM, Nat Sakimura  
wrote:
   

 Hi OAuthers: 
XARA (Cross App Resource Access) paper was gaining interest here in Japan today 
because of the Register article[1]. I went over the attack description in the 
full paper [2]. 
The paper presents four kinds of vulnerabilities.   
   - Password Stealing (Keychain)   

   - Container Cracking (BundleID check bug on the part of Apple App Store)   

   - IPC Interception (a. WebSocket non-authentication, and b. local oauth 
redirect)    

   - Scheme Hijacking
Of those, 3.b and 4 are relevant to us, and we kind of knew them all the way 
through. 
These are the target attack that PKCE specifically wants to address, and does 
address, I believe. 

[1] 
http://www.theregister.co.uk/2015/06/17/apple_hosed_boffins_drop_0day_mac_ios_research_blitzkrieg/[2]
 https://sites.google.com/site/xaraflaws/



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


   



-- 
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] XARA vulnerability Paper and PKCE

[Bill Mills]

PKCE solves a subset of this, but not the general case.  It doesn't solve the 
FB example in the paper where the FB token is passed between apps locally.
It is a clear win for the OAuth code flow for example though. 


 On Thursday, June 18, 2015 7:31 AM, Nat Sakimura  
wrote:
   

 Hi OAuthers: 
XARA (Cross App Resource Access) paper was gaining interest here in Japan today 
because of the Register article[1]. I went over the attack description in the 
full paper [2]. 
The paper presents four kinds of vulnerabilities.   
   - Password Stealing (Keychain)   

   - Container Cracking (BundleID check bug on the part of Apple App Store)   

   - IPC Interception (a. WebSocket non-authentication, and b. local oauth 
redirect)    

   - Scheme Hijacking
Of those, 3.b and 4 are relevant to us, and we kind of knew them all the way 
through. 
These are the target attack that PKCE specifically wants to address, and does 
address, I believe. 

[1] 
http://www.theregister.co.uk/2015/06/17/apple_hosed_boffins_drop_0day_mac_ios_research_blitzkrieg/[2]
 https://sites.google.com/site/xaraflaws/



-- 
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] redircet_uri matching algorithm

[Bill Mills]

+1 


 On Thursday, May 21, 2015 12:29 PM, Mike Jones 
 wrote:
   

 +1

I vehemently concur that that working group should stay completely clear of 
facilitating this insecure practice.

                -- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Antonio Sanso
Sent: Thursday, May 21, 2015 12:41 AM
To: John Bradley
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] redircet_uri matching algorithm


On May 21, 2015, at 4:35 AM, John Bradley  wrote:

> I think the correct answer is that clients should always assume exact 
> redirect_uri matching, and servers should always enforce it.  
> 
> Anything else is asking for trouble.

FWIW I completely agree with John here...

regards

antonio


> 
> If clients need to maintain some state the correct thing to do is use the 
> state parameter, and not append extra path or query elements to there 
> redirect_uri.
> 
> A significant number of security problems in the wild come from servers not 
> enforcing this.
> 
> I may be taking an excessively hard line, but partial matching is not 
> something we should be encouraging by making easier.
> 
> I did do a draft on a way to safely use state 
> https://tools.ietf.org/id/draft-bradley-oauth-jwt-encoded-state-04.txt
> 
> John B.
> 
> 
>> On May 16, 2015, at 4:43 AM, Patrick Gansterer  wrote:
>> 
>> "OAuth 2.0 Dynamic Client Registration Protocol" [1] is nearly finished and 
>> provides the possibility to register additional "Client Metadata".
>> 
>> OAuth 2.0 does not define any matching algorithm for the redirect_uris. The 
>> latest information on that topic I could find is [1], which is 5 years old. 
>> Is there any more recent discussion about it?
>> 
>> I'd suggest to add an OPTIONAL "redirect_uris_matching_method" client 
>> metadata. Possible valid values could be:
>> * "exact": The "redirect_uri" provided in a redirect-based flow must match 
>> exactly one of of the provided strings in the "redirect_uris" array.
>> * "prefix": The "redirect_uri" must begin with one of the "redirect_uris". 
>> (e.g. "http://example.com/path/subpath"; would be valid with 
>> ["http://example.com/path/";, "http://example.com/otherpath/";])
>> * "regex": The provided "redirect_uris" are threatened as regular 
>> expressions, which the "redirect_uri" will be matched against. (e.g. 
>> "http://subdomain.example.com/path5/"; would be valid with 
>> ["^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/"]
>> 
>> If not defined the server can choose any supported method, so we do not 
>> break existing implementations. On the other side it allows an client to 
>> make sure that a server supports a specific matching algorithm required by 
>> the client. ATM a client has no possibility to know how a server handles the 
>> redirect_uris.
>> 
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29
>> [2] http://www.ietf.org/mail-archive/web/oauth/current/msg02617.html
>> 
>> --
>> Patrick Gansterer
>> 
>> ___
>> 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] JWT binding for OAuth 2.0

[Bill Mills]

Yes, Microsoft supports this on Hotmail/Outlook.com and the Outlook client 
supports it. 


 On Tuesday, April 14, 2015 2:42 PM, John Bradley  wrote:
   

 There is a OAuth binding to SASL 
https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19
Google supports it for IMAP/SMTP,  I think the latest iOS and OSX mail client 
updates use it rather than passwords for Google.I also noticed Outlook on 
Android using it.
The access token might be a signed or encrypted JWT itself.  I don’t know that 
wrapping it again necessarily helps.
Yes we should have bindings to other non http protocols.  
Is there something specific that you are looking for that is not covered by 
SASL?
John B.



On Apr 14, 2015, at 6:21 PM, Prabath Siriwardena  wrote:
At the moment we only HTTP binding to transport the access token (please 
correct me if not)..
This creates a dependency on the transport.
How about creating a JWT binding for OAuth 2.0..? We can transport the access 
token as an encrypted JWT header parameter..?


Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : +1 650 625 7950

http://blog.facilelogin.com
http://blog.api-security.org___
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

[Bill Mills]

s equal to the scope originally granted by the resource 
owner.  The authorization server MAY issue a new refresh token, in which case 
the client MUST discard the old refresh token and replace it with the new 
refresh token.  The authorization server MAY revoke the old refresh token after 
issuing a new refresh token to the client.  If a new refresh token is issued, 
the refresh scope MUST be identical to that of the refresh token included by 
the client in the request.  Since the RS is attempting to obtain a new AT, what 
happens to the old AT that was submitted as a refresh_token, should the AS 
issue a new refresh_token, which it is allowed to do as stated above?  Since 
this was really an AT, doesn’t this mean the RS and issuing AS will be required 
to REVOKE the AT?  If the AS is not the AS that issued the original AT and 
there is no scope= value in the request, how does it ensure the request isn’t 
asking for more access than was granted by the granting AS?  Best 
regards,DonDonald F. CoffinFounder/CTO  REMI Networks2335 Dunwoody Crossing 
Suite EDunwoody, GA 30338-8221  Phone:  (949) 636-8571Email:   
donald.cof...@reminetworks.com  From: Bill Mills 
[mailto:wmills_92...@yahoo.com] 
Sent: Thursday, March 26, 2015 6:04 PM
To: Bill Mills; Donald F. Coffin; 'Phil Hunt'
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Token Chaining Use Case    Again, I don't think 
requiring a call out to an internal token reissuer is a general solution.  That 
said...  The RS calls the token endpoint treating the AT as a refresh token in 
all cases and using the refresh_token grant type.  Desired scope is specified 
by the RS.  It's not in spec if there are derivative internal scopes not in the 
original scope list though.  This doesn't support internal scopes for 
partitioning that the AS doesn't know about.  An internal AS providing chaining 
would need to understand the AT just as the RS does, and treat it as a refresh 
token.  -bill  On Thursday, March 26, 2015 2:22 PM, Donald F. Coffin 
 wrote:  Bill, Can you clarify your thoughts on 
the following: · What AS endpoint does the RS call and how does it 
present the AT he received?· What is the grant_type value the RS use in 
the above endpoint request?· What does the AS do if the AT was issued 
by another AS (which is possible using Justin’s use case)? Best 
regards,DonDonald F. CoffinFounder/CTO REMI Networks2335 Dunwoody Crossing 
Suite EDunwoody, GA 30338-8221 Phone:  (949) 636-8571Email:   
donald.cof...@reminetworks.com From: Bill Mills [mailto:wmills_92...@yahoo.com] 
Sent: Thursday, March 26, 2015 5:13 PM
To: Donald F. Coffin; 'Phil Hunt'
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Token Chaining Use Case The RS calling back to the AS 
won't be confused, the token it gets would be it's refresh token.  I don't see 
any reason why the AS can't be smart enough to know that a token that looks 
like an access token it issued is usable as a refresh token for limited 
purposes or downscoping.    On Thursday, March 26, 2015 1:46 PM, Donald F. 
Coffin  wrote: -1 Although  Justin’s point 
might be a bit pre-mature as far as a standards discussion, the more critical 
reason IMHO is calling the AS’s /Token endpoint with a grant_type of 
“refresh_token” but providing an issued AT rather than an issued refresh_token 
(RT) will definitely create a backwards compatibility issue for many 
implementations. Best regards,DonDonald F. CoffinFounder/CTO REMI Networks2335 
Dunwoody Crossing Suite EDunwoody, GA 30338-8221 Phone:  (949) 
636-8571Email:   donald.cof...@reminetworks.com From: Phil Hunt 
[mailto:phil.h...@oracle.com] 
Sent: Thursday, March 26, 2015 4:22 PM
To: Bill Mills
Cc: 
Subject: Re: [OAUTH-WG] Token Chaining Use Case +1. We all have to change 
production code when non final specs evolve.  I particularly don't see this as 
a valid argument at the start of a standards discussion. 
Phil
On Mar 26, 2015, at 15:13, Bill Mills  wrote:
By definition an access token is becoming a form of refresh token.    The 
"because my implementation didn't do it that way" isn't convincing me.  On 
Thursday, March 26, 2015 12:44 PM, Justin Richer  wrote: 
Because many implementations (including mine which does support my old token 
chaining draft) treat access tokens and refresh tokens separately in terms of 
data store and structure. Additionally, the refresh token is tied to the client 
and presented by the client. But in this case it's someone downstream, an RS, 
presenting the token. So unlike a refresh token being presented by the one it 
was issued to, this token is being presented by someone it was presented to.  
The feeling is close, but not quite the same in either development or 
assumptions. -- Justin / Sent from my phone /

 Original message 
From: Bill Mills  
Date: 03/26/2015 2:24 PM (GMT-06:00) 
To: Justin Richer , "&quo

Re: [OAUTH-WG] Token Chaining Use Case

[Bill Mills]

Again, I don't think requiring a call out to an internal token reissuer is a 
general solution.  That said...
The RS calls the token endpoint treating the AT as a refresh token in all cases 
and using the refresh_token grant type.  Desired scope is specified by the RS.  
It's not in spec if there are derivative internal scopes not in the original 
scope list though.  This doesn't support internal scopes for partitioning that 
the AS doesn't know about. 
An internal AS providing chaining would need to understand the AT just as the 
RS does, and treat it as a refresh token.
-bill
 On Thursday, March 26, 2015 2:22 PM, Donald F. Coffin 
 wrote:
   

 #yiv8232628268 -- filtered {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 
4;}#yiv8232628268 filtered {font-family:Wingdings;panose-1:5 0 0 0 0 0 0 0 0 
0;}#yiv8232628268 filtered {panose-1:2 4 5 3 5 4 6 3 2 4;}#yiv8232628268 
filtered {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv8232628268 
filtered {font-family:Cambria;panose-1:2 4 5 3 5 4 6 3 2 4;}#yiv8232628268 
filtered {panose-1:3 6 8 2 4 4 6 7 3 4;}#yiv8232628268 
p.yiv8232628268MsoNormal, #yiv8232628268 li.yiv8232628268MsoNormal, 
#yiv8232628268 div.yiv8232628268MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv8232628268 a:link, 
#yiv8232628268 span.yiv8232628268MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv8232628268 a:visited, #yiv8232628268 
span.yiv8232628268MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv8232628268 
p.yiv8232628268MsoListParagraph, #yiv8232628268 
li.yiv8232628268MsoListParagraph, #yiv8232628268 
div.yiv8232628268MsoListParagraph 
{margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv8232628268
 p.yiv8232628268msonormal, #yiv8232628268 li.yiv8232628268msonormal, 
#yiv8232628268 div.yiv8232628268msonormal 
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv8232628268 
p.yiv8232628268msochpdefault, #yiv8232628268 li.yiv8232628268msochpdefault, 
#yiv8232628268 div.yiv8232628268msochpdefault 
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv8232628268 
span.yiv8232628268msohyperlink {}#yiv8232628268 
span.yiv8232628268msohyperlinkfollowed {}#yiv8232628268 
span.yiv8232628268emailstyle17 {}#yiv8232628268 p.yiv8232628268msonormal1, 
#yiv8232628268 li.yiv8232628268msonormal1, #yiv8232628268 
div.yiv8232628268msonormal1 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv8232628268 
span.yiv8232628268msohyperlink1 
{color:blue;text-decoration:underline;}#yiv8232628268 
span.yiv8232628268msohyperlinkfollowed1 
{color:purple;text-decoration:underline;}#yiv8232628268 
span.yiv8232628268emailstyle171 
{color:windowtext;font-weight:normal;font-style:normal;text-decoration:none 
none;}#yiv8232628268 p.yiv8232628268msochpdefault1, #yiv8232628268 
li.yiv8232628268msochpdefault1, #yiv8232628268 div.yiv8232628268msochpdefault1 
{margin-right:0in;margin-left:0in;font-size:10.0pt;}#yiv8232628268 
span.yiv8232628268EmailStyle27 
{color:windowtext;font-weight:normal;font-style:normal;text-decoration:none 
none;}#yiv8232628268 .yiv8232628268MsoChpDefault 
{font-size:10.0pt;}#yiv8232628268 filtered {margin:1.0in 1.0in 1.0in 
1.0in;}#yiv8232628268 div.yiv8232628268WordSection1 {}#yiv8232628268 filtered 
{}#yiv8232628268 filtered {font-family:Symbol;}#yiv8232628268 filtered 
{}#yiv8232628268 filtered {font-family:Wingdings;}#yiv8232628268 filtered 
{font-family:Symbol;}#yiv8232628268 filtered {}#yiv8232628268 filtered 
{font-family:Wingdings;}#yiv8232628268 filtered 
{font-family:Symbol;}#yiv8232628268 filtered {}#yiv8232628268 filtered 
{font-family:Wingdings;}#yiv8232628268 ol {margin-bottom:0in;}#yiv8232628268 ul 
{margin-bottom:0in;}#yiv8232628268 Bill,  Can you clarify your thoughts on the 
following:  · What AS endpoint does the RS call and how does it present 
the AT he received?

· What is the grant_type value the RS use in the above endpoint request?

· What does the AS do if the AT was issued by another AS (which is 
possible using Justin’s use case)?  Best regards,DonDonald F. CoffinFounder/CTO 
 REMI Networks2335 Dunwoody Crossing Suite EDunwoody, GA 30338-8221  Phone: 
 (949) 636-8571Email:   donald.cof...@reminetworks.com  From: Bill Mills 
[mailto:wmills_92...@yahoo.com] 
Sent: Thursday, March 26, 2015 5:13 PM
To: Donald F. Coffin; 'Phil Hunt'
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Token Chaining Use Case  The RS calling back to the AS 
won't be confused, the token it gets would be it's refresh token.  I don't see 
any reason why the AS can't be smart enough to know that a token that looks 
like an access token it issued is usable as a refresh token for limited 
purposes or downscoping.      On Thursday, March 26, 2015 1:46 PM, Donald F. 
Coffin  wrote:  -1 Although  Justin’s point 
might be a bit pre-mature as far as a standards discussion, the more critical 
reas

Re: [OAUTH-WG] Token Chaining Use Case

[Bill Mills]

The RS calling back to the AS won't be confused, the token it gets would be 
it's refresh token.  I don't see any reason why the AS can't be smart enough to 
know that a token that looks like an access token it issued is usable as a 
refresh token for limited purposes or downscoping.  


 On Thursday, March 26, 2015 1:46 PM, Donald F. Coffin 
 wrote:
   

 #yiv0625374937 #yiv0625374937 -- _filtered #yiv0625374937 
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv0625374937 
{panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv0625374937 
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv0625374937 
{font-family:Cambria;panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv0625374937 
{panose-1:3 6 8 2 4 4 6 7 3 4;}#yiv0625374937 #yiv0625374937 
p.yiv0625374937MsoNormal, #yiv0625374937 li.yiv0625374937MsoNormal, 
#yiv0625374937 div.yiv0625374937MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv0625374937 a:link, 
#yiv0625374937 span.yiv0625374937MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv0625374937 a:visited, #yiv0625374937 
span.yiv0625374937MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv0625374937 
span.yiv0625374937EmailStyle17 
{color:windowtext;font-weight:normal;font-style:normal;text-decoration:none 
none;}#yiv0625374937 .yiv0625374937MsoChpDefault {font-size:10.0pt;} _filtered 
#yiv0625374937 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv0625374937 
div.yiv0625374937WordSection1 {}#yiv0625374937 -1  Although  Justin’s point 
might be a bit pre-mature as far as a standards discussion, the more critical 
reason IMHO is calling the AS’s /Token endpoint with a grant_type of 
“refresh_token” but providing an issued AT rather than an issued refresh_token 
(RT) will definitely create a backwards compatibility issue for many 
implementations.  Best regards,DonDonald F. CoffinFounder/CTO  REMI 
Networks2335 Dunwoody Crossing Suite EDunwoody, GA 30338-8221  Phone:  
(949) 636-8571Email:   donald.cof...@reminetworks.com  From: Phil Hunt 
[mailto:phil.h...@oracle.com] 
Sent: Thursday, March 26, 2015 4:22 PM
To: Bill Mills
Cc: 
Subject: Re: [OAUTH-WG] Token Chaining Use Case  +1. We all have to change 
production code when non final specs evolve.   I particularly don't see this as 
a valid argument at the start of a standards discussion. 
Phil
On Mar 26, 2015, at 15:13, Bill Mills  wrote:
By definition an access token is becoming a form of refresh token.    The 
"because my implementation didn't do it that way" isn't convincing me.    On 
Thursday, March 26, 2015 12:44 PM, Justin Richer  wrote:  
Because many implementations (including mine which does support my old token 
chaining draft) treat access tokens and refresh tokens separately in terms of 
data store and structure. Additionally, the refresh token is tied to the client 
and presented by the client. But in this case it's someone downstream, an RS, 
presenting the token. So unlike a refresh token being presented by the one it 
was issued to, this token is being presented by someone it was presented to.   
The feeling is close, but not quite the same in either development or 
assumptions.  -- Justin  / Sent from my phone /

---- Original message 
From: Bill Mills  
Date: 03/26/2015 2:24 PM (GMT-06:00) 
To: Justin Richer , ""  
Subject: Re: [OAUTH-WG] Token Chaining Use Case So why can't the access tokne 
simply be re-used as a refresh token?  Why would it need a new grant type at 
all?      On Thursday, March 26, 2015 11:31 AM, 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 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 wel

Re: [OAUTH-WG] Token Chaining Use Case

[Bill Mills]

Requiring a round trip to the AS is going to have a huge headwind for 
implementation in high performance environments.
I think we need to pursue something like what Phil is talking about where the 
intermediary server has it's own credential or authority.  


 On Thursday, March 26, 2015 1:25 PM, Phil Hunt  
wrote:
   

 See below

Phil

> On Mar 26, 2015, at 15:15, Justin Richer  wrote:
> 
> Your service layout will determine whether or not each bit calls the same AS 
> that issued the original token, since you can easily do it across boundaries 
> if your AS takes in cross domain tokens. That’s another benefit of having it 
> be a generic token swap, you can build it out using the same mechanism and 
> get both behaviors.
> 
> The AS could reject the swap for any number of conditions: wrong client 
> asked, token is expired, scopes don’t align, bad token, etc.
> 
> You can always optimize your system such that you just send a high-powered 
> token down the chain, in which case you’re not using token swapping. This is 
> not for those cases, obviously. This is for the cases when you *are* doing 
> token swapping and usually downscoping the privileges.

There is no high power token in my new proposal. Each server must act on its 
own authority with its own token. The original at is passed as evidence of 
scoped authority to the internal services. 

There is no super token. 

> 
> — Justin
> 
>> On Mar 26, 2015, at 2:53 PM, Phil Hunt  wrote:
>> 
>> What if A calls be with it’s own authorization token (server token ST1) and 
>> passes AT1 in another header e.g. on-behalf-of.
>> 
>> You save a call and can still check the scope downstream. Further, service B 
>> and C can each check whether ST1 and ST2 had the right to wield AT1 even 
>> when AT1’s POP proof is a proof of the external client.
>> 
>> The only reason I can think to call the AS is if there is some dynamic 
>> condition that might cause an AS to reject the swap.  If AT1 is valid, I 
>> can’t think of another reason why the answer isn’t already YES for all 
>> calls. If its no, its likely a permanent configuration problem not a dynamic 
>> decision.  In other words, B always expects A to call it on behalf of some 
>> one.  Likewise, C is always expecting B.
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> phil.h...@oracle.com
>> 
>>> On 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 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 follows the recipe of “I got a token, I get another token 
>>> based on this to call someone else”. It’s also analogous to the refresh 
>>> token flow, but with access tokens going in and out. I’ve deployed this 
>>> setup several times in different service deployments. Even though there is 
>>> a performance hit in the additional round trips (as Phil brought up in 
>>> another thread), in these cases the desire to have the tokens hold least 
>>> privilege access rights (smallest set of scopes per service) outweighed any 
>>> performance hit (which was shown to be rather small in practice).
>>> 
>>> What I want is for the token swap draft to define or use a mechanism that 
>>> allows us to do this. I think we can do that pretty easily by adjusting the 
>>> token swap syntax and language, and explicitly calling out the semantic 
>>> processing portion (the current core of the docume

Re: [OAUTH-WG] Token Chaining Use Case

[Bill Mills]

By definition an access token is becoming a form of refresh token.    The 
"because my implementation didn't do it that way" isn't convincing me. 


 On Thursday, March 26, 2015 12:44 PM, Justin Richer  
wrote:
   

  Because many implementations (including mine which does support my old token 
chaining draft) treat access tokens and refresh tokens separately in terms of 
data store and structure. Additionally, the refresh token is tied to the client 
and presented by the client. But in this case it's someone downstream, an RS, 
presenting the token. So unlike a refresh token being presented by the one it 
was issued to, this token is being presented by someone it was presented to. 
The feeling is close, but not quite the same in either development or 
assumptions.
-- Justin
/ Sent from my phone /

 Original message 
From: Bill Mills  
Date: 03/26/2015 2:24 PM (GMT-06:00) 
To: Justin Richer , ""  
Subject: Re: [OAUTH-WG] Token Chaining Use Case 

So why can't the access tokne simply be re-used as a refresh token?  Why would 
it need a new grant type at all?
 


 On Thursday, March 26, 2015 11:31 AM, 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 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 
follows the recipe of “I got a token, I get another token based on this to call 
someone else”. It’s also analogous to the refresh token flow, but with access 
tokens going in and out. I’ve deployed this setup several times in different 
service deployments. Even though there is a performance hit in the additional 
round trips (as Phil brought up in another thread), in these cases the desire 
to have the tokens hold least privilege access rights (smallest set of scopes 
per service) outweighed any performance hit (which was shown to be rather small 
in practice).

What I want is for the token swap draft to define or use a mechanism that 
allows us to do this. I think we can do that pretty easily by adjusting the 
token swap syntax and language, and explicitly calling out the semantic 
processing portion (the current core of the document) for what it is: a way for 
a token issuer to communicate to a token service specific actions. At a high 
level, the spec would be something like:



1. How to swap a token at an AS
  1. Send a request to the token endpoint with a new grant type, and a token 
(of any type/format/flavor) on the way in
  2. Get back a new token in a token response
2. Communicating act as / on behalf of semantics via a JWT assertion
  1. How to create (as an AS/RS/client/other issuer) a JWT with act-as semantics
  2. What to do (as an AS/RS) with a JWT with act-as semantics
  3. How to create a JWT with on-behalf-of semeantics
  4. What to do with a JWT with on-behalf-of-semantics
  5. How to possibly represent these semantics with something other than a JWT



Section 2 uses the syntax from section 1. Other applications, like the one I 
laid out above, can use the syntax from section 1 as well. This works for 
structured, unstructured, self-generated, cross-domain, within-domain, and 
other tokens.


 — 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

Re: [OAUTH-WG] Token Chaining Use Case

[Bill Mills]

So why can't the access tokne simply be re-used as a refresh token?  Why would 
it need a new grant type at all?
 


 On Thursday, March 26, 2015 11:31 AM, 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 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 
follows the recipe of “I got a token, I get another token based on this to call 
someone else”. It’s also analogous to the refresh token flow, but with access 
tokens going in and out. I’ve deployed this setup several times in different 
service deployments. Even though there is a performance hit in the additional 
round trips (as Phil brought up in another thread), in these cases the desire 
to have the tokens hold least privilege access rights (smallest set of scopes 
per service) outweighed any performance hit (which was shown to be rather small 
in practice).

What I want is for the token swap draft to define or use a mechanism that 
allows us to do this. I think we can do that pretty easily by adjusting the 
token swap syntax and language, and explicitly calling out the semantic 
processing portion (the current core of the document) for what it is: a way for 
a token issuer to communicate to a token service specific actions. At a high 
level, the spec would be something like:



1. How to swap a token at an AS
  1. Send a request to the token endpoint with a new grant type, and a token 
(of any type/format/flavor) on the way in
  2. Get back a new token in a token response
2. Communicating act as / on behalf of semantics via a JWT assertion
  1. How to create (as an AS/RS/client/other issuer) a JWT with act-as semantics
  2. What to do (as an AS/RS) with a JWT with act-as semantics
  3. How to create a JWT with on-behalf-of semeantics
  4. What to do with a JWT with on-behalf-of-semantics
  5. How to possibly represent these semantics with something other than a JWT



Section 2 uses the syntax from section 1. Other applications, like the one I 
laid out above, can use the syntax from section 1 as well. This works for 
structured, unstructured, self-generated, cross-domain, within-domain, and 
other tokens.


 — 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

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

[Bill Mills]

STS? 


 On Tuesday, March 17, 2015 2:40 PM, John Bradley  wrote:
   

 This is fun:)
I might ask what part of a OAuth 1.0a token is the user credential.   That is a 
slippery idea in itself.  The token is a reference to some notion of identity 
(in some cases) that needs to be dereferenced anyway.
So in the same way a POP JWT access token in OAuth 2 that may indeed contain 
claims about the subject would need to be exchanged at a AS for a new token 
containing claims about the subject and the new presenter, or depending on the 
security model it could be included directly in a new self signed AT.
>From a enterprise policy point of view having a REST like STS functionality is 
>I think the right long term answer.
John B.



On Mar 17, 2015, at 6:32 PM, Bill Mills  wrote:
In practice one of the drawbacks of the Oauth 1.0a tokens was that they were 
not proxyable and so a connection to the edge then means you have to unwrap 
that and make a new internal token to be usedwhich isn't as good as the actual 
user credential.  


 On Tuesday, March 17, 2015 2:26 PM, John Bradley  wrote:
   

 PoP tokens need to be presented with a proof the presenter knows the secret.  
That is the same principal as in OAuth 1.0a with needing to show knowledge of 
the "token secret".
I don't know what you mean by proxies internally.   If the RS needs another 
token to access a resource it should use the assertion flow and authenticate 
itself to get another token based on the access token.Passing around a PoP 
token as a bearer token is insecure/bad.
In OAuth 1.0a because of the tight relationship between the "Service Provider" 
and the "Protected Resource" people would be less likely to try it but because 
the protected resource knows the "token secret" it could still do lots of 
unexpected bad things.
Proxying access tokens is not something RS should do, they need to be exchanged 
at a AS for a new AT with the correct rights and optionally binding it to a new 
PoP key.
John B.



On Mar 17, 2015, at 6:14 PM, Bill Mills  wrote:

Yes.  There's still the open question of whether/how PoP tokens can be proxied 
internally within a site though.  If they can be proxied then it goes back to 
unsolved. 


 On Tuesday, March 17, 2015 2:12 PM, John Bradley  wrote:
   

 Or by OAuth 2 PoP.    


On Mar 17, 2015, at 6:00 PM, Bill Mills  wrote:
"Yes but it is custom.  People are inventing structured scopes like 
"aud:https://foo.com";, and that potentially doesn't solve the security issue if 
a client just passes on the scopes it receives in the error response, the bad 
RS just adds a scope for the good RS."
This isn't solved by "aud", it is solved by OAuth 1.0a though  


 On Tuesday, March 17, 2015 1:54 PM, John Bradley  wrote:
   

 Yes but it is custom.  People are inventing structured scopes like 
"aud:https://foo.com";, and that potentially doesn't solve the security issue if 
a client just passes on the scopes it receives in the error response, the bad 
RS just adds a scope for the good RS.
The client then potentially needs to understand the custom structures scopes of 
every AS it might deal with.
I think that would lead to lots of problems trying to make that a pattern long 
term.   At teh moment yes you can do it with a scope as long as the client and 
AS both understand what is going on.

We added "aud" as a separate parameter for PoP as the token format for 
different RS might be different as well as the symmetric  pop keys needing to 
be encrypted with different keys.Yes we could have invented a special scope to 
carry the audience but a separate parameter was much cleaner.
I know some people have started using "aud" as a way to communicate the 
resource when a scope applies to multiple RS but they may take different token 
formats JWT vs opaque etc.
Brian commented that the "aud" parameter may be useful beyond PoP so we might 
want to think about documenting it in it's own mini spec, if I understood him 
correctly.
I think that may not be a bad idea as we are also planning on using it in NAPPS.
John B.

On Mar 17, 2015, at 5:39 PM, Bill Mills  wrote:
I don't think it's "overloading scope names" to use them that way.  The aud 
value(s) could as easily be carried in scope as anywhere.  Nothing says a scope 
can't be "https://foo.com";, and that Foo.com requires that scope to be present 
for a token to be accepted.  I would not make it foo.com-read-mail for example.
If it's more convenient to put it in aud I can accept that, but it's the same 
functionality and can be implemented in scopes now. 


 On Tuesday, March 17, 2015 12:41 PM, John Bradley  
wrote:
   

 People have been overloading scope names to create implicit audience.   
The problem is that clients need to know via some magic method that you need to 
a

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

[Bill Mills]

In practice one of the drawbacks of the Oauth 1.0a tokens was that they were 
not proxyable and so a connection to the edge then means you have to unwrap 
that and make a new internal token to be usedwhich isn't as good as the actual 
user credential.  


 On Tuesday, March 17, 2015 2:26 PM, John Bradley  wrote:
   

 PoP tokens need to be presented with a proof the presenter knows the secret.  
That is the same principal as in OAuth 1.0a with needing to show knowledge of 
the "token secret".
I don't know what you mean by proxies internally.   If the RS needs another 
token to access a resource it should use the assertion flow and authenticate 
itself to get another token based on the access token.Passing around a PoP 
token as a bearer token is insecure/bad.
In OAuth 1.0a because of the tight relationship between the "Service Provider" 
and the "Protected Resource" people would be less likely to try it but because 
the protected resource knows the "token secret" it could still do lots of 
unexpected bad things.
Proxying access tokens is not something RS should do, they need to be exchanged 
at a AS for a new AT with the correct rights and optionally binding it to a new 
PoP key.
John B.



On Mar 17, 2015, at 6:14 PM, Bill Mills  wrote:

Yes.  There's still the open question of whether/how PoP tokens can be proxied 
internally within a site though.  If they can be proxied then it goes back to 
unsolved. 


 On Tuesday, March 17, 2015 2:12 PM, John Bradley  wrote:
   

 Or by OAuth 2 PoP.    


On Mar 17, 2015, at 6:00 PM, Bill Mills  wrote:
"Yes but it is custom.  People are inventing structured scopes like 
"aud:https://foo.com";, and that potentially doesn't solve the security issue if 
a client just passes on the scopes it receives in the error response, the bad 
RS just adds a scope for the good RS."
This isn't solved by "aud", it is solved by OAuth 1.0a though  


 On Tuesday, March 17, 2015 1:54 PM, John Bradley  wrote:
   

 Yes but it is custom.  People are inventing structured scopes like 
"aud:https://foo.com";, and that potentially doesn't solve the security issue if 
a client just passes on the scopes it receives in the error response, the bad 
RS just adds a scope for the good RS.
The client then potentially needs to understand the custom structures scopes of 
every AS it might deal with.
I think that would lead to lots of problems trying to make that a pattern long 
term.   At teh moment yes you can do it with a scope as long as the client and 
AS both understand what is going on.

We added "aud" as a separate parameter for PoP as the token format for 
different RS might be different as well as the symmetric  pop keys needing to 
be encrypted with different keys.Yes we could have invented a special scope to 
carry the audience but a separate parameter was much cleaner.
I know some people have started using "aud" as a way to communicate the 
resource when a scope applies to multiple RS but they may take different token 
formats JWT vs opaque etc.
Brian commented that the "aud" parameter may be useful beyond PoP so we might 
want to think about documenting it in it's own mini spec, if I understood him 
correctly.
I think that may not be a bad idea as we are also planning on using it in NAPPS.
John B.

On Mar 17, 2015, at 5:39 PM, Bill Mills  wrote:
I don't think it's "overloading scope names" to use them that way.  The aud 
value(s) could as easily be carried in scope as anywhere.  Nothing says a scope 
can't be "https://foo.com";, and that Foo.com requires that scope to be present 
for a token to be accepted.  I would not make it foo.com-read-mail for example.
If it's more convenient to put it in aud I can accept that, but it's the same 
functionality and can be implemented in scopes now. 


 On Tuesday, March 17, 2015 12:41 PM, John Bradley  
wrote:
   

 People have been overloading scope names to create implicit audience.   
The problem is that clients need to know via some magic method that you need to 
ask for scope "purple" to get write access to RS 2.
Having an explicit "aud" parameter gives clients a way to communicate to the AS 
what RS they are asking for a token for. 

the security issue is that if a client discovers a API out via some out of band 
mechanism the OAuth error code can tell the client go to AS X and ask for Scope 
Y.  
Unfortunately without POP tokens or at-least passing the URI of the RS to the 
AS via "aud", a bad RS could get a legitimate client to give it a token that 
can be replayed at a legitimate RS.
This was one of the issues that Eran Hammer-Lahav was particularly concerned 
about.  
I think I proposed a "aud" parameter to the token endpoint back then as a 
alternative to requiring HMAC tokens, but that got los

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

[Bill Mills]

Yes.  There's still the open question of whether/how PoP tokens can be proxied 
internally within a site though.  If they can be proxied then it goes back to 
unsolved. 


 On Tuesday, March 17, 2015 2:12 PM, John Bradley  wrote:
   

 Or by OAuth 2 PoP.    


On Mar 17, 2015, at 6:00 PM, Bill Mills  wrote:
"Yes but it is custom.  People are inventing structured scopes like 
"aud:https://foo.com";, and that potentially doesn't solve the security issue if 
a client just passes on the scopes it receives in the error response, the bad 
RS just adds a scope for the good RS."
This isn't solved by "aud", it is solved by OAuth 1.0a though  


 On Tuesday, March 17, 2015 1:54 PM, John Bradley  wrote:
   

 Yes but it is custom.  People are inventing structured scopes like 
"aud:https://foo.com";, and that potentially doesn't solve the security issue if 
a client just passes on the scopes it receives in the error response, the bad 
RS just adds a scope for the good RS.
The client then potentially needs to understand the custom structures scopes of 
every AS it might deal with.
I think that would lead to lots of problems trying to make that a pattern long 
term.   At teh moment yes you can do it with a scope as long as the client and 
AS both understand what is going on.

We added "aud" as a separate parameter for PoP as the token format for 
different RS might be different as well as the symmetric  pop keys needing to 
be encrypted with different keys.Yes we could have invented a special scope to 
carry the audience but a separate parameter was much cleaner.
I know some people have started using "aud" as a way to communicate the 
resource when a scope applies to multiple RS but they may take different token 
formats JWT vs opaque etc.
Brian commented that the "aud" parameter may be useful beyond PoP so we might 
want to think about documenting it in it's own mini spec, if I understood him 
correctly.
I think that may not be a bad idea as we are also planning on using it in NAPPS.
John B.

On Mar 17, 2015, at 5:39 PM, Bill Mills  wrote:
I don't think it's "overloading scope names" to use them that way.  The aud 
value(s) could as easily be carried in scope as anywhere.  Nothing says a scope 
can't be "https://foo.com";, and that Foo.com requires that scope to be present 
for a token to be accepted.  I would not make it foo.com-read-mail for example.
If it's more convenient to put it in aud I can accept that, but it's the same 
functionality and can be implemented in scopes now. 


 On Tuesday, March 17, 2015 12:41 PM, John Bradley  
wrote:
   

 People have been overloading scope names to create implicit audience.   
The problem is that clients need to know via some magic method that you need to 
ask for scope "purple" to get write access to RS 2.
Having an explicit "aud" parameter gives clients a way to communicate to the AS 
what RS they are asking for a token for. 

the security issue is that if a client discovers a API out via some out of band 
mechanism the OAuth error code can tell the client go to AS X and ask for Scope 
Y.  
Unfortunately without POP tokens or at-least passing the URI of the RS to the 
AS via "aud", a bad RS could get a legitimate client to give it a token that 
can be replayed at a legitimate RS.
This was one of the issues that Eran Hammer-Lahav was particularly concerned 
about.  
I think I proposed a "aud" parameter to the token endpoint back then as a 
alternative to requiring HMAC tokens, but that got lost in the confusion at the 
time.
At that time though people were not yet thinking about interoperable OAuth API, 
 only relatively tightly bound clients that were preconfigured for the API 
endpoints they were using.
In Health and other places we are starting to see standard clients that 
discover API endpoints and configure themselves based on a users Identity to 
use a arbitrary OAuth AS, moving into federation of AT.
That is one of the reasons POP will be important, as it prevents RS from 
misusing federated tokens by presenting them at other RS.
The simplest thing to do is have the client say what RS it is trying to access 
explicitly (The "aud" parameter), and including an audience in the AT.  to 
protect against malicious RS.
PoP is the step up that also protects against tokens being intercepted and 
replayed by another client.
John B.

On Mar 17, 2015, at 4:10 PM, Bill Mills  wrote:
This may have been hashed out already and I missed it, but "aud" just becomes 
another kind of scope, correct?
 


 On Tuesday, March 17, 2015 8:50 AM, John Bradley  wrote:
   

 You could do that, but it is probably safer for the AS to know what RS it can 
issue tokens for and refuse to issue a token for RS A to a client asking for a 
token with RS X as the aud.
John B.

On Mar 16,

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

[Bill Mills]

"Yes but it is custom.  People are inventing structured scopes like 
"aud:https://foo.com";, and that potentially doesn't solve the security issue if 
a client just passes on the scopes it receives in the error response, the bad 
RS just adds a scope for the good RS."
This isn't solved by "aud", it is solved by OAuth 1.0a though  


 On Tuesday, March 17, 2015 1:54 PM, John Bradley  wrote:
   

 Yes but it is custom.  People are inventing structured scopes like 
"aud:https://foo.com";, and that potentially doesn't solve the security issue if 
a client just passes on the scopes it receives in the error response, the bad 
RS just adds a scope for the good RS.
The client then potentially needs to understand the custom structures scopes of 
every AS it might deal with.
I think that would lead to lots of problems trying to make that a pattern long 
term.   At teh moment yes you can do it with a scope as long as the client and 
AS both understand what is going on.

We added "aud" as a separate parameter for PoP as the token format for 
different RS might be different as well as the symmetric  pop keys needing to 
be encrypted with different keys.Yes we could have invented a special scope to 
carry the audience but a separate parameter was much cleaner.
I know some people have started using "aud" as a way to communicate the 
resource when a scope applies to multiple RS but they may take different token 
formats JWT vs opaque etc.
Brian commented that the "aud" parameter may be useful beyond PoP so we might 
want to think about documenting it in it's own mini spec, if I understood him 
correctly.
I think that may not be a bad idea as we are also planning on using it in NAPPS.
John B.

On Mar 17, 2015, at 5:39 PM, Bill Mills  wrote:
I don't think it's "overloading scope names" to use them that way.  The aud 
value(s) could as easily be carried in scope as anywhere.  Nothing says a scope 
can't be "https://foo.com";, and that Foo.com requires that scope to be present 
for a token to be accepted.  I would not make it foo.com-read-mail for example.
If it's more convenient to put it in aud I can accept that, but it's the same 
functionality and can be implemented in scopes now. 


 On Tuesday, March 17, 2015 12:41 PM, John Bradley  
wrote:
   

 People have been overloading scope names to create implicit audience.   
The problem is that clients need to know via some magic method that you need to 
ask for scope "purple" to get write access to RS 2.
Having an explicit "aud" parameter gives clients a way to communicate to the AS 
what RS they are asking for a token for. 

the security issue is that if a client discovers a API out via some out of band 
mechanism the OAuth error code can tell the client go to AS X and ask for Scope 
Y.  
Unfortunately without POP tokens or at-least passing the URI of the RS to the 
AS via "aud", a bad RS could get a legitimate client to give it a token that 
can be replayed at a legitimate RS.
This was one of the issues that Eran Hammer-Lahav was particularly concerned 
about.  
I think I proposed a "aud" parameter to the token endpoint back then as a 
alternative to requiring HMAC tokens, but that got lost in the confusion at the 
time.
At that time though people were not yet thinking about interoperable OAuth API, 
 only relatively tightly bound clients that were preconfigured for the API 
endpoints they were using.
In Health and other places we are starting to see standard clients that 
discover API endpoints and configure themselves based on a users Identity to 
use a arbitrary OAuth AS, moving into federation of AT.
That is one of the reasons POP will be important, as it prevents RS from 
misusing federated tokens by presenting them at other RS.
The simplest thing to do is have the client say what RS it is trying to access 
explicitly (The "aud" parameter), and including an audience in the AT.  to 
protect against malicious RS.
PoP is the step up that also protects against tokens being intercepted and 
replayed by another client.
John B.

On Mar 17, 2015, at 4:10 PM, Bill Mills  wrote:
This may have been hashed out already and I missed it, but "aud" just becomes 
another kind of scope, correct?
 


 On Tuesday, March 17, 2015 8:50 AM, John Bradley  wrote:
   

 You could do that, but it is probably safer for the AS to know what RS it can 
issue tokens for and refuse to issue a token for RS A to a client asking for a 
token with RS X as the aud.
John B.

On Mar 16, 2015, at 8:27 PM, Dixie Baker  wrote:

The threat that RFC6819 4.6.4 describes is when a client obtains an AT and then 
sends it to a counterfeit RS, which then uses the AT to access resources from a 
legitimate RS, on the end-user's behalf.  
The suggested countermeasure is a bit difficult to interpret:  "

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

[Bill Mills]

I don't think it's "overloading scope names" to use them that way.  The aud 
value(s) could as easily be carried in scope as anywhere.  Nothing says a scope 
can't be "https://foo.com";, and that Foo.com requires that scope to be present 
for a token to be accepted.  I would not make it foo.com-read-mail for example.
If it's more convenient to put it in aud I can accept that, but it's the same 
functionality and can be implemented in scopes now. 


 On Tuesday, March 17, 2015 12:41 PM, John Bradley  
wrote:
   

 People have been overloading scope names to create implicit audience.   
The problem is that clients need to know via some magic method that you need to 
ask for scope "purple" to get write access to RS 2.
Having an explicit "aud" parameter gives clients a way to communicate to the AS 
what RS they are asking for a token for. 

the security issue is that if a client discovers a API out via some out of band 
mechanism the OAuth error code can tell the client go to AS X and ask for Scope 
Y.  
Unfortunately without POP tokens or at-least passing the URI of the RS to the 
AS via "aud", a bad RS could get a legitimate client to give it a token that 
can be replayed at a legitimate RS.
This was one of the issues that Eran Hammer-Lahav was particularly concerned 
about.  
I think I proposed a "aud" parameter to the token endpoint back then as a 
alternative to requiring HMAC tokens, but that got lost in the confusion at the 
time.
At that time though people were not yet thinking about interoperable OAuth API, 
 only relatively tightly bound clients that were preconfigured for the API 
endpoints they were using.
In Health and other places we are starting to see standard clients that 
discover API endpoints and configure themselves based on a users Identity to 
use a arbitrary OAuth AS, moving into federation of AT.
That is one of the reasons POP will be important, as it prevents RS from 
misusing federated tokens by presenting them at other RS.
The simplest thing to do is have the client say what RS it is trying to access 
explicitly (The "aud" parameter), and including an audience in the AT.  to 
protect against malicious RS.
PoP is the step up that also protects against tokens being intercepted and 
replayed by another client.
John B.

On Mar 17, 2015, at 4:10 PM, Bill Mills  wrote:
This may have been hashed out already and I missed it, but "aud" just becomes 
another kind of scope, correct?
 


 On Tuesday, March 17, 2015 8:50 AM, John Bradley  wrote:
   

 You could do that, but it is probably safer for the AS to know what RS it can 
issue tokens for and refuse to issue a token for RS A to a client asking for a 
token with RS X as the aud.
John B.

On Mar 16, 2015, at 8:27 PM, Dixie Baker  wrote:

The threat that RFC6819 4.6.4 describes is when a client obtains an AT and then 
sends it to a counterfeit RS, which then uses the AT to access resources from a 
legitimate RS, on the end-user's behalf.  
The suggested countermeasure is a bit difficult to interpret:  "Associate the 
endpoint URL of the resource server the client talked to with the access token 
(e.g., in an audience field) and validate the association at a legitimate 
resource server.  The endpoint URL validation policy may be strict (exact 
match) or more relaxed (e.g., same host).  This would require telling the 
authorization server about the resource server endpoint URL in the 
authorization process."  
As I read this, the suggestion is to have the client pass the URL of the bad RS 
in the request to the AS (using the audience field).  The AS then would include 
that RS URL in the AT.  Then, when the client passes the AT to the bad RS, and 
it passes it on to the good RS, the good RS will check the audience field, 
compare that URL with its own, and refuse the request.  
-Dixie


Dixie B. Baker, Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo Beach, CA):  310-791-9671
Mobile:  310-279-2579
On Mar 16, 2015, at 11:39 AM, John Bradley  wrote:


Brian and I were talking about "aud" used as a parameter to the token endpoint 
when using a code or refresh token to indicate what RS the resulting AT will be 
used at.
Sending a audience in the AT wouldn't help prevent the attack being discussed,  
though it may stop other sorts of attacks if the RS can tell if a AT was issued 
for it or another RS.
In PoP having the AS check that you are sending the AT to the correct RS is 
less important as the AT if stolen can't be used to replay against the real AS.
Though depending on the app the bogus RS feeding the app the wrong info may 
well be a problem as well.
John B.

On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt  
wrote:

I don't think putting an aud into an AT will help to prevent counterfeit RSs 
(as long as the aud is nit directly derived from the original URL used by the 

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

[Bill Mills]

This may have been hashed out already and I missed it, but "aud" just becomes 
another kind of scope, correct?
 


 On Tuesday, March 17, 2015 8:50 AM, John Bradley  wrote:
   

 You could do that, but it is probably safer for the AS to know what RS it can 
issue tokens for and refuse to issue a token for RS A to a client asking for a 
token with RS X as the aud.
John B.

On Mar 16, 2015, at 8:27 PM, Dixie Baker  wrote:

The threat that RFC6819 4.6.4 describes is when a client obtains an AT and then 
sends it to a counterfeit RS, which then uses the AT to access resources from a 
legitimate RS, on the end-user's behalf.  
The suggested countermeasure is a bit difficult to interpret:  "Associate the 
endpoint URL of the resource server the client talked to with the access token 
(e.g., in an audience field) and validate the association at a legitimate 
resource server.  The endpoint URL validation policy may be strict (exact 
match) or more relaxed (e.g., same host).  This would require telling the 
authorization server about the resource server endpoint URL in the 
authorization process."  
As I read this, the suggestion is to have the client pass the URL of the bad RS 
in the request to the AS (using the audience field).  The AS then would include 
that RS URL in the AT.  Then, when the client passes the AT to the bad RS, and 
it passes it on to the good RS, the good RS will check the audience field, 
compare that URL with its own, and refuse the request.  
-Dixie


Dixie B. Baker, Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo Beach, CA):  310-791-9671
Mobile:  310-279-2579
On Mar 16, 2015, at 11:39 AM, John Bradley  wrote:


Brian and I were talking about "aud" used as a parameter to the token endpoint 
when using a code or refresh token to indicate what RS the resulting AT will be 
used at.
Sending a audience in the AT wouldn't help prevent the attack being discussed,  
though it may stop other sorts of attacks if the RS can tell if a AT was issued 
for it or another RS.
In PoP having the AS check that you are sending the AT to the correct RS is 
less important as the AT if stolen can't be used to replay against the real AS.
Though depending on the app the bogus RS feeding the app the wrong info may 
well be a problem as well.
John B.

On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt  
wrote:

I don't think putting an aud into an AT will help to prevent counterfeit RSs 
(as long as the aud is nit directly derived from the original URL used by the 
client to invoke the counterfeit RS. as long as the aud is a symbolic name of 
any kind, the counterfeit RS will accept ATs for the legitimate RS and just 
(ab)use it.
POP on the contrary helps since the counterfeit RS, in order to send a message 
to the legitimate RS, needs to produce a new digitally signed message using the 
correct secret, which it doesn't know.
kind regards,Torsten.



Am 16.03.2015 um 17:40 schrieb Dixie Baker :



Using the "aud" parameter makes sense to me.  Good suggestion.
Authenticating the client to the RS would not address the counterfeit RS 
threat. 
-Dixie
 
Dixie B. Baker, Ph.D.
Senior Partner
Martin, Blanck and Associates
Office (Redondo Beach, CA):  310-791-9671
Mobile:  310-279-2579
On Mar 16, 2015, at 6:43 AM, Brian Campbell  wrote:

We've used "aud" (optionally) with OAuth 2 and bearer tokens to help identify 
the RS to whom the AT should be issued. It is useful but it's mostly about 
getting format/content/etc of the AT correct for the RS rather than it is about 
preventing possible AT leaks.

I do think an "aud(iance)" parameter at both token and authorization endpoints 
would have utility beyond the POP work. So defining it independently might make 
sense. 

On Sun, Mar 15, 2015 at 11:34 AM, John Bradley  wrote:

In POP key distribution we do introduce a "audiance" parameter to the 
token_endpoint. 
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#section-3.1
It would be possible to have a small spec to define using "aud" with bearer 
tokens, however that would be undefined behaviour at this point.
I don't know of any clients that would try to access a RS server and then besed 
on the error response try and get a access token from the AS specified in the 
error.
In POP we are trying to both protect agains that attack and more common ones 
like doing a MiM to intercept the AT or the RS being hacked and leaking the 
token.
Using "aud" with bearer tokens would be useful, but probably won't stop the 
majority of possible AT leaks.
John B.


On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt  
wrote:
  Hi Josh,
 
 I'm not aware of a common practice to use such a parameter. The WG is instead 
heading towards authenticated requests to the resource server (see 
https://tools.ietf.org/html/rfc6819#section-5.4.2). 
 
 Please take a look onto 
http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further drafts 
on this topic.
 
 kind regards,
 Torsten.
 
 Am 03.03.2015 um 18:27

Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?

[Bill Mills]

If this spec is about providing a single option for doing this as an option 
that's fine.  If it becomes MTI for using POP tokens at all  think that's a 
mistake.    OAuth 2 provides a framework and one optional token type, Bearer, 
which is not MTI.  That's a reasonable thing and would work here. 

 On Sunday, March 8, 2015 10:48 PM, Tirumaleswar Reddy (tireddy) 
 wrote:
   

 #yiv6169713675 #yiv6169713675 -- _filtered #yiv6169713675 
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv6169713675 
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv6169713675 
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv6169713675 
{font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv6169713675 
#yiv6169713675 p.yiv6169713675MsoNormal, #yiv6169713675 
li.yiv6169713675MsoNormal, #yiv6169713675 div.yiv6169713675MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv6169713675 a:link, 
#yiv6169713675 span.yiv6169713675MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv6169713675 a:visited, #yiv6169713675 
span.yiv6169713675MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv6169713675 
p.yiv6169713675MsoAcetate, #yiv6169713675 li.yiv6169713675MsoAcetate, 
#yiv6169713675 div.yiv6169713675MsoAcetate 
{margin:0in;margin-bottom:.0001pt;font-size:8.0pt;}#yiv6169713675 
p.yiv6169713675msonormal, #yiv6169713675 li.yiv6169713675msonormal, 
#yiv6169713675 div.yiv6169713675msonormal 
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv6169713675 
span.yiv6169713675msohyperlink {}#yiv6169713675 
span.yiv6169713675msohyperlinkfollowed {}#yiv6169713675 
span.yiv6169713675emailstyle17 {}#yiv6169713675 p.yiv6169713675msonormal1, 
#yiv6169713675 li.yiv6169713675msonormal1, #yiv6169713675 
div.yiv6169713675msonormal1 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv6169713675 
span.yiv6169713675msohyperlink1 
{color:blue;text-decoration:underline;}#yiv6169713675 
span.yiv6169713675msohyperlinkfollowed1 
{color:purple;text-decoration:underline;}#yiv6169713675 
span.yiv6169713675emailstyle171 {color:#1F497D;}#yiv6169713675 
span.yiv6169713675BalloonTextChar {}#yiv6169713675 
span.yiv6169713675EmailStyle27 {color:#1F497D;}#yiv6169713675 
.yiv6169713675MsoChpDefault {font-size:10.0pt;} _filtered #yiv6169713675 
{margin:1.0in 1.0in 1.0in 1.0in;}#yiv6169713675 div.yiv6169713675WordSection1 
{}#yiv6169713675 In this use case RS and AS could be implemented and operated 
by different providers, MTI solves the interop issue.    -Tiru    From: Bill 
Mills [mailto:wmills_92...@yahoo.com]
Sent: Monday, March 09, 2015 11:10 AM
To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?    
Explain to me why there should be one other than the desire to over-specify?  
Why is one so clearly superior to any of the various possibilities that it 
should be mandated?    I do not think that there is any clearly superior 
mechanism and so making any particular one MTI is pointless and just likely to 
cause perfectly good implementations to be out of spec.    On Sunday, March 8, 
2015 10:24 PM, Tirumaleswar Reddy (tireddy)  wrote:    Hi 
Bill,   Can you please provide more details why mandating specific key 
distribution mechanism is not appropriate especially in case of loosely coupled 
systems ?   -Tiru   From: Bill Mills [mailto:wmills_92...@yahoo.com]
Sent: Monday, March 09, 2015 10:27 AM
To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?   
I do not believe making any specific key distribution MTI is aproprpiate.   On 
Sunday, March 8, 2015 8:06 PM, Tirumaleswar Reddy (tireddy)  
wrote:   Hi Hannes,

http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01#section-5.3discusses
 long-term secret shared by the authorization server with the resource server 
but does not mention the out-of-band mechanism.

In 
http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-13#section-4.1.1we
 had provided three mechanisms for long-term key establishment. In this use 
case RS and AS could be offered by the same provider (tightly-coupled) or by 
different providers (loosely-coupled).

Thoughts on which one should be mandatory to implement ?
(This question came up in ISEG review and probably would be a question for 
proof-of-possession work as well)

Thanks and Regards,
-Tiru 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Saturday, March 07, 2015 12:30 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?
> 
> Hi all,
> 
> does anyone have free cycles to review
> draft-ietf-tram-turn-third-party-authz, which happens to use OAuth 2.0 in a 
> way
> that is similar to the proof-of-possession work wi

Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?

[Bill Mills]

Explain to me why there should be one other than the desire to over-specify?  
Why is one so clearly superior to any of the various possibilities that it 
should be mandated?
I do not think that there is any clearly superior mechanism and so making any 
particular one MTI is pointless and just likely to cause perfectly good 
implementations to be out of spec. 

 On Sunday, March 8, 2015 10:24 PM, Tirumaleswar Reddy (tireddy) 
 wrote:
   

 #yiv3556672566 #yiv3556672566 -- _filtered #yiv3556672566 
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv3556672566 
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv3556672566 
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv3556672566 
{font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv3556672566 
#yiv3556672566 p.yiv3556672566MsoNormal, #yiv3556672566 
li.yiv3556672566MsoNormal, #yiv3556672566 div.yiv3556672566MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv3556672566 a:link, 
#yiv3556672566 span.yiv3556672566MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv3556672566 a:visited, #yiv3556672566 
span.yiv3556672566MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv3556672566 
span.yiv3556672566EmailStyle17 {color:#1F497D;}#yiv3556672566 
.yiv3556672566MsoChpDefault {} _filtered #yiv3556672566 {margin:1.0in 1.0in 
1.0in 1.0in;}#yiv3556672566 div.yiv3556672566WordSection1 {}#yiv3556672566 Hi 
Bill,    Can you please provide more details why mandating specific key 
distribution mechanism is not appropriate especially in case of loosely coupled 
systems ?    -Tiru    From: Bill Mills [mailto:wmills_92...@yahoo.com]
Sent: Monday, March 09, 2015 10:27 AM
To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?    
I do not believe making any specific key distribution MTI is aproprpiate.    On 
Sunday, March 8, 2015 8:06 PM, Tirumaleswar Reddy (tireddy)  
wrote:    Hi Hannes,

http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01#section-5.3discusses
 long-term secret shared by the authorization server with the resource server 
but does not mention the out-of-band mechanism.

In 
http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-13#section-4.1.1we
 had provided three mechanisms for long-term key establishment. In this use 
case RS and AS could be offered by the same provider (tightly-coupled) or by 
different providers (loosely-coupled).

Thoughts on which one should be mandatory to implement ?
(This question came up in ISEG review and probably would be a question for 
proof-of-possession work as well)

Thanks and Regards,
-Tiru 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Saturday, March 07, 2015 12:30 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?
> 
> Hi all,
> 
> does anyone have free cycles to review
> draft-ietf-tram-turn-third-party-authz, which happens to use OAuth 2.0 in a 
> way
> that is similar to the proof-of-possession work with a new access token 
> format.
> 
> Ciao
> Hannes
> 
>  Forwarded Message 
> Subject: [saag] tram draft - anyone willing to help out?
> Date: Fri, 06 Mar 2015 15:43:57 +
> From: Stephen Farrell 
> To: s...@ietf.org 
> 
> 
> Hiya,
> 
> There's a draft in IESG eval that attracted a bunch of perhaps fundamental
> discusses and comments [1] about its security properties. I think this may be 
> one
> where the authors could do with a bit more help from the security
> mafia^H^H^H^H^Hcommunity.
> (I looked at their wg list and only see a v. thin smattering of names I'd 
> recognise
> from this list.) So if you're willing and have a little time, please let me 
> know
> and/or get in touch with the authors.
> 
> And btw - this might not seem so important but I'd worry it may end up being a
> major source of system level vulnerabilities for WebRTC deployments if we get 
> it
> wrong and many sites don't deploy usefully good security for this bit of the
> WebRTC story.
> 
> Thanks in advance,
> S.
> 
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ballot/
> 
> ___
> saag mailing list
> s...@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
> 
> 

___
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] Fwd: [saag] tram draft - anyone willing to help out?

[Bill Mills]

I do not believe making any specific key distribution MTI is aproprpiate. 

 On Sunday, March 8, 2015 8:06 PM, Tirumaleswar Reddy (tireddy) 
 wrote:
   

 Hi Hannes,

http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01#section-5.3 
discusses long-term secret shared by the authorization server with the resource 
server but does not mention the out-of-band mechanism.

In 
http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-13#section-4.1.1
 we had provided three mechanisms for long-term key establishment. In this use 
case RS and AS could be offered by the same provider (tightly-coupled) or by 
different providers (loosely-coupled).

Thoughts on which one should be mandatory to implement ?
(This question came up in ISEG review and probably would be a question for 
proof-of-possession work as well)

Thanks and Regards,
-Tiru

> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Saturday, March 07, 2015 12:30 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?
> 
> Hi all,
> 
> does anyone have free cycles to review
> draft-ietf-tram-turn-third-party-authz, which happens to use OAuth 2.0 in a 
> way
> that is similar to the proof-of-possession work with a new access token 
> format.
> 
> Ciao
> Hannes
> 
>  Forwarded Message 
> Subject: [saag] tram draft - anyone willing to help out?
> Date: Fri, 06 Mar 2015 15:43:57 +
> From: Stephen Farrell 
> To: s...@ietf.org 
> 
> 
> Hiya,
> 
> There's a draft in IESG eval that attracted a bunch of perhaps fundamental
> discusses and comments [1] about its security properties. I think this may be 
> one
> where the authors could do with a bit more help from the security
> mafia^H^H^H^H^Hcommunity.
> (I looked at their wg list and only see a v. thin smattering of names I'd 
> recognise
> from this list.) So if you're willing and have a little time, please let me 
> know
> and/or get in touch with the authors.
> 
> And btw - this might not seem so important but I'd worry it may end up being a
> major source of system level vulnerabilities for WebRTC deployments if we get 
> it
> wrong and many sites don't deploy usefully good security for this bit of the
> WebRTC story.
> 
> Thanks in advance,
> S.
> 
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ballot/
> 
> ___
> saag mailing list
> s...@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
> 
> 

___
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://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-02

[Bill Mills]

Hannes,
Please update my e-mail to wimi...@microsoft.com and my affilliation to 
Microsoft in the next draft.
Thanks,
-bill___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[Bill Mills]

I was OK with SHOULD because there's no firm measure of "enough entropy".  
Whether it's SHOULD or MUST is moot without some way to quantify it. 

 On Wednesday, February 18, 2015 1:27 AM, Nat Sakimura 
 wrote:
   

 Hi Hannes, 

The reason I have put SHOULD there instead of MUST is 
that there may be a valid reason not to in a controlled 
environment, and it does not interfere the interoperability.
The deployment may opt to use other control than entropy, 
and SHOULD allows it while MUST does not. 

Having said that, if the WG is OK with a MUST there, 
I am fine with incorporating the proposed change. 

Cheers, 

Nat


On Wed, 18 Feb 2015 09:43:30 +0100
Hannes Tschofenig  wrote:

> Hi Nat,
> 
> thanks for the quick response.
> 
> I was hoping to see a statement like "The code verifier MUST have
> enough entropy to make it impractical to guess the value." in the
> text rather than the SHOULD. Given all the other statements in the
> draft I am not sure what the should actually means. Under what
> conditions would an implementer not provide enough entropy to make
> guessing impractical?
> 
> Ciao
> Hannes
> 
> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
> > Hi Hannes, 
> > 
> > I hereby confirm that I have submit the draft  in full conformance
> > with the  provisions of BCP 78 and BCP 79.
> > 
> > Re: Security Consideration (7.1) and section 4.1
> > 
> > The first part of the 7.1 is a non-normative prose explaining that
> > the implementers got to make sure that the code verifier is hard to
> > guessed or modeled. In a way, this is laying out the basic security
> > property requirment on the code verifier. 
> > 
> > Then, it goes onto the implementation guideance that one need to
> > use a cryptographic random number generator instead of relying on a
> > rand() in some language that are  not cryptographically random to
> > generate 32-octet sequence. The same text is in 4.1 as well. 
> > 
> > We did not copy "code verifier SHOULD have enough entropy to make
> > it impractical to guess the value" here because that looked
> > needlessly repeating, but if you want, I have no objection in
> > adding it to 7.1. 
> > 
> > Alternatively, in 7.1, after explaining the rationale, we can just
> > point to 4.1 for the control and implementation guidance. 
> > 
> > Re: 32-octet
> > 
> > We chose it because we are using SHA256 in generating the code
> > challange. Having more entropy does not help us here, while having
> > less octets increases the risk. 
> > 
> > Best, 
> > 
> > Nat 
> > 
> > 
> > 
> > On Tue, 17 Feb 2015 17:56:33 +0100
> > Hannes Tschofenig  wrote:
> > 
> >> Hi Nat, John, Naveen,
> >>
> >> thanks a lot for your work on the document.
> >>
> >> I still need responses to this mail to complete the shepherd
> >> writeup:
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
> >>
> >> I definitely need the IPR confirmation.
> >>
> >> It would also be helpful to have someone who implemented the
> >> specification as it currently is. I asked Brian and Thorsten for
> >> clarification regarding their statements that they implemented
> >> earlier versions of the spec.
> >>
> >> As a final remark I still believe that the text regarding the
> >> randomness is still a bit inconsistent. Here are two examples:
> >>
> >> 1) In the Security Consideration you write that "The security model
> >> relies on the fact that the code verifier is not learned or
> >> guessed by the attacker.  It is vitally important to adhere to
> >> this principle. "
> >>
> >> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
> >> have enough entropy to make it impractical to guess the value.  It
> >> is RECOMMENDED that the output of a suitable random number
> >> generator be used to create a 32-octet sequence."
> >>
> >> There is clearly a long way from a SHOULD have enough entropy to
> >> the text in the security consideration section where you ask for
> >> 32 bytes entropy.
> >>
> >> It is also not clear why you ask for 32 bytes of entropy in
> >> particular.
> >>
> >> Ciao
> >> Hannes
> >>
> > 
> > 
> 


-- 
Nat Sakimura (n-sakim...@nri.co.jp)
Nomura Research Institute, Ltd. 

本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信
することを意図しております。意図された受取人以外の方によるこれらの情報の
開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール
を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受
信されたメールを削除していただきますようお願い致します。 PLEASE READ:
The information contained in this e-mail is confidential and intended
for the named recipient(s) only. If you are not an intended recipient
of this e-mail, you are hereby notified that any review, dissemination,
distribution or duplication of this message is strictly prohibited. If
you have received this message in error, please notify the sender
immediately and delete your copy from your system.

___
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/o

Re: [OAUTH-WG] user impersonation protocol?

[Bill Mills]

Straight impersonation with no limitations isn't a good solution in the long 
run. 

 On Monday, February 16, 2015 1:13 PM, William Denniss 
 wrote:
   

 I led a discussion on a related topic at a recent IIW (specifically exploring 
the "account sharing" use case), the notes are here: 
http://iiw.idcommons.net/Account_Sharing_at_the_IDP_(Identity_Provider).  It 
was an interesting discussion, the whole topic of impersonation certainly 
raises a lot of policy questions.
As for the technical implementation, our conclusion was that the simplest 
approach for impersonation would be to continue to supply an ID Token for the 
target user (i.e. 'sub' represents the user being impersonated), and add an 
additional JWT claim for the user doing the impersonation (e.g. 'ipb' meaning 
"impersonated by").
Thus, any relying party who doesn't understand this claim continues to work as 
before (oblivious to the fact the user is being impersonated), and those who 
understand the claim and care about impersonation can take action (e.g. log a 
better audit trail, limit some functionality or outright block the behavior).
If this approach sounds interesting to you, perhaps we could formally register 
& standardise the 'ipb' claim.  Of course, anyone can use this technique today 
via a private claim.

On Mon Feb 16 2015 at 7:36:23 AM Justin Richer  wrote:

Another question is whether or not you can user rights delegation (ie vanilla 
OAuth) or if you really do need impersonation. You may be able to get the 
desired results with less complexity that way.

-- Justin
/ Sent from my phone /

 Original message ----
From: Bill Burke  
Date:02/16/2015 10:20 AM (GMT-05:00) 
To: Bill Mills , Justin Richer , oauth 
 
Cc: 
Subject: Re: [OAUTH-WG] user impersonation protocol? 

Yeah, I know its risky, but that's the requirement.  Was just wondering 
if there was any protocol work being done around it, so that we could 
avoid doing a lot of the legwork to make it safe/effective.  Currently 
for us, we need to do this between two separate IDPs, which is where the 
protocol work comes in...If it was just a single IDP managing 
everything, then it would just be an internal custom IDP feature.

Thanks all.



On 2/16/2015 12:37 AM, Bill Mills wrote:
> User impersonation is very very risky.  The legal aspects of it must be
> considered.  There's a lot of work to do to make it safe/effective.
>
> Issuing a scoped token that allows ready only access can work with the
> above caveats.  Then properties/componenets have to explicitly support
> the new scope and do the right thing.
>
>
> On Sunday, February 15, 2015 8:34 PM, Justin Richer  wrote:
>
>
> For this case you'd want to be very careful about who was able to do
> such impersonation, obviously, but it's doable today with custom IdP
> behavior. You can simply use OpenID Connect and have the IdP issue an id
> token for the target user instead of the "actual" current user account.
>
> I would also suggest considering adding a custom claim to the id token
> to indicate this is taking place. That way you can differentiate where
> needed, including in logs.
>
> -- Justin
>
> / Sent from my phone /
>
>
>  Original message 
> From: Bill Burke 
> Date:02/15/2015 10:55 PM (GMT-05:00)
> To: oauth 
> Cc:
> Subject: [OAUTH-WG] user impersonation protocol?
>
> We have a case where we want to allow a logged in admin user to
> impersonate another user so that they can visit differents browser apps
> as that user (So they can see everything that the user sees through
> their browser).
>
> Anybody know of any protocol work being done here in the OAuth group or
> some other IETF or even Connect effort that would support something like
> this?
>
> Thanks,
>
> Bill
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> ___
> OAuth mailing list
> 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
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



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

Re: [OAUTH-WG] user impersonation protocol?

[Bill Mills]

I don't think there is protocol work required.  IMO you can best support this 
with limited cookies or tokens that are not otherwise valid and the server then 
needs to support with the right behavior.  Might be a BCP doc I suppose, but I 
don't know if it's worth the effort. 

 On Monday, February 16, 2015 7:35 AM, Justin Richer  
wrote:
   

 Another question is whether or not you can user rights delegation (ie vanilla 
OAuth) or if you really do need impersonation. You may be able to get the 
desired results with less complexity that way.

-- Justin
/ Sent from my phone /

 Original message 
From: Bill Burke  
Date:02/16/2015 10:20 AM (GMT-05:00) 
To: Bill Mills , Justin Richer , oauth 
 
Cc: 
Subject: Re: [OAUTH-WG] user impersonation protocol? 

Yeah, I know its risky, but that's the requirement.  Was just wondering 
if there was any protocol work being done around it, so that we could 
avoid doing a lot of the legwork to make it safe/effective.  Currently 
for us, we need to do this between two separate IDPs, which is where the 
protocol work comes in...If it was just a single IDP managing 
everything, then it would just be an internal custom IDP feature.

Thanks all.



On 2/16/2015 12:37 AM, Bill Mills wrote:
> User impersonation is very very risky.  The legal aspects of it must be
> considered.  There's a lot of work to do to make it safe/effective.
>
> Issuing a scoped token that allows ready only access can work with the
> above caveats.  Then properties/componenets have to explicitly support
> the new scope and do the right thing.
>
>
> On Sunday, February 15, 2015 8:34 PM, Justin Richer  wrote:
>
>
> For this case you'd want to be very careful about who was able to do
> such impersonation, obviously, but it's doable today with custom IdP
> behavior. You can simply use OpenID Connect and have the IdP issue an id
> token for the target user instead of the "actual" current user account.
>
> I would also suggest considering adding a custom claim to the id token
> to indicate this is taking place. That way you can differentiate where
> needed, including in logs.
>
> -- Justin
>
> / Sent from my phone /
>
>
>  Original message 
> From: Bill Burke 
> Date:02/15/2015 10:55 PM (GMT-05:00)
> To: oauth 
> Cc:
> Subject: [OAUTH-WG] user impersonation protocol?
>
> We have a case where we want to allow a logged in admin user to
> impersonate another user so that they can visit differents browser apps
> as that user (So they can see everything that the user sees through
> their browser).
>
> Anybody know of any protocol work being done here in the OAuth group or
> some other IETF or even Connect effort that would support something like
> this?
>
> Thanks,
>
> Bill
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> ___
> OAuth mailing list
> 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
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


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

Re: [OAUTH-WG] user impersonation protocol?

[Bill Mills]

User impersonation is very very risky.  The legal aspects of it must be 
considered.  There's a lot of work to do to make it safe/effective.
Issuing a scoped token that allows ready only access can work with the above 
caveats.  Then properties/componenets have to explicitly support the new scope 
and do the right thing. 

 On Sunday, February 15, 2015 8:34 PM, Justin Richer  
wrote:
   

 For this case you'd want to be very careful about who was able to do such 
impersonation, obviously, but it's doable today with custom IdP behavior. You 
can simply use OpenID Connect and have the IdP issue an id token for the target 
user instead of the "actual" current user account. 
I would also suggest considering adding a custom claim to the id token to 
indicate this is taking place. That way you can differentiate where needed, 
including in logs.
-- Justin
/ Sent from my phone /

 Original message 
From: Bill Burke  
Date:02/15/2015 10:55 PM (GMT-05:00) 
To: oauth  
Cc: 
Subject: [OAUTH-WG] user impersonation protocol? 

We have a case where we want to allow a logged in admin user to 
impersonate another user so that they can visit differents browser apps 
as that user (So they can see everything that the user sees through 
their browser).

Anybody know of any protocol work being done here in the OAuth group or 
some other IETF or even Connect effort that would support something like 
this?

Thanks,

Bill

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

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

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


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

[OAUTH-WG] code flow for browsers?

[Bill Mills]

Does https://tools.ietf.org/html/draft-ietf-oauth-spop-10 provide a way for us 
to replace the implicit flow with the code+proof key model?  Yes, Implicit 
saves a round trip.  This does deal nicely with some of the security concerns 
raised recently around how fragments are handled in the browser.
-bill  ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Bill Mills]

Ah, BNF builtin parser error, that's 42*128.  I had parsed that as 
128unreserved as the name. 

 On Thursday, February 5, 2015 12:47 PM, John Bradley  
wrote:
   

 We are discussing the minimum size,  the max is currently 128 characters.


On Feb 5, 2015, at 5:11 PM, Bill Mills  wrote:
Is there a compelling reason to make that length fixed?  
 

 On Thursday, February 5, 2015 10:10 AM, Brian Campbell 
 wrote:
   

 22-chars (128 bits) as a lower limit seems just fine for this case.

"ccm" works for me but I don't feel strongly about it either way.



On Thu, Feb 5, 2015 at 9:49 AM, John Bradley  wrote:

Inline


> On Feb 4, 2015, at 10:43 PM, Manger, James  
> wrote:
>
>>    Title           : Proof Key for Code Exchange by OAuth Public Clients
>>      Filename        : draft-ietf-oauth-spop-09.txt
>> https://tools.ietf.org/html/draft-ietf-oauth-spop-09
>
>
> Some nits on this draft:
>
> 1. 42 chars.
> The lower limit of 42 chars for code_verifier: is not mentioned in prose 
> (just the upper limit); is too high (128-bits=22-chars is sufficient); and 
> doesn't correspond to 256-bits (BASE64URL-ENCODE(32 bytes) gives 43 chars, 
> not 42).

In my editors draft I fixed the 43 octet base64url encoding of 32bytes.  I 
originally had 43 but it got changed at some point

Is there working group feedback on making the lower limit clear in the prose 
and if so what should it be?  22-chars (128 bits) or 43 char (256 bits)?


>
> 2.
> Quotes around "code_verifier" and "code_challenge" in prose are okay, though 
> not really necessary as the underscore is enough to distinguish them as 
> technical labels. Quotes around these terms in formula is bad as it looks 
> like the formula applies to the 13 or 14 chars of the label. The quoting is 
> also used inconsistently.
> Suggestion: remove all quotes around "code_verifier" and "code_challenge" in 
> prose and formula.
> For example, change ASCII("code_verifier") to ASCII(code_verifier).
>

I am going to leave this for a later formatting cleanup at the moment, I need 
to find a good style compromise that works with rfcmarkup.

> 3.
> Two ways to check code_verifier are given in appendix B, whereas only one of 
> these is mentioned in section 4.6.
>  SHA256(verifier) === B64-DECODE(challenge)
>  B64-ENCODE(SHA256(verifier)) === challenge
>
> I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and drop the 
> 1st from appendix B). It is simpler to mention only one. It also means 
> base64url-decoding is never done, and doesn't need to be mentioned in the 
> spec.
>
Yes when I added the example I realized that the normative text was the more 
complicated way to do the comparison.

I will go back and refactor the main text to talk about the simpler comparison 
and drop the base64url-decode references.
>
> 4.
> Expand "MTI" to "mandatory to implement".

Done in editors draft.
>
> P.S. Suggesting code challenge method names not exceed 8 chars to be compact 
> is a bit perverse given the field holding these values has the long name 
> "code_challenge_method" ;)

  On the topic of the parameter  name  "code_challange_method",  James has a 
point in that it is a bit long.

We could shorten it to "ccm".   If we want to change the name sooner is better 
than later.

It is that balance between compactness and clear parameter names for 
developers, that we keep running into.

I don't know that encouraging longer parameter values is the best direction.

Feedback please

John B.
>
> --
> James Manger
>
> ___
> 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] I-D Action: draft-ietf-oauth-spop-09.txt

[Bill Mills]

Is there a compelling reason to make that length fixed?  
 

 On Thursday, February 5, 2015 10:10 AM, Brian Campbell 
 wrote:
   

 22-chars (128 bits) as a lower limit seems just fine for this case.

"ccm" works for me but I don't feel strongly about it either way.



On Thu, Feb 5, 2015 at 9:49 AM, John Bradley  wrote:

Inline


> On Feb 4, 2015, at 10:43 PM, Manger, James  
> wrote:
>
>>    Title           : Proof Key for Code Exchange by OAuth Public Clients
>>      Filename        : draft-ietf-oauth-spop-09.txt
>> https://tools.ietf.org/html/draft-ietf-oauth-spop-09
>
>
> Some nits on this draft:
>
> 1. 42 chars.
> The lower limit of 42 chars for code_verifier: is not mentioned in prose 
> (just the upper limit); is too high (128-bits=22-chars is sufficient); and 
> doesn't correspond to 256-bits (BASE64URL-ENCODE(32 bytes) gives 43 chars, 
> not 42).

In my editors draft I fixed the 43 octet base64url encoding of 32bytes.  I 
originally had 43 but it got changed at some point

Is there working group feedback on making the lower limit clear in the prose 
and if so what should it be?  22-chars (128 bits) or 43 char (256 bits)?


>
> 2.
> Quotes around "code_verifier" and "code_challenge" in prose are okay, though 
> not really necessary as the underscore is enough to distinguish them as 
> technical labels. Quotes around these terms in formula is bad as it looks 
> like the formula applies to the 13 or 14 chars of the label. The quoting is 
> also used inconsistently.
> Suggestion: remove all quotes around "code_verifier" and "code_challenge" in 
> prose and formula.
> For example, change ASCII("code_verifier") to ASCII(code_verifier).
>

I am going to leave this for a later formatting cleanup at the moment, I need 
to find a good style compromise that works with rfcmarkup.

> 3.
> Two ways to check code_verifier are given in appendix B, whereas only one of 
> these is mentioned in section 4.6.
>  SHA256(verifier) === B64-DECODE(challenge)
>  B64-ENCODE(SHA256(verifier)) === challenge
>
> I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and drop the 
> 1st from appendix B). It is simpler to mention only one. It also means 
> base64url-decoding is never done, and doesn't need to be mentioned in the 
> spec.
>
Yes when I added the example I realized that the normative text was the more 
complicated way to do the comparison.

I will go back and refactor the main text to talk about the simpler comparison 
and drop the base64url-decode references.
>
> 4.
> Expand "MTI" to "mandatory to implement".

Done in editors draft.
>
> P.S. Suggesting code challenge method names not exceed 8 chars to be compact 
> is a bit perverse given the field holding these values has the long name 
> "code_challenge_method" ;)

  On the topic of the parameter  name  "code_challange_method",  James has a 
point in that it is a bit long.

We could shorten it to "ccm".   If we want to change the name sooner is better 
than later.

It is that balance between compactness and clear parameter names for 
developers, that we keep running into.

I don't know that encouraging longer parameter values is the best direction.

Feedback please

John B.
>
> --
> James Manger
>
> ___
> 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-WG] Feedback Re: I-D Action: draft-ietf-oauth-spop-06.txt

[Bill Mills]

7.2 --  "If the server does not support PKCE, it does not generate error." 
should read "If the server does not support PKCE it does not generate an error."
Otherwise read to go in my opinion. 

 On Wednesday, January 21, 2015 6:23 PM, "internet-dra...@ietf.org" 
 wrote:
   

 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Authorization Protocol 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-06.txt
    Pages          : 16
    Date            : 2015-01-21

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.


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:
http://tools.ietf.org/html/draft-ietf-oauth-spop-06

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


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

Re: [OAUTH-WG] Fwd: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18

[Bill Mills]

3 items fixed, thank you 

 On Friday, January 2, 2015 7:01 AM, "Ebling, Sebastian" 
 wrote:
   

 Hello,

There is a little typo in Section 3.2.2:
Replace "The URL for for a document" with "The URL for a document".


Section 3. contains
"2.  Server responds with a successful authentication.

  In the case where authorization fails the server sends an error
  result, then client MUST then send an additional message to the
  server in order to allow the server to finish the exchange."
There is a switch between authentication and authorization. Even if the access 
token represents authorization information I suggest to write "In the case 
where authentication fails" because it is more consistent here.

Section 3.2.2. introduces "oauth-configuration", the example in section 4.3 
uses "openid-configuration".

Regards

Sebastian Ebling


Von: OAuth [mailto:oauth-boun...@ietf.org] Im Auftrag von Bill Mills
Gesendet: Montag, 29. Dezember 2014 18:46
An: oauth@ietf.org
Betreff: Re: [OAUTH-WG] Fwd: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18

No other comments on this?  Any "It's ready to go."?

On Monday, December 15, 2014 9:34 AM, Benjamin Kaduk  wrote:

Hi all,

There may be some interested parties over here; please feel free to chime
in on this WGLC over on the kitten list.

-Ben

-- Forwarded message --
Date: Mon, 15 Dec 2014 12:14:30 -0500
From: Benjamin Kaduk 
To: kit...@ietf.org
Cc: kitten-cha...@tools.ietf.org
Subject: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18

This message begins the fourth Working Group Last Call (WGLC) of "A set of
SASL Mechanisms for OAuth" .  Due to
the overlap of the last call period with holidays, the duration of the
WGLC is extended to four weeks, so the WGLC will end on 12 January 2015.
The draft is available at:

https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18

Because the changes between -15 and -18 involve behavior changes,
including changes regarding discovery and dynamic registration, the Chairs
decided to issue an additional last call.

Please review the document and send comments to the Working Group
mailing list < kitten at itef.org > or the co-chairs < kitten-chairs
at tools.ietf.org > before the end of the WGLC.  Any and all comments
on the document are sought in order to access the strength of
consensus.  Even if you have read and commented on this or earlier
versions of the draft, please feel free to comment again.  This is
particularly important if you found issues with the previous version.

As a reminder, comments can be anything from "this looks fine" to
"this is a horrible idea"; they can include suggestions for minor
editorial corrections to significant editorial changes.


- Your Kitten Chairs

___
Kitten mailing list
kit...@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

___
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] Fwd: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18

[Bill Mills]

Thank you both for the feedback. 

 On Tuesday, December 30, 2014 5:28 AM, John Bradley  
wrote:
   

 I have been tracking it.  It is ready. 

Sent from my iPhone

> On Dec 15, 2014, at 2:33 PM, Benjamin Kaduk  wrote:
> 
> Hi all,
> 
> There may be some interested parties over here; please feel free to chime
> in on this WGLC over on the kitten list.
> 
> -Ben
> 
> -- Forwarded message --
> Date: Mon, 15 Dec 2014 12:14:30 -0500
> From: Benjamin Kaduk 
> To: kit...@ietf.org
> Cc: kitten-cha...@tools.ietf.org
> Subject: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18
> 
> This message begins the fourth Working Group Last Call (WGLC) of "A set of
> SASL Mechanisms for OAuth" .  Due to
> the overlap of the last call period with holidays, the duration of the
> WGLC is extended to four weeks, so the WGLC will end on 12 January 2015.
> The draft is available at:
> 
> https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18
> 
> Because the changes between -15 and -18 involve behavior changes,
> including changes regarding discovery and dynamic registration, the Chairs
> decided to issue an additional last call.
> 
> Please review the document and send comments to the Working Group
> mailing list < kitten at itef.org > or the co-chairs < kitten-chairs
> at tools.ietf.org > before the end of the WGLC.  Any and all comments
> on the document are sought in order to access the strength of
> consensus.  Even if you have read and commented on this or earlier
> versions of the draft, please feel free to comment again.  This is
> particularly important if you found issues with the previous version.
> 
> As a reminder, comments can be anything from "this looks fine" to
> "this is a horrible idea"; they can include suggestions for minor
> editorial corrections to significant editorial changes.
> 
> 
> - Your Kitten Chairs
> 
> ___
> Kitten mailing list
> kit...@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten
> 
> ___
> 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] Fwd: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18

[Bill Mills]

No other comments on this?  Any "It's ready to go."? 

 On Monday, December 15, 2014 9:34 AM, Benjamin Kaduk  wrote:
   

 Hi all,

There may be some interested parties over here; please feel free to chime
in on this WGLC over on the kitten list.

-Ben

-- Forwarded message --
Date: Mon, 15 Dec 2014 12:14:30 -0500
From: Benjamin Kaduk 
To: kit...@ietf.org
Cc: kitten-cha...@tools.ietf.org
Subject: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18

This message begins the fourth Working Group Last Call (WGLC) of "A set of
SASL Mechanisms for OAuth" .  Due to
the overlap of the last call period with holidays, the duration of the
WGLC is extended to four weeks, so the WGLC will end on 12 January 2015.
The draft is available at:

https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18

Because the changes between -15 and -18 involve behavior changes,
including changes regarding discovery and dynamic registration, the Chairs
decided to issue an additional last call.

Please review the document and send comments to the Working Group
mailing list < kitten at itef.org > or the co-chairs < kitten-chairs
at tools.ietf.org > before the end of the WGLC.  Any and all comments
on the document are sought in order to access the strength of
consensus.  Even if you have read and commented on this or earlier
versions of the draft, please feel free to comment again.  This is
particularly important if you found issues with the previous version.

As a reminder, comments can be anything from "this looks fine" to
"this is a horrible idea"; they can include suggestions for minor
editorial corrections to significant editorial changes.


- Your Kitten Chairs

___
Kitten mailing list
kit...@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

___
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-signed-http-request-00.txt

[Bill Mills]

Ah yes, I am remembering vague snatches of that Sunday meeting we had in London.
In 3.1 it states you have to use a hash function of equal size to the JWT 
wrapper's.  Why don't we just specify that the same function must be used?
Why include a timestamp explicitly here when we could use the Date header?
There's no nonce included in anything here, was that an explicit decision?
How is line continuation handled for header values?  This should probably be 
explicit about that.
Repeated headers...  "Repeated header names are processed separately with no 
special handling." this wants to be clearer.  Does this mean you repeated a 
header name in the list?  (which explicitly should not be allowed).  I think 
this needs to explicitly say "If a header name is specified then all headers 
with the same name must be processed for that header.".  The next question is 
ordering, will any frameworks or proxies re-order headers of the same name?  If 
so then we probably have to produce a sorted list of headers.  
Do we need to handle repeated parameter values explicitly?  
-bill 

 On Monday, December 22, 2014 8:26 AM, "Richer, Justin P." 
 wrote:
   

 Yes it did, as part of the PoP suite. It's the current stab at an HTTP 
presentation mechanism for PoP tokens.
 -- Justin
On Dec 22, 2014, at 11:21 AM, Bill Mills  wrote:

Did this get adopted as a WG item already and I missed it?

On Monday, December 22, 2014 4:33 AM, Justin Richer  wrote:


That's easy: any headers. That's why the signer specifies which ones. Would be 
good to have since guidance tough, and examples. 

-- Justin
/ Sent from my phone /

 Original message 
From: Sergey Beryozkin 
Date:12/22/2014 7:08 AM (GMT-05:00) 
To: oauth@ietf.org 
Cc: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00.txt 

Hi Justin

I see a fair bit of interest toward this work now being shown from my 
colleagues; it would help if the next draft could clarify which HTTP 
headers can be signed given it is difficult to get hold of some of HTTP 
headers typically created by a low level HTTP transport component.

Thanks, Sergey

On 21/07/14 14:58, internet-dra...@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>   This draft is a work item of the Web Authorization Protocol Working Group 
>of the IETF.
>
>  Title   : A Method for Signing an HTTP Requests for OAuth
>  Authors : Justin Richer
>    John Bradley
>    Hannes Tschofenig
> Filename    : draft-ietf-oauth-signed-http-request-00.txt
> Pages   : 11
> Date    : 2014-07-21
>
> Abstract:
> This document a method for offering data origin authentication and
> integrity protection of HTTP requests.  To convey the relevant data
> items in the request a JSON-based encapsulation is used and the JSON
> Web Signature (JWS) technique is re-used.  JWS offers integrity
> protection using symmetric as well as asymmetric cryptography.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00
>
>
> 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


___
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-signed-http-request-00.txt

[Bill Mills]

Did this get adopted as a WG item already and I missed it? 

 On Monday, December 22, 2014 4:33 AM, Justin Richer  
wrote:
   

 That's easy: any headers. That's why the signer specifies which ones. Would be 
good to have since guidance tough, and examples. 

-- Justin
/ Sent from my phone /

 Original message 
From: Sergey Beryozkin  
Date:12/22/2014 7:08 AM (GMT-05:00) 
To: oauth@ietf.org 
Cc: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00.txt 

Hi Justin

I see a fair bit of interest toward this work now being shown from my 
colleagues; it would help if the next draft could clarify which HTTP 
headers can be signed given it is difficult to get hold of some of HTTP 
headers typically created by a low level HTTP transport component.

Thanks, Sergey

On 21/07/14 14:58, internet-dra...@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>   This draft is a work item of the Web Authorization Protocol Working Group 
>of the IETF.
>
>  Title   : A Method for Signing an HTTP Requests for OAuth
>  Authors : Justin Richer
>    John Bradley
>    Hannes Tschofenig
> Filename    : draft-ietf-oauth-signed-http-request-00.txt
> Pages   : 11
> Date    : 2014-07-21
>
> Abstract:
> This document a method for offering data origin authentication and
> integrity protection of HTTP requests.  To convey the relevant data
> items in the request a JSON-based encapsulation is used and the JSON
> Web Signature (JWS) technique is re-used.  JWS offers integrity
> protection using symmetric as well as asymmetric cryptography.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-00
>
>
> 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


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

Re: [OAUTH-WG] SPOP: Code Challenge Discussion

[Bill Mills]

Quoting from 7.1 
"It is RECOMMENDED that the output of a suitable random number generator be 
used to create a 32-octet sequence."
So the spec is already recommending 256 bits of randomness, is that language 
not clear enough? 

 On Wednesday, December 3, 2014 3:17 AM, Hannes Tschofenig 
 wrote:
   

 Hi all,

I am trying to figure out how to progress the SPOP document and
therefore I read through the discussion about the code challenge, see

I wanted to share my view about this topic.

As a summary, the mechanism works as follows:

C: Compute code_verifier:=rand()
C: Compute code_challenge:=func(code_verifier)

(For this discussion, the function func() is SHA-256.)

C: Send(Authz Request + code_challenge,S)

S: store code_challenge
S: Send(Authz Grant,C)

C: Send(Access Token Request || code_verifier, S)

S: Compute code_challenge':=func(code_verifier)
S: IF (code_challenge'==code_challenge) THEN SUCCESS ELSE FAIL.

The document currently does not say how much entropy the random number
has to have.

The text only talks about the output size and SHA-256 indeed produces a
256 bit output.

Here is the relevant text:

"
  NOTE: code verifier SHOULD have enough entropy to make it impractical
  to guess the value.  It is RECOMMENDED that the output of a suitable
  random number generator be used to create a 32-octet sequence.
"

I suggest to recommend at least 128 bits, which is inline with the
recommendations for symmetric ciphers in
http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07

I would also suggest to reference RFC 4086 concerning the creation of
random numbers.

Furthermore, since you allow other hash functions to be used as well it
would be good to give guidance about what the properties of those hash
functions should be. You definitely want a cryptographic hash function
that provides pre-image resistance, second pre-image resistance, and
collision resistance.

Given the size of the input and output it is impractical to compute a
table that maps code_verifies to code_challenges.

This mechanism provides better properties than the "plain" mechanism
since it deals with an attacker that can see responses as well as
requests (but cannot modify them). It does not provide any protection
against a true man-in-the-middle attacker.

Ciao
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] Review of draft-ietf-oauth-introspection-01

[Bill Mills]

+1 for "Making authentication to the introspection endpoint a MUST if 
additional attributes are present is OK" 

 On Tuesday, December 2, 2014 12:15 PM, John Bradley  
wrote:
   

 Many of the proprietary introspection protocols in use return scope, role or 
other meta data for the RS to make its access policy decision on.One of the 
reasons for using opaque tokens rather than JWT is to prevent leakage of that 
info.
Making authentication to the introspection endpoint a MUST if additional 
attributes are present is OK,  I might even be inclined to say that 
authentication of some sort is always required, but that might be going a bit 
far for some use cases.
We have a lot of proprietary ways to do this from IBM, Layer 7, Ping etc.  It 
would be nice if we could standardize it.   Precluding other attributes would 
not be helpful for adoption.

One issue that we haven’t addressed in this spec is what happens if there are 
multiple AS for the RS and how it would decide what introspection endpoint to 
use.Perhaps that needs to be a extension, leaving this for the simple case.
However having more than on e AS per RS is not as unusual as it once was in 
larger environments.
John B.


On Dec 2, 2014, at 4:56 PM, Richer, Justin P.  wrote:

Agreed, which is why we've got space for the "sub" and "user_id" fields but not 
anything else about the user, and we've got a privacy considerations section 
for dealing with that. If you can help make the wording on that section 
stronger, I'd appreciate it.
 -- Justin
On Dec 2, 2014, at 2:25 PM, Bill Mills  wrote:

If introspection returns any other user data beyond what is strictly required 
to validate the token based solely on possession of the public part it would be 
a mistake.

On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P."  
wrote:


That's all fine -- it's all going over TLS anyway (RS->AS) just like the 
original token fetch by the client (C->AS). Doesn't mean you need TLS *into* 
the RS (C->RS) with a good PoP token. 
Can you explain how this is related to "act on behalf of"? I don't see any 
connection.
 -- Justin
On Dec 2, 2014, at 2:09 PM, Bill Mills  wrote:

Fetching the public key for a token might be fine, but what if the 
introspection endpoint returns the symmetric key?  Data about the user?  Where 
does this blur the line between this and "act on behalf of"?

On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P."  
wrote:


The call to introspection has a TLS requirement, but the call to the RS 
wouldn't necessarily have that requirement. The signature and the token 
identifier are two different things. The identifier doesn't do an attacker any 
good on its own without the verifiable signature that's associated with it and 
the request. What I'm saying is that you introspect the identifier and get back 
something that lets you, the RS, check the signature.
 -- Justin
On Dec 2, 2014, at 1:40 PM, Bill Mills  wrote:

"However, I think it's very clear how PoP tokens would work. ..."
I don't know if that's true.  POP tokens (as yet to be fully defined) would 
then also have a TLS or transport security requirement unless there is token 
introspection client auth in play I think.  Otherwise I can as an attacker take 
that toklen and get info about it that might be useful, and I don't think 
that's what we want.
-bill










___
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] Review of draft-ietf-oauth-introspection-01

[Bill Mills]

If introspection returns any other user data beyond what is strictly required 
to validate the token based solely on possession of the public part it would be 
a mistake. 

 On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." 
 wrote:
   

 That's all fine -- it's all going over TLS anyway (RS->AS) just like the 
original token fetch by the client (C->AS). Doesn't mean you need TLS *into* 
the RS (C->RS) with a good PoP token. 
Can you explain how this is related to "act on behalf of"? I don't see any 
connection.
 -- Justin
On Dec 2, 2014, at 2:09 PM, Bill Mills  wrote:

Fetching the public key for a token might be fine, but what if the 
introspection endpoint returns the symmetric key?  Data about the user?  Where 
does this blur the line between this and "act on behalf of"?

On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P."  
wrote:


The call to introspection has a TLS requirement, but the call to the RS 
wouldn't necessarily have that requirement. The signature and the token 
identifier are two different things. The identifier doesn't do an attacker any 
good on its own without the verifiable signature that's associated with it and 
the request. What I'm saying is that you introspect the identifier and get back 
something that lets you, the RS, check the signature.
 -- Justin
On Dec 2, 2014, at 1:40 PM, Bill Mills  wrote:

"However, I think it's very clear how PoP tokens would work. ..."
I don't know if that's true.  POP tokens (as yet to be fully defined) would 
then also have a TLS or transport security requirement unless there is token 
introspection client auth in play I think.  Otherwise I can as an attacker take 
that toklen and get info about it that might be useful, and I don't think 
that's what we want.
-bill








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

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

[Bill Mills]

Fetching the public key for a token might be fine, but what if the 
introspection endpoint returns the symmetric key?  Data about the user?  Where 
does this blur the line between this and "act on behalf of"? 

 On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." 
 wrote:
   

 The call to introspection has a TLS requirement, but the call to the RS 
wouldn't necessarily have that requirement. The signature and the token 
identifier are two different things. The identifier doesn't do an attacker any 
good on its own without the verifiable signature that's associated with it and 
the request. What I'm saying is that you introspect the identifier and get back 
something that lets you, the RS, check the signature.
 -- Justin
On Dec 2, 2014, at 1:40 PM, Bill Mills  wrote:

"However, I think it's very clear how PoP tokens would work. ..."
I don't know if that's true.  POP tokens (as yet to be fully defined) would 
then also have a TLS or transport security requirement unless there is token 
introspection client auth in play I think.  Otherwise I can as an attacker take 
that toklen and get info about it that might be useful, and I don't think 
that's what we want.
-bill




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

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

[Bill Mills]

"However, I think it's very clear how PoP tokens would work. ..." 
I don't know if that's true.  POP tokens (as yet to be fully defined) would 
then also have a TLS or transport security requirement unless there is token 
introspection client auth in play I think.  Otherwise I can as an attacker take 
that toklen and get info about it that might be useful, and I don't think 
that's what we want.
-bill


 On Tuesday, December 2, 2014 6:06 AM, Justin Richer  
wrote:
   

  Hannes, thanks for the review. Comments inline.
 
 On 12/2/2014 6:23 AM, Hannes Tschofenig wrote:
  
 Hi Justin,

I have a few remarks regarding version -01 of the token introspection
document.

* Terminology

The token introspection protocol is a client-server protocol but the
term "client" already has a meaning in OAuth. Here the client of the
token introspection protocol is actually the resource server. I believe
it would make sense to clarify this issue in the terminology section or
in the introduction. Maybe add a figure (which you could copy from
Figure 4 of
http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt.

Maybe you want to call these two parties, the introspection client and
the introspection server. 
 
 I tried to avoid the word "client" for this very reason. The draft used to say 
"client or protected resource" throughout, but in a few years of deployment 
experience it's become clear that it's pretty much just protected resources 
that need to do introspection so I changed that text throughout. I don't think 
that "introspection client" will help here because the party already has a name 
from OAuth and we should inherit it.
 
 
 * Scope

I think the document needs to be very clear that is only applicable to
bearer tokens (and not to PoP tokens). This issue was raised at the last
IETF meeting as well. 
 
 I think the document should be clear that it *specifies* the mechanism for 
bearer tokens, since that's the only OAuth token type that's defined publicly 
right now, and that the details for PoP will have to be specified in another 
spec -- that's exactly what Appendix C is there for, and if that can be 
clearer, please suggest better text.
 
 However, I think it's very clear how PoP tokens would work. You send the value 
returned as the "access_token" in the token endpoint response, which is 
effectively the public portion of the PoP token. Just like a bearer token, this 
value is passed as-is from the client to the RS and would be passed as-is from 
the RS to the AS during introspection. The AS can then use that to look up the 
key and return it in an as-yet-unspecified field so that the RS can validate 
the request. The RS wouldn't send the signature or signed portion of the 
request for the AS to validate -- that's a bad idea. But these are all details 
that we can work out in the PoP-flavored extension. As I noted in the other 
thread, we'll have to make a similar extension for Revocation, so I still don't 
think it makes sense to hold up this work and wait for PoP to be finished 
because it's useful now, as-is.
 
 
 * Meta-Information

You have replicated a lot of the claims defined in
https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31
and I am wondering why you have decided to not just re-use the entire
registry from JWT?

If you want to create a separate registry (which I wouldn't recommend)
then you have to put text into the IANA consideration section. 
 
 The idea was to inherit JWT's syntax and semantics, at least on the wire, and 
add additional fields. It probably makes sense to just inherit the JWT 
registry, so we can do that.
 
 
 When you write:

"
The endpoint MAY allow other parameters to provide further context to
the query.
"

You could instead write that the token introspection MUST ignore any
parameters from the request message it does not understand. 
 
 Noted, will add.
 
 
 Of course, there is the question whether any of those would be security
critical and hence ignoring them would cause problems?! 
 
 Anything security critical would be provider-specific, in which case it 
wouldn't ignore them. 
 
 
 * Security

The requirement for authenticating the party issuing the introspection
request to the token introspection endpoint is justified in the security
and the privacy consideration section. The security threat is that an
attacker could use the endpoint to testing for tokens. The privacy
threat is that a resource server learns about the content of the token,
which may contain personal data. I see the former as more dangerous than
the latter since a legitimate resource server is supposed to learn about
the authorization information in the token. An attacker who had gotten
hold of tokens will not only learn about the content of the token but he
will also be able to use it to get access to the protected resource itself.

In any case, to me this sounds like mutual authentication should be
mandatory to implement. This is currently not the case. On top of that
there is singl

Re: [OAUTH-WG] OAuth in the news again....

[Bill Mills]

I think the motion here is going to be social/legal and not standards based.  
We can preach on this all we want, but in the end folks like the EFF and major 
privacy watchdogs will carry the water here. 

 On Monday, December 1, 2014 5:02 PM, Nat Sakimura  
wrote:
   

 Indeed, and there are commercial incentives for it. 
I have doubts about the legal effectiveness of such consent but that is the 
de-facto situation right now. On the longer run, there are initiatives like 
information sharing and consent WG at Kantara and ISO/IEC SC 27/WG 5 study 
group on notice and consent which hopefully would emerge with a better model 
but that only helps the future and not now. 
Do you have some suggestions to help the situation in the mean time? 
On Tue Dec 02 2014 at 9:51:39 Bill Mills  wrote:

Mis-stated perhaps, but it's highlighting a core problem we punt on at the 
protocol layer.  FB as the example here tries to make teh friction of using a 
FB login as low as possible, and so the user consent stuff is dialed down to 
the very minimum of acceptable.  This is the common pattern, get a user consent 
and you're covered legally and then the drive is to make that consent as 
minimally invasive (read effective) as possible.


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

Re: [OAUTH-WG] OAuth in the news again....

[Bill Mills]

Mis-stated perhaps, but it's highlighting a core problem we punt on at the 
protocol layer.  FB as the example here tries to make teh friction of using a 
FB login as low as possible, and so the user consent stuff is dialed down to 
the very minimum of acceptable.  This is the common pattern, get a user consent 
and you're covered legally and then the drive is to make that consent as 
minimally invasive (read effective) as possible.___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth in the news again....

[Bill Mills]

that link does not contain the quoted text.  Also the quoted text isn't wrong 
when you look at the FB OAuth usage and how users actually use it. 

 On Monday, December 1, 2014 8:42 AM, Kathleen Moriarty 
 wrote:
   

 Hi Hannes,

When something is written up and agreed upon, I'd recommend that we
tweet about it in force to get the writeup some attention in an effort
to help prevent this in the future.  I could blog about it in the IESG
blogs too if helpful.

On Mon, Dec 1, 2014 at 11:25 AM, Hannes Tschofenig
 wrote:
> Hi all,
>
> I fear we have to write another article to clarify what OAuth does and
> what it does not do based on the misinformation spread with this recent
> article:
> http://www.techopedia.com/definition/26694/oauth
>
> A quote from that article:
> "
> Graham Williams, a Vancouver-based technology expert, points to what is
> known as an "open authentication protocol" — or OAuth — where people
> often unwittingly share personal information with third-party websites.
> "
>
> Ciao
> Hannes
>
>
> ___
> 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


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

Re: [OAUTH-WG] draft-ietf-oauth-spop-04: a way of making code_challenge

[Bill Mills]

In this case it ceaper to add bits than use soemthing like BCrypt.



On Monday, November 17, 2014 9:33 PM, John Bradley  wrote:
I think where we are differing is that you think looking up a precomputed plain 
based on a indexed hash across some sort of media can be done faster than 3 
Giga SHA256 Hash/s.
on a small system http://thepasswordproject.com/oclhashcat_benchmarking 

I don't think the largest disk arrays can keep up with that.

Do you have some evidence that shows that precomputing hashes would be an 
effective attack against 256 bits of entropy.   I agree that it would be agains 
the 40 ish bits of entropy in a password.

The likely mitigation is using PBKDF2 or BCrypt rather than SHA256, but that 
would slow adoption and can be added later.

John B.




My contention is that it can't 

> On Nov 17, 2014, at 10:27 PM, takamichi saito  wrote:
> 
> 
> I agree that GPU can/may find the value on the fly.
> But, it can not find it within the session.
> The draft idea is enough against the attack with GPU.
> 
> On the other, the draft idea provide ONLY one combination of hash and its 
> plain. The attacker can prepare THE COMBINATION to success the attack.
> 
> Adding client_ID or server_ID separate the searching space.
> Then the attacker have to find the value in each case for the attack.
> (The reason was said before.)
> 
> 
> (2014/11/17 13:33), John Bradley wrote:
>> The question is what is the attack.
>> 
>> Any salt added needs to be communicated from the client to the AS, so we
>> must assume that the attacker has it.
>> 
>> The attacker can then a) create rainbow table using the client id or
>> whatever is the known salt.  Yes the attacker  must create a new table
>> per client.
>> Salting is really only effective for low entropy passwords to try and
>> slow down a rainbow table attack by making the input to the hash be
>> higher than the that of the password on it's own.
>> 
>> Currently attackers can generate over 4Billion SHA256 hashes per second
>> on a single GPU card.  (Thank you bitcoin)
>> 
>> It is faster to generate the hashes than to look them up via a index.
>> 
>> If you are generating the hash in real time salting provides no
>> determent, as the salt is just included in the hash calculation.
>> 
>> If the code verifier was a password rather than a 256bit random key then
>> a hash would add value against rainbow tables.
>> 
>> In reality finding a collision against a salted password is much easier
>> using real time hash generation than by using rainbow tables.
>> 
>> Using SHA256 with a short hash is not safe for passwords any more.
>> Something like PBES2 with at-least 200 rounds needs to be used, if you
>> want have password files from being compromised quickly if disclosed.
>>  (Yes I know people are not doing that,  and hence part of the reason
>> why passwords are no longer secure)
>> 
>> More entropy in the code verifier adds to security eg moving to SHA512
>> and larger verifiers, but adding a salt to SHA256 is basically a no op
>> when defending against modern attacks.
>> 
>> I did originally agree with your position and wanted to HMAC the
>> client_id to defend against rainbow tables, however I am now convinced
>> that the attack has moved on so that is no more efective than a plain
>> hash over a random 256bit value.
>> 
>> John B.
>> 
>>> On Nov 16, 2014, at 11:06 PM, Nat Sakimura >> <mailto:sakim...@gmail.com>> wrote:
>>> 
>>> I am actually not convinced. Since the code verifier is 256bit random,
>>> adding salt does not seem to help.
>>> Salting definitely helps if len(password) << 256 bit, but ...
>>> 
>>> 
>>> On Mon Nov 17 2014 at 11:39:07 takamichi saito >> <mailto:sa...@cs.meiji.ac.jp>> wrote:
>>> 
>>> 
>>> 
>>>(2014/11/14 13:02), Bill Mills wrote:
>>>> Yes, "plain" is actually sufficient.  The hashed value protects
>>>against
>>>> disclosure/logging threats on the server auth server and proxies
>>>perhaps
>>>> where the HTTPS is terminated somewhere other than the auth server
>>>> itself, it's not actually required for the basic
>>>functionality/security
>>>> of the mechanism.
>>> 
>>>In the threat model of the SPOP scheme, a wiretap is in it.
>>> 
>>>And more, the hash is not used to keep secretly in the sever/client.
>>> 
>>> 
>>>>
>>>>
>>>> On Thursday, N

Re: [OAUTH-WG] draft-ietf-oauth-spop-04: a way of making code_challenge

[Bill Mills]

There will be no rainbow table for 256bits of search space.  Suppose then that 
clientID has 256 possible values.  How does salting with client ID do anything 
more than making the search space 264 bits?

You keep saying that a salt is better than just adding entropy, but never 
actually justifying it.



On Monday, November 17, 2014 8:34 PM, takamichi saito  
wrote:
(2014/11/18 13:17), Bill Mills wrote:
> Again, the only value of including client ID or any other value in this case 
> is to increase the number of bits of entropy in the value being hashed. Using 
> client ID is only useful if it's actually got decent entropy in it, if it's 
> just a version number then or a server name or address it adds very little.
>

Client_ID is not for adding entropy.
Again, Client_ID is separating the attacker's searching space.

> Yes, salting is valuable for passwords which have very low entropy.  But as 
> has been discussed it adds little in this case.  Your arguments are correct 
> for passwords but not for 256 bits of random number.
>

I agree that human-made password is low entropy.
As I say, adding Client_ID can force the attacker has to search the 
value in each attack.
If the attacker uses GPU, he can not get the value within the session.

I never confuse about password in these discussions.



> Regards,
>
> -bill
>
>
>
> On Monday, November 17, 2014 7:27 PM, takamichi saito  
> wrote:
>
> I agree that GPU can/may find the value on the fly.
> But, it can not find it within the session.
> The draft idea is enough against the attack with GPU.
>
> On the other, the draft idea provide ONLY one combination of hash and
> its plain. The attacker can prepare THE COMBINATION to success the attack.
>
> Adding client_ID or server_ID separate the searching space.
> Then the attacker have to find the value in each case for the attack.
> (The reason was said before.)
>
>
> (2014/11/17 13:33), John Bradley wrote:
>> The question is what is the attack.
>>
>> Any salt added needs to be communicated from the client to the AS, so we
>> must assume that the attacker has it.
>>
>> The attacker can then a) create rainbow table using the client id or
>> whatever is the known salt.  Yes the attacker  must create a new table
>> per client.
>> Salting is really only effective for low entropy passwords to try and
>> slow down a rainbow table attack by making the input to the hash be
>> higher than the that of the password on it's own.
>>
>> Currently attackers can generate over 4Billion SHA256 hashes per second
>> on a single GPU card.  (Thank you bitcoin)
>>
>> It is faster to generate the hashes than to look them up via a index.
>>
>> If you are generating the hash in real time salting provides no
>> determent, as the salt is just included in the hash calculation.
>>
>> If the code verifier was a password rather than a 256bit random key then
>> a hash would add value against rainbow tables.
>>
>> In reality finding a collision against a salted password is much easier
>> using real time hash generation than by using rainbow tables.
>>
>> Using SHA256 with a short hash is not safe for passwords any more.
>> Something like PBES2 with at-least 200 rounds needs to be used, if you
>> want have password files from being compromised quickly if disclosed.
>>(Yes I know people are not doing that,  and hence part of the reason
>> why passwords are no longer secure)
>>
>> More entropy in the code verifier adds to security eg moving to SHA512
>> and larger verifiers, but adding a salt to SHA256 is basically a no op
>> when defending against modern attacks.
>>
>> I did originally agree with your position and wanted to HMAC the
>> client_id to defend against rainbow tables, however I am now convinced
>> that the attack has moved on so that is no more efective than a plain
>> hash over a random 256bit value.
>>
>> John B.
>>
>>> On Nov 16, 2014, at 11:06 PM, Nat Sakimura >> <mailto:sakim...@gmail.com>> wrote:
>>>
>>> I am actually not convinced. Since the code verifier is 256bit random,
>>> adding salt does not seem to help.
>>> Salting definitely helps if len(password) << 256 bit, but ...
>>>
>>>
>>> On Mon Nov 17 2014 at 11:39:07 takamichi saito >> <mailto:sa...@cs.meiji.ac.jp>> wrote:
>>>
>>>
>>>
>>>  (2014/11/14 13:02), Bill Mills wrote:
>>>  > Yes, "plain" is actually sufficient.  The hashed value protects
>>>  against
>>>  > disclosure/logging th

Re: [OAUTH-WG] draft-ietf-oauth-spop-04: a way of making code_challenge

[Bill Mills]

Again, the only value of including client ID or any other value in this case is 
to increase the number of bits of entropy in the value being hashed. Using 
client ID is only useful if it's actually got decent entropy in it, if it's 
just a version number then or a server name or address it adds very little.

Yes, salting is valuable for passwords which have very low entropy.  But as has 
been discussed it adds little in this case.  Your arguments are correct for 
passwords but not for 256 bits of random number.

Regards,

-bill 



On Monday, November 17, 2014 7:27 PM, takamichi saito  
wrote:

I agree that GPU can/may find the value on the fly.
But, it can not find it within the session.
The draft idea is enough against the attack with GPU.

On the other, the draft idea provide ONLY one combination of hash and 
its plain. The attacker can prepare THE COMBINATION to success the attack.

Adding client_ID or server_ID separate the searching space.
Then the attacker have to find the value in each case for the attack.
(The reason was said before.)


(2014/11/17 13:33), John Bradley wrote:
> The question is what is the attack.
>
> Any salt added needs to be communicated from the client to the AS, so we
> must assume that the attacker has it.
>
> The attacker can then a) create rainbow table using the client id or
> whatever is the known salt.  Yes the attacker  must create a new table
> per client.
> Salting is really only effective for low entropy passwords to try and
> slow down a rainbow table attack by making the input to the hash be
> higher than the that of the password on it's own.
>
> Currently attackers can generate over 4Billion SHA256 hashes per second
> on a single GPU card.  (Thank you bitcoin)
>
> It is faster to generate the hashes than to look them up via a index.
>
> If you are generating the hash in real time salting provides no
> determent, as the salt is just included in the hash calculation.
>
> If the code verifier was a password rather than a 256bit random key then
> a hash would add value against rainbow tables.
>
> In reality finding a collision against a salted password is much easier
> using real time hash generation than by using rainbow tables.
>
> Using SHA256 with a short hash is not safe for passwords any more.
> Something like PBES2 with at-least 200 rounds needs to be used, if you
> want have password files from being compromised quickly if disclosed.
>   (Yes I know people are not doing that,  and hence part of the reason
> why passwords are no longer secure)
>
> More entropy in the code verifier adds to security eg moving to SHA512
> and larger verifiers, but adding a salt to SHA256 is basically a no op
> when defending against modern attacks.
>
> I did originally agree with your position and wanted to HMAC the
> client_id to defend against rainbow tables, however I am now convinced
> that the attack has moved on so that is no more efective than a plain
> hash over a random 256bit value.
>
> John B.
>
>> On Nov 16, 2014, at 11:06 PM, Nat Sakimura > <mailto:sakim...@gmail.com>> wrote:
>>
>> I am actually not convinced. Since the code verifier is 256bit random,
>> adding salt does not seem to help.
>> Salting definitely helps if len(password) << 256 bit, but ...
>>
>>
>> On Mon Nov 17 2014 at 11:39:07 takamichi saito > <mailto:sa...@cs.meiji.ac.jp>> wrote:
>>
>>
>>
>> (2014/11/14 13:02), Bill Mills wrote:
>> > Yes, "plain" is actually sufficient.  The hashed value protects
>> against
>> > disclosure/logging threats on the server auth server and proxies
>> perhaps
>> > where the HTTPS is terminated somewhere other than the auth server
>> > itself, it's not actually required for the basic
>> functionality/security
>> > of the mechanism.
>>
>> In the threat model of the SPOP scheme, a wiretap is in it.
>>
>> And more, the hash is not used to keep secretly in the sever/client.
>>
>>
>> >
>> >
>> > On Thursday, November 13, 2014 7:07 PM, takamichi saito
>> > mailto:sa...@cs.meiji.ac.jp>> wrote:
>> >
>> >
>> > Sorry for my poor english.
>> >
>> >
>> > 2014/11/14 10:55、Bill Mills > <mailto:wmills_92...@yahoo.com>
>> > <mailto:wmills_92...@yahoo.com
>> <mailto:wmills_92...@yahoo.com>__>> のメール：
>> >
>> >  > The whole mechanism relies on the attacker not having access
>> to the
>> > code_verifier or hash.  It's defending against the attacker
&

Re: [OAUTH-WG] Adding machine readable errors to SPOP?

[Bill Mills]

I sent some feedback on that section in a different message on list. 

 On Friday, November 14, 2014 12:41 PM, Nat Sakimura  
wrote:
   

 That pretty much was the conclusion we reached. I believe that it was what the 
F2F room inclined to. So, for -04, we added a section on error response but it 
doesn't have those granular errors. 
On Fri, Nov 14, 2014 at 07:07 John Bradley  wrote:

 Nat and I discussed it yesterday and I am still personally unconvinced 
that the errors from the authorization endpoint are helpful.   So I am 
personally against adding specific errors for S256_unsupported 
On Nov 14, 2014, at 6:52 AM, Nat Sakimura  wrote:

I find not much, if any. 


On Fri, Nov 14, 2014 at 06:27 Brian Campbell  wrote:

I struggle to see the value in adding more fine grained machine readable error 
messages for this. 

Do we really want clients to try and negotiate the code_challenge_method using 
browser redirects? Especially in light of the fact that we'll likely also be 
discouraging AS's from redirecting on some error conditions when there's no 
user interaction. 

On Wed, Nov 12, 2014 at 1:48 PM, Nat Sakimura  wrote:

As discussed at F2F today at IETF 91 OAuth WG, there has been some request to 
have a more fine grained machine readable error messages. 
Currently, it only returns the error defined in RFC6749 and any more details is 
supposed to be returned in error_descripton and error_uri. 
So, I came up with the following proposal. If WG agrees, I would put text 
embodying it into the draft-04. Otherwise, I would like to go as is. You have 
to speak out to put it in. (I am sending out -03, which we meant to send before 
submit freeze, without it..) 
nErrorresponse to authorization requestlReturns invalid_request withadditional 
error param spop_error with the following values: 
▪S256_unsupported▪none_unsupported▪invalid_code_challengeClientsMUST NOT accept 
the downgrade request throughthis as it may be a downgrade attack by a MITM. 
nErrorresponse to token requestlReturns invalid_request withadditional error 
param spop_error with the following values: ▪invalid 
_code_verifier▪verifier_challenge_mismatchnAuthorizationserver should return 
more descriptive information on lerror_descriptionlerror_uri





___
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] crosspost.... SASL OAUTH

[Bill Mills]

Yep, fair enough.  Done. 

 On Friday, November 14, 2014 6:33 AM, Brian Campbell 
 wrote:
   

 Given the state of things, maybe the MAC Token specification 
[I-D.ietf-oauth-v2-http-mac] reference should be changed or omitted?

On Thu, Nov 13, 2014 at 7:01 PM, Bill Mills  wrote:

There's a draft it would be great to get more eyes on in the Kitten WG
draft-ietf-kitten-sasl-oauth-17 - A set of SASL Mechanisms for OAuth

Nearing it's 5th and hopefully final WGLC, so any more eyes and comments on it 
would be welcome.
Thanks,
-bill
___
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-spop-04: a way of making code_challenge

[Bill Mills]

Adding client ID is no better than simply adding extra random bits, but 256 is 
a LOT.
Also remember that the server SHOULD:
-    only allowing a code to be tried once-    at a very minimum should have a 
severely limited number of tries for a code-    a short time window to use a 
code
Unless you can brute force 256 bits of (pseudo)random in under a minute or two 
the code is dead.  Guess wrong, the code should be dead/trash.
 

 On Thursday, November 13, 2014 7:03 PM, takamichi saito 
 wrote:
   

 Sorry for my poor english.


2014/11/14 10:45、John Bradley  のメール：

> We have discussed it and that was in fact my original recommendation.  
> However I have been convinced that it adds complexity without any real 
> improvement in security. 

Really?
I think that there is same discussion in storing passwords with salt.
It seems to be dangerous to use hashes of fixed-range values.


> 
> The reality is that people don't bother with rainbow tables these days.  They 
> calculate hashes on the fly faster than they can look them up.  If you are 
> generating the hashes to find a collision then having fixed text that is 
> known to the attacker won't help.

How quick?
Since lifetime of the code_challenge is short, it can works effectively.

>  
> 
> It is better for people to have more entropy in the code verifier than to 
> have a fixed block of text.  I want to avoid people using less bits of 
> entropy because they think the hmac is adding something. 

I agree.
Then, we should add “client ID” in code_challenge.
We can get a few more entropy, since client ID is not fixed value.


> 
> I will come up with some text for the spec, as you are not the only person 
> asking that question. 

Thank you.

> 
> The other issue is that the term HMAC is scary to developers and we want 
> maximum adoption. 



> 
> John B. 
> 
> Sent from my iPhone
> 
>> On Nov 13, 2014, at 3:28 PM, takamichi saito  wrote:
>> 
>> 
>> Hi all,
>> 
>> I appreciate this idea, simple and powerful to achieve proof of possession.
>> But, I have some questions against the scheme.
>> Sorry if these ware already discussed.
>> 
>> I worry about using a hash function in simple way.
>> I mean, a simple use of random as code_verifier may cause that malicious 
>> client can have any code_verifier and code_challenge.
>> All combinations of random and its hash can be obtained, it may not be risk?
>> 
>> So, we should use:
>> S256 "code_challenge" = BASE64URL(SHA256("code_verifier" + “client ID”))
>> or
>> S256 "code_challenge" = BASE64URL(SHA256("code_verifier" + “client ID” + 
>> “server ID”))
>> Where, you know that client ID is client’s unique name.
>> 
>> 
>> Other problem is the following, using Nat’s slide:
>> http://www.slideshare.net/nat_sakimura/1112-spoppresso .
>> 
>> 0.    Attacker prepares own code_verifier and code_challenge.
>> 1.    replage legitimate challenge with malicious code_challenge.
>> 5. Attacker can submits own code_verifier.
>> 
>> It may be out of the draft, I think.
>> 
>> Best regards,
>> 
>> 
>> ;; takamixhi saito
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth


;; takamixhi saito

___
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-spop-04: a way of making code_challenge

[Bill Mills]

Yes, "plain" is actually sufficient.  The hashed value protects against 
disclosure/logging threats on the server auth server and proxies perhaps where 
the HTTPS is terminated somewhere other than the auth server itself, it's not 
actually required for the basic functionality/security of the mechanism. 

 On Thursday, November 13, 2014 7:07 PM, takamichi saito 
 wrote:
   

 Sorry for my poor english.


2014/11/14 10:55、Bill Mills  のメール：

> The whole mechanism relies on the attacker not having access to the 
> code_verifier or hash.  It's defending against the attacker getting the code 
> via weakness in IPC or other such mechanism like URI handlers.  How many more 
> bits is secure beyond 256 bits of entropy recommended?  If you want to make 
> it longer then just make it longer, salting doesn't really help that much.
> 
> The original value or the hashed value *should* be protected by the transport 
> security, and if it isn't then the attacker could be stealing the original 
> credential used to authenticate anyway.
> 

Is it correct?
You mean that we don’t need to use hash itself? Only to use plain is enough?


> 
> 
> 
> On Thursday, November 13, 2014 5:40 PM, takamichi saito 
>  wrote:
> 
> 
> 
> Hi all,
> 
> I appreciate this idea, simple and powerful to achieve proof of possession.
> But, I have some questions against the scheme.
> Sorry if these ware already discussed.
> 
> I worry about using a hash function in simple way.
> I mean, a simple use of random as code_verifier may cause that malicious 
> client can have any code_verifier and code_challenge.
> All combinations of random and its hash can be obtained, it may not be risk?
> 
> So, we should use:
> S256 "code_challenge" = BASE64URL(SHA256("code_verifier" + “client ID”))
> or
> S256 "code_challenge" = BASE64URL(SHA256("code_verifier" + “client ID” + 
> “server ID”))
> Where, you know that client ID is client’s unique name.
> 
> 
> Other problem is the following, using Nat’s slide:
> http://www.slideshare.net/nat_sakimura/1112-spoppresso .
> 
> 0.    Attacker prepares own code_verifier and code_challenge.
> 1.    replage legitimate challenge with malicious code_challenge.
> 5. Attacker can submits own code_verifier.
> 
> It may be out of the draft, I think.
> 
> Best regards,
> 
> 
> ;; takamixhi saito
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 


;; takamixhi saito

___
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] crosspost.... SASL OAUTH

[Bill Mills]

There's a draft it would be great to get more eyes on in the Kitten WG
draft-ietf-kitten-sasl-oauth-17 - A set of SASL Mechanisms for OAuth

Nearing it's 5th and hopefully final WGLC, so any more eyes and comments on it 
would be welcome.
Thanks,
-bill___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-spop-04: a way of making code_challenge

[Bill Mills]

The whole mechanism relies on the attacker not having access to the 
code_verifier or hash.  It's defending against the attacker getting the code 
via weakness in IPC or other such mechanism like URI handlers.  How many more 
bits is secure beyond 256 bits of entropy recommended?  If you want to make it 
longer then just make it longer, salting doesn't really help that much.
The original value or the hashed value *should* be protected by the transport 
security, and if it isn't then the attacker could be stealing the original 
credential used to authenticate anyway.

 

 On Thursday, November 13, 2014 5:40 PM, takamichi saito 
 wrote:
   

 
Hi all,

I appreciate this idea, simple and powerful to achieve proof of possession.
But, I have some questions against the scheme.
Sorry if these ware already discussed.

I worry about using a hash function in simple way.
I mean, a simple use of random as code_verifier may cause that malicious client 
can have any code_verifier and code_challenge.
All combinations of random and its hash can be obtained, it may not be risk?

So, we should use:
S256 "code_challenge" = BASE64URL(SHA256("code_verifier" + “client ID”))
or
S256 "code_challenge" = BASE64URL(SHA256("code_verifier" + “client ID” + 
“server ID”))
Where, you know that client ID is client’s unique name.


Other problem is the following, using Nat’s slide:
http://www.slideshare.net/nat_sakimura/1112-spoppresso .

0.    Attacker prepares own code_verifier and code_challenge.
1.    replage legitimate challenge with malicious code_challenge.
5. Attacker can submits own code_verifier.

It may be out of the draft, I think.

Best regards,


;; takamixhi saito

___
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] draft-ietf-oauth-spop-04 BNF

[Bill Mills]

I understand the intent of:
S256  "code_challenge" = BASE64URL(SHA256("code_verifier"))
but I think what it really says is take the base64url encoding of the sha256 
hash of the constant string "code_verifier".  Are those quotes really supposed 
to be there?
-bill 

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

[OAUTH-WG] draft-ietf-oauth-spop-04 comments

[Bill Mills]

This draft has crypto agility problems.

4.3 code_challenge_method default to 'plain' should be noted as supporting 
legacy clients.  This section should specify that S256 is MTI rather than 
leaving it to 4.4.1.

I'd be much happier if this section said something like, "The server MUST 
support a code_challenge_method other than 'plain', as such S256 is MTI as of 
the publication of this document.  The server MAY implement a 
code_challenge_method other than S256, and if it does then implementing a 
mechanism for the client to discover the supported code_challenge_method is 
RECOMMENDED."

4.4.1 requires that S256 be used even if it also supports something other than 
'plain'.

7.2 is too tightly coupled to S256.  Instead it should say something like 
"Clients that support anything other than the 'plain'  algorithm MUST NOT 
attempt using 'plain' or fall back to it if they are returned an 
"unsupported_spop_transform" error by the server.

This spec should probably also register preferred_code_challenge_method as an 
extension in the OAuth error registryto allow minimal discovery/debugging, and 
with the above will solve most of the agility problems.
 


On the naming thing  How about a title such as "Code Interception 
Protection for the OAuth Authorization Code Grant" and in the intro section 
make the last sentence "This specification describes a symmetric proof of 
possession mechanism that acts as a control against this threat.".  I think 
this removes the POP/SPOP confusion and says all the same stuff.

-bill

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

Re: [OAUTH-WG] Adding machine readable errors to SPOP?

[Bill Mills]

Let's not enumerate all possible failure paths as error messages.  Simply 
putting "unsupported_hash" is best.  The client then needs a way to discover 
allowed hashes.  You could register something like "supported_hashes" to allow 
that to be returned.
We really need to figure out if discovery will simply leverage OpenID 
deiscovery (which seems workable) or if we define something completely else. 

 On Wednesday, November 12, 2014 2:48 PM, Nat Sakimura  
wrote:
   

 I've thought about that, and I thought we could just add the error message 
when we add new alg. 
e.g., when we add SHA-3-256, we can add SHA-3-256_unsupported. 
On Thu Nov 13 2014 at 5:56:38 Mike Jones  wrote:

Is S256_unsupported or algorithm_unsupported the better error description?  I’m 
asking because I also expect that at some point in the approval process for 
this document you’ll be asked to support algorithm agility (for instance, being 
able to use SHA-3-256). 
    -- Mike From: OAuth [mailto:oauth-boun...@ietf.org]On Behalf Of Nat Sakimura
Sent: Wednesday, November 12, 2014 10:49 AM
To: oauth
Subject: [OAUTH-WG] Adding machine readable errors to SPOP? As discussed at F2F 
today at IETF 91 OAuth WG, there has been some request to have a more fine 
grained machine readable error messages.  Currently, it only returns the error 
defined in RFC6749 and any more details is supposed to be returned in 
error_descripton and error_uri.  So, I came up with the following proposal. If 
WG agrees, I would put text embodying it into the draft-04. Otherwise, I would 
like to go as is. You have to speak out to put it in. (I am sending out -03, 
which we meant to send before submit freeze, without it..)  nError response to 
authorization requestlReturnsinvalid_request with additional error 
paramspop_errorwith the following 
values:▪S256_unsupported▪none_unsupported▪invalid_code_challengeClients MUST 
NOT accept the downgraderequest through this as it may be a downgradeattack by 
a MITM.nError response to token requestlReturnsinvalid_request with additional 
error paramspop_errorwith the following values:▪invalid 
_code_verifier▪verifier_challenge_mismatchnAuthorization server should return 
more descriptive information on lerror_descriptionlerror_uri   

___
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-spop naming

[Bill Mills]

I don't actually care if we change the document tracking name from 
...-oauth-spop as long as we change the name of the thing in the text.  
Agreed doc name changing is annoying, it's survivable though.  Having done it 
once I'd do it differently if I had to do it again, submitting the last version 
of the original as -00 of the new name just before submitting a new set of 
changes to it as -01. 

 On Wednesday, November 12, 2014 9:02 AM, John Bradley  
wrote:
   

 The OAuth meeting is today.
We ran into the publication deadline for the IETF meeting during IIW so haven't 
published a update yet.
We do have text on defining error codes that we will discuss today. 
I expect the name discussion will also happen today.    Changing the draft name 
is annoying for document tracker continuity but doable.
John B.
On Nov 12, 2014, at 6:56 AM, Brian Campbell  wrote:

I agree that changing the name could avoid a lot of unnecessary confusion (and 
said as much in Sept 
https://www.ietf.org/mail-archive/web/oauth/current/msg13361.html). 


On Wed, Nov 12, 2014 at 9:46 AM, Bill Mills  wrote:

Any progress on naming on this thing?   Didn't see any reply to my previous 
comment, but that might have been because I replied to the -02 publication 
notice and it might have gotten filtered.
Similarly, the question of extending the error registry to allow the server 
tofeed back a failure if the server's required hash method isn't sent.  Also 
may need a way to advertise what hash method is required.
Regards,
-bill
___
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-WG] draft-ietf-oauth-spop naming

[Bill Mills]

Any progress on naming on this thing?   Didn't see any reply to my previous 
comment, but that might have been because I replied to the -02 publication 
notice and it might have gotten filtered.
Similarly, the question of extending the error registry to allow the server 
tofeed back a failure if the server's required hash method isn't sent.  Also 
may need a way to advertise what hash method is required.
Regards,
-bill___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Wrapping access token and codes

[Bill Mills]

So you're wanting end to end security not relying on TLS?




Have you seen the new draft on protecting codes from interception?  Currently 
called SPOP but needs a different name.
  On Thursday, November 6, 2014 4:12 AM, Sergey Beryozkin 
 wrote:
   

 Hi

Does it make sense to consider supporting an access token or code 
wrapping as part of the standard OAuth2 responses ?

For example, if a client has registered its public key with AS then say 
the access token response would contain the regular

{"access_token":"1234345"}

except that "1234345" would actually be a JWE RSA-OAEP wrapped opaque 
token with a client's public key being used. Or a direct key encrypted 
token if the client and the server only share the client secret 
allocated to the client during the registration.

The net result is that only the registered confidential client would be 
able to extract the actual opaque access token. The response would 
actually be

{"access_token":"1234345", wrapped:true}.

I definitely plan to use this approach as a simple mechanism for making 
a safer distribution of mac keys as part of access token responses; but 
IMHO it can be handy for minimizing the possibility of the 
access/refresh tokens or codes being intercepted...

Sergey

___
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] status of bearer token redelegation drafts

[Bill Mills]

We need to think about this, and whatever we build in this space should work 
for POP tokens as well.  I'd love to hear the concrete use cases and problems 
to be solved.




POP tokens (like OAuth 1.0a) are likely not to be proxyable, so the edge 
servers really should have a way to get a new credential for accessing other 
services on behalf of the user.




Another major consideration is that auth servers are frequently not scaled to 
handle the full edge transaction load, that's part of the point of issuing a 
longer lived credential by a server that's already done all the expensive 
policy and DB checks.




I'm not a big fan of a token exchange through the auth server for that reason, 
as well as the added cost incurred for the network round trips that's being 
built in.




-bill
  On Monday, November 3, 2014 2:00 PM, "Richer, Justin P." 
 wrote:
   

  There's a new working group document where this component *could* be captured 
(and I would argue it should), and that's:
https://tools.ietf.org/wg/oauth/draft-ietf-oauth-token-exchange/
However, at the moment it's more concerned with the semantically-aware 
assertion swap instead of an opaque token swap. Personally, I think that the 
syntax should be general (like in my and in Phil's draft) to allow for any kind 
of input and output token, and if someone wants to standardize an assertion on 
top of that, they can. Hopefully we can get that clear in the WG as progress 
continues on this new document.
 -- Justin


On Nov 3, 2014, at 2:54 PM, Ajanta Adhikari  wrote:

Note sure if I can reply to the mailing list yet so responding directly.
-

Bas,
We (Akamai) came up with a similar design before I read the draft from Justin 
and Phil. I talked to Justin at IIW about our design choice and he seems to 
think its in the right direction.
There is a reference to it from our OAUTH scope design session at IIW 
http://iiw.idcommons.net/OAuth_2_Scope_Design_Discuss_iom

I would be happy to share additional details if you are interested. We do not 
publish our implementation to public.

Thanks,
Ajanta


On Mon, Nov 3, 2014 at 3:02 AM, Bas Zoetekouw  wrote:

Hi All,

For a client of ours, I am looking into OAuth token redelegation from
one RS to another.  I've found two drafts that more or less describe the
scenario they want to implement:
https://tools.ietf.org/html/draft-richer-oauth-chain-00 and
http://tools.ietf.org/html/draft-hunt-oauth-chain-01
Could anyone comment on the status of those?
In particular I'ld be interested in hearing whether anyone is using
either of those specs in practice, and whether there is any progress on
the drafts.

Best regards,
Bas Zoetekouw.
SURFnet.

--
Bas Zoetekouw
SURFnet Advanced Services
Tel: +31 30 2305362   Fax:+31 30 2305329
SURFnet -  POBox 19035 -  NL-3501 DA Utrecht - The Netherlands

___
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-01.txt

[Bill Mills]

Also the nae here "SPOP" is oging to be confusing with the POP token draft 
that's been discussed for quite a while.  Naming is allways horrible fun, but 
this one is somewhat worse than some options.
-bill   

 On Tuesday, October 28, 2014 12:53 PM, Bill Mills  
wrote:
   

 The server needs to be able to enforce policy with S256 as being required.  
This means that you need to add a new error under the OAuth error registry in 
this spec that allows the server to indicate the required hash.
-bill 

 On Sunday, October 26, 2014 4:18 PM, "internet-dra...@ietf.org" 
 wrote:
   

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

        Title          : Symmetric Proof of Possession for the OAuth 
Authorization Code Grant
        Authors        : Nat Sakimura
                          John Bradley
                          Naveen Agarwal
    Filename        : draft-ietf-oauth-spop-01.txt
    Pages          : 11
    Date            : 2014-10-26

Abstract:
  The OAuth 2.0 public client utilizing Authorization Code Grant (RFC
  6749 - 4.1) is susceptible to the code interception attack.  This
  specification describes a mechanism that acts as a control against
  this threat.


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:
http://tools.ietf.org/html/draft-ietf-oauth-spop-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-01


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

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

[Bill Mills]

The server needs to be able to enforce policy with S256 as being required.  
This means that you need to add a new error under the OAuth error registry in 
this spec that allows the server to indicate the required hash.
-bill 

 On Sunday, October 26, 2014 4:18 PM, "internet-dra...@ietf.org" 
 wrote:
   

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

        Title          : Symmetric Proof of Possession for the OAuth 
Authorization Code Grant
        Authors        : Nat Sakimura
                          John Bradley
                          Naveen Agarwal
    Filename        : draft-ietf-oauth-spop-01.txt
    Pages          : 11
    Date            : 2014-10-26

Abstract:
  The OAuth 2.0 public client utilizing Authorization Code Grant (RFC
  6749 - 4.1) is susceptible to the code interception attack.  This
  specification describes a mechanism that acts as a control against
  this threat.


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:
http://tools.ietf.org/html/draft-ietf-oauth-spop-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-01


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

Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call

[Bill Mills]

+1 on OIDC being an authentication solution, OAuth is authorization and the 
pitfalls of using it as authN have been well hashed out.  If people are still 
getting it wrong more guidance is needed. 

 On Monday, October 20, 2014 1:07 PM, "Richer, Justin P." 
 wrote:
   

 Right, when you get the AT directly from the token endpoint and it's good for 
something, that will *probably* tell you the user is logged in. This is 
assuming that the authentication context can also be communicated, audience 
restrictions can be communicated, and all the other good stuff the document 
talks about. A real problem tends to stem from clients who will take access 
tokens from various public endpoints and use them directly (implicit clients 
are inherently open to this problem). Or that an access token can have a life 
long past the authentication event, so if a client saves the access token off 
someplace, does a bunch of work, then finally asks "Who's there?" and makes the 
user info API call, it's going to get info but not necessarily what it assumes. 

Really, all of this is why there's the ID Token and the Signed Request 
components in OIDC and FBC, respectively. Plus you don't always want the 
profile information on every request, so having something the client can read 
directly saves a round trip to fetch data it doesn't really want. Having the 
separation between the authentication context and the profile information 
really does make the code paths a bit simpler.

 -- Justin

On Oct 20, 2014, at 3:20 PM, Hans Zandbelt  wrote:

> My point is that it *is* a guarantee if the AT just came to the client in a 
> code flow; I don't see a problem with that although clients have to be aware 
> of what they're doing and not allow any other flows for this.
> 
> Hans.
> 
> On 10/20/14, 9:04 PM, Richer, Justin P. wrote:
>> This is actually one of the sticky bits that I've tried to address in the 
>> document itself -- I've seen apps that assume that if they're given an 
>> access token that can be used to fetch profile information then the user is 
>> actually there. This isn't actually a guarantee, but it's commonly true 
>> enough that developers get lazy and rely on it.
>> 
>>  -- Justin
>> 
>> 
>> On Oct 20, 2014, at 2:42 PM, Hans Zandbelt  
>> wrote:
>> 
>>> or pointier: there are OAuth 2.0 deployments today that offer login 
>>> semantics because they have a REST/JSON user profile API that can be 
>>> accessed using the AT that was obtained in a code flow; should that be 
>>> acknowledged in the doc?
>>> 
>>> Hans.
>>> 
>>> On 10/16/14, 11:23 PM, Hans Zandbelt wrote:
 a deployment-related question that I have around this topic:
 
 it seems that authentication using OAuth 2.0 is possible today for
 confidential clients using the code flow, with a registered
 redirect_uri, not consuming/storing/using refresh_tokens, and assuming
 that there's an API that returns user identity info in JSON format and
 the claim that uniquely identifies the user is known by the client.
 
 The usage/presence of the short-lived code in this scenario/flow
 guarantees that the user has just authenticated, and the audience issue
 is covered by the fact that the code (thus the access_token in the token
 endpoint response) are bound to the confidential client, all as per
 standard OAuth 2.0 semantics.
 
 2 questions about that:
 - is this right or am I overlooking some security/semantics issues here
 - if right, would it make sense to acknowledge that or is that muddying
 the waters even more (the current text does seem to only implicitly
 acknowledge this)
 
 There may be value in acknowledging this because the majority of OAuth
 2.0 OPs exposing a userinfo-like API would adhere to a REST GET+JSON
 response anyhow [1] thus achieving login semantics with plain OAuth 2.0
 and a bit of common practice wrt. the user info API.
 
 Thanks for the excellent write-up!
 
 Hans.
 
 PS: I've been asked this concrete question about Spotify's OAuth 2.0
 support and in fact I'm able to configure Spotify as an IDP to my OIDC
 client with a minor workaround to abstain from expecting an id_token in
 the token endpoint response, but calling the Spotify specific user info
 endpoint like it was a standards-compliant OpenID Connect endpoint. (the
 client has a per-OP configurable unique user id claim name anyhow).
 
 On 10/16/14, 7:27 PM, Richer, Justin P. wrote:
> Ah yes, good catch! If only someone would put up a webpage describing
> the difference between authorization and authentication and why people
> need to stop confusing the two.
> 
> Oh wait...
> 
> 
> On Oct 16, 2014, at 1:06 PM, Hans Zandbelt
>  wrote:
> 
>> About the write-up: at the end of the metaphor section it says:
>> "These recipes each add a number of items, such as a common profile
>> API, to OAuth

Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

[Bill Mills]

This is exactly the same problem space as webfinger, you want to know something 
about a user and there's a useful set of information you might reasonably 
query, but in the end the server may have it's own schema of data it returns.  
There won't be a single schema that fits all use cases, Any given RS/AS 
ecosystem may decide they have custom stuff and omit other stuff.  I think the 
more rigid the MTI schema gets the harder the battle in this case.


On Tuesday, July 29, 2014 2:56 AM, Paul Madsen  wrote:
 


Standardized Introspection will be valuable in NAPPS, where the AS and RS may 
be in different policy domains.

Even for single policy domains, there are enterprise scenarios where the RS is 
from a different vendor than the AS, such as when an API gateway validates 
tokens issued by an 'IdP' . We've necessarily defined our own introspection 
endpoint and our gateway partners have implemented it, (at the instruction of 
the customer in question). But of course it's proprietary to us.

Paul

On Jul 28, 2014, at 8:59 PM, Phil Hunt  wrote:


That doesn’t explain the need for inter-operability. What you’ve described is 
what will be common practice.
>
>
>It’s a great open source technique, but that’s not a standard.
>
>
>JWT is much different. JWT is a foundational specification that describes the 
>construction and parsing of JSON based tokens. There is inter-op with token 
>formats that build on top and there is inter-op between every communicating 
>party.
>
>
>In OAuth, a site may never implement token introspection nor may it do it the 
>way you describe.  Why would that be a problem?  Why should the group spend 
>time on something where there may be no inter-op need.
>
>
>Now that said, if you are in the UMA community.  Inter-op is quite 
>foundational.  It is very very important. But then maybe the spec should be 
>defined within UMA?
>
>
>Phil
>
>
>@independentid
>www.independentid.comphil.h...@oracle.com
>
>
>
>
>On Jul 28, 2014, at 5:39 PM, Justin Richer  wrote:
>
>It's analogous to JWT in many ways: when you've got the AS and the RS 
>separated somehow (different box, different domain, even different software 
>vendor) and you need to communicate a set of information about the approval 
>delegation from the AS (who has the context to know about it) through to the 
>RS (who needs to know about it to make the authorization call). JWT gives us 
>an interoperable way to do this by passing values inside the token itself, 
>introspection gives a way to pass the values by reference via the token as an 
>artifact. The two are complementary, and there are even cases where you'd want 
>to deploy them together.
>>
>> -- Justin
>>
>>On 7/28/2014 8:11 PM, Phil Hunt wrote:
>>
>>Could we have some discussion on the interop cases?
>>>
>>>
>>>Is it driven by scenarios where AS and resource are separate domains? Or may 
>>>this be only of interest to specific protocols like UMA?
>>>
>>>
>>>From a technique principle, the draft is important and sound. I am just not 
>>>there yet on the reasons for an interoperable standard. 
>>>
>>>
>>>Phil
>>>
>>>On Jul 28, 2014, at 17:00, Thomas Broyer  wrote:
>>>
>>>
>>>Yes. This spec is of special interest to the platform we're building for 
>>>http://www.oasis-eu.org/



On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig 
 wrote:

Hi all,
>
>during the IETF #90 OAuth WG meeting, there was strong
consensus in
>adopting the "OAuth Token Introspection"
>(draft-richer-oauth-introspection-06.txt) specification
as an OAuth WG
>work item.
>
>We would now like to verify the outcome of this call for
adoption on the
>OAuth WG mailing list. Here is the link to the document:
>http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/
>
>If you did not hum at the IETF 90 OAuth WG meeting, and
have an opinion
>as to the suitability of adopting this document as a WG
work item,
>please send mail to the OAuth WG list indicating your
opinion (Yes/No).
>
>The confirmation call for adoption will last until
August 10, 2014.  If
>you have issues/edits/comments on the document, please
send these
>comments along to the list in your response to this Call
for Adoption.
>
>Ciao
>Hannes & Derek
>
>
>___
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth
>
>




-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ 
>>>___
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] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

[Bill Mills]

+1 adoption


On Monday, July 28, 2014 11:41 AM, Hannes Tschofenig 
 wrote:
 


Hi all,

during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
work item.

We would now like to verify the outcome of this call for adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/

If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion (Yes/No).

The confirmation call for adoption will last until August 10, 2014.  If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for Adoption.

Ciao
Hannes & Derek

___
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-hunt-oauth-v2-user-a4c-05.txt

[Bill Mills]

Then why aren't people using this instead of (mis)using OAuth for this?

Different question, if we do define AC4 will people move to that, or continue 
doing the wrong thing anyway?


On Thursday, July 24, 2014 8:57 AM, Nat Sakimura  wrote:
 




2014-07-24 10:30 GMT-04:00 Phil Hunt :

I’m not at all saying that OpenID is bad. If you want an IDP, its fine.  But if 
all a client wants is authentication, they think why can’t I just use RFC6749?
If all what one wants is to build a simple client, there is a standing document 
called OpenID Connect Basic Client Implementer's Guide 1.0. 

It is a profile that deals only the 'code' flow. 
Size-wise, it is 32 pages. The break down are as below approximately: 

Abstract, Intro, ToC - 2.5 pages
Terminology - 1.5 pages
Getting ID Token - 9 pages
ID Token Validation - 1 page (Seems missing from a4c draft?)
Userinfo Endpoint - 7 pages
Serializations - 1 page (missing in a4c?)
String Operations etc. - 1 pages (missing in a4c?)
Considerations - 2 pages (very brief in a4c)
References, Acknowledgement - 2 pages
Document History etc. - 7 pages


The a4c draft is 14 pages long. It will be longer than this in the end as it is 
missing bunch of things. 
The comparable portion of the Basic Client Profile is 14 pages or so. 

Just one data point. 

-- 
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] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

[Bill Mills]

This could also be solved by explicitly defining a scope for access tokens 
specific to the needed (no-op?) behavior for ac4.


On Thursday, July 24, 2014 8:34 AM, "tors...@lodderstedt.net" 
 wrote:
 


I honestely don't understand why you care about omiting the access token on the 
token endpoint response. You want to omit user consent? Fine, do it. There is 
no text in the spec that forces an AS to explicitely acquire user consent. 
Authorization from the resource owner can be acquired in many ways, showing an 
user consent page is just one option. We authorize DT internal services using a 
pre-configured policy. So the customer will never (need to) see a consent 
screen. The same approach can be used in enterprise deployments. 
regards,
Torsten.
Am 24.07.2014 10:49, schrieb Mike Jones:
Here's a point of technical discussion for your consideration about the current 
content of a4c and a possible simplification.
> 
>Having thought about the views expressed about defining the new response type 
>and grant type values, I came up with a possible syntax change that would be 
>much more minimal and accomplish the same thing.  Rather than defining a new 
>response type and a new grant type, instead, we could just use the existing 
>code flow and say that it's legal for the token endpoint to return the value 
>"access_token=none".  That way, the delta to OAuth 2.0 for the no-access-token 
>case would be very small and the syntax of the response from the token 
>endpoint would be unchanged.
> 
>And while people might initially think that since we'd be defining a 
>distinguished access_token result value we might be stepping on 
>implementations, "none" doesn't meet the minimum entropy requirements in OAuth 
>2.0, so wouldn't conflict with any conforming implementation.
> 
>    Best wishes,
>    -- Mike
> 
>From:OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
>Sent: Thursday, July 24, 2014 7:34 AM
>To: John Bradley
>Cc: oauth@ietf.org list
>Subject: Re: [OAUTH-WG] New Version Notification for 
>draft-hunt-oauth-v2-user-a4c-05.txt
> 
>+1
> 
>Phil
> 
>@independentid
>www.independentid.com
>phil.h...@oracle.com
> 
> 
> 
>On Jul 24, 2014, at 10:25 AM, John Bradley  wrote:
>
>
>
>I am not against discussion in the WG.
> 
>I happen to agree with Phil's fundamental premise that some developers are 
>using OAuth in a insecure way to do authentication.
> 
>That raises the question of how to best educate them, and or address technical 
>barriers.
> 
>It is on the second point that people's opinions seem to divide.
> 
>Some people thing that if we have a OAuth flow that eliminates the access 
>token (primarily to avoid asking for consent as I understand it) and just 
>return a id_token from the token endpoint that can be done in a spec short 
>enough to het people to read.   The subtext of this is that the Connect 
>specification is too large that it scare people,  and they don't find the spec 
>in the first place because it is not a RFC.
> 
>An other common possession is that if you don't want to prompt the user for 
>consent then don't ask for scopes.  Twisting the OAuth spec to not return an 
>access token is not OAuth,  yes you could use a different endpoint rather than 
>the token endpoint, but that is not OAuth.   Connect was careful not to break 
>the OAuth spec.    As long as you are willing to take a access token with no 
>scopes (the client needs to understand that there are no attributes one way or 
>another anyway or it will break) then you don't need to change OAuth.   You 
>can publish a profile of connect that satisfies the use case.
> 
>I think Mike has largely done that but it might be better being less stingy on 
>references back to the larger spec.
> 
>The questions are do we modify OAuth to not return an access token, and if so 
>how,  and if we do is it still OAuth.
> 
>The other largely separable question is do we create confusion in the market 
>and slow the the adoption of identity federation on top of OAuth, or find a 
>way to make this look like a positive alignment of interests around a subset 
>of Connect.
> 
>There are a number of options.  
>1: We can do a profile in the OIDF and publish it as a IETF document.   
>Perhaps the cleanest from an IPR point of view.
>2:We can do a profile in the OAuth WG referencing connect.
>3:We can do a AD sponsored profile that is not in the OAuth WG.
>4:We can do a small spec in OAuth to add response_type to the token endpoint.  
>in combination with 1, 2, or 3
> 
>I agree that stoping developers doing insecure things needs to be addressed 
>somehow.  
>I am not personally convinced that Oauth without access tokens is sensible.
> 
>Looking forward to the meeting:)
> 
>John B.
>On Jul 24, 2014, at 6:52 AM, Brian Campbell  wrote:
>
>
>
>I'd note that the reaction at the conference to Ian's statement was 
>overwhelmingly positive. There was a

Re: [OAUTH-WG] refresh tokens and client instances

[Bill Mills]

I would argue that if the user approved a specific access profile that the 
token should be limited to that.  If it wants more rights/scope that should 
trigger an approval from the user based on a full authentication.  It's all a 
bit mudy though because you could imagine implementing a more limited scope the 
user would not have to approve.


On Monday, July 7, 2014 2:09 PM, John Bradley  wrote:
 


Inline
On Jul 7, 2014, at 4:59 PM, Sergey Beryozkin  wrote:

> Hi John, All,
> On 03/07/14 23:02, John Bradley wrote:
>> Yes,
>> 
>> The the undifferentiated is initially differentiated by the user during 
>> Authorization by having a code returned and then by exchanging the code for 
>> a refresh token.
>> It however returns to being undifferentiated on subsequent authorization 
>> requests.
>> This makes having sticky grants (only asking for permission for incremental 
>> scopes) a potential security problem, as the AS has no way to know if the 
>> client is the one that the pervious authorization was intended for.
>> 
>> Some AS just assume that you want the same permissions across all instances 
>> of a client,  however if this is a public client then someone could 
>> impersonate the client app and basically do privilege escalation.
>> 
> Why would a public client holding a refresh token securely entered into it by 
> a user request a new authorization without actually requesting the new scopes 
> ? The client can just get a new access/refresh token from now on ?

A client holding a refresh token may want to add additional scopes, perhaps it 
only initially asked for permission to get a email address and now it wants a 
phone number.

If it is a public client the AS needs to ask for permission to grant both 
scopes,  it can't treat the email permission as sticky.
> 
>> What dynamic client registration gives us for native apps is a way to 
>> identify specific instances of clients at the authorization endpoint by 
>> having different client_id and validating that with instance specific client 
>> credentials.  This also prevents the use of code if it is intercepted in the 
>> reply from the authorization endpoint.
>> 
> Would it be fair to say that a dynamic client registration is a preferred 
> method of registering *public* clients from now on, *unless*
> no sticky grants are used in which case a typical/default registration mode 
> is OK ?

It is up to the AS and how it wants to manage clients.  Some will not want to 
manage thousands of client_id, others won't mind.  

If you don't have sticky grants and can mitigate code being intercepted in the 
response by using http://tools.ietf.org/html/draft-sakimura-oauth-tcse ,
then having a public client works.


> 
> Thanks, Sergey
> 
>> John B.
>> 
>> On Jul 3, 2014, at 12:28 PM, Sergey Beryozkin  wrote:
>> 
>>> Hi
>>> On 03/07/14 16:40, Bill Mills wrote:
>>>> Implementations may/SHOULD bind refresh tokens to specific client
>>>> instances.  Yes, it's possible that the client ID with dynamic
>>>> registration is unique to each client, but many of the token theft use
>>>> cases include the possibility of stealing the client ID too if you know
>>>> you need to.
>>>> 
>>> What exactly is a 'client instance' when we talk about having a single 
>>> client id registration, with the id shared between multiple devices (which 
>>> is what I believe this thread started from).
>>> 
>>> What I understood, as far as the authorization service is concerned, a 
>>> 'client instance' for AS is a combination of a client id + code grant.
>>> 
>>> + (optional) refresh token (as was mentioned earlier). But it appears to me 
>>> a client instance can be uniquely identified by two values only without a 
>>> refresh token.
>>> 
>>> When a user authorizes a given device and gets a grant code and enters it 
>>> into the device securely we have a 'client instance' ready to get the 
>>> tokens, with that device (client instance) using a client id and the grant 
>>> code to get an access token and a refresh token.
>>> 
>>> Lets say it sends a "client_id=1&code=2" sequence to get the tokens.
>>> A client id + a code value constitutes a client instance, because a code 
>>> would be unique per every authorization, right ?
>>> 
>>> So the service will return an access token + refresh token to the device. 
>>> Refresh Token could've been associated with a record containing a client id 
>>> + grant code info earlier or at the moment the cod

Re: [OAUTH-WG] Agenda requests, please

[Bill Mills]

I just started a new job and won't be there, probably not listening in on the 
chat either


On Thursday, July 3, 2014 10:39 AM, Brian Campbell  
wrote:
 


Unfortunately I won't be in Toronto for #90 due to a conflict that week with 
the Cloud Identity Summit.

Hopefully nothing will come up from the  IESG on the assertion bundle but I 
trust Mike can handle it, if something requiring agenda time does surface 
between now and then.




On Wed, Jul 2, 2014 at 8:06 AM, Hannes Tschofenig  
wrote:

Hi all,
>
>by next Monday we have to post a draft agenda for the upcoming IETF
>meeting.
>
>If you would like to talk about a specific topic, please let us know.
>
>My impression regarding the status of our work is the following:
>
>
> Current WG items ---
>
>* Dynamic Client Registration
>
>We are waiting for an update but the document could be completed by the
>IETF meeting. ==> no presentation time.
>
>* JWT
>
>Currently in IESG processing and a new draft update has just been
>submitted. ==> no presentation time (#)
>
>* Assertion Bundle
>
>Currently in IESG processing. ==> no presentation time (#)
>
>* Dynamic Client Registration Management Protocol
>
>We had a discussion about this work at the last IETF meeting and the
>path forward looked somewhat difficult. Nothing has happened since that
>time and I am inclined to remove it from the list of WG items.
>
>* Proof-of-Possession Security
>
>We have several new documents and I hope we can turn into working group
>items already before the meeting. We would then use the meeting time to
>discuss open issues.
>
>#: No presentation time unless some challenging comments from the IESG
>surface.
>
> Proposed New WG items ---
>
>I would also like to put the following items on the agenda.
>
>* Token Introspection
>
>* draft-sakimura-oauth-tcse-03
>
> Other items ---
>
>Phil might want to bring up this item since it was discussed on the
>list: draft-hunt-oauth-v2-user-a4c
>
>Other ideas/suggestions?
>
>Ciao
>Hannes
>
>
>___
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth
>
>


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

Re: [OAUTH-WG] refresh tokens and client instances

[Bill Mills]

You might have a public client, the Flickr client for example (which uses OAuth 
1 right now but it's a useful example) where the client ID is baked into the 
install.  In this case binding the token to the client ID means only that 
someone who steals the token and tries to use it with a different client ID 
would fail.

With DynReg that client could generate a nonce and include it in a dynamically 
registered client ID and then the credential could be bound to that specific 
software instance.

A 3rd possibility is multiple clients on a device sharing the same auth 
context, in which case they all use the same library perhaps and so several 
installed apps all would share the same "client id" from the servers 
perspective (the one for the auth API) but they might each get different scopes.


On Thursday, July 3, 2014 9:28 AM, Sergey Beryozkin  
wrote:
 


Hi
On 03/07/14 16:40, Bill Mills wrote:
> Implementations may/SHOULD bind refresh tokens to specific client
> instances.  Yes, it's possible that the client ID with dynamic
> registration is unique to each client, but many of the token theft use
> cases include the possibility of stealing the client ID too if you know
> you need to.
>
What exactly is a 'client instance' when we talk about having a single 
client id registration, with the id shared between multiple devices 
(which is what I believe this thread started from).

What I understood, as far as the authorization service is concerned, a 
'client instance' for AS is a combination of a client id + code grant.

+ (optional) refresh token (as was mentioned earlier). But it appears to 
me a client instance can be uniquely identified by two values only 
without a refresh token.

When a user authorizes a given device and gets a grant code and enters 
it into the device securely we have a 'client instance' ready to get the 
tokens, with that device (client instance) using a client id and the 
grant code to get an access token and a refresh token.

Lets say it sends a "client_id=1&code=2" sequence to get the tokens.
A client id + a code value constitutes a client instance, because a code 
would be unique per every authorization, right ?

So the service will return an access token + refresh token to the 
device. Refresh Token could've been associated with a record containing 
a client id + grant code info earlier or at the moment the code is 
exchanged for an access token.

During the subsequent refresh token grant request we have "client id + 
refresh token" as a client instance.

I'm not sure what exactly I'd like to ask here :-), but I wonder if the 
above sounds right, then I guess I'd like to conclude that when we talk 
about the authorization code grant then a refresh token is not the only 
key that uniquely identifies a client instance:

Initially it is a client id + code grant, a refresh token does not offer 
an extra uniqueness at the point of the client device requesting an 
access token with a code. Refresh token only starts acting as the key 
client instance identifier at a refresh token grant time.

Sorry for a long email, I'm very likely missing something, so any 
clarifications will be welcome

Thanks, Sergey







> -bill
>
>
> On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin
>  wrote:
>
>
> Hi
>
> I'm finding the answers from John interesting but I'm failing to
> understand why refresh tokens are mentioned in scope of identifying the
> specific client instances.
>
> AFAIK refresh tokens would only go on the wire, assuming they are
> supported, when a client exchanges a grant for a new access token.
> And when the client uses a refresh token grant.
>
> Was it really about a refresh token grant where the incoming client id
> and refresh token pair can uniquely identify the actual client instance
> ? That would make sense.
>
> Something else I'd like to clarify.
> John mentions a refresh token is created at the authorization grant
> initialization time. Would it make any difference, as far as the
> security properties of a grant are concerned, if refresh token was only
> created at a grant to access token exchange point of time ?
>
> Thanks, Sergey
>
> On 27/06/14 19:21, John Bradley wrote:
>  > Inline
>  >
>  > On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri  <mailto:m.nakhj...@samsung.com>
>  > <mailto:m.nakhj...@samsung.com <mailto:m.nakhj...@samsung.com>>> wrote:
>  >
>  >> Hi John,
>  >> Thank you for your reply. Would appreciate if you consider my inline
>  >> comments below and respond again!
>  >> R,
>  >> Madjid
>  >> *From:*John Bradley [mailto:ve7...@ve7jtb.com
> <mailto:ve7...@ve7jtb.com>]
>  >> *Sent:*Wednesday, June 25, 2014 5:56 PM
&g

Re: [OAUTH-WG] refresh tokens and client instances

[Bill Mills]

Implementations may/SHOULD bind refresh tokens to specific client instances.  
Yes, it's possible that the client ID with dynamic registration is unique to 
each client, but many of the token theft use cases include the possibility of 
stealing the client ID too if you know you need to.

-bill


On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin  
wrote:
 


Hi

I'm finding the answers from John interesting but I'm failing to 
understand why refresh tokens are mentioned in scope of identifying the 
specific client instances.

AFAIK refresh tokens would only go on the wire, assuming they are 
supported, when a client exchanges a grant for a new access token.
And when the client uses a refresh token grant.

Was it really about a refresh token grant where the incoming client id 
and refresh token pair can uniquely identify the actual client instance 
? That would make sense.

Something else I'd like to clarify.
John mentions a refresh token is created at the authorization grant 
initialization time. Would it make any difference, as far as the 
security properties of a grant are concerned, if refresh token was only 
created at a grant to access token exchange point of time ?

Thanks, Sergey

On 27/06/14 19:21, John Bradley wrote:
> Inline
>
> On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri  > wrote:
>
>> Hi John,
>> Thank you for your reply. Would appreciate if you consider my inline
>> comments below and respond again!
>> R,
>> Madjid
>> *From:*John Bradley [mailto:ve7...@ve7jtb.com]
>> *Sent:*Wednesday, June 25, 2014 5:56 PM
>> *To:*Madjid Nakhjiri
>> *Cc:*oauth@ietf.org 
>> *Subject:*Re: [OAUTH-WG] refresh tokens and client instances
>> In 3.3 It is saying that the refresh token is a secret that the
>> Authorization server has bound to the client_id, that the
>> Authorization server effectively uses to differentiate between
>> instances of that client_id.
>> Madjid>>If I have 10,000s of devices, each with an instance of the
>> OAUTH client, but they are all using the same client ID, how would the
>> server know which token to use for what client? unless when I am
>> creating a token, I also include something that uniquely identifies
>> each instance? Don’t I have to use SOMETHING that is unique to that
>> instance (user grant/ID?)?
> When the grant is issued you create and store a refresh token which is
> effectively the identifier for that instance/grant combination.
> When it comes back on a request to the token endpoint you look up the
> grants associated with it.   You also hack that the client_id sent in
> the request matches to detect errors mostly)
>
>> When the refresh token is generated, it can be stored in a table with
>> the client_id and the information about the grant.   You could also do
>> it statelesly by creating a signed object as the refresh token.
>> Madjid>>agreed, but for the signed object to be self-sustained, again
>> would I not need something beyond a “population” client_ID? Are we
>> prescriptive what “information about the grant” is?
> You would be creating a bearer token as long as the AS signs it you can
> put whatever grant grant info you like in it, that is implementation
> specific.  It  could be a list of the scopes granted and the subject.
>> The spec is silent on the exact programming method that the
>> Authorization server uses.
>> Madjid>>Are there any other specs in IETF or elsewhere (OASIS, etc?)
>> that prescribe token calculation (e.g. hash function, parameters, etc)?
>
> You can look at JOSE and JWT for a way to create tokens
> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token
>> In 3.7 Deployment independent describes using the same client_id
>> across multiple instances of a native client, or multiple instances of
>> a Java Script client running in a browsers with the same callback uri.
>> Since the publishing of this RFC we have also developed a spec for
>> dynamic client registration so it is possible to give every native
>> client it's own client_id and secret making them confidential clients.
>> Madjid>>I would need to look at those specs, however, I thought that
>> the “confidential client” designation has to do with the client
>> ability to hold secrets and perform a-by-server-acceptable
>> authentication. Does dynamic client registration affect client’s
>> ability in that aspect?
>
> Yes it doesn't require the secret to be in the downloaded instance of
> the native app.  It can be populated at first run, changing it from
> public to confidential.
> Confidential is not just for web servers any more.
>> There is also a middle ground some people take by doing a proof of
>> possession for code in native applications to prevent the interception
>> of responses to the client by malicious applications on the device.
>> https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/
>> John B.
>> On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri > > wrote:
>>
>>
>> Hi all,
>> I am n

[OAUTH-WG] The underlying question Re: Question regarding draft-hunt-oauth-v2-user-a4c

[Bill Mills]

Let's come back to the problem statement.  It sounds like Oauth is being 
(mis)used for plain authentication , we want to deal with that, and OpenID 
isn't appaently satisfying the need of the folks doing this.  Is that 
essentially correct?

What is the use case that the minimal OIDC implementation doesn't solve?

Is the problem that people want to use existing OAuth implementations and they 
would rather use/extend them than go to OIDC?



On Friday, June 13, 2014 4:15 PM, Phil Hunt  wrote:
 


I think this is a false argument. What we desire to do or not do is not always 
the WG's choice.

It’s not me asking an authentication enhancement. The issue is whether to 
address improper authentication in the wild. Several of us all blogged about 
this a while a go and the problem with improper use of 6749 for authentication 
continues to grow.

Would it be better if we thought about this as the authentication “bug”?

I’m not sure everyone is on the same page regarding the term “authentication". 
In none of the scenarios discussed are we talking about “performing” 
authentication. We are talking about passing the authentication context from 
the AS in a non-opaque form to the client where the client is the audience of 
that information.

The authentication term is especially confusing because what developers *think* 
they are doing is authentication. It is not.

Phil

@independentid
www.independentid.comphil.h...@oracle.com



On Jun 13, 2014, at 2:34 PM, Anil Saldhana  wrote:

Brian - I agree. We should neither overload nor extend the WG charter to 
include any aspect of SSO or authentication.
>
>I am hoping Prateek/Phil's feedback on OIDC can be addressed by
  OIDC.  
>
>From John's email, it seemed like a path forward is a Deployment
  Profile at OIDC. Hopefully everybody will be happy with that.
>
>
>On 06/13/2014 04:23 PM, Brian Campbell wrote:
>
>I agree that, at this point, debating the details of a4c is premature. 
>SSO/authentication are not part of the WG charter and, as I've said before, 
>I'd object to changing the charter to include it. Other than a small but vocal 
>minority, I think it's fair to say that that's also been the prevailing 
>sentiment of this group.  
>>
>>
>>
>>
>>On Fri, Jun 13, 2014 at 1:43 PM, John Bradley  wrote:
>>
>>Hi Anil,
>>>
>>>There are a number of profile efforts being looked at in
  the OIDF.   The Mobile Network operators lead by the GSMA
  are starting profile work on a standard profile that will
  be supported by mobile operators globally, that includes
  looking at how a Client/RP/SP can register there client
  once for use across multiple IdP AS, as well as
  standardized LoA and user-info schema extensions.
>>>
>>>Torsten Lodderstedt is the chair of that effort and can
  chime in.
>>>
>>>I suspect that a Basic IdP for SSO profile is
  significantly less ambitious than that and could be done
  in the current Connect WG.
>>>
>>>If there is interest from the members to start it.   The
  main time blocking factor might be getting a new
  grant_type spec approved in the the OAuth WG if we wanted
  to support that.
>>>
>>>The IdP profile is simple they can publish a discovery
  document saying they only support that that limited
  feature set, that way they would also be compatible with
  existing connect clients.
>>>
>>>{
>>>"scopes_supported": ["openid"],
>>>"response_types_supported":["code"],
>>>"response_modes_supported":["query"],
>>>"grant_types_supported":["authorization_code",
  "code_id_token_only"],
>>>"acr_values_supported":["2","3"]
>>>}
>>>
>>>They don't need to publish one if they don't intend to be
  discoverable to clients but knowing what the path forward
  to supporting generic client is helpful I think.
>>>
>>>Everything exists now other than the new grant_type exists
  now.
>>>
>>>The work would mostly be putting together the examples
  based on supporting a minimal flow.
>>>
>>>Now I should point out that there are people who believe
  that the default flow should be implicit with the
  "id_token" response_type and intend to support that.
>>>Phil's draft concentrates on only one use case.   Having a
  IdP deployment profile for it is not a problem, but it
  will not be for every IdP.   That is one of the reasons
  why discovery and registration are important features of
  Connect.
>>>
>>>John B.
>>>
>>>
>>>
>>>On Jun 13, 2014, at 1:26 PM, Anil Saldhana  wrote:
>>>
 On 06/12/2014 04:18 PM, John Bradley wrote:
> All but a handful of OAuth WG participants
  participated in developing OpenID Connect.
>
> Yes some companies chose not to participate
  for whatever reasons and have not committe

Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

[Bill Mills]

If you need user info based on an access token the introspection endpoint is 
the right way to go.  Even so, there's issues with using an access token as an 
authenticator and this is a major reason why OpenID is the right way to go for 
authn.


On Thursday, June 5, 2014 12:42 PM, Anthony Nadalin  
wrote:
 


It’s great but some ways but also very limiting if you are counting on certain 
requirements to be represented in the access token
 
From:OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Thursday, June 5, 2014 12:40 PM
To: Bill Mills
Cc: Phil Hunt; oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
 
+1
 
the access token is opaque to the client. That's great! Let's keep it that way.

Am 05.06.2014 um 21:20 schrieb Bill Mills :
Can't agree more with the peril of overloading auth information into an access 
token.
> 
>On Thursday, June 5, 2014 11:05 AM, Mike Jones  
>wrote:
> 
>Hannes, the Access Token and ID Token do quite different things and have 
>different structures and properties.  The Access Token is an opaque value that 
>grants access to resources.  An ID Token is a non-opaque JWT security token 
>that makes claims about the authentication that occurred.  You can have one 
>without the other or you can have both, depending upon the use case.  Thus, 
>trying to move information between them would be problematic in several 
>regards.
>
>Also, trying to overload the Access Token to convey authentication information 
>has been demonstrated in practice to be fraught with peril, and has resulted 
>in some of the most prominent security breaches related to the misuse of OAuth.
>
>                -- Mike
>
>-Original Message-
>From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
>Sent: Thursday, June 05, 2014 8:54 AM
>To: Hannes Tschofenig
>Cc: oauth@ietf.org
>Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c
>
>You are correct. Just adding to access token would make a lot of devs happy 
>and that certainly should be discussed. 
>
>Two requirements issues:
>
>1. A key use case is passing auth ctx only. An access token means asking for 
>consent to access something. This causes many sites to loose new users. Authen 
>only can be implicit consent. 
>
>2.  Compatibility with OpenId ID Token and flows. 
>
>3. There is a need to support re-auth and MFA/LOA negotiation. Eg web site 
>would like to obtain a higher level of assurance for a higher risk action. 
>
>The non-tech requirement is the soln must be received by client and service 
>provider developers as easy to implement in addition to 6749 or even OAuth 
>1.1a. I mention it because devs feel this should be trivial.  Your suggestion 
>of adding to access token certainly
 fits this. 
>
>Phil
>
>> On Jun 5, 2014, at 0:44, Hannes Tschofenig  wrote:
>> 
>> Hi Phil,
>> 
>> thanks for producing this document write-up. I have a somewhat basic 
>> question regarding the document.
>> 
>> The id token contains the following mandatory information:
>> - sis: issuer
>> - sub: subject
>> - aud: audience
>> - iat: issued at
>> - exp: expiry
>> - auth_time: time when the end user was authenticated
>> 
>> An access token (when encoded as a JWT) may contain all these fields 
>> except the auth_time (since auth_time is not defined in the JWT spec).
>> 
>> Given that your proposal actually does not define the authentication 
>> protocol to be used between the resource owner/end user and the 
>> authorisation server I am wondering whether it would be possible to 
>> just add the auth_time parameter (and maybe some of the optional 
>> parameters) to the access token. Then, you can skip the id token.
>> 
>> How do I come up with that question? In Kerberos, for example, the 
>> above-listed information is carried within a single container (within 
>> the ticket) and so I am curious to hear why we have to send the 
>> information twice in OAuth (once in the access token, when the info is 
>> passed per value, and again via the id token).
>> 
>> Maybe I missing something important here.
>> 
>> Ciao
>> Hannes
>> 
>> 
>
>___
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth
>
>
>___
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth
> 
___
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

[Bill Mills]

Can't agree more with the peril of overloading auth information into an access 
token.


On Thursday, June 5, 2014 11:05 AM, Mike Jones  
wrote:
 


Hannes, the Access Token and ID Token do quite different things and have 
different structures and properties.  The Access Token is an opaque value that 
grants access to resources.  An ID Token is a non-opaque JWT security token 
that makes claims about the authentication that occurred.  You can have one 
without the other or you can have both, depending upon the use case.  Thus, 
trying to move information between them would be problematic in several regards.

Also, trying to overload the Access Token to convey authentication information 
has been demonstrated in practice to be fraught with peril, and has resulted in 
some of the most prominent security breaches related to the misuse of OAuth.

                -- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, June 05, 2014 8:54 AM
To: Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

You are correct. Just adding to access token would make a lot of devs happy and 
that certainly should be discussed. 

Two requirements issues:

1. A key use case is passing auth ctx only. An access token means asking for 
consent to access something. This causes many sites to loose new users. Authen 
only can be implicit consent. 

2.  Compatibility with OpenId ID Token and flows. 

3. There is a need to support re-auth and MFA/LOA negotiation. Eg web site 
would like to obtain a higher level of assurance for a higher risk action. 

The non-tech requirement is the soln must be received by client and service 
provider developers as easy to implement in addition to 6749 or even OAuth 
1.1a. I mention it because devs feel this should be trivial.  Your suggestion 
of adding to access token certainly fits this. 

Phil

> On Jun 5, 2014, at 0:44, Hannes Tschofenig  wrote:
> 
> Hi Phil,
> 
> thanks for producing this document write-up. I have a somewhat basic 
> question regarding the document.
> 
> The id token contains the following mandatory information:
> - sis: issuer
> - sub: subject
> - aud: audience
> - iat: issued at
> - exp: expiry
> - auth_time: time when the end user was authenticated
> 
> An access token (when encoded as a JWT) may contain all these fields 
> except the auth_time (since auth_time is not defined in the JWT spec).
> 
> Given that your proposal actually does not define the authentication 
> protocol to be used between the resource owner/end user and the 
> authorisation server I am wondering whether it would be possible to 
> just add the auth_time parameter (and maybe some of the optional 
> parameters) to the access token. Then, you can skip the id token.
> 
> How do I come up with that question? In Kerberos, for example, the 
> above-listed information is carried within a single container (within 
> the ticket) and so I am curious to hear why we have to send the 
> information twice in OAuth (once in the access token, when the info is 
> passed per value, and again via the id token).
> 
> Maybe I missing something important here.
> 
> Ciao
> Hannes
> 
> 

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


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

Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03

[Bill Mills]

The HTTP specs don't limit these things, but implementations do, and the 
problems when you run into them are a rea pain.

DO we want to make this a hard limit, or should it be guidance in the form of 
RECOMMENDED or SHOULD?


On Friday, May 16, 2014 9:35 AM, Brian Campbell  
wrote:
 
Yeah, I agree with John here. There are a few good reasons to restrict the 
length of the code_challenge. One is trying to keep the authorization request 
URI to reasonable size as it will eventually run into various limits on clients 
and/or servers. The other is constraining the amount of data that an AS needs 
to store per code.






On Fri, May 16, 2014 at 7:41 AM, John Bradley  wrote:

From the AS side you probably want to know what the max size you need to store 
per code.
>
>
>
>On the call to the token endpoint it is a POST so size should not be an issue. 
> 
>
>
>
>
>On May 16, 2014, at 3:10 PM, Nat Sakimura  wrote:
>
>Now that I cannot remember what limit we were hitting, it might be a good idea 
>to remove the constraint and see if anyone protests. 
>>
>>
>>What do you think? 
>>
>>
>>Nat
>>
>>
>>
>>2014-05-14 20:46 GMT+09:00 Brian Campbell :
>>
>>That too would suggest that the length limit be on code_challenge because 
>>that's the parameter that will be on URIs getting passed around. The 
>>code_verifier is sent directly in the POST body from client to AS. 
>>>
>>>
>>>
>>>
>>>On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura  wrote:
>>>
>>>+1 for octet. We used to have "bytes" in JW* so I used "bytes" here, while 
>>>at the same time complaining in Jose that it should be "octet". JW* changed 
>>>to "octet" but I failed to sync with it in the last few edits. 


I do not quite remember which platform, but the reason for the limit was 
that some platform had some limitations as to the length of the sting to be 
passed to it through URI and we did not want the challenges to be truncated 
by that limit. 


Best, 


Nat



2014-05-13 6:56 GMT+09:00 Brian Campbell :


And it'd give the AS some direct guidance on protecting itself from crazy 
long code_challenge values rather than relying on the client not to do 
something creative. 
>
>
>
>
>On Mon, May 12, 2014 at 3:54 PM, Brian Campbell 
> wrote:
>
>Right but that's why I'm asking why not just put the limit on 
>code_challange rather than inferring it from code_verifyer + challenge 
>algorithm, which probably bounds it but doesn't necessarily do so? It's 
>not a big deal but would read more clearly, I think.
>>
>>
>>
>>
>>On Mon, May 12, 2014 at 3:48 PM, John Bradley  wrote:
>>
>>I think octets is more consistent with other JW* and OAuth specs.
>>>
>>>The code_challange is the same length as the code_verifyer or is a hash 
>>>of the code_verifyer so likely smaller than 128octets (43 ish for base64 
>>>256 bit)
>>>
>>>Limiting the code_verifyer size sets the upper bound for code_challange, 
>>>unless someone comes up with a really creative code challenge algorithm.
>>>
>>>I will talk to nat about changing it to octets when I see him tomorrow.
>>>
>>>John B.
>>>
>>>
>>>On May 12, 2014, at 11:15 PM, Derek Atkins  wrote:
>>>
 Brian Campbell  writes:

> I notice that code_verifier is defined as "high entropy cryptographic 
> random
> string of length less than 128 bytes"  [1], which brought a few 
> questions and
> comments to mind. So here goes:
>
> Talking about the length of a string in terms of bytes is always 
> potentially
> confusing. Maybe characters would be an easier unit for people like 
> me to wrap
> their little brains around?

 It depends if it really is characters or bytes.  For example there are
 many multi-byte UTF-8 characters, so if it really is bytes then saying
 characters is wrong because it could overflow.  So let's make sure we
 know what we're talking about.  Historically, if we're talking bytes 
 the
 IETF often uses the phrase "octets".  Would that be less confusing?

> Why are we putting a length restriction on the code_verifier anyway? 
> It seems
> like it'd be more appropriate to restrict the length of the 
> code_challenge
> because that's the thing the AS will have to maintain somehow (store 
> in a DB
> or memory or encrypt into the code). Am I missing something here?
>
> Let me also say that I hadn't looked at this document since its early 
> days in
> draft -00 or -01 last summer but I like the changes and how it's been 
> kept
> pretty simple for the common use-case while still allowing for crypto 
> agility/
> extension. Nice work!
>

Re: [OAUTH-WG] AC4 and what does it solve?

[Bill Mills]

The "re-auth" problem is an interesting one, the question of how does the 
client know if the user new authentication matches the previous one for 
something like mailbox access?  What happens if the end user doesn't auth as 
the same user?  If you really need this I think Connect solves this well, and 
OAuth is currently ocmpletely silent on this. 

 I don't think the userID indication to the client really does what we want.  
If we want to do this in OAuth I think it would be better to hand the expired 
token back to the AS and say "this is the user I expect" and have the AS fail 
if that doesn't match.

-bill
On Thursday, May 15, 2014 9:54 AM, Mike Jones  
wrote:
 
The "acr" claim (authentication context class reference) and the "acr_values" 
request parameter are explicitly modelled on the SAML authentication context 
work, but without the more complicated parts that didn't work out well in 
practice.  In this case, the request is just an ordered list of requested "acr" 
values.  Some of those values might be level numbers, but they also can and 
will be URNs such as "urn:mace:incommon:iap:silver" or 
"urn:mace:incommon:iap:bronze".  In fact, the same values can be used as are 
used with SAML, if it makes sense in the application context.

Phil, I don't understand why you're saying re-auth would be any different with 
full Connect than with AC4.  The re-auth request would be the same - an OAuth 
authorization request using prompt=none - in both cases.

                Cheers,
                -- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, May 15, 2014 9:43 AM
To: Thomas Hardjono
Cc: OAuth WG
Subject: Re: [OAUTH-WG] AC4 and what does it solve?

Thomas,

The intent was to be compatible with Connect (by request) but to solve only the 
authentication issue.  That would explain the overlap with UMA.

The issue (or bug?) we face is that OAuth Clients who continue to use 6749 
alone, aren't really authenticating users.

More importantly there is the question that has emerged over the past year 
about whether the client should know and be able to request authentication 
techniques and or levels.  There is a demarcation issue to sort out.

There is also the re-authen requirement that happens a lot where clients wish 
to elevate assurance level some how and may want to access a resource (not 
related to user profile).  In the re-auth case, you know the users profile, you 
just want to confirm is this really Thomas?  Just using OpenID means a much 
more complicated set of requests if only because everything has to be done 
twice.

Regarding AuthnContext, I understand the same issue happened and the model 
chosen (for assurance) didn't work. I don't want to repeat past sins (as Brian 
says). I believe LoA was the solution to the problem, but I think Mike wants to 
talk some more about it - which is why it is in draft 02. 

Phil

@independentid
www.independentid.com
phil.h...@oracle.com



On May 15, 2014, at 9:14 AM, Thomas Hardjono  wrote:

> 
> Phil,
> 
> I also just read draft-hunt-oauth-v2-user-a4c-02.
> This proposal sounds awfully close to what UMA is doing for consent 
> management.
> 
> The Resource Owner (RO) in UMA has the option to set access control 
> policy (including expected the authentication LOA of the user/client). 
> The RO also has the option to require the Client/User to provide 
> Claims regarding both entities (UMA distinguishes between the Client 
> and the Human person using the Client). UMA relies on OpenID-Connect 
> OP to provide the Claims.
> 
> btw. is your intention to create something akin to AuthnContext in 
> SAML2.0?
> 
> Best.
> 
> /thomas/
> 
> 
> 
> 
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Bill Mills
> Sent: Thursday, May 15, 2014 11:51 AM
> To: OAuth WG
> Subject: [OAUTH-WG] AC4 and what does it solve?
> 
> I'm reading the AC4 draft and I want to understand the problems it's 
> actually trying to solve, which isn't as clear as it could be in the 
> prose.  It looks like it's extending OAuth to:
> 
> 1) Allowing the client to specify a desired authentication level.
> 2) Giving the client an opaque identifier to differentiate users.
> 3) Telling the client what level of authentication was used.
> 
> Do I have this right?
> 
> Thanks,
> 
> -bill
> ___
> 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-WG] AC4 and what does it solve?

[Bill Mills]

I'm reading the AC4 draft and I want to understand the problems it's actually 
trying to solve, which isn't as clear as it could be in the prose.  It looks 
like it's extending OAuth to:

1) Allowing the client to specify a desired authentication level.
2) Giving the client an opaque identifier to differentiate users.
3) Telling the client what level of authentication was used.

Do I have this right?

Thanks,

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

Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

[Bill Mills]

I think there's a use case for this work that may or may not be covered by the 
PoP spec, and in fact I think this work is related to that.  The MAC token work 
is really one use case of POP tokens.  Rather than shouting it down let's 
figure out how to solve this use case.


On Wednesday, May 14, 2014 8:39 AM, Justin Richer  wrote:
 
I agree with Brian and object to the Authentication work item. I think there’s 
limited interest and utility in such a draft, especially now that OpenID 
Connect has been published and its core authentication capabilities are 
identical to what was called for in the other draft a year ago (a similarity, 
I’ll add, which was noted at the time). 

 — Justin



On May 14, 2014, at 8:24 AM, Brian Campbell  wrote:

I would object to 'OAuth Authentication' being picked up by the WG as a work 
item. The starting point draft has expired and it hasn't really been discusses 
since Berlin nearly a year ago.  As I recall, there was only very limited 
interest in it even then. I also don't believe it fits well with the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of
 Possession for Code Extension' for which there is an excellent starting
 point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a 
relativity simple security enhancement which addresses problems currently being 
encountered in deployments of native clients.  






On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig  
wrote:

Hi all,
>
>you might have seen that we pushed the assertion documents and the JWT
>documents to the IESG today. We have also updated the milestones on the
>OAuth WG page.
>
>This means that we can plan to pick up new work in the group.
>We have sent a request to Kathleen to change the milestone for the OAuth
>security mechanisms to use the proof-of-possession terminology.
>
>We also expect an updated version of the dynamic client registration
>spec incorporating last call feedback within about 2 weeks.
>
>We would like you to think about adding the following milestones to the
>charter as part of the re-chartering effort:
>
>-
>
>Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
>Proposed Standard
>Starting point: 
>
>Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
>a Proposed Standard
>Starting point: 
>
>Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
>Proposed Standard
>Starting point: 
>
>-
>
>We also updated the charter text to reflect the current situation. Here
>is the proposed text:
>
>-
>
>Charter for Working Group
>
>
>The Web Authorization (OAuth) protocol allows a user to grant a
>third-party Web site or application access to the user's protected
>resources, without necessarily revealing their long-term credentials,
>or even their identity. For example, a photo-sharing site that
>supports OAuth could allow its users to use a third-party printing Web
>site to print their private pictures, without allowing the printing
>site to gain full control of the user's account and without having the
>user share his or her photo-sharing sites' long-term credential with
>the printing site.
>
>The OAuth 2.0 protocol suite encompasses
>
>* a protocol for obtaining access tokens from an authorization
>server with the resource owner's consent,
>* protocols for presenting these access tokens to resource server
>for access to a protected resource,
>* guidance for securely using OAuth 2.0,
>* the ability to revoke access tokens,
>* standardized format for security tokens encoded in a JSON format
>  (JSON Web Token, JWT),
>* ways of using assertions with OAuth, and
>* a dynamic client registration protocol.
>
>The working group also developed security schemes for presenting
>authorization tokens to access a protected resource. This led to the
>publication of the bearer token, as well as work that remains to be
>completed on proof-of-possession and token exchange.
>
>The ongoing standardization effort within the OAuth working group will
>focus on enhancing interoperability and functionality of OAuth
>deployments, such as a standard for a token introspection service and
>standards for additional security of OAuth requests.
>
>-
>
>Feedback appreciated.
>
>Ciao
>Hannes & Derek
>
>
>
>___
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 

 Brian Campbell
Portfolio Architect
@ bcampb...@pingidentity.com 
 +1 720.317.2061 
Connect with us…   

___
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] [http-auth] Review Request for third draft of "Signing HTTP Messages"

[Bill Mills]

I do look at some of the stuff we're doing and thing "Is that all gonna fit in 
one header line?".   Breaking some of this out into a new header field is 
reasonable but doesn't feel as clean as having it all in one place.


On Tuesday, May 13, 2014 8:33 AM, Justin Richer  wrote:
 
They’re similar in that they both take elements from the HTTP message and 
create a signature on them, and they use the same “list the order of the 
elements” trick to avoid normalization to a large extent. The main difference 
is that my draft uses JWS as the signature (and ultimately transport) mechanism 
and the Cavage draft (and the AWS method it is born from, as I understand it) 
uses a new HTTP auth header format, much like OAuth 1.0 and the (old, dusty, 
abandoned, can-we-stop-bringing-it-up) MAC draft. My original (unpublished) 
version of the draft didn’t actually specify or care how you got the key, as I 
think that HTTP signing is a general mechanism.

That said, there seems to be a lot of interest in solving this case that OAuth 
1.0 managed to get somewhat right-ish.

— Justin


On May 12, 2014, at 1:59 PM, Hannes Tschofenig  
wrote:

> Conceptually, draft-cavage-http-signatures-02 is the same as OAuth 1.0.
> Therefore, the symmetric key part of the document is the same as the MAC
> token.
> 
> Not quite sure why the authors have not read the OAuth work.
> 
> On 05/09/2014 01:22 AM, Phil Hunt wrote:
>> How does this compare with justin's draft?
>> 
>> Phil
>> 
>> Begin forwarded message:
>> 
>>> *From:* Manu Sporny >> >
>>> *Date:* May 8, 2014 at 14:41:55 PDT
>>> *To:* IETF HTTP Auth mailto:http-a...@ietf.org>>
>>> *Cc:* Julian Reschke >> >, Mark Nottingham >> >, Web Payments CG >> >
>>> *Subject:* *[http-auth] Review Request for third draft of "Signing
>>> HTTP Messages"*
>>> 
>>> After feedback from Mark Nottingham[1], Julian Reschke[2], folks in the
>>> HTTP Auth WG, and people in the Web Payments CG, we've modified the HTTP
>>> Signatures specification in the following ways:
>>> 
>>> 1. The specification has been renamed to "Signing HTTP Messages".
>>> 2. The specification now covers both a signature-based Authorization
>>>  mechanism (client-to-server) as well as a general mechanism to sign
>>>  HTTP messages (client-to-server and server-to-client).
>>> 3. A new "Signature" header has been introduced.
>>> 4. The layout has been modified heavily to streamline the information
>>>  conveyed in the spec.
>>> 5. New registries have been created for the algorithms referred to in
>>>  the specification.
>>> 6. We're now more specific in the way certain canonicalizations are
>>>  performed.
>>> 7. More examples have been added, including how to digitally sign
>>>  the body of an HTTP message.
>>> 
>>> The basic mechanism of generating the signatures has not changed (and
>>> has been stable for over a year).
>>> 
>>> The newest spec can be found here:
>>> 
>>> http://tools.ietf.org/html/draft-cavage-http-signatures-02
>>> 
>>> The diff is here:
>>> 
>>> http://tools.ietf.org/rfcdiff?url2=draft-cavage-http-signatures-02.txt
>>> 
>>> Matt, Yoav, Kathleen, if there are no show stopping review comments, I'd
>>> like to push this spec onto the RFC track in the HTTP Auth WG, or
>>> HTTPbis/2 WG. It'll be ready for a LC in a month or two. I realize that
>>> HTTP Auth may be shutting down next month, so what's the next step to
>>> get the HTTP Signatures spec further down the IETF RFC track?
>>> 
>>> -- manu
>>> 
>>> [1]
>>> http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0038.html
>>> [2]
>>> http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0036.html
>>> 
>>> -- 
>>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>>> Founder/CEO - Digital Bazaar, Inc.
>>> blog: The Marathonic Dawn of Web Payments
>>> http://manu.sporny.org/2014/dawn-of-web-payments/
>>> 
>>> ___
>>> http-auth mailing list
>>> http-a...@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/http-auth
>> 
>> 
>> ___
>> 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] Fwd: HTTP protocol version in MAC signatures

[Bill Mills]

The MAC draft has been idle for a while, the mindshare has been on POP tokens.  
Also we haven't had anyone looking to actively adopt a signed HTTP token 
profile.  You're solving a real problem and have a need for it, so rekindling 
this in some form would be good.  I've always maintained that we need a signed 
token type because we have use cases where we use OAuth 1.0a for Flickr and 
strategically I'd like to get something in the OAuth 2 framework to replace it.

A POP token could include an encrypted HMAC secret, but I'm not sure if the 
extra decrypt required at the server kills the benefit of the speed of HMAC.


On Tuesday, May 13, 2014 8:16 AM, Blair Strang  wrote:
 
Hi Hannnes,

Yes, so in terms of well-defined specs for HTTP request signing, there is 
basically AWS, OAuth 1.0a HMAC, and the OAuth 2.0 draft HMAC stuff which is 
looking a bit abandoned.

The v2 and v4 signing processes for AWS are documented here.
[1] http://docs.aws.amazon.com/general/latest/gr/signature-version-2.html

[2] http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html

Looking at the slides you sent, my colleague Scott and I have been working on 
something running along the same lines. This has largely been for internal use, 
but we have had our eye on a design with general utility.

So far we have been working to clearly define *only* how HTTP requests can be 
authenticated using a JWT/JWS, independent of the issues of key distribution 
and sessions (an OAuth2 extension is one option for sessions / key agreement, 
but there are obviously other ways).


We actually have a spec and proof of concept in progress for JWS based request 
signing. We do need some time to clean up the spec for public consumption, but 
would you be interested in seeing that?

Thanks,

    Blair.

 Long form details below here -

Our view is that request authentication (mac/signature) and the session (or key 
agreement) mechanisms needed to support it are largely orthogonal.

We have been working to specify a mechanism for authenticating HTTP requests 
using JWT/JWS. (The tokens look just like JWTs, but it is better to specify on 
top of JWS).

Our approach was that the client computes a "signature base string" or "string 
to sign" in a fashion very similar to AWS v2, while adding header signing 
similar to that in AWS v4. This fixes a gap in the OAuth 1.0a HMAC token spec. 

The client then embeds a digest of the "signature base string" in a JWS signed 
by the client, along with several other required fields (e.g. a field 
identifying the requestor, optional key id, expiry, list of signed http 
headers, ...) to authenticate the request.

The nice thing about embedding the request digest in a JWT/JWS signed payload 
is that you get all the flexibility of JWS in terms of algorithms. 

Also, the implementation also comes out very nice, since you need just string 
processing of the request to get a canonical version plus a digest operation - 
and the "hard crypto stuff" can be handled by a JWS library. 

However, there are some constraints in terms of practicality using the JWS 
standard (not insurmountable, but there):

1. RSA - A client with a private key can easily RSA-sign HTTP requests, but the 
Authorization: header will be several hundred bytes long due to the size of the 
RSA signature. Speed is high, but so is bandwidth required.

2. ECDSA - ECDSA produces much smaller payloads (few hundred bytes) but 
requires much more processing effort (order of milliseconds).

3. HMAC - A shared HMAC key will be the most efficient in terms of speed & 
storage, but requires additional session establishment dance which is slightly 
less elegant than a client using a private key directly.

Request authorisation using a private key directly works well for 
server-to-server or "big client" to server, but not so well for mobile with 
power and bandwidth constraints. In this case, the approach we are taking for a 
client to bootstrap from possession of a private key is to send an RSA signed 
request to establish a shared HMAC key, then use HMAC signed requests.

Thanks & regards,

    Blair.

--
Blair Strang | Senior Security Engineer
Covata | Own Your Data
covata.com

Level 4 156 Clarence Street | Sydney NSW 2000
© 2014 CDHL parent company for all Covata entities











On Tue, May 13, 2014 at 4:02 AM, Hannes Tschofenig  
wrote:

Hi Phil,
>Hi Blair,
>
>this is a good point. I also don't see a reason why the HTTP protocol
>version should be included in the keyed message digest (from a security
>point of view).
>
>It might, however, be worthwhile to point out that we are exploring
>different solution directions, as described in this slide deck
>http://www.tschofenig.priv.at/oauth/IETF-OAuth-PoP.pptx
>
>For this reason it might be interesting to know what AWS implements. Do
>you guys have a reference?
>
>Ciao
>Hannes
>
>
>On 05/09/2014 05:47 AM, Phil Hunt wrote:
>> Fyi
>>
>> Phil
>>
>> Begin forwarded message:
>>
>>> *From:* Blair Stra

Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

[Bill Mills]

To me the fundamental question of whether a client has to be registered in each 
place it is used is quite significant.  We don't address the problem and have 
not discussed it enough.

-bill
On Friday, April 4, 2014 11:39 PM, Torsten Lodderstedt 
 wrote:
 
Hi Bill,

which scalability problem are you referring to? As far as I remember there were 
issues around the management API but not the core protocol.

regards,
Torsten.

Am 04.04.2014 um 18:41 schrieb Bill Mills :


Given the fundamental scalability problem we discussed in London do we really 
feel we're ready?
>On Friday, April 4, 2014 3:07 AM, Hannes Tschofenig 
> wrote:
> 
>Hi all,
>
>This is a Last Call for comments on the dynamic client registration
>documents:
>
>* OAuth 2.0 Dynamic Client Registration Core Protocol
>http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16
>
>* OAuth 2.0 Dynamic Client Registration Metadata
>http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00
>
>Since we have to do the last call for these two documents together we
>are setting the call for **3 weeks**.
>
>Please have your comments in no later than April 25th.
>
>Ciao
>Hannes & Derek
>
>___
>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] Working Group Last Call on Dynamic Client Registration Documents

[Bill Mills]

Given the fundamental scalability problem we discussed in London do we really 
feel we're ready?
On Friday, April 4, 2014 3:07 AM, Hannes Tschofenig  
wrote:
 
Hi all,

This is a Last Call for comments on the dynamic client registration
documents:

* OAuth 2.0 Dynamic Client Registration Core Protocol
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16

* OAuth 2.0 Dynamic Client Registration Metadata
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00

Since we have to do the last call for these two documents together we
are setting the call for **3 weeks**.

Please have your comments in no later than April 25th.

Ciao
Hannes & Derek

___
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-hunt-oauth-pop-architecture-00.txt

[Bill Mills]

I really *like* the name "proof of possession", but I think the acronym PoP is 
going to be confused with POP.  HOTK has the advantage of not being a homonym 
for aything else.  What about "Possession Proof"?

 
-bill




William J. Mills
"Paranoid" MUX Yahoo!


On Thursday, April 3, 2014 1:38 AM, "internet-dra...@ietf.org" 
 wrote:
 

A new version of I-D, draft-hunt-oauth-pop-architecture-00.txt
has been successfully submitted by Hannes Tschofenig and posted to the
IETF repository.

Name:        draft-hunt-oauth-pop-architecture
Revision:    00
Title:        OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
Document date:    2014-04-03
Group:        Individual Submission
Pages:        21
URL:            
http://www.ietf.org/internet-drafts/draft-hunt-oauth-pop-architecture-00.txt
Status:        
https://datatracker.ietf.org/doc/draft-hunt-oauth-pop-architecture/
Htmlized:      http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-00


Abstract:
   The OAuth 2.0 bearer token specification, as defined in RFC 6750,
   allows any party in possession of a bearer token (a "bearer") to get
   access to the associated resources (without demonstrating possession
   of a cryptographic key).  To prevent misuse, bearer tokens must to be
   protected from disclosure in transit and at rest.

   Some scenarios demand additional security protection whereby a client
   needs to demonstrate possession of cryptographic keying material when
   accessing a protected resource.  This document motivates the
   development of the OAuth 2.0 proof-of-possession security mechanism.

                                                                                
  


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

The IETF Secretariat___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fwd: [kitten] [IANA #731918] SASL mechanism not listed

[Bill Mills]

Google used XOAUTH for it's original OAuth 1.0a based mechanism.  They used 
XOAUTH2 to specifically not conflict with whatever name we standardized on for 
the mechanism as standardized.

They plan, according to Ryan who's been participating on list, to implement the 
standardized mechanism definition under the OAUTHBEARER mechanism name so there 
should be no conflict.

Regards,

-bill



On Monday, March 24, 2014 12:34 PM, Stephen Farrell  
wrote:
 

See below. I think (not quite sure) that this is better
discussed on the kitten list.

Ta,
S.



 Original Message 
Subject: [kitten] [IANA #731918] SASL mechanism not listed
Date: Mon, 24 Mar 2014 19:33:06 +
From: Stephen Farrell 
To: kit...@ietf.org 
CC: iana-questi...@iana.org 


Hiya,

IANA were asked the following question a while back, but I
dropped the ball;-)

I'd appreciate your thoughts on the matter. I'm not quite
sure which registries are meant exactly though.

(I'll also forward to the oauth WG, but not cross-post)

Thanks,
S.



The following draft describes a SASL mechanism that is in use on
GMail and should not therefore be allocated to another scheme unless
we want bad things to happen.

http://tools.ietf.org/id/draft-murchison-sasl-login-00.txt

The strings XOAUTH and XOAUTH2 are also being used for a preliminary
version of the OAUTH spec as well.

The reason Google is using this particular mechanism rather than
PLAIN is that it is the one that has the widest client support:

http://www.fehcom.de/qmail/smtpauth.html

So it would be a real disaster if this particular code point was re-issued.

It would probably be a good idea if every registry had a list of 'dirty'
code points that must not be reused because there are existing applications.



___
Kitten mailing list
kit...@ietf.org
https://www.ietf.org/mailman/listinfo/kitten




___
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] Discussion about Dynamic Client Registration Management Work

[Bill Mills]

I'm in.



On Wednesday, March 5, 2014 1:20 AM, John Bradley  wrote:
 
OK
On Mar 5, 2014, at 9:19 AM, Richer, Justin P.  wrote:

> I can do that, too.
> 
> -- Justin
> 
> From: OAuth [oauth-boun...@ietf.org] on behalf of Phil Hunt 
> [phil.h...@oracle.com]
> Sent: Tuesday, March 04, 2014 1:13 PM
> To: Hannes Tschofenig
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Discussion about Dynamic Client Registration 
> Management Work
> 
> WFM
> 
> Phil
> 
>> On Mar 4, 2014, at 18:04, Hannes Tschofenig  
>> wrote:
>> 
>> Hi all,
>> 
>> at today's OAuth meeting I suggested to get together during the week to
>> continue our conversation about draft-ietf-oauth-dyn-reg-management-00,
>> which dominated our conversation at the meeting today.
>> 
>> I would suggest to get together on **Thursday, at 11:30** (for lunch) at
>> the IETF registration desk.
>> 
>> Objections?*
>> 
>> Ciao
>> Hannes
>> 
>> PS: I know that your schedule during the IETF meeting is quite full ...
>> 
>> ___
>> 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