Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 12 Feb 2013 11:10:27 +0200

Here are my notes. 

Participants:

* John Bradley
* Derek Atkins
* Phil Hunt
* Prateek Mishra
* Hannes Tschofenig
* Mike Jones
* Antonio Sanso
* Justin Richer

Notes: 

My slides are available here: http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt

Slide #2 summarizes earlier discussions during the conference calls. 

-- HTTP vs. JSON

Phil noted that he does not like to use the MAC Token draft as a starting point because it does not re-use any of the work done in the JOSE working group and in particular all the libraries that are available today. He mentioned that earlier attempts to write the MAC Token code lead to problems for implementers. 

Justin responded that he does not agree with using JSON as a transport mechanism since this would replicate a SOAP style. 

Phil noted that he wants to send JSON but the signature shall be computed over the HTTP header field. 

-- Flexibility for the keyed message digest computation

From earlier discussion it was clear that the conference call participants wanted more flexibility regarding the keyed message digest computation. For this purpose Hannes presented the DKIM based approach, which allows selective header fields to be included in the digest. This is shown in slide #4. 

After some discussion the conference call participants thought that this would meet their needs. Further investigations would still be useful to determine the degree of failed HMAC calculations due to HTTP proxies modifying the content. 

-- Key Distribution

Hannes presented the open issue regarding the choice of key distribution. Slides #6-#8 present three techniques and Hannes asked for feedback regarding the preferred style. Justin and others didn't see the need to decide on one mechanism - they wanted to keep the choice open. Derek indicated that this will not be an acceptable approach. Since the resource server and the authorization server may, in the OAuth 2.0 framework, be entities produced by different vendors there is an interoperability need. Justin responded that he disagrees and that the resource server needs to understand the access token and referred to the recent draft submission for the token introspection endpoint. Derek indicated that the resource server has to understand the content of the access token and the token introspection endpoint just pushes the problem around: the resource server has to send the access token to the authorization server and then the resource server gets the result back (which he then again needs to understand) in order to make a meaningful authorization decision. 

Everyone agreed that the client must receive the session key from the authorization server and that this approach has to be standardized. It was also agreed that this is a common approach among all three key distribution mechanisms.

Hannes asked the participants to think about their preference. 

The questions regarding key naming and the indication for the intended resource server the client wants to talk to have been postponed. 
 
Ciao
Hannes

---

From: William Mills <[email-masked]>
Date: Tue, 12 Feb 2013 01:27:29 -0800 (PST)

Is key distribution how AS and PR share keys  for token encryption/decryption or specifically about the keys for the HOK tokens?

For the MAC token spec, I don't actually care whether we use JSON or now, but I'm in full agreement that we do NOT duplicate any HTTP info into the JSON.  Just signatures of that stuff.

________________________________
 From: Hannes Tschofenig <[email-masked]>
To: IETF oauth WG <[email-masked]> 
Sent: Tuesday, February 12, 2013 1:10 AM
Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
 
Here are my notes. 

Participants:

* John Bradley
* Derek Atkins
* Phil Hunt
* Prateek Mishra
* Hannes Tschofenig
* Mike Jones
* Antonio Sanso
* Justin Richer

Notes: 

-- HTTP vs. JSON

-- Key Distribution

Hannes presented the open issue regarding the choice of key distribution. Slides #6-#8 present three techniques and Hannes asked for feedback regarding the preferred style. Justin and others didn't see the need to decide on one mechanism - they wanted to keep the choice open. Derek indicated that this will not be an acceptable approach. Since the resource server and the authorization server may, in the OAuth 2.0 framework, be entities produced by different vendors there is an interoperability need. Justin responded that he disagrees and that the resource server needs to understand the access token and referred to the recent draft submission for the token introspection endpoint. Derek indicated that the resource server has to understand the content of the access token and the token introspection endpoint just pushes the problem around: the resource server has to send the access token to the authorization server and then the resource server gets the result
 back (which he then a
gain needs to understand) in order to make a meaningful authorization decision. 

Ciao
Hannes

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 12 Feb 2013 11:44:27 +0200

Hi Bill, 

> Is key distribution how AS and PR share keys  for token encryption/decryption or specifically about the keys for the HOK tokens?
In order for the client to compute the keyed message digest it needs to have the session key. This session key is sent from the authorization server to the client and everyone on the call agreed that this has to be standardized. 

The resource server who receives the message from the client also needs to have the session key to verify the message. How the resource server obtains this session key was subject for some discussion on the call. I presented three different ways of how the resource server is able to obtain that key. We have to decide on one mandatory-to-implement mechanism. The open issue is which one? 
 
> For the MAC token spec, I don't actually care whether we use JSON or now, but I'm in full agreement that we do NOT duplicate any HTTP info into the JSON.  Just signatures of that stuff.
I believe the folks on the call also agreed with you on that aspect that the content of the HTTP message should not be replicated in the JSON payload itself. 

Ciao
Hannes

> Hannes presented the open issue regarding the choice of key distribution. Slides #6-#8 present three techniques and Hannes asked for feedback regarding the preferred style. Justin and others didn't see the need to decide on one mechanism - they wanted to keep the choice open. Derek indicated that this will not be an acceptable approach. Since the resource server and the authorization server may, in the OAuth 2.0 framework, be entities produced by different vendors there is an interoperability need. Justin responded that he disagrees and that the resource server needs to understand the access token and referred to the recent draft submission for the token introspection endpoint. Derek indicated that the resource server has to understand the content of the access token and the token introspection endpoint just pushes the problem around: the resource server has to send the access token to the authorization server and then the resource server gets the result back (which he then a

---

From: William Mills <[email-masked]>
Date: Tue, 12 Feb 2013 02:06:55 -0800 (PST)

For key exchange that's true for symmetric key, but no key exchange is required for public key signing by the client.

There's so many possibilities here, but I think the best is that the key materiel is conveyed in the token.  The key could be included directly, or another way to implement would be that a salt is included in the token and then the secret is some crypto hash of the token contents and a shared secret between the AS and the PR.  

If we we must pick one I'd say include the signing key as part of the encrypted token itself.  Completely self contained then.

________________________________
 From: Hannes Tschofenig <[email-masked]>
To: William Mills <[email-masked]> 
Cc: Hannes Tschofenig <[email-masked]>; IETF oauth WG <[email-masked]> 
Sent: Tuesday, February 12, 2013 1:44 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
 
Hi Bill, 

Ciao
Hannes

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 12 Feb 2013 10:28:56 +0000

Hi Hannes,

how this session key "differs" from the key described in the current draft [0]?

Thanks and regards

Antonio

