Subject: [OAUTH-WG] WG Survey

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 18 Feb 2010 10:14:25 -0700

A few questions we should answer before moving forward. Considering *your* use cases and reasons for being here:

1. Why are you here? What are you trying to solve that is not already addressed by existing specifications (OAuth 1.0a, WRAP, etc)?

2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point? Something else?

3. If we start from draft-hammer-oauth, what needs to change to turn it into OAuth 2.0?

4. If we start from draft-hardt-oauth, what needs to change to turn it into OAuth 2.0?

5. Do you think the approach of working first on 'how to use a token' and then on 'how to get a token' is right?

6. Should we go back to working on a single specification?

7. Do you think the protocol should include a signature-based authentication scheme?

EHL

---

From: "Paul C. Bryan" <[email-masked]>
Date: Thu, 18 Feb 2010 10:20:46 -0800

On Thu, 2010-02-18 at 10:14 -0700, Eran Hammer-Lahav wrote:
> A few questions we should answer before moving forward. Considering
> *your* use cases and reasons for being here:
> 
> 1. Why are you here?

I have built and plan to continue building OAuth implementations. I am
also working on the UMA protocol, which currently relies heavily on
OAuth.

> What are you trying to solve that is not already addressed by existing
> specifications (OAuth 1.0a, WRAP, etc)?

OAuth 1.x currently requires signatures that include consumer key and
secret, which is problematic when (distributed) policy enforcement
points need consumer key material to verify signatures.

OAuth has a lot of potential for securing resources, beyond its current
scope of delegating access. Separating delegation from authentication
further supports this.

> 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting

OAuth 1.0a.

> 3. If we start from draft-hammer-oauth, what needs to change to turn

Off the top of my head:

- separation of token issuance (delegation) and request authentication
- abstract token format w. concrete minimum supportable set
- token usage profiles (e.g. bearer vs. symmetric key vs. asymmetric)

> 4. If we start from draft-hardt-oauth, what needs to change to turn it

No comment.

> 5. Do you think the approach of working first on 'how to use a token'
> and then on 'how to get a token' is right?

Yes.

> 6. Should we go back to working on a single specification?

Yes.

> 7. Do you think the protocol should include a signature-based

Yes.

Paul

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 18 Feb 2010 21:28:31 +0100

Hi,
> A few questions we should answer before moving forward. Considering *your* use cases and reasons for being here:
I'm interested to learn about status and directions of upcomming OAuth 
2.0 standard and to contribute my experiences with token based web 
service security infrastructures.
> What are you trying to solve that is not already addressed by existing specifications (OAuth 1.0a, WRAP, etc)?
>    
I would appreciate improved support for environments with central 
authorization services and an "open triangle" style architecture (no 
direct communication between web service and authorization server) .

OAuth 1.0a requires the protected resource to know consumer key and 
secret, which is a security issue in our environment (central 
authorization server, various services exposing protected resources 
outside of our control). It should be sufficent to use token related 
data in order to verify a token (or a message carrying the token, 
respectively).

Just passing the token (bearer tokens) to a service should be an option 
(typically over HTTPS).

It is difficult to revoke access tokens in our environment. I see the 
following options:
  a) Force the protected resource to check the token validity on each 
request (requires remote calls - imperformant)
  b) Push revocations to all services (complex)
  c) Use a combination of long (months)- and short-living 
(minutes-hours) tokens, long-living tokens are exchanged for short 
living tokens, which in turn are used for service invocation. The 
revocation is checked by the authorization server when issuing 
short-living tokens.
The coming OAuth spec should support option (c)

> 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point? Something else?
draft-hammer-http-token-auth + WRAP

> 4. If we start from draft-hardt-oauth, what needs to change to turn it into OAuth 2.0?
authorization servers should optionally issue token secrets in order to 
support message signing.
> 5. Do you think the approach of working first on 'how to use a token' and then on 'how to get a token' is right?
Both topics interdependent on each other, so building the big picture 
first and elaborate the specification in two steps later on might be better
> 6. Should we go back to working on a single specification?
yes.
> 7. Do you think the protocol should include a signature-based authentication scheme?
yes.

regards,
Torsten.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 18 Feb 2010 21:00:48 -0700

> 1. Why are you here? What are you trying to solve that is not already
> addressed by existing specifications (OAuth 1.0a, WRAP, etc)?

I would like to see OAuth 1.0 extended to support more methods for obtaining tokens to optimize usability for non-web-based clients. I also want to clean the overall architecture and simplify parts of the spec that were originally designed to work on very limited platforms. I am also concerned about the security implications of WRAP adoption as currently written. 
 