[0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 12 Feb 2013 10:37:44 +0000

Hi Hannes, All,
> Phil noted that he does not like to use the MAC Token draft as a starting point because it does not re-use any of the work done in the JOSE working group and in particular all the libraries that ar…

I'm concerned that the argument about the arguable absence of utilities 
for processing MAC tokens; it is obvious it is simpler to process MAC 
than more involved tokens and to be honest it is really not a point at 
all as the utility of a given token type should be judged on what it can 
bring to the whole system as opposed to whether it can be simpler or not 
to implement it - apologies if I've misread the above note and/or taken 
it out of context

Thanks, Sergey

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 12 Feb 2013 13:06:47 +0200

The transport of the session key from the authorization server is described in Section 5.1 and is called "mac_key". 

The mechanism to transport the session key from the authorization server to the resource server is not yet described in the document. This has historical reasons: OAuth 1.0 did not separate the authorization server from the resource server in the way OAuth 2.0 does.

Ciao
Hannes

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 12 Feb 2013 11:51:51 +0000

Thanks Hannes

> The mechanism to transport the session key from the authorization server to the resource server is not yet described in the document. This has historical reasons: OAuth 1.0 did not separate the aut…

but why do not we hit this same issue in the JWS case? In this situation there is as well a key for sign... And AS and RS can be as well two different entities...

Regards

Antonio

---

From: William Mills <[email-masked]>
Date: Tue, 12 Feb 2013 07:53:07 -0800 (PST)

One of the things I do not like about a MTI key transport mechanism if we put it in the token is that there will be some systems that already have a per user secret provisioned and we'll be forcing data duplication.  If if the encrypted token already includes any random component that could easily be used as part of the signing key.  So I feel like this will fatten up the token, potentially a lot.

If we don't put it in the token this problem is WAY harder.

________________________________
 From: Hannes Tschofenig <[email-masked]>
To: Antonio Sanso <[email-masked]> 
Cc: Hannes Tschofenig <[email-masked]>; William Mills <[email-masked]>; IETF oauth WG <[email-masked]> 
Sent: Tuesday, February 12, 2013 3:06 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

Ciao
Hannes

On Feb 12, 2013, at 12:28 PM, Antonio Sanso wrote:

>>> Hannes presented the open issue regarding the choice of key distribution. Slides #6-#8 present three techniques and Hannes asked for feedback regarding the preferred style. Justin and others didn't see the need to decide on one mechanism - they wanted to keep the choice open. Derek indicated that this will not be an acceptable approach. Since the resource server and the authorization server may, in the OAuth 2.0 framework, be entities produced by different vendors there is an interoperability need. Justin responded that he disagrees and that the resource server needs to understand the access token and referred to the recent draft submission for the token introspection endpoint. Derek indicated that the resource server has to understand the content of the access token and the token introspection endpoint just pushes the problem around: the resource server has to send the access token to the authorization server and then the resource server gets the
 result back (which he then
>> a

---

From: John Bradley <[email-masked]>
Date: Tue, 12 Feb 2013 13:47:16 -0300

The token may or may not need to be encrypted on top of being signed.  All tokens red to be signed.

If the Key is asymmetric or using DH key agreement it would not need to be encrypted. 
If it is a symmetric key then yes you need to use encrypted key transport.   The JOSE working group is working on a clean method of using JOSE fro Key transport.
We should align with that.

In some ways ECDH-ES would be perfect for this, but I am realistic about adoption.

If we fall back to regular DH then if RS's have a way of communicating there DH info to the AS then when the client requests a token providing it's DH info the server can place that in the token and return the RS's info in a separate parameter to the client and the key is never sent over the wire, so no encryption needed.  

One problem is that who the intended RS is may be a touch vague in OAuth. (This affects both key transport and agreement.)  so the AS may not know what the RS is if it is not explicit in the scope.

That may lead us to make asymmetric keys (including the public key of the client)  as the default as that is the only one that works with both known and unknown RS.

You could design a DH floe to work where the RS on request failures provides its DH info and then the client passes that and it's info to the AS in the token request.
That works but sort of messes up the flow.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Tue, 12 Feb 2013 09:30:50 -0800

Clarification.  I think Justin and I were in agreement that we don't want to see a format that requires JSON payloads.  We are both interested in a JSON token used in the authorization header that could be based on a computed signature of some combination of http headers and body if possible.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Tue, 12 Feb 2013 12:34:31 -0500

That's my reading of it as well, Phil, thanks for providing the 
clarification. One motivator behind using a JSON-based token is to be 
able to re-use some of the great work that the JOSE group is doing but 
apply it to an HTTP payload.

What neither of us want is a token type that requires stuffing all 
query, header, and other parameters *into* the JSON object itself, which 
would be a more SOAPy approach.

  -- Justin

---

From: Prateek Mishra <[email-masked]>
Date: Wed, 13 Feb 2013 11:13:32 -0500

Hannes,

1) Its not clear to me that we need  to specify exchanges between the AS 
and the RS as part of this work. The core specification leaves this
unspecified. There could be many different ways that the AS and RS 
collaborate to validate signatures in messages received from the client.

2) Regarding (symmetric) key distribution, dont we need some kind of 
existing trust relationship between the client and AS to make this 
possible? I guess it
would be enough to require use of a "confidential" client, that would 
make it possible for the two parties to agree on a session key at the 
point where an access token
is  issued by the AS.

3) I think do need an MTI key distribution protocol as part of the 
specification, leaving that as a choice would hurt interoperability.

- prateek

---

From: William Mills <[email-masked]>
Date: Wed, 13 Feb 2013 21:41:24 -0800 (PST)

You have a trust relationship with the user and perhaps with the client.

________________________________
 From: Prateek Mishra <[email-masked]>
To: [email-masked] 
Sent: Wednesday, February 13, 2013 8:13 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
 
Hannes,

- prateek

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Feb 2013 09:45:38 +0200

Hi Prateek, 

thanks for your questions. 

On Feb 13, 2013, at 6:13 PM, Prateek Mishra wrote:

> Hannes,
> 
> 1) Its not clear to me that we need  to specify exchanges between the AS and the RS as part of this work. The core specification leaves this
> unspecified. There could be many different ways that the AS and RS collaborate to validate signatures in messages received from the client.

It depends what the group wants to accomplish. So far, I thought that the goal was to offer the ability to provide a sufficient description in our specifications so that the authorization server and the resource server can be provided by different vendors and that they still interoperate. 

The group may have changed their mind in the meanwhile. 

What is your view? 

> 
> 2) Regarding (symmetric) key distribution, dont we need some kind of existing trust relationship between the client and AS to make this possible? I guess it
> would be enough to require use of a "confidential" client, that would make it possible for the two parties to agree on a session key at the point where an access token
> is  issued by the AS.

That's a very good question. I have not formed an option about this issue yet particularly given the recent capability to dynamically register clients.

> 
> 3) I think do need an MTI key distribution protocol as part of the specification, leaving that as a choice would hurt interoperability.

That's my impression as well.  

Ciao
Hannes

---

From: Justin Richer <[email-masked]>
Date: Thu, 14 Feb 2013 09:00:27 -0500

> The group may have changed their mind in the meanwhile.

My view on this, as expressed in the call, is that the interoperability 
be between the Client and AS and between the Client and RS. 
Interoperability between AS and RS from different vendors is a different 
question all together, and I don't think it really ought to be in scope 
for this. I think that with this signed token component we should build 
something that doesn't *preclude* this kind of AS/RS interop, but that 
the solution to that is a more general question. This is the motivation 
behind things like the token introspection draft.

> That's a very good question. I have not formed an option about this issue yet particularly given the recent capability to dynamically register clients.

I don't think that signing tokens should require confidential clients. 
This was one of the implementation issues with OAuth 1, as it required a 
"consumer_secret" at all times. This led to Google telling people to use 
"anonymous" as the "consumer_secret" for what were effectively public 
clients. Even with dynamic registration, there's still a place for 
public clients, in my opinion.

> That's my impression as well.

I agree that we need to pick one style that assumes which party needs 
access to which keys and what time. I disagree that we need to define 
exactly how all of those keys get there.

  -- Justin

---

From: Prateek Mishra <[email-masked]>
Date: Thu, 14 Feb 2013 13:59:43 -0500

Regarding the question of AS to RS communication, I think capturing it 
is a reasonable task but not one essential to this activity.

So my view would be to exclude it from consideration in this groups 
activity. We have many use-cases where support for confirmation that goes
beyond the currently supported bearer model would be valuable. In these 
cases, the AS and RS belong to the same administrative domain.

- prateek

---

From: Prateek Mishra <[email-masked]>
Date: Thu, 14 Feb 2013 14:20:57 -0500

Justin - my comment was scoped to *key distribution* - not to the 
general use of public clients.

I was wondering how one can distribute keys or have key agreement 
between an AS and a client, if there is no existing trust relationship 
between them. Maybe there is some
clever crypto way of achieving this, but I personally dont understand 
how this might happen.

- prateek

>>> would be enough to require use of a "confidential" client, that 
>>> would make it possible for the two parties to agree on a session key 
>>> at the point where an access token
>>> is  issued by the AS.
>> That's a very good question. I have not formed an option about this 
>> issue yet particularly given the recent capability to dynamically 
>> register clients.
>
> This was one of the implementation issues with OAuth 1, as it required 
> a "consumer_secret" at all times. This led to Google telling people to 
> use "anonymous" as the "consumer_secret" for what were effectively 
> public clients. Even with dynamic registration, there's still a place 
> for public clients, in my opinion.
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 14 Feb 2013 14:24:31 -0500

Prateek,

My point was that a public client could very easily and safely be issued 
a secret in the form of an OAuth token. This includes any type of 
signing key that the MAC/etc token would want to use. What public 
client's can't have are configuration-time keys, like a client_secret. 
It's important to not conflate the two.

  -- Justin

On 02/14/2013 02:20 PM, Prateek Mishra wrote:
>>>> 2) Regarding (symmetric) key distribution, dont we need some kind 
>>>> of existing trust relationship between the client and AS to make 
>>>> this possible? I guess it
>>>> would make it possible for the two parties to agree on a session 
>>>> key at the point where an access token
>>>> is  issued by the AS.
>> I don't think that signing tokens should require confidential 
>> clients. This was one of the implementation issues with OAuth 1, as 
>> it required a "consumer_secret" at all times. This led to Google 
>> telling people to use "anonymous" as the "consumer_secret" for what 
>> were effectively public clients. Even with dynamic registration, 
>> there's still a place for public clients, in my opinion.
>>
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 14 Feb 2013 21:44:10 +0000

I'm in favor of reusing the JWT work that this WG is also doing. :-)

I'm pretty skeptical of us inventing another custom scheme for signing HTTP headers.  That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved in the first place.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Tuesday, February 12, 2013 9:35 AM
To: Phil Hunt
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

That's my reading of it as well, Phil, thanks for providing the clarification. One motivator behind using a JSON-based token is to be able to re-use some of the great work that the JOSE group is doing but apply it to an HTTP payload.

What neither of us want is a token type that requires stuffing all query, header, and other parameters *into* the JSON object itself, which would be a more SOAPy approach.

  -- Justin