> 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point?

Strictly from an editor's perspective, OAuth 1.0a (as documented in the recently approved draft-hammer-oauth RFC) offers the best narrative to build on. The document has gone through many revisions and reflects over a year of work on top of the original OAuth specification. It would be easier to add the new methods of obtaining a token into OAuth, than to rewrite WRAP to reach the same level of document maturity.
 
> 3. If we start from draft-hammer-oauth, what needs to change to turn it into

To start with, adding all the new flows in WRAP to make it feature complete. The authentication section needs to be cleaned up and incorporate a new message format for signing (similar to Brian's proposal), as well as remove the need to use the client credentials for accessing resources. It also needs to replace PLAINTEXT with a simpler, cleaner bearer token solution that does not require reading the entire specification to implement.
 
> 4. If we start from draft-hardt-oauth, what needs to change to turn it into

The primary issues are similar to the OAuth specification in how parameters are sent, named, as well as lacking any support for signatures.

Ignoring the early stage of the draft, the document needs more clarity in its terminology. It uses an architecture that is not fully explained or specified, leaving too much for the implementer to figure out. For example, WRAP doesn't directly support the separation of the token issuer from the resource server because it doesn't explain how such a decoupling can be implemented in practice.
 
> then on 'how to get a token' is right?

I am not sure anymore. It has not worked so far, and it seems people are not motivated to engage this effort because they don't see how all the pieces come together. It looks like taking one of the two specs (1.0a or WRAP) and starting to revise it frequently until it is feature complete is going to get people more engaged.
 
> 6. Should we go back to working on a single specification?

Yes. Same as the previous answer. I am still not sure if we should end up publishing a single specification, but when we are done, we can ask the opposite question if the 'how to use a token' section is more useful on its own.

Yes.

I agree that a bearer token over SSL/TLS offers more than an HMAC-based signature over non-secure channel. I personally don't see much value in the HMAC signature because any token-issuing server will have to support SSL/TLS for sending tokens in the first place. So the argument that we need to support servers without SSL/TLS is false (note that draft-hammer-oauth as approved requires SSL/TLS for all plaintext secrets). I don't know enough to say if the argument that HMAC is cheaper/faster/easier than always using SSL/TLS is true or not.

What I am interested in is support for asymmetric secrets because that's the only way I know to avoid the need for client registration, without giving up completely on client identity verification. But since this requires a signature process, defining an HMAC option becomes just a matter of a few more lines. In other words, if we support an RSA-SHA1-like method, we might as well also support HMAC. I posted my use case for this separately.

EHL

---

From: Brian Eaton <[email-masked]>
Date: Thu, 18 Feb 2010 22:00:25 -0800

> 1. Why are you here? What are you trying to solve that is not already addressed by existing specifications (OAuth 1.0a, WRAP, etc)?

WRAP solves almost all of them.

I see a need for passing signed claims about identity around, and I
don't think SWT or SAML are good choices for that.  I don't think the
signed identity claims are necessary in the core OAuth spec, they are
an advanced use case that most OAuth implementers (client and server)
should completely ignore.

> 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point? Something else?

WRAP.

> 5. Do you think the approach of working first on 'how to use a token' and then on 'how to get a token' is right?

I think "how to use a token" should be about two lines. =)

> 7. Do you think the protocol should include a signature-based authentication scheme?

See above about signed claims about identity.

---

From: Brent Goldman <[email-masked]>
Date: Thu, 18 Feb 2010 22:02:34 -0800

> 1. Why are you here? What are you trying to solve that is not already addressed by existing specifications (OAuth 1.0a, WRAP, etc)?

I'm here because I believe that openness can make the internet a better place. In a perfect world, an app developer wouldn't have to write code for each new service provider; everything would just work. More concretely, I'm here because I want to help develop OAuth into something suitable not only for the average-sized site, but suitable even for a site as large and complicated as Facebook to adopt as its main authorization protocol.

The problems with OAuth 1.0a are that the flow is too complicated, the protocol is non-performant (specifically, too many roundtrips), and it doesn't support non-website use cases such as desktop or mobile as effectively as other protocols.

> 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point? Something else?

By focusing on actual use cases, I believe WRAP has more potential as a starting point. However, OAuth 1.0a is more mature. Either would be fine as a starting point.

Yes.

> 6. Should we go back to working on a single specification?

I'm not sure if working on a single specification is the right answer (e.g., we might want one specification for obtaining tokens and another one for how to use them), but I believe we should unify efforts on a set of interoperable standards instead of working on competing ones.