On 02/12/2013 12:30 PM, Phil Hunt wrote:
>> My slides are available here: 
>> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>
>> Hannes presented the open issue regarding the choice of key 
>> distribution. Slides #6-#8 present three techniques and Hannes asked 
>> for feedback regarding the preferred style. Justin and others didn't 
>> see the need to decide on one mechanism - they wanted to keep the 
>> choice open. Derek indicated that this will not be an acceptable 
>> approach. Since the resource server and the authorization server may, 
>> in the OAuth 2.0 framework, be entities produced by different vendors 
>> there is an interoperability need. Justin responded that he disagrees 
>> and that the resource server needs to understand the access token and 
>> referred to the recent draft submission for the token introspection 
>> endpoint. Derek indicated that the resource server has to understand 
>> the content of the access token and the token introspection endpoint 
>> just pushes the problem around: the resource server has to send the 
>> access token to the authorization server and then the resource server 
>> gets the result back (which he the
 n

---

From: William Mills <[email-masked]>
Date: Thu, 14 Feb 2013 17:31:37 -0800 (PST)

I disagree with "That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved in the first place.", unless "solving" means does not address the need for it at all.

OAuth 2 does several good things, but it still lacks a defined token type that is safe to user over plain text HTTP.  1.0a solved that.

________________________________
 From: Mike Jones <[email-masked]>
To: Justin Richer <[email-masked]>; Phil Hunt <[email-masked]> 
Cc: IETF oauth WG <[email-masked]> 
Sent: Thursday, February 14, 2013 1:44 PM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

                -- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Tuesday, February 12, 2013 9:35 AM
To: Phil Hunt
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

  -- Justin

n

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 15 Feb 2013 07:05:34 +0100

Hi Bill,

OAuth 2.0 took a different direction by relying on HTTPS to provide the basic protection. So the need to have a token, which can be used for service requests over plain HTTP is arguable. My understanding of this activity was, the intend is to provide additional protection on top of HTTPS.

regards,
Torsten.

---

From: William Mills <[email-masked]>
Date: Thu, 14 Feb 2013 23:08:35 -0800 (PST)

I fundamentally disagree with that too.  OAuth 2 is the *framework*, one which supports multiple token types.  Bearer tokens were the first credential type defined.

OAuth 1.0a also requires HTTPS transport for authentication and getting the token.

There are  real use cases for tokens usable over plain text with integrity protection.

-bill

________________________________
 From: Torsten Lodderstedt <[email-masked]>
To: William Mills <[email-masked]> 
Cc: Mike Jones <[email-masked]>; Justin Richer <[email-masked]>; Phil Hunt <[email-masked]>; IETF oauth WG <[email-masked]> 
Sent: Thursday, February 14, 2013 10:05 PM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

Hi Bill,

regards,
Torsten.

>That's my reading of it as well, Phil, thanks for providing the clarification. One motivator behind using a JSON-based token is to be able to
 re-use some of the great work that the JOSE group is doing but apply it to an HTTP payload.
>> On
 Hannes

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 15 Feb 2013 16:22:34 +0100

Hi Bill,

I think one needs to compare the costs/impact of HTTPS on one side and the implementation of integrity protection and replay detection on the other. We had this discussion several times.

regards,
Torsten.

---

From: John Bradley <[email-masked]>
Date: Fri, 15 Feb 2013 12:45:30 -0300

Remember that proof of possession is intended to prove that the client that was issued the token is the one presenting it.   
We tend to mix that up with replay and other protection issues.

To do this you don't need to authenticate the client.  
The client can prove it controls a key by signing something for the Authorization server,  the AS then includes the public key in the JWS access token.   The client then produces a hash over some number of elements and signs that with its private key in a JWS.

With asymmetric there is no need for the AS to produce the key.    Having the client produce the key pair is quite traditional proof of possession.

The RS only needs to verify the access token in the way a RS would normally all the key distribution can be public as it is public keys.

I have always found the symmetric proof of possession mechanisms to be painfully complex to do properly with DH etc.

Encrypting the symmetric key to the RS would work but relays on an implicit assumption about what RS the client may present the token to otherwise all the RS have to share private keys(probably a bad thing)

John B.

On 2013-02-14, at 4:20 PM, Prateek Mishra <[email-masked]> wrote:

> Justin - my comment was scoped to *key distribution* - not to the general use of public clients.
> 
> I was wondering how one can distribute keys or have key agreement between an AS and a client, if there is no existing trust relationship between them. Maybe there is some
> clever crypto way of achieving this, but I personally dont understand how this might happen.
> 
> - prateek
> 
>> 
>> I don't think that signing tokens should require confidential clients. This was one of the implementation issues with OAuth 1, as it required a "consumer_secret" at all times. This led to Google telling people to use "anonymous" as the "consumer_secret" for what were effectively public clients. Even with dynamic registration, there's still a place for public clients, in my opinion.
>> 
>

---

From: Prateek Mishra <[email-masked]>
Date: Fri, 15 Feb 2013 11:00:55 -0500

John - two separate issues here -

(i) for the symmetric key case, whether we need a key distribution 
method for the client and AS/RS, and if so, what form should it take?

(ii) asymmetric case is quite different, I agree with your point - the 
client could be pre-provisioned with a managed key pair (many enterprise 
cases)
or generate them ephemerally. We dont need a key distribution method here.

Unfortunately, its hard to get away from the symmetric key case, maybe 
this will change once we have widespread support for ecc.

- prateek

---

From: William Mills <[email-masked]>
Date: Fri, 15 Feb 2013 08:09:49 -0800 (PST)

I'll repeat the use case for Flickr, which requires OAuth 1.0a type capabilites that OAuth 2 does not provide.  Simply stating "move to HTTPS" is not a viable response here.  

Sent: Friday, February 15, 2013 7:22 AM

Hi Bill,

regards,
Torsten.

>>That's my reading of it as well, Phil, thanks for providing the clarification.
 One motivator behind using a JSON-based token is to be able to
 re-use some of the great work that the JOSE group is doing but apply it to an HTTP payload.
 Hannes

---

From: Phil Hunt <[email-masked]>
Date: Fri, 15 Feb 2013 08:19:32 -0800

Bill

You aren't objecting to https in the as communications correct?  It is the rs comms which is plain http where you want to protect the credential from theft.  

Even replay is not the primary issue here. 

Phil

Sent from my phone.

---

From: William Mills <[email-masked]>
Date: Fri, 15 Feb 2013 08:21:55 -0800 (PST)

Exactly.  And in the Flickr case replay of the same event is not a problem.  Thanks for keeping me honest, work just cranked the dial up to 11.5 so I'm a bit distracted.

________________________________
 From: Phil Hunt <[email-masked]>
To: William Mills <[email-masked]> 
Cc: Torsten Lodderstedt <[email-masked]>; Mike Jones <[email-masked]>; Justin Richer <[email-masked]>; IETF oauth WG <[email-masked]> 
Sent: Friday, February 15, 2013 8:19 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

Bill

Phil

Sent from my phone.

 Hannes

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 15 Feb 2013 16:25:30 +0000

I wonder why it is proving so difficult to get a nearly completed MAC 
draft completed ?
Is it because:
1. JWT was first in OAuth2 and thus it wins ?
2. MAC is not 'capable' enough as JWT is ?
3. Not enough motivation for some vendors to push MAC ?

Example, in cases where not a product but a development framework is 
shipped (as with us for example), IMHO is it a big motivation to get MAC 
done for the reasons repeated many times. Or in case of migrating Flickr 
users to OAuth2.
I think I can see why no interest is there where nothing is really 
achieved if JWT is used from the get go, no particular need to get OAuth 
1.0 developers out there migrating to the particular products.

This is 3. Re 2, I think there was enough expressed to suggest that it 
can complement JWT nicely. So far I'm inclined to think it is 3. and 2. 
which stop it from being completed, with 3. 'contributing' indirectly 
but significantly,

Just my 2c
Thanks, Sergey

On 15/02/13 16:09, William Mills wrote:
> I'll repeat the use case for Flickr, which requires OAuth 1.0a type
> capabilites that OAuth 2 does not provide. Simply stating "move to
> HTTPS" is not a viable response here.
>
> ------------------------------------------------------------------------
> *From:* Torsten Lodderstedt <[email-masked]>
> *To:* William Mills <[email-masked]>
> *Cc:* Mike Jones <[email-masked]>; Justin Richer
> <[email-masked]>; Phil Hunt <[email-masked]>; IETF oauth WG
> <[email-masked]>
> *Sent:* Friday, February 15, 2013 7:22 AM
> *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference
> Call - 11th February 2013
>
> Hi Bill,
>
> I think one needs to compare the costs/impact of HTTPS on one side and
> the implementation of integrity protection and replay detection on the
> other. We had this discussion several times.
>
> regards,
> Torsten.
>
> Am 15.02.2013 um 08:08 schrieb William Mills <[email-masked]
> <mailto:[email-masked]>>:
>
>> I fundamentally disagree with that too. OAuth 2 is the *framework*,
>> one which supports multiple token types. Bearer tokens were the first
>> credential type defined.
>>
>> ------------------------------------------------------------------------
>> *From:* Torsten Lodderstedt <[email-masked]
>> <mailto:[email-masked]>>
>> *To:* William Mills <[email-masked]
>> <mailto:[email-masked]>>
>> *Cc:* Mike Jones <[email-masked]
>> <mailto:[email-masked]>>; Justin Richer
>> <[email-masked] <mailto:[email-masked]>>; Phil Hunt
>> <[email-masked] <mailto:[email-masked]>>; IETF oauth WG
>> <[email-masked] <mailto:[email-masked]>>
>> *Sent:* Thursday, February 14, 2013 10:05 PM
>> *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team
>> Conference Call - 11th February 2013
>>
>> Hi Bill,
>>
>> OAuth 2.0 took a different direction by relying on HTTPS to provide
>> the basic protection. So the need to have a token, which can be used
>> for service requests over plain HTTP is arguable. My understanding of
>> this activity was, the intend is to provide additional protection on
>> top of HTTPS.
>>
>> regards,
>> Torsten.
>>
>> Am 15.02.2013 um 02:31 schrieb William Mills <[email-masked]
>> <mailto:[email-masked]>>:
>>
>>> I disagree with "That was the impediment to OAuth 1.0 adoption that
>>> OAuth 2.0 solved in the first place.", unless "solving" means does
>>> not address the need for it at all.
>>>
>>> OAuth 2 does several good things, but it still lacks a defined token
>>> type that is safe to user over plain text HTTP. 1.0a solved that.
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Mike Jones <[email-masked]
>>> <mailto:[email-masked]>>
>>> *To:* Justin Richer <[email-masked] <mailto:[email-masked]>>;
>>> Phil Hunt <[email-masked] <mailto:[email-masked]>>
>>> *Cc:* IETF oauth WG <[email-masked] <mailto:[email-masked]>>
>>> *Sent:* Thursday, February 14, 2013 1:44 PM
>>> *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team
>>> Conference Call - 11th February 2013
>>>
>>> I'm pretty skeptical of us inventing another custom scheme for
>>> signing HTTP headers. That was the impediment to OAuth 1.0 adoption
>>> that OAuth 2.0 solved in the first place.
>>>
>>> -- Mike
>>>
>>> From: [email-masked] <mailto:[email-masked]>
>>> [mailto:[email-masked] <mailto:[email-masked]>] On
>>> Behalf Of Justin Richer
>>> able to re-use some of the great work that the JOSE group is doing
>>> but apply it to an HTTP payload.
>>>
>>> query, header, and other parameters *into* the JSON object itself,
>>> which would be a more SOAPy approach.
>>>
>>> -- Justin
>>>
>>> > Clarification. I think Justin and I were in agreement that we don't
>>> want to see a format that requires JSON payloads. We are both
>>> interested in a JSON token used in the authorization header that
>>> could be based on a computed signature of some combination of http
>>> headers and body if possible.
>>> >
>>> > Phil
>>> >
>>> > @independentid
>>> > www.independentid.com <http://www.independentid.com/>
>>> > [email-masked] <mailto:[email-masked]>
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >> Phil noted that he does not like to use the MAC Token draft as a
>>> starting point because it does not re-use any of the work done in the
>>> JOSE working group and in particular all the libraries that are
>>> available today. He mentioned that earlier attempts to write the MAC
>>> Token code lead to problems for implementers.
>>> >>
>>> >> Justin responded that he does not agree with using JSON as a
>>> transport mechanism since this would replicate a SOAP style.
>>> >>
>>> >> From earlier discussion it was clear that the conference call
>>> participants wanted more flexibility regarding the keyed message
>>> digest computation. For this purpose Hannes presented the DKIM based
>>> approach, which allows selective header fields to be included in the
>>> digest. This is shown in slide #4.
>>> >>
>>> >> After some discussion the conference call participants thought
>>> that this would meet their needs. Further investigations would still
>>> be useful to determine the degree of failed HMAC calculations due to
>>> HTTP proxies modifying the content.
>>> >>
>>> >> -- Key Distribution
>>> >>
>>> >> Everyone agreed that the client must receive the session key from
>>> the authorization server and that this approach has to be
>>> standardized. It was also agreed that this is a common approach among
>>> all three key distribution mechanisms.
>>> >>
>>> >> The questions regarding key naming and the indication for the
>>> intended resource server the client wants to talk to have been postponed.
>>> >>
>>> >> Ciao
>>> >> Hannes
>>> >>
>>> >>
>>> >> [email-masked] <mailto:[email-masked]>
>>> > [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>

---

From: Tim Bray <[email-masked]>
Date: Fri, 15 Feb 2013 08:49:19 -0800

Not deeply acquainted with the Flickr scenario, but it occurs to me to ask:
If OAuth 1.0 is working well for them, why don’t they just keep using it?
 I.e. if there’s already a good solution in place for people who require
secure authn/authz over insecure channels, why would we go the extra work
of duplicating that in OAuth 2 territory? -T

On Fri, Feb 15, 2013 at 8:09 AM, William Mills <[email-masked]>wrote:

> capabilites that OAuth 2 does not provide.  Simply stating "move to HTTPS"
> is not a viable response here.
>
>   ------------------------------
> *Cc:* Mike Jones <[email-masked]>; Justin Richer <
> [email-masked]>; Phil Hunt <[email-masked]>; IETF oauth WG <
> [email-masked]>
> I think one needs to compare the costs/impact of HTTPS on one side and the
> implementation of integrity protection and replay detection on the other.
> We had this discussion several times.
>
> regards,
> Torsten.
>
> I fundamentally disagree with that too.  OAuth 2 is the *framework*, one
> which supports multiple token types.  Bearer tokens were the first
> credential type defined.
>
>   ------------------------------
> *Cc:* Mike Jones <[email-masked]>; Justin Richer <
> [email-masked]>; Phil Hunt <[email-masked]>; IETF oauth WG <
> [email-masked]>
> OAuth 2.0 took a different direction by relying on HTTPS to provide the
> basic protection. So the need to have a token, which can be used for
> service requests over plain HTTP is arguable. My understanding of this
> activity was, the intend is to provide additional protection on top of
> HTTPS.
>
> regards,
> Torsten.
>
> I disagree with "That was the impediment to OAuth 1.0 adoption that OAuth
> 2.0 solved in the first place.", unless "solving" means does not address
> the need for it at all.
>
> OAuth 2 does several good things, but it still lacks a defined token type
> that is safe to user over plain text HTTP.  1.0a solved that.
>
>   ------------------------------
> *From:* Mike Jones <[email-masked]>
> *To:* Justin Richer <[email-masked]>; Phil Hunt <[email-masked]>
> *Cc:* IETF oauth WG <[email-masked]>
> I'm pretty skeptical of us inventing another custom scheme for signing
> HTTP headers.  That was the impediment to OAuth 1.0 adoption that OAuth 2.0
> solved in the first place.
>
>                 -- Mike
>
> clarification. One motivator behind using a JSON-based token is to be able
> to re-use some of the great work that the JOSE group is doing but apply it
> to an HTTP payload.
>
> What neither of us want is a token type that requires stuffing all query,
> header, and other parameters *into* the JSON object itself, which would be
> a more SOAPy approach.
>
>   -- Justin
>
> want to see a format that requires JSON payloads.  We are both interested
> in a JSON token used in the authorization header that could be based on a
> computed signature of some combination of http headers and body if possible.
> >
> > Phil
> >
> > @independentid
> > www.independentid.com
> > [email-masked]
> >
> >
> >
> >
> >
> starting point because it does not re-use any of the work done in the JOSE
> working group and in particular all the libraries that are available today.
> He mentioned that earlier attempts to write the MAC Token code lead to
> problems for implementers.
> >>
> >> Justin responded that he does not agree with using JSON as a transport
> mechanism since this would replicate a SOAP style.
> >>
> participants wanted more flexibility regarding the keyed message digest
> computation. For this purpose Hannes presented the DKIM based approach,
> which allows selective header fields to be included in the digest. This is
> shown in slide #4.
> >>
> >> After some discussion the conference call participants thought that
> this would meet their needs. Further investigations would still be useful
> to determine the degree of failed HMAC calculations due to HTTP proxies
> modifying the content.
> >>
> >> -- Key Distribution
> >>
> >> Everyone agreed that the client must receive the session key from the
> authorization server and that this approach has to be standardized. It was
> also agreed that this is a common approach among all three key distribution
> mechanisms.
> >>
> >> The questions regarding key naming and the indication for the intended
> resource server the client wants to talk to have been postponed.
> >>
> >> Ciao
> >> Hannes
> >>
> >>

---

From: William Mills <[email-masked]>
Date: Fri, 15 Feb 2013 10:29:13 -0800 (PST)

At this point I am more in favor converting the MAC token format to JWT and getting the signature envelope added that way.  It's really a matter of time.

MAC stalled because folks see the HOK tokens as a replacement.  

It's also been a matter of Justin and I having the time to take it up again.

________________________________
 From: Sergey Beryozkin <[email-masked]>
To: [email-masked] 
Sent: Friday, February 15, 2013 8:25 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

Just my 2c
Thanks, Sergey

---

From: William Mills <[email-masked]>
Date: Fri, 15 Feb 2013 12:50:34 -0800 (PST)

Because we're goign to want a single implementation, not N.

________________________________
 From: Tim Bray <[email-masked]>
To: William Mills <[email-masked]> 
Cc: Torsten Lodderstedt <[email-masked]>; IETF oauth WG <[email-masked]> 
Sent: Friday, February 15, 2013 8:49 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

Not deeply acquainted with the Flickr scenario, but it occurs to me to ask: If OAuth 1.0 is working well for them, why don’t they just keep using it?  I.e. if there’s already a good solution in place for people who require secure authn/authz over insecure channels, why would we go the extra work of duplicating that in OAuth 2 territory? -T

On Fri, Feb 15, 2013 at 8:09 AM, William Mills <[email-masked]> wrote:

 Hannes

---

From: Justin Richer <[email-masked]>
Date: Fri, 15 Feb 2013 15:54:59 -0500

So that you can fetch and manage all your tokens using the same code 
paths as the OAuth2 services. The "get a token" part will be identical 
to Oauth2 Bearer (except for some details of what comes back from the 
token endpoint, of course), it's the "use a token" bit that really 
changes and is up in the air. You get to use scopes, and state, and 
refresh tokens, and all the other good stuff.

I've brought it up before, but I think it might be worthwhile, at least 
as an exercise, to define a method to get OAuth1-style tokens from an 
OAuth2 token endpoint. You'd defer to OAuth1 for how to use them with a 
protected resource.

  -- Justin

On 02/15/2013 11:49 AM, Tim Bray wrote:
> Not deeply acquainted with the Flickr scenario, but it occurs to me to 
> ask: If OAuth 1.0 is working well for them, why don't they just keep 
> using it?  I.e. if there's already a good solution in place for people 
> who require secure authn/authz over insecure channels, why would we go 
> the extra work of duplicating that in OAuth 2 territory? -T
>
> On Fri, Feb 15, 2013 at 8:09 AM, William Mills <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I'll repeat the use case for Flickr, which requires OAuth 1.0a
>     type capabilites that OAuth 2 does not provide.  Simply stating
>     "move to HTTPS" is not a viable response here.
>
>     <[email-masked] <mailto:[email-masked]>>; IETF oauth
>     WG <[email-masked] <mailto:[email-masked]>>
>     I think one needs to compare the costs/impact of HTTPS on one side
>     and the implementation of integrity protection and replay
>     detection on the other. We had this discussion several times.
>
>     regards,
>     Torsten.
>
>     Am 15.02.2013 um 08:08 schrieb William Mills
>     <[email-masked] <mailto:[email-masked]>>:
>
>>     I fundamentally disagree with that too.  OAuth 2 is the
>>     *framework*, one which supports multiple token types.  Bearer
>>     tokens were the first credential type defined.
>>
>>     <[email-masked] <mailto:[email-masked]>>; IETF oauth
>>     WG <[email-masked] <mailto:[email-masked]>>
>>     OAuth 2.0 took a different direction by relying on HTTPS to
>>     provide the basic protection. So the need to have a token, which
>>     can be used for service requests over plain HTTP is arguable. My
>>     understanding of this activity was, the intend is to provide
>>     additional protection on top of HTTPS.
>>
>>     regards,
>>     Torsten.
>>
>>     Am 15.02.2013 um 02:31 schrieb William Mills
>>     <[email-masked] <mailto:[email-masked]>>:
>>
>>>     I disagree with "That was the impediment to OAuth 1.0 adoption
>>>     that OAuth 2.0 solved in the first place.", unless "solving"
>>>     means does not address the need for it at all.
>>>
>>>     OAuth 2 does several good things, but it still lacks a defined
>>>     token type that is safe to user over plain text HTTP.  1.0a
>>>     solved that.
>>>
>>>     *To:* Justin Richer <[email-masked]
>>>     <mailto:[email-masked]>>; Phil Hunt <[email-masked]
>>>     <mailto:[email-masked]>>
>>>     signing HTTP headers.  That was the impediment to OAuth 1.0
>>>     adoption that OAuth 2.0 solved in the first place.
>>>
>>>                     -- Mike
>>>
>>>     [mailto:[email-masked] <mailto:[email-masked]>]
>>>     On Behalf Of Justin Richer
>>>     clarification. One motivator behind using a JSON-based token is
>>>     to be able to re-use some of the great work that the JOSE group
>>>     is doing but apply it to an HTTP payload.
>>>
>>>     What neither of us want is a token type that requires stuffing
>>>     all query, header, and other parameters *into* the JSON object
>>>     itself, which would be a more SOAPy approach.
>>>
>>>       -- Justin
>>>
>>>     > Clarification.  I think Justin and I were in agreement that we
>>>     don't want to see a format that requires JSON payloads. We are
>>>     both interested in a JSON token used in the authorization header
>>>     that could be based on a computed signature of some combination
>>>     of http headers and body if possible.
>>>     >
>>>     > Phil
>>>     >
>>>     > @independentid
>>>     >> Phil noted that he does not like to use the MAC Token draft
>>>     as a starting point because it does not re-use any of the work
>>>     done in the JOSE working group and in particular all the
>>>     libraries that are available today. He mentioned that earlier
>>>     attempts to write the MAC Token code lead to problems for
>>>     implementers.
>>>     >>
>>>     >>  From earlier discussion it was clear that the conference
>>>     call participants wanted more flexibility regarding the keyed
>>>     message digest computation. For this purpose Hannes presented
>>>     the DKIM based approach, which allows selective header fields to
>>>     be included in the digest. This is shown in slide #4.
>>>     >>
>>>     >> After some discussion the conference call participants
>>>     thought that this would meet their needs. Further investigations
>>>     would still be useful to determine the degree of failed HMAC
>>>     calculations due to HTTP proxies modifying the content.
>>>     >>
>>>     >> -- Key Distribution
>>>     >>
>>>     >> Everyone agreed that the client must receive the session key
>>>     from the authorization server and that this approach has to be
>>>     standardized. It was also agreed that this is a common approach
>>>     among all three key distribution mechanisms.
>>>     >>

---

From: William Mills <[email-masked]>
Date: Fri, 15 Feb 2013 13:04:02 -0800 (PST)

>I've brought it up before, but I think it might be worthwhile, at least as an exercise, to define a method to get OAuth1-style tokens from an OAuth2 token endpoint. You'd defer to OAuth1 for how to use them >with a protected resource.

YES!

________________________________
 From: Justin Richer <[email-masked]>
To: Tim Bray <[email-masked]> 
Cc: William Mills <[email-masked]>; IETF oauth WG <[email-masked]> 
Sent: Friday, February 15, 2013 12:54 PM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

So that you can fetch and manage all your tokens using the same code paths as the OAuth2 services. The "get a token" part will be identical to Oauth2 Bearer (except for some details of what comes back from the token endpoint, of course), it's the "use a token" bit that really changes and is up in the air. You get to use scopes, and state, and refresh tokens, and all the other good stuff.

I've brought it up before, but I think it might be worthwhile, at
    least as an exercise, to define a method to get OAuth1-style tokens
    from an OAuth2 token endpoint. You'd defer to OAuth1 for how to use
    them with a protected resource.

 -- Justin

                        <[email-masked]>:
>>>>I'm in favor of reusing
                                              the JWT work that this WG
                                              is also doing. :-)
>>>>
>>>>I'm pretty skeptical of us
                                              inventing another custom
                                              scheme for signing HTTP
                                              headers.  That was the
                                              impediment to OAuth 1.0
                                              adoption that OAuth 2.0
>>>>Subject: Re: [OAUTH-WG]
                                              Minutes from the OAuth
                                              Design Team Conference
>>>>
>>>>That's my reading of it as
                                              well, Phil, thanks for
                                              providing the
                                              clarification. One
                                              motivator behind using a
                                              JSON-based token is to be
                                              able to re-use some of the
                                              great work that the JOSE
                                              group is doing but apply
                                              it to an HTTP payload.
>>>>
>>>>What neither of us want is
                                              a token type that requires
                                              stuffing all query,
                                              header, and other
                                              parameters *into* the JSON
                                              object itself, which would
                                              be a more SOAPy approach.
>>>>> Clarification.  I
                                              think Justin and I were in
                                              agreement that we don't
                                              want to see a format that
                                              requires JSON payloads. 
                                              We are both interested in
                                              a JSON token used in the
                                              authorization header that
                                              could be based on a
                                              computed signature of some
                                              combination of http
                                              headers and body if
                                              possible.
>>>>> On 2013-02-12, at
                                              1:10 AM, Hannes Tschofenig
                                              wrote:
>>>>>> Here are my
                                              notes.
>>>>>> * Hannes
                                              Tschofenig
>>>>>> Slide #2
                                              summarizes earlier
                                              discussions during the
                                              conference calls.
>>>>>> Phil noted that
                                              he does not like to use
                                              the MAC Token draft as a
                                              starting point because it
                                              does not re-use any of the
                                              work done in the JOSE
                                              working group and in
                                              particular all the
                                              libraries that are
                                              available today. He
                                              mentioned that earlier
                                              attempts to write the MAC
                                              Token code lead to
                                              problems for implementers.
>>>>>> Justin responded
                                              that he does not agree
                                              with using JSON as a
                                              transport mechanism since
                                              this would replicate a
                                              SOAP style.
>>>>>> Phil noted that
                                              he wants to send JSON but
                                              the signature shall be
                                              computed over the HTTP
                                              header field.
>>>>>> -- Flexibility
                                              for the keyed message
                                              digest computation
>>>>>>  From earlier
                                              discussion it was clear
                                              that the conference call
                                              participants wanted more
                                              flexibility regarding the
                                              keyed message digest
                                              computation. For this
                                              purpose Hannes presented
                                              the DKIM based approach,
                                              which allows selective
                                              header fields to be
                                              included in the digest.
                                              This is shown in slide #4.
>>>>>> After some
                                              discussion the conference
                                              call participants thought
                                              that this would meet their
                                              needs. Further
                                              investigations would still
                                              be useful to determine the
                                              degree of failed HMAC
                                              calculations due to HTTP
                                              proxies modifying the
                                              content.
>>>>>> -- Key
                                              Distribution
>>>>>> Hannes presented
                                              the open issue regarding
                                              the choice of key 
>>>>>> distribution.
                                              Slides #6-#8 present three
                                              techniques and Hannes
                                              asked 
>>>>>> for feedback
                                              regarding the preferred
                                              style. Justin and others
                                              didn't 
>>>>>> see the need to
                                              decide on one mechanism -
                                              they wanted to keep the 
>>>>>> choice open.
                                              Derek indicated that this
                                              will not be an acceptable 
>>>>>> approach. Since
                                              the resource server and
                                              the authorization server
                                              may, 
>>>>>> in the OAuth 2.0
                                              framework, be entities
                                              produced by different
                                              vendors 
>>>>>> there is an
                                              interoperability need.
                                              Justin responded that he
                                              disagrees 
>>>>>> and that the
                                              resource server needs to
                                              understand the access
                                              token and 
>>>>>> referred to the
                                              recent draft submission
                                              for the token
                                              introspection 
>>>>>> endpoint. Derek
                                              indicated that the
                                              resource server has to
                                              understand 
>>>>>> the content of
                                              the access token and the
                                              token introspection
                                              endpoint 
>>>>>> just pushes the
                                              problem around: the
                                              resource server has to
                                              send the 
>>>>>> access token to
                                              the authorization server
                                              and then the resource
                                              server 
>>>>>> gain needs to
                                              understand) in order to
                                              make a meaningful
                                              authorization decision.