Yes.

---

From: David Recordon <[email-masked]>
Date: Thu, 18 Feb 2010 22:24:36 -0800

Glad to see this thread. :)

> addressed by existing specifications (OAuth 1.0a, WRAP, etc)?

OAuth has been insanely successful the past few years in terms of almost
eliminating new password-based APIs.  That said, developers both large and
small have found it to be complex and not as simple to implement as
possible.  We now have the opportunity to develop OAuth 2.0 based on what
we've learned and new methodologies in APIs that weren't prevalent two years
ago.  Overall, I want to modernize OAuth so that it's not just "FooCo
supports OAuth" but rather "FooCo has a million developers using OAuth".

> 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point?

I think that WRAP has a lot of the right ideas (multiple ways to get tokens
and relies on SSL), but ultimately wasn't created in an open process and was
shaped by small number of implementors.  I also think that there are lessons
to be learned from OAuth 1.0 which haven't made their way into the current
WRAP draft.

If I were to write a draft, I'd start with an empty document and merge in
appropriate sections from draft-hammer-oauth, draft-hammer-http-token-auth,
and WRAP.  I'd then probably rewrite half of the text as it gets merged
together.

3. If we start from draft-hammer-oauth, what needs to change to turn it into
> OAuth 2.0?

Eran had a good answer here.

4. If we start from draft-hardt-oauth, what needs to change to turn it into
> OAuth 2.0?

Eran had a good answer here.

> then on 'how to get a token' is right?

I think it's hard to compare text from this split approach to the WRAP draft
spec.

> 6. Should we go back to working on a single specification?

Yes.  We can split it apart later, but should optimize for a single easy to
understand document.

7. Do you think the protocol should include a signature-based authentication
> scheme?

Yes.  See http://www.ietf.org/mail-archive/web/oauth/current/msg01049.html.

---

From: Chris Messina <[email-masked]>
Date: Fri, 19 Feb 2010 07:59:33 -0800

+1 to what Dave said.

I almost wrote the same thing (though admittedly with less technical  
insight).

To me, the needs are:

1. Consolidate the needs for OAuth 2.0
2. Merge the documents as necessary; rinse, wash, repeat until we have  
a satisfactorially readable and comprehensible document (2.0 should be  
one of Eran's "editor's drafts").
3. We need more flow diagrams methinks (I'll volunteer to prettify any  
ASCII drawings).
4. This document needs to tell the marketplace that OAuth is:  
evolving, stable, secure, and getting easier to implement in more  
diverse (and realistic) environments. And that 2.0 isn't abandoning  
1.0a, but improving on that foundation to solve the problems that have  
become clearer to us in the past several years since 1.0 was released.
5. I would volunteer to write a context-setting document to help  
people who aren't active in these lists understand the goals, context,  
and purpose behind revving OAuth.

Managing the transition and outreach for the next rev of OAuth will be  
nearly as important as getting to a final document in my mind.

Chris

Sent from my iPhone 2G

On Feb 18, 2010, at 10:24 PM, David Recordon <[email-masked]>  
wrote:

> On Thu, Feb 18, 2010 at 9:14 AM, Eran Hammer-Lahav <[email-masked] 
> > wrote:
> 1. Why are you here? What are you trying to solve that is not  
> already addressed by existing specifications (OAuth 1.0a, WRAP, etc)?
>
> OAuth has been insanely successful the past few years in terms of  
> almost eliminating new password-based APIs.  That said, developers  
> both large and small have found it to be complex and not as simple  
> to implement as possible.  We now have the opportunity to develop  
> OAuth 2.0 based on what we've learned and new methodologies in APIs  
> that weren't prevalent two years ago.  Overall, I want to modernize  
> OAuth so that it's not just "FooCo supports OAuth" but rather "FooCo  
> has a million developers using OAuth".
>
>
> I think that WRAP has a lot of the right ideas (multiple ways to get  
> tokens and relies on SSL), but ultimately wasn't created in an open  
> process and was shaped by small number of implementors.  I also  
> think that there are lessons to be learned from OAuth 1.0 which  
> haven't made their way into the current WRAP draft.
>
> If I were to write a draft, I'd start with an empty document and  
> merge in appropriate sections from draft-hammer-oauth, draft-hammer- 
> http-token-auth, and WRAP.  I'd then probably rewrite half of the  
> text as it gets merged together.
>
>
> 5. Do you think the approach of working first on 'how to use a  
> token' and then on 'how to get a token' is right?
>
> I think it's hard to compare text from this split approach to the  
> WRAP draft spec.
>
>
> Yes.  We can split it apart later, but should optimize for a single  
> easy to understand document.
>
>

---

From: Luke Shepard <[email-masked]>
Date: Fri, 19 Feb 2010 11:37:32 -0800

1. Why are you here? What are you trying to solve that is not already addressed by existing specifications (OAuth 1.0a, WRAP, etc)

I'm here because we have a huge opportunity, right now, to move authentication down the "stack" a level. Just as developers don't have to worry about HTTP anymore - it just sorta happens effortlessly - likewise, I want to build a spec that has enough widespread adoption so that the entire tools ecosystem supports it. If we are successful, then developers won't have to think about auth - they can worry about building their applications.

One thing that I haven't seen mentioned much is the relationship between OpenID and OAuth. A primary goal of mine in OAuth 2.0 is to see a path to smooth interop with OpenID. The current OpenID/OAuth Hybrid protocol is awkward and overly complex; it would be nice if the two protocols stacked on top of each other really nicely.

For a service like Facebook to truly adopt OAuth as our one standard way of logging in, it must be able to support identity as well as authorization. To me, this is one of the elephants in the room that we need to address.

Dave summed this up nicely - I'd like to see what he comes up with. Personally, I have a preference towards starting with WRAP, because it better reflects the Facebook Connect use cases than does OAuth 1.0a.

On Feb 19, 2010, at 10:59 AM, Chris Messina wrote:

+1 to what Dave said.

I almost wrote the same thing (though admittedly with less technical insight).

To me, the needs are:

1. Consolidate the needs for OAuth 2.0
2. Merge the documents as necessary; rinse, wash, repeat until we have a satisfactorially readable and comprehensible document (2.0 should be one of Eran's "editor's drafts").
3. We need more flow diagrams methinks (I'll volunteer to prettify any ASCII drawings).
4. This document needs to tell the marketplace that OAuth is: evolving, stable, secure, and getting easier to implement in more diverse (and realistic) environments. And that 2.0 isn't abandoning 1.0a, but improving on that foundation to solve the problems that have become clearer to us in the past several years since 1.0 was released.
5. I would volunteer to write a context-setting document to help people who aren't active in these lists understand the goals, context, and purpose behind revving OAuth.

Managing the transition and outreach for the next rev of OAuth will be nearly as important as getting to a final document in my mind.

Chris

Sent from my iPhone 2G

On Feb 18, 2010, at 10:24 PM, David Recordon <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Feb 18, 2010 at 9:14 AM, Eran Hammer-Lahav <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
A few questions we should answer before moving forward. Considering *your* use cases and reasons for being here:

OAuth has been insanely successful the past few years in terms of almost eliminating new password-based APIs.  That said, developers both large and small have found it to be complex and not as simple to implement as possible.  We now have the opportunity to develop OAuth 2.0 based on what we've learned and new methodologies in APIs that weren't prevalent two years ago.  Overall, I want to modernize OAuth so that it's not just "FooCo supports OAuth" but rather "FooCo has a million developers using OAuth".

I think that WRAP has a lot of the right ideas (multiple ways to get tokens and relies on SSL), but ultimately wasn't created in an open process and was shaped by small number of implementors.  I also think that there are lessons to be learned from OAuth 1.0 which haven't made their way into the current WRAP draft.

If I were to write a draft, I'd start with an empty document and merge in appropriate sections from draft-hammer-oauth, draft-hammer-http-token-auth, and WRAP.  I'd then probably rewrite half of the text as it gets merged together.

I think it's hard to compare text from this split approach to the WRAP draft spec.

Yes.  We can split it apart later, but should optimize for a single easy to understand document.

Yes.  See <http://www.ietf.org/mail-archive/web/oauth/current/msg01049.html> http://www.ietf.org/mail-archive/web/oauth/current/msg01049.html.

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

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

---

From: Mark Mcgloin <[email-masked]>
Date: Sun, 21 Feb 2010 11:27:10 +0000

addressed by existing specifications (OAuth 1.0a, WRAP, etc)?
I want to see a single hardened protocol rather than fragmented proprietty
solutions.
My leaning is towards a secure solution suitable for enterprise customers
more than an easy to use solution for long end developers. To that end,
standardizing on something that can then be used to build better library
support should satisfy all parties

> 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting
point? Something else?
Not sure. Wrap is better from architecture point of view but OAuth has put
more thought into security

> 3. If we start from draft-hammer-oauth, what needs to change to turn it
into OAuth 2.0?
Better separation of authorization (Get a token) from authentication (use a
token)

> 4. If we start from draft-hardt-oauth, what needs to change to turn it
into OAuth 2.0?
Fill out section on security considerations, e.g. Spell out assumptions on
infrastructure like SSL that are required to ensure security or threat
models for non-SSL

> 6. Should we go back to working on a single specification?
Yes

> 7. Do you think the protocol should include a signature-based
authentication scheme?
Yes. I think there will be some use cases or worries from over-cautious
CIOs that it will neccessitate it.

Mark McGloin

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sun, 21 Feb 2010 18:12:59 +0200

Hi Eran, 

There are a couple of problems with this survey. See below
 
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Eran Hammer-Lahav
>Sent: 18 February, 2010 19:14
>To: OAuth WG ([email-masked])
>Subject: [OAUTH-WG] WG Survey
>
>A few questions we should answer before moving forward. 
>Considering *your* use cases and reasons for being here:
>

During the conference call we figured out that there is no way one would
easily agree to a single scenario or deployment variant. 

This is where some the disagreements come from. Some folks have the
super-secure governmental application in mind, others want to support
the enterprise environment which are able to spend a lot of money on
security, and then there are others that focus on the web developer that
does not have even money for the certs. 

How do you want to provide a solution that fits everyone? Not really
possible IMHO (unless you introduce the notion of "profiles"). 

>starting point? Something else?

Largely irrelevant as the content will change anyway 

>to turn it into OAuth 2.0?

Depends on the scenarios you want to cover under item (1). 

>4. If we start from draft-hardt-oauth, what needs to change to 

Depends on the scenarios you want to cover under item (1). 

>token' and then on 'how to get a token' is right?

Nope. First, you have to figure out what you want the specification to
accomplish. 

>6. Should we go back to working on a single specification?

Does not matter. This is purely a document management / authorship
question that would come last. 

>7. Do you think the protocol should include a signature-based 

That depends on the scenarios you want to cover. 

Ciao
Hannes

---

From: David Recordon <[email-masked]>
Date: Sun, 21 Feb 2010 09:42:27 -0800

Hey Hannes,
Not to be taken the wrong way, but we've already had eight really
informative responses to this survey.  It would be useful to
understand what you're interested in solving within this working group
versus just hearing the belief that the survey is broken. :)

Cheers,
--David

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sun, 21 Feb 2010 20:22:05 +0200

Hi David, 

It is good that folks share their thoughts. 

Sometimes it is, however, difficult to pinpoint the real challenge. To
me it seems that the different deployment scenarios people have in mind
cause most of the problems.

Here is an example conversation from the recent virtual interim meeting
chat: 

* Blaine argues that some web developers cannot afford a certificate and
hence, for him, OAuth with only TLS based authentication is not enough.
This demands token and HTTP message content signing mechanisms.

* Brian claims that TLS is sufficient to protect bearer tokens.  

* Jeff and Eve argue that they have scenarios where you need to have TLS
and signed tokens. 

So, what are the options: 

1) You support all three scenarios. The spec will be large and various
people will claim it is complex and that there might be an
interoperability problem*. 

2) You pick only one of the three scenarios. Let's say you pick the
scenario Brian has in mind. The specification is simpler than (1) but
will obviously not cover the scenario the other folks had in mind. That
may or may not matter. Maybe the developer group Blaine has in mind
suddenly decides to buy certificates to be more security aware. Who
knows. It is a bit hard to predict the future. In any case, Blaine, Jeff
and Eve will be unhappy and will likely do what they want anyway, namely
to extend OAuth in their favorite way (in the usual forum shopping
mentality). 