>>>>>> Everyone agreed
                                              that the client must
                                              receive the session key
                                              from the authorization
                                              server and that this
                                              approach has to be
                                              standardized. It was also
                                              agreed that this is a
                                              common approach among all
                                              three key distribution
                                              mechanisms.
>>>>>> Hannes asked the
                                              participants to think
                                              about their preference.
>>>>>> The questions
                                              regarding key naming and
                                              the indication for the
                                              intended resource server
                                              the client wants to talk
                                              to have been postponed.
>>>>>> OAuth mailing
                                              list
>>>>> https://www.ietf.org/mailman/listinfo/oauth
OAuth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Fri, 15 Feb 2013 13:52:23 -0800

Sorry. I have to disagree. The way 1.0 is written, it is not a shortcut to turn it into a token for 2. 

Phil

Sent from my phone.

On 2013-02-15, at 13:04, William Mills <[email-masked]> wrote:

> I've brought it up before, but I think it might be worthwhile, at least as an exercise, to define a method to get OAuth1-style tokens from an OAuth2 token endpoint. You'd defer to OAuth1 for how to use them with a protected resource.
> 
>  -- Justin
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 15 Feb 2013 21:57:37 +0000

It's a pretty good shortcut to not have to deal with request tokens, to be able to use scopes, to have access to client assertions and other methods of client auth, and not have to do signing when talking to the AS. It's no shortcut when talking to the RS, that's for sure.

 -- Justin