Does this make any sense to you? 

Now, what would you do?

Ciao
Hannes

PS: I am sure that Eran is concerned about the time it will take him to
edit the documents back and forth.

Regarding (*): There is an interoperability problem but there is already
one anyway since many other parts in the specification are not described
so that independent implementations will have a hard time to interwork
automatically anyway.

>From: ext David Recordon [mailto:[email-masked]] 
>Sent: 21 February, 2010 19:42
>To: Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: Eran Hammer-Lahav; [email-masked]
>Subject: Re: [OAUTH-WG] WG Survey
>
>Hey Hannes,
>Not to be taken the wrong way, but we've already had eight 
>really informative responses to this survey.  It would be 
>useful to understand what you're interested in solving within 
>this working group versus just hearing the belief that the 
>survey is broken. :)
>
>Cheers,
>--David
>
>On Sun, Feb 21, 2010 at 8:12 AM, Tschofenig, Hannes (NSN - 
>FI/Espoo) <[email-masked]> wrote:
>> Hi Eran,
>>
>> During the conference call we figured out that there is no way one 
>> would easily agree to a single scenario or deployment variant.
>>
>> security, and then there are others that focus on the web developer 
>> that does not have even money for the certs.
>>
>>>4. If we start from draft-hardt-oauth, what needs to change 
>to turn it 
>>>into OAuth 2.0?
>>
>>

---

From: "Vrancken Bart bv" <[email-masked]>
Date: Mon, 22 Feb 2010 09:52:35 +0100

Hello folks,

>addressed by existing specifications (OAuth 1.0a, WRAP, etc)?

I am here because I support open standards and would like to see some
improvements/additions to the protocol. Recursive delegation is the main
pain point that I want to address (see the ID of redelegation) 
This is important for Mesh-ups or for content managers that use
different services to have good interoperability with the different
providers.
WRAP could help here for TLS-enabled environments, but there are use
cases where you don't have such an environment. 

>2. Should the WG start by taking WRAP or OAuth 1.0a as its starting
point? >Something else?

Or we start a new document, combining the different ID's or we should
start from our previous "consensus" around OAuth 1.0a

>3. If we start from draft-hammer-oauth, what needs to change to turn it

The idea of Resource Owner Authorization should be adapted to provide a
clean way to do the recursive delegation flow.
Replacing the "PLAINTEXT"-method with WRAP

>4. If we start from draft-hardt-oauth, what needs to change to turn it
into >OAuth 2.0?

I see WRAP as a nice replacement for the "PLAINTEXT"-method, so the
other cases should be added.

>5. Do you think the approach of working first on 'how to use a token'
and >then on 'how to get a token' is right?

There should be a simple spec having the whole flow, instead that you
should read different documents to get a feeling of what there is
written. Maybe the split could be used, if there is a third document
that glues them together with a clear vision/use case.

>6. Should we go back to working on a single specification?

See previous answer

Yes.

Best regards,

Bart Vrancken

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 23 Feb 2010 00:06:41 +1100

> addressed by existing specifications (OAuth 1.0a, WRAP, etc)?

I am here because delegation is really important functionality for the web.
I want delegation functionality that can work even when a client has not been pre-registered with a service.
I want delegation functionality that fits well with the style of the web (particularly HTTP).
I want a logically clean protocol for the best chance of being applicable to a variety of scenarios (eg decouple authz and authn, minimal spots for service-specific "additional params").

> 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting

WRAP is probably a better starting point.

> 3. If we start from draft-hammer-oauth, what needs to change to turn it

Remove the request signing mechanisms.

> 4. If we start from draft-hardt-oauth, what needs to change to turn it

Separate user/client/server delegation from client/server credential refresh -- I am not sure they are as related as WRAP makes out.

Better 401 Unauthorized WWW-Authenticate responses (not just "WRAP" for everything).

"Discovery" (within direct HTTP request/response flow): of redirect URIs, of authentication mechanisms, of the domains where a token can be used...

> and then on 'how to get a token' is right?

No.
As long as "how to get a token" can result in an authz token (& some metadata) or an id plus secret key (& some metadata) then any number of different approaches can be adopted for "how to use a token" -- and they can be chosen at any time, by anyone.

It would be nice to have one simple "how to use a token" option specified up front -- ie a bearer token scheme -- so you can visualise a complete delegation flow.

> 6. Should we go back to working on a single specification?

No.
A separate spec just for transmitting a bearer token would be useful (and short).

> 7. Do you think the protocol should include a signature-based

No.
The delegation protocol should be capable of working with signature-based auth schemes.
Any number of signature schemes can be defined separately if there is agreement on what to sign (URI, host, headers, body...), what to sign with (password, shared secret, public key crypto...), what security to offer (user auth, data origin auth, confidentiality, replay protection, with or without clocks, zero-knowledge proof...), what performance is important (latency, round trips, 1-pass...), and what operational security is possible (nonces, cleartext keys, short-term keys...)

--
James Manger

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 22 Feb 2010 15:46:38 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Thursday, February 18, 2010 9:14 AM
To: OAuth WG ([email-masked])
Subject: [OAUTH-WG] WG Survey

>1. Why are you here? What are you trying to solve that is not already addressed by existing specifications (OAuth 1.0a, WRAP, etc)?
To further a specification to cover use cases that have emerged. WRAP currently covers those use cases and OAuth 1.0a does not.

>2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point? Something else?
WRAP 

>3. If we start from draft-hammer-oauth, what needs to change to turn it into OAuth 2.0?
Remove the request signing mechanisms