On Feb 15, 2013, at 4:52 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

Sent from my phone.

YES!

________________________________
From: Justin Richer <[email-masked]<mailto:[email-masked]>>
To: Tim Bray <[email-masked]<mailto:[email-masked]>>
Cc: William Mills <[email-masked]<mailto:[email-masked]>>; IETF oauth WG <[email-masked]<mailto:[email-masked]>>
Sent: Friday, February 15, 2013 12:54 PM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

 -- Justin

On Fri, Feb 15, 2013 at 8:09 AM, William Mills <[email-masked]<mailto:[email-masked]>> wrote:
I'll repeat the use case for Flickr, which requires OAuth 1.0a type capabilites that OAuth 2 does not provide.  Simply stating "move to HTTPS" is not a viable response here.

________________________________
From: Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>
To: William Mills <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>; Justin Richer <[email-masked]<mailto:[email-masked]>>; Phil Hunt <[email-masked]<mailto:[email-masked]>>; IETF oauth WG <[email-masked]<mailto:[email-masked]>>
Sent: Friday, February 15, 2013 7:22 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

Hi Bill,

regards,
Torsten.

Am 15.02.2013 um 08:08 schrieb William Mills <[email-masked]<mailto:[email-masked]>>:

-bill

________________________________
From: Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>
To: William Mills <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>; Justin Richer <[email-masked]<mailto:[email-masked]>>; Phil Hunt <[email-masked]<mailto:[email-masked]>>; IETF oauth WG <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, February 14, 2013 10:05 PM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

Hi Bill,

regards,
Torsten.

Am 15.02.2013 um 02:31 schrieb William Mills <[email-masked]<mailto:[email-masked]>>:

________________________________
From: Mike Jones <[email-masked]<mailto:[email-masked]>>
To: Justin Richer <[email-masked]<mailto:[email-masked]>>; Phil Hunt <[email-masked]<mailto:[email-masked]>>
Cc: IETF oauth WG <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, February 14, 2013 1:44 PM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

                -- Mike

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Justin Richer
Sent: Tuesday, February 12, 2013 9:35 AM
To: Phil Hunt
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

  -- Justin

On 02/12/2013 12:30 PM, Phil Hunt wrote:
> www.independentid.com<http://www.independentid.com/>
> [email-masked]<mailto:[email-masked]>
>
>
>
>
>
n
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 15 Feb 2013 22:10:02 +0000

HI,
On 15/02/13 18:29, William Mills wrote:
> At this point I am more in favor converting the MAC token format to JWT
> and getting the signature envelope added that way. It's really a matter
> of time.
>
Sure, thanks for the above info, as I've said before I'm ultimately fine 
with having MAC supported just in our implementation for example, and 
let those users who decide to use know that they actually write a 
compliant OAuth2 code - but not inter-operable unless some other stack 
does it too...Interoperability may not be highly important in some cases 
too, so...

Ultimately whatever the experts decide upon will be good I guess, the 
question will remain though if dropping MAC will help with avoiding 
having N- number of OAuth(s) variants - it appears the sentiment is 
quite strong in oAuth1 community toward this style MAC kind of replicates.

Thanks, Sergey

> *From:* Sergey Beryozkin <[email-masked]>
> *To:* [email-masked]
> *Sent:* Friday, February 15, 2013 8:25 AM
> <mailto:[email-masked]>
>  > <mailto:[email-masked] <mailto:[email-masked]>>>:
>  >
> <mailto:[email-masked]>
>  >> <mailto:[email-masked] <mailto:[email-masked]>>>
> <mailto:[email-masked]>
>  >> <mailto:[email-masked] <mailto:[email-masked]>>>
> <mailto:[email-masked]>
>  >> <mailto:[email-masked]
> <mailto:[email-masked]>>>; Justin Richer
>  >> <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>; Phil Hunt
>  >> <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>; IETF oauth WG
>  >> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>
> <mailto:[email-masked]>
>  >> <mailto:[email-masked] <mailto:[email-masked]>>>:
>  >>
> <mailto:[email-masked]>
>  >>> <mailto:[email-masked]
> <mailto:[email-masked]>>>
>  >>> *To:* Justin Richer <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>;
>  >>> Phil Hunt <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>
>  >>> *Cc:* IETF oauth WG <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>
> <mailto:[email-masked] <mailto:[email-masked]>>
>  >>> [mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>] On
>  >>> Behalf Of Justin Richer
> <mailto:[email-masked] <mailto:[email-masked]>>
>  >>> >
>  >>> >
>  >>> >
>  >>> >
>  >>> >
>  >>> >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>  >>> > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>  >>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>  >>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>  >>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>

---

From: William Mills <[email-masked]>
Date: Fri, 15 Feb 2013 22:02:50 -0800 (PST)

All the same concepts/info are available in the AS: client ID, client auth, and can deliver both token and secret.  What's magic once the client has the token that's missing?

________________________________
 From: Phil Hunt <[email-masked]>
To: William Mills <[email-masked]> 
Cc: Justin Richer <[email-masked]>; Tim Bray <[email-masked]>; IETF oauth WG <[email-masked]> 
Sent: Friday, February 15, 2013 1:52 PM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

Phil

Sent from my phone.

                                              inventing another custom
                                              scheme for signing HTTP
                                              headers.  That was the
                                              impediment to OAuth 1.0
                                              adoption that OAuth 2.0
                                              Minutes from the OAuth
                                              Design Team Conference
                                              well, Phil, thanks for
                                              providing the
                                              clarification. One
                                              motivator behind using a
                                              notes.
                                              Tschofenig
                                              summarizes earlier
                                              discussions during the
                                              conference calls.
                                              he does not like to use
                                              the MAC Token draft as a
                                              that he does not agree
                                              with using JSON as a
                                              for the keyed message
                                              digest computation
                                              discussion it was clear
                                              that the conference call
                                              participants wanted more
                                              Distribution
                                              the open issue regarding
                                              the choice of key 
                                              regarding the preferred
                                              style. Justin and others
                                              didn't 
                                              the resource server and
                                              the authorization server
                                              may, 
                                              framework, be entities
                                              produced by different
                                              vendors 
                                              interoperability need.
                                              Justin responded that he
                                              disagrees 
                                              resource server needs to
                                              understand the access
                                              token and 
                                              recent draft submission
                                              for the token
                                              introspection 
                                              indicated that the
                                              resource server has to
                                              understand 
                                              the access token and the
                                              token introspection
                                              endpoint 
                                              problem around: the
                                              resource server has to
                                              send the 
                                              the authorization server
                                              and then the resource
                                              server 
                                              understand) in order to
                                              make a meaningful
                                              authorization decision.
                                              that the client must
                                              receive the session key
                                              from the authorization
                                              server and that this
                                              approach has to be
                                              participants to think
                                              about their preference.
                                              regarding key naming and
                                              the indication for the
                                              intended resource server
                                              the client wants to talk
                                              to have been postponed.
                                              list

---

From: Phil Hunt <[email-masked]>
Date: Fri, 15 Feb 2013 23:22:21 -0800

I don't see oauth1 tokens as a short cut because eran said the token in oauth1 (which is inside the oauth1 spec) had many implementation problems by client developers. Why go there and re-invent what jwt could do easily?

Do you need hok? Do you need replay protection? Do you need message signing? Are asymmetric keys needed?  I get the impression the group is less interested in the last two. 

There is also key distribution to resource server. I think we have client nailed but getting keys to resource server needs some discussion - especially if the path is through the token itself.  

I suppose we can move faster if we assume rs obtains keys in an unspecified manner like what happened in oauth1. 

Phil

Sent from my phone.

---

From: [email-masked]
Date: Sat, 16 Feb 2013 16:02:20 +0800

Who has a rather detailed description about the three key distribution 
machanisms?
Please tell me if I am wrong in understanding them only from the ppt and 
previouse mac and hotk document:

1. The key distributuon means AS distributing a short-term-key  to client 
and RS;
2. AS and RS has another way of sharing a long-term-key which is not 
covered by the design team;
3. Client-AS and Client-RS  may have their ways of authentication  not 
using the short-term-key;
4. short-term-key is only used for protecting access token from being 
stolen or abused by entities other than the client(as bear token);
   then there are 3 possible approaches for generating an access token 
(suppose short-term-key is irrelevant with long-term-key):
   1) access token=F(...,short-term-key) // not secure, and equivalent to 
the case that access token being short-term-key
   2) access token=F(...,longt-term-key) //pass. for no short-term-key is 
invloved 
   3) access token=F(...,short-term-key,long-term-key)// I guess this case 
is the base on which the design team is discussing ?

 Based on the above pre-assumption,the following is my opinion on the 3 
key distribution mechanisms:
key-transport: in this meachanism short-term-key is transported from AS to 
client, then to RS,
               short-term-key could be transported inside or outside of 
access token, which is no big difference,
               the security of this mecha is actually guaranteed by 
long-term-key;
key-retrieval: short-term-key is obtained from AS  by RS directly, it is 
more secure, but need an extra information exchange between RS and AS each 
time Client is requesting resource to RS.

key-agreement: short-term-key could be derived from long-term-key and some 
other information included in (or accompanying) access token,
               this mecha is actually not different from case 2) above, 
that is no short-term-key is required to send actually. 

[email-masked] 写于 2013-02-12 17:10:27:

> starting point because it does not re-use any of the work done in 
> the JOSE working group and in particular all the libraries that are 
> this would meet their needs. Further investigations would still be 
> useful to determine the degree of failed HMAC calculations due to 
> approach. Since the resource server and the authorization server 
> may, in the OAuth 2.0 framework, be entities produced by different 
> vendors there is an interoperability need. Justin responded that he 
> disagrees and that the resource server needs to understand the 
> access token and referred to the recent draft submission for the 
> token introspection endpoint. Derek indicated that the resource 
> server has to understand the content of the access token and the 
> token introspection endpoint just pushes the problem around: the 
> resource server has to send the access token to the authorization 
> server and then the resource server gets the result back (which he then 
a

---

From: William Mills <[email-masked]>
Date: Sat, 16 Feb 2013 09:57:28 -0800 (PST)

The reason to support 1.0a tokens in 2 is simply to provide a migration path when a site has 1.0a endpoint it wants to support.

Sent: Friday, February 15, 2013 11:22 PM

Phil

Sent from my phone.

                                              inventing another custom
                                              scheme for signing HTTP
                                              headers.  That was the
                                              impediment to OAuth 1.0
                                              adoption that OAuth 2.0
                                              Minutes from the OAuth
                                              Design Team Conference
                                              well, Phil, thanks for
                                              providing the
                                              clarification. One
                                              motivator behind using a
                                              notes.
                                              Tschofenig
                                              summarizes earlier
                                              discussions during the
                                              conference calls.
                                              he does not like to use
                                              the MAC Token draft as a
                                              that he does not agree
                                              with using JSON as a
                                              for the keyed message
                                              digest computation
                                              discussion it was clear
                                              that the conference call
                                              participants wanted more
                                              Distribution
                                              the open issue regarding
                                              the choice of key 
                                              regarding the preferred
                                              style. Justin and others
                                              didn't 
                                              the resource server and
                                              the authorization server
                                              may, 
                                              framework, be entities
                                              produced by different
                                              vendors 
                                              interoperability need.
                                              Justin responded that he
                                              disagrees 
                                              resource server needs to
                                              understand the access
                                              token and 
                                              recent draft submission
                                              for the token
                                              introspection 
                                              indicated that the
                                              resource server has to
                                              understand 
                                              the access token and the
                                              token introspection
                                              endpoint 
                                              problem around: the
                                              resource server has to
                                              send the 
                                              the authorization server
                                              and then the resource
                                              server 
                                              understand) in order to
                                              make a meaningful
                                              authorization decision.
                                              that the client must
                                              receive the session key
                                              from the authorization
                                              server and that this
                                              approach has to be
                                              participants to think
                                              about their preference.
                                              regarding key naming and
                                              the indication for the
                                              intended resource server
                                              the client wants to talk
                                              to have been postponed.
                                              list

---

From: Sergey Beryozkin <[email-masked]>
Date: Sun, 17 Feb 2013 17:31:33 +0000

Hi,
On 16/02/13 17:57, William Mills wrote:
> The reason to support 1.0a tokens in 2 is simply to provide a migration
> path when a site has 1.0a endpoint it wants to support.
>

I really like the idea of having a migration path, which is very 
important to have, but IMHO this approach won't work. Appears to me that 
having a MAC completed (whenever feasible of course) will work better, 
it will be a statement of intent/invitation...

Cheers, Sergey

> *From:* Phil Hunt <[email-masked]>
> *Cc:* Justin Richer <[email-masked]>; Tim Bray <[email-masked]>;
> IETF oauth WG <[email-masked]>
> *Sent:* Friday, February 15, 2013 11:22 PM
> I don't see oauth1 tokens as a short cut because eran said the token in
> oauth1 (which is inside the oauth1 spec) had many implementation
> problems by client developers. Why go there and re-invent what jwt could
> do easily?
>
> Do you need hok? Do you need replay protection? Do you need message
> signing? Are asymmetric keys needed? I get the impression the group is
> less interested in the last two.
>
> There is also key distribution to resource server. I think we have
> client nailed but getting keys to resource server needs some discussion
> - especially if the path is through the token itself.
>
> I suppose we can move faster if we assume rs obtains keys in an
> unspecified manner like what happened in oauth1.
>
> Phil
>
> Sent from my phone.
>
> On 2013-02-15, at 22:02, William Mills <[email-masked]
>> All the same concepts/info are available in the AS: client ID, client
>> auth, and can deliver both token and secret. What's magic once the
>> client has the token that's missing?
>>
>> *From:* Phil Hunt <[email-masked] <mailto:[email-masked]>>
>> *Cc:* Justin Richer <[email-masked] <mailto:[email-masked]>>;
>> Tim Bray <[email-masked] <mailto:[email-masked]>>; IETF oauth WG
>> *Sent:* Friday, February 15, 2013 1:52 PM
>>> them >with a protected resource.
>>>
>>> YES!
>>>
>>> *From:* Justin Richer <[email-masked] <mailto:[email-masked]>>
>>> *To:* Tim Bray <[email-masked] <mailto:[email-masked]>>
>>> *Cc:* William Mills <[email-masked]
>>> <mailto:[email-masked]>>; IETF oauth WG <[email-masked]
>>> <mailto:[email-masked]>>
>>> *Sent:* Friday, February 15, 2013 12:54 PM
>>> paths as the OAuth2 services. The "get a token" part will be
>>> identical to Oauth2 Bearer (except for some details of what comes
>>> back from the token endpoint, of course), it's the "use a token" bit
>>> that really changes and is up in the air. You get to use scopes, and
>>> state, and refresh tokens, and all the other good stuff.
>>>
>>>> Not deeply acquainted with the Flickr scenario, but it occurs to me
>>>> to ask: If OAuth 1.0 is working well for them, why don’t they just
>>>> keep using it? I.e. if there’s already a good solution in place for
>>>> people who require secure authn/authz over insecure channels, why
>>>> would we go the extra work of duplicating that in OAuth 2 territory? -T
>>>>
>>>> On Fri, Feb 15, 2013 at 8:09 AM, William Mills
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>     I think one needs to compare the costs/impact of HTTPS on one
>>>>     side and the implementation of integrity protection and replay
>>>>>     <[email-masked] <mailto:[email-masked]>>; IETF
>>>>>     oauth WG <[email-masked] <mailto:[email-masked]>>
>>>>>     provide the basic protection. So the need to have a token,
>>>>>     which can be used for service requests over plain HTTP is
>>>>>     arguable. My understanding of this activity was, the intend is
>>>>>     to provide additional protection on top of HTTPS.
>>>>>
>>>>>     regards,
>>>>>     Torsten.
>>>>>
>>>>>>     [mailto:[email-masked]
>>>>>>     <mailto:[email-masked]>] On Behalf Of Justin Richer
>>>>>>     That's my reading of it as well, Phil, thanks for providing
>>>>>>     the clarification. One motivator behind using a JSON-based
>>>>>>     token is to be able to re-use some of the great work that the
>>>>>>     JOSE group is doing but apply it to an HTTP payload.
>>>>>>
>>>>>>     > Clarification. I think Justin and I were in agreement that
>>>>>>     we don't want to see a format that requires JSON payloads. We
>>>>>>     are both interested in a JSON token used in the authorization
>>>>>>     header that could be based on a computed signature of some
>>>>>>     combination of http headers and body if possible.
>>>>>>     >
>>>>>>     > Phil
>>>>>>     >
>>>>>>     > @independentid
>>>>>>     >> Justin responded that he does not agree with using JSON as
>>>>>>     a transport mechanism since this would replicate a SOAP style.
>>>>>>     >>
>>>>>>     >> Phil noted that he wants to send JSON but the signature
>>>>>>     shall be computed over the HTTP header field.
>>>>>>     >>
>>>>>>     the DKIM based approach, which allows selective header fields
>>>>>>     to be included in the digest. This is shown in slide #4.
>>>>>>     >>
>>>>>>     thought that this would meet their needs. Further
>>>>>>     investigations would still be useful to determine the degree
>>>>>>     of failed HMAC calculations due to HTTP proxies modifying the
>>>>>>     content.
>>>>>>     >>
>>>>>>     >> -- Key Distribution
>>>>>>     >>
>>>>>>     >> Everyone agreed that the client must receive the session
>>>>>>     key from the authorization server and that this approach has
>>>>>>     to be standardized. It was also agreed that this is a common
>>>>>>     approach among all three key distribution mechanisms.
>>>>>>     >>
>>>>>>     >> The questions regarding key naming and the indication for
>>>>>>     the intended resource server the client wants to talk to have
>>>>>>     been postponed.
>>>>>>     >>
>>>>>>     >> Ciao
>>>>>>     >> Hannes
>>>>>>     >>
>>>>>>     >>