>5. Do you think the approach of working first on 'how to use a token' and then on 'how to get a token' is right?
How to use a token may not be the right thing to concentrate on as I can see different tokens for different uses, so would support an emphasis on 'how to get a token'

>6. Should we go back to working on a single specification?
If we can get agreement on the use cases and agree on the function/features, makes sense

>7. Do you think the protocol should include a signature-based authentication scheme?
Not a required item

---

From: Ethan Jewett <[email-masked]>
Date: Mon, 22 Feb 2010 11:10:22 -0600

> 1. Why are you here? What are you trying to solve that is not already addressed by existing specifications (OAuth 1.0a, WRAP, etc)?

OAuth 1.0a already meets most of my needs, but I think that there is
room for improvement, clarification, and simplification, especially
around key/token/secret acquisition and management and around the
PLAINTEXT method.

> 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point? Something else?

On the resource access side, OAuth 1.0a. WRAP does not address the
signature methods at all, so I do not think it is a good starting
point.

On the access token acquisition side, the WRAP profile approach makes
a lot of sense in that it acknowledges and takes on the complexity of
acquiring a token in different scenarios. However, I think we would
still need to define something which the different profiles are ...
profiling ... so we probably need to start from OAuth 1.0a and add on
the profiles. Perhaps it makes sense to publish the profiles as
separate documents instead of as part of the main document, but I'd
think they need to be developed in parallel.

> 3. If we start from draft-hammer-oauth, what needs to change to turn it into OAuth 2.0?

I haven't gotten to thoroughly review the current draft, but from my
point of view it looks pretty good from the resource access
perspective. If replacing the entire PLAINTEXT flow with WRAP would
make people happy, then I would be for that, but I don't see much
difference between them. I think it really depends on what current
implementations use WRAP (not sure about the number) vs. OAuth 1.0a
PLAINTEXT (not many to my knowledge).

> 4. If we start from draft-hardt-oauth, what needs to change to turn it into OAuth 2.0?

I haven't been able to review this draft in detail. I like the
profiling approach to a certain extent, but the fact that it
completely ignores the signature scenario (and thereby ignores the
vast majority of OAuth deployments as far as I can tell) is extremely
problematic when considering it as a starting point.

> 5. Do you think the approach of working first on 'how to use a token' and then on 'how to get a token' is right?

Yes. I think that as long as we are agreed that a single access token
is being used and that token is opaque to the client, then this
approach makes sense.

> 6. Should we go back to working on a single specification?

I'm in the "no" camp, but mostly for logistical reasons. I have a hard
time reading through a new draft of a specification that includes both
pieces.

It is worth noting that there was (IIRC) some confusion in the OAuth
community, especially around signature calculation, that seemed to be
caused by having both parts of the OAuth model in one document. People
had a hard time understanding that the token acquisition flow and the
resource request were very different animals.

> 7. Do you think the protocol should include a signature-based authentication scheme?

Absolutely. It's worth noting that OAuth 1.0a had a PLAINTEXT method
similar to WRAP. As far as I can tell, it would have been possible for
WRAP to define its resource access method to be compatible with the
OAuth 1.0a PLAINTEXT method. I only say this to point out that none of
the main OAuth implementations support the PLAINTEXT method to my
knowledge, even though they could have done so.

I think there are a lot of reasons one would want to use a signature
method over the PLAINTEXT method or WRAP (and there are a lot of
reasons in the other direction). But this is just a survey, so that
answer is plenty long enough :-)

Ethan

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 22 Feb 2010 17:02:32 -0700

> A few questions we should answer before moving forward.

Eran, I think those were good questions. I've summarized the list
feedback so far below. I'm out of time for the moment, but will reply
with some of my own thoughts soon...

> Considering *your* use cases and reasons for being here:

Reasons include:

- need to build applications on top of OAuth
- interested in token-based infrastructures
- interested in non-web applications
- want to simplify the architecture
- concerned about security issues
- want an extension for passing around signed identity claims
- want to build Internet-scale applications
- seeking greater simplicity
- see a need for a widespread authn/authz technology
- concerned about fragmentation / care about open standards

> What are you trying to solve that is not already addressed by 
> existing specifications (OAuth 1.0a, WRAP, etc)?

Problems include:

- 1.0a doesn't easily support distributed policy enforcement
- there is a lot of potential beyond the use cases covered in 1.0a
- need improved support for central authorization services
- protected resource needs to know consumer key and secret (security issue)
- should be an option to pass a bearer token over an encrypted channel
- in some environments it is difficult to revoke access tokens
- need support for asymmetric secrets to avoid client registration
- OAuth 1.0a flow is too complex
- too many round trips
- doesn't support non-web use cases very well
- need more pictures / flow diagrams to make it more readable
- integrate better with OpenID
- the problems depend on the use cases (define those first)
- recursive delegation is undefined
- optimize for the web
- support more use cases than defined in 1.0a
- clarify what we have in 1.0a

> 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting 

Both: 5 (take the best parts from each document)
WRAP: 4
Either: 2 (just start with use cases!)
OAuth 1.0a: 2

- separation of token issuance (delegation) and request authentication
- abstract token format w. concrete minimum supportable set
- token usage profiles (e.g. bearer vs. symmetric key vs. asymmetric)
- add the flows from WRAP
- add a new message format for signing
- don't require client credentials to access protected resources
- replace PLAINTEXT with a simpler bearer token format or WRAP/TLS
- better separation of authorization (get a token) from authentication
(use a token)
- remove signing requests
- keep signing requests but simplify

> 4. If we start from draft-hardt-oauth, what needs to change to turn 

- to support message signing, authorization servers should optionally
issue token secrets
- more clearly explain the architecture, especially how the token issuer
can be separate from the resource server
- improve security considerations
- add non-PLAINTEXT use cases
- separate user/client/server delegation from client/server credential
refresh
- better 401 Unauthorized WWW-Authenticate responses
- discovery of redirect URIs, of authentication mechanisms, of the
domains where a token can be used
- need support for signed requests (majority of deployments)

> and then on 'how to get a token' is right?

No: 7
Yes: 3
Abstain / Unsure: 3

considerations:
- these steps are interdependent
- more productive to start from either WRAP or OAuth 1.0a and iterate
- hard to compare this approach to a more integrated approach
- it all depends on the goals and use cases
- OK to have many ways to use a token
- need simple bearer token to define the entire flow

> 6. Should we go back to working on a single specification?

Yes: 8
No: 2
Doesn't matter: 2
Abstain / Unsure: 1

> 7. Do you think the protocol should include a signature-based 

Yes: 10
No / make it optional: 2
Depends on use cases: 1

/psa

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 23 Feb 2010 15:40:07 -0500

>> already addressed by existing specifications (OAuth 1.0a, WRAP, etc)?
I am working on the security aspects of identity management, and I find 
that OAuth is trying to solve an essential piece of the puzzle there as 
far as delegation is concerned. I also observe that telecom 
providers--my customers--are interested in OAuth (and may be seeing 
there what I don't yet see). This is another motivation for me--I am 
very interested in integrating telecom and Web 2.0. (In fact, I started 
in the IETF 14 years ago by bringing that proposal...)
>> starting point? Something else?
Something else: Use cases and the requirements.  The WG must produce the 
requirements based on agreed use cases. Now, it is absolutely clear that 
both the WRAP and 1.0 people will ensure that their interests and 
agendas are reflected in the requirements, and this is fine, this is how 
we will ensure that OAuth WG synthesize both.  Personally, I think that 
WRAP is much cleaner than OAuth 1.0, and I like clean things. But I also 
see some cases where WRAP would not be applicable.

To this end, use cases is the best mechanism to express the vision of 
the WG. I would start with them first (in the informational RFC), 
meaning that the can be developed in parallel with the requirements.

I don't think Hannes said that in exactly same words, but I suspect that 
he and I have the same idea here.

>> 4. If we start from draft-hardt-oauth, what needs to change to 
(Since I chose the "something else" option in item 2,  questions 3 and 4 
are not applicable.)
>> token' and then on 'how to get a token' is right?
Maybe. But even then, once it is clear' how to use a token', when 
working on 'how to get a token' this clarity will be less apparent, so 
this subject would need to be revisited.. When you do things like that, 
there is always a recursion (and it is not bad).

To make things more effective, I strongly agree with Hannes that the 
objectives (in terms of use cases and requirements) must come first.
>> 6. Should we go back to working on a single specification?
I am not sure that this should be an objective. Of course, if everything 
is simple, and there is a consensus, this is the best way. But it does 
not appear to me that there is a consensus, and if this is the case, it 
will be impossible to force one specification.  In fact, there has been 
a precedent in the IETF where more than one solution was developed and 
it was left to the market to choose one.
>> 7. Do you think the protocol should include a signature-based 

ABSOLUTELY.  I thought there has been a good discussion on that, and all 
the arguments are on the table.

Respectfully submitted by

Igor Faynberg