Subject: [OAUTH-WG] OAuth 2.0 / Charter

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 29 Nov 2009 00:59:21 -0700

With the cleanup of the 1.0 specification [1] and the publication of an informational RFC (pending IESG approval), I no longer see value in a standard closely based on the 1.0 specification, which was the original intention of this WG. This is also reflected by the recent interest in the WRAP proposal [2].

Instead, I think we should develop two specifications that while closely in line with the original plan, represent a significant shift. In other words, I am proposing we develop OAuth 2.0, not 1.1.

The new proposal is to develop two specifications:

1. Token Authorization Method

An RFC 2617 Authorization header called 'Token' for authenticating requests with token-based credentials. Tokens (with optional shared-secret) are usually used in place of other credentials (usernames, etc.) and represent some combination of scope and authorization. The token method will include an extensible signature-based option based on the HMAC-SHA1 method, and a bearer token (with optional secret) option based on the PLAINTEXT method. The RSA option will be dropped. 

2. OAuth 2.0

A specification based on the browser-redirection flow described in OAuth 1.0 as well as new methods defined in WRAP (I-D submission pending). OAuth will be redefined to cover the authorization component only, and will no longer be bound to a single authentication method. This will make OAuth immediately useful for other protocols than HTTP (while HTTP will be used to obtain tokens, tokens will be useful in other protocols, not just with the HTTP and Token method).

---

While the current charter allows much of this work, it contradicts its spirit and the understanding reached when we created the working group. 

I would like to ask:

- Is this approach favorable by the group?
- Do we need to adjust the language in the charter to support?

EHL

[1] http://tools.ietf.org/html/draft-hammer-oauth
[2] http://bit.ly/oauth-wrap

---

From: Richard Barnes <[email-masked]>
Date: Sun, 29 Nov 2009 13:34:11 -0800

Eran,

A few thoughts on item (1), the authentication method (it is more  
properly "authentication").

I would like to get the group's impressions on what the goals are for  
item (1), i.e., what we want the new authentication method to provide  
that current methods don't.  As I think I said before, my impression  
is that the whole "token" aspect of the authentication is not the real  
value (those are just additional semantics layered on the bits that  
carried in the protocol).  Some candidates for goals:
1. Work with a single HTTP request (when no negotiation is required)  
[as opposed to 2 for Digest]
2. Protect credentials from exposure on the wire (when not PLAINTEXT)  
[as opposed to Basic]
3. Include non-MAC-based signature methods and method negotiation
4. Bind the authenticated entity to the request

Why are we dropping RSA?  Because there's no developer interest?   
Because it's kind of redundant with TLS?  Something else?

--Richard

On Nov 28, 2009, at 11:59 PM, Eran Hammer-Lahav wrote:

> With the cleanup of the 1.0 specification [1] and the publication of  
> an informational RFC (pending IESG approval), I no longer see value  
> in a standard closely based on the 1.0 specification, which was the  
> original intention of this WG. This is also reflected by the recent  
> interest in the WRAP proposal [2].
>
> Instead, I think we should develop two specifications that while  
> closely in line with the original plan, represent a significant  
> shift. In other words, I am proposing we develop OAuth 2.0, not 1.1.
>
> An RFC 2617 Authorization header called 'Token' for authenticating  
> requests with token-based credentials. Tokens (with optional shared- 
> secret) are usually used in place of other credentials (usernames,  
> etc.) and represent some combination of scope and authorization. The  
> token method will include an extensible signature-based option based  
> on the HMAC-SHA1 method, and a bearer token (with optional secret)  
> option based on the PLAINTEXT method. The RSA option will be dropped.
>
> 2. OAuth 2.0
>
> A specification based on the browser-redirection flow described in  
> OAuth 1.0 as well as new methods defined in WRAP (I-D submission  
> pending). OAuth will be redefined to cover the authorization  
> component only, and will no longer be bound to a single  
> authentication method. This will make OAuth immediately useful for  
> other protocols than HTTP (while HTTP will be used to obtain tokens,  
> tokens will be useful in other protocols, not just with the HTTP and  
> Token method).
>
> ---
>
> While the current charter allows much of this work, it contradicts  
> its spirit and the understanding reached when we created the working  
> group.
>
> I would like to ask:
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Paul C. Bryan" <[email-masked]>
Date: Sun, 29 Nov 2009 15:07:58 -0800

To the overall approach, +1.

Some follow-up questions:

1. Why drop RSA? It seems some form of public key cryptography will be
necessary/useful to make web-based-attribute-containing tokens
Internet-scalable.

2. Is it an objective to have the Token auth-scheme contain extension
points so that new token formats can be introduced without need to
redefine the scheme or draft a new one?

Paul

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 30 Nov 2009 10:51:38 +1100

> I am proposing we develop OAuth 2.0, not 1.1.
> …

YES.

James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 30 Nov 2009 00:29:41 -0700

This is very much in line with my thinking.

EHL

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]]
> Sent: Sunday, November 29, 2009 1:34 PM
> To: Eran Hammer-Lahav
> Cc: Peter Saint-Andre ([email-masked]); Lisa Dusseault
> ([email-masked]); OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter
> 
> Eran,
> 
> A few thoughts on item (1), the authentication method (it is more properly
> "authentication").
> 
> I would like to get the group's impressions on what the goals are for item (1),
> i.e., what we want the new authentication method to provide that current
> methods don't.  As I think I said before, my impression is that the whole
> "token" aspect of the authentication is not the real value (those are just
> additional semantics layered on the bits that carried in the protocol).  Some
> candidates for goals:
> 1. Work with a single HTTP request (when no negotiation is required) [as
> opposed to 2 for Digest] 2. Protect credentials from exposure on the wire
> (when not PLAINTEXT) [as opposed to Basic] 3. Include non-MAC-based
> signature methods and method negotiation 4. Bind the authenticated entity
> to the request
> 
> > an informational RFC (pending IESG approval), I no longer see value in
> > a standard closely based on the 1.0 specification, which was the
> > closely in line with the original plan, represent a significant shift.
> > In other words, I am proposing we develop OAuth 2.0, not 1.1.
> >
> > pending). OAuth will be redefined to cover the authorization component
> > only, and will no longer be bound to a single authentication method.
> > This will make OAuth immediately useful for other protocols than HTTP
> > (while HTTP will be used to obtain tokens, tokens will be useful in
> > other protocols, not just with the HTTP and Token method).
> >
> > ---
> >
> > While the current charter allows much of this work, it contradicts its
> > spirit and the understanding reached when we created the working
> > group.
> >
> > I would like to ask:
> >

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 30 Nov 2009 00:34:03 -0700

> From: Paul C. Bryan [mailto:[email-masked]]
> Sent: Sunday, November 29, 2009 3:08 PM
> To: Eran Hammer-Lahav
> necessary/useful to make web-based-attribute-containing tokens Internet-
> scalable.

Mostly due to lack of implementation experience or interest within the OAuth community. But also because the Plain and MAC versions are based on a simple symmetric shared secret, while PK requires more. This means we will need to support different types of tokens. While I am open to this if needed, it seems to add a significant complexity. Also, part 2 will then need to be able to provision both symmetric and asymmetric secrets which adds to the complexity there.

In other words, why put the effort in if no one is asking for this (based on 2 years of deployment experience).

> 2. Is it an objective to have the Token auth-scheme contain extension points
> so that new token formats can be introduced without need to redefine the
> scheme or draft a new one?

Yes, but see above.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 30 Nov 2009 00:36:02 -0700

Keep in mind that we are not going to include token structure in scope. We are simply proposing a method in which the token is a string, leaving it up to other efforts to give it structure if needed.

EHL

From: Greg Brail [mailto:[email-masked]]
Sent: Sunday, November 29, 2009 9:05 PM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email-masked])
Subject: RE: OAuth 2.0 / Charter

I've been following this discussion for a while now as a relative newcomer and I think this is a great idea. Forgive me if all you guys have reached this conclusion already:

Since we all understand OAuth, there are other places where tokens are popping up:

*      As a "more secure" replacement for username / password authentication in web services APIs like Amazon's

*      As a way for the developer of an API to understand which developer's applications are being used against the API, when it is less important to identify the actual user (for instance, the classical "API key" use case, or "two-legged OAuth")

*      As a way for the developer of a mobile app to ensure that only that app can make use of a particular web service, even if it is not important to identify the actual user

*      Lots of others I'm sure I'm missing

The sooner there is some movement towards a standard "token," the sooner we will have token support in a variety of programming environments. Plus, a standard token will reduce the propensity of web services builders to design their own tokens, with varying levels of security.

Plus, the OAuth flow has clearly proven to be useful and it deserves to be a standard that makes use of the standard token.

On the design of the token itself, I hope that it will have a place for one, two, or even more combinations of keys and secrets, so that it can handle simple use cases, more complex use cases such as OAuth, and even those that require three or more separate identifiers for a request.

                                                            greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Sunday, November 29, 2009 2:59 AM
To: Peter Saint-Andre ([email-masked]); Lisa Dusseault ([email-masked])
Cc: OAuth WG ([email-masked])
Subject: [OAUTH-WG] OAuth 2.0 / Charter

2. OAuth 2.0

---

I would like to ask:

EHL

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Moore, Jonathan (CIM)" <[email-masked]>
Date: Mon, 30 Nov 2009 09:22:08 -0500

Eran Hammer-Lahav writes, with respect to RSA support:
> In other words, why put the effort in if no one is asking for this
> (based on 2 years of deployment experience).

Ok, I'll ask for it then! Our main use cases for OAuth 1.0 have been for
2-legged, server-to-server integrations with known third parties. Public
key cryptography offers a lot of advantages here in terms of ease of
properly making a secure association between organizations. At least in
our shop, it's considerably easier for us to deal with PKI than it is to
set up SSL endpoints and/or run internal CAs.

Also, and especially when the response *body* does not require privacy,
I'd much rather spend my CPU cycles doing public-key cryptography on the
HTTP headers than encrypting an entire response payload via SSL. I also
lose the benefits of HTTP intermediaries when I have to tunnel over SSL.

I'm happy to participate here to work to keep this support in OAuth 2.0
(I'm just coming up to speed on the WG here).

Thanks,
Jon
........
Jon Moore
Comcast Interactive Media

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Eran Hammer-Lahav
Sent: Monday, November 30, 2009 2:34 AM
To: Paul C. Bryan
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter

> necessary/useful to make web-based-attribute-containing tokens
Internet-
> scalable.

Mostly due to lack of implementation experience or interest within the
OAuth community. But also because the Plain and MAC versions are based
on a simple symmetric shared secret, while PK requires more. This means
we will need to support different types of tokens. While I am open to
this if needed, it seems to add a significant complexity. Also, part 2
will then need to be able to provision both symmetric and asymmetric
secrets which adds to the complexity there.

In other words, why put the effort in if no one is asking for this
(based on 2 years of deployment experience).

> 2. Is it an objective to have the Token auth-scheme contain extension
points

Yes, but see above.

EHL

---

From: Paul Lindner <[email-masked]>
Date: Mon, 30 Nov 2009 06:27:28 -0800

Also note that Opensocial uses RSA signed 2-legged requests extensively.
 Billions of calls are made this way and the code to receive them is in wide
use.

---

From: Pelle Braendgaard <[email-masked]>
Date: Mon, 30 Nov 2009 10:53:32 -0500

+1 for all minus dropping RSA.

I think the main reason we haven't seen a lot of RSA implementations
yet has been because the kind of businesses who I think would be
interested in using this such as banks/payments etc are not
traditionally early adopters. If we want to see OAUTH used in these
areas in the future I think it would be a very good idea to leave it
in.

I am personally working on creating new OAuth based financial
transaction standard called OpenTransact, where we are planning on
standardizing on RSA in the next revision.

Regards
Pelle

-- 
http://agree2.com - Reach Agreement!
http://extraeagle.com - Solutions for the electronic Extra Legal world
http://stakeventures.com - Bootstrapping blog

---

From: Brian Eaton <[email-masked]>
Date: Mon, 30 Nov 2009 09:28:58 -0800

> set up SSL endpoints and/or run internal CAs.

Yes.  This is *huge*.  It's not the most visible use case for OAuth
(it doesn't demo well, because it just works =), but it is incredibly
important.

Cheers,
Brian

---

From: Hans Granqvist <[email-masked]>
Date: Mon, 30 Nov 2009 09:31:14 -0800

It's tricky. If you allow only MACs, you have to forgo no only RSA
(and ECC...) but also
potentially traditional symmetric key schemes -- their usability
notwithstanding.

On the other hand, if you try to cover all possible key schemes, it
quickly becomes
unmanageable.

Eran, is there a way to define what you want and leave it open for,
say an RSA extension,
as long as it can be represented as a string, such as
{ALGORITHM}:{STRING}, and where
any extra protocol flows are out of this specification's scope?

-Hans

---

From: John Panzer <[email-masked]>
Date: Mon, 30 Nov 2009 09:43:11 -0800

I'm +1 on the general approach and splitting the two specifications.  I have
some concerns that the change in scope of "OAuth" between 1.0 and 2.0 will
be confusing.

--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

On Sat, Nov 28, 2009 at 11:59 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> With the cleanup of the 1.0 specification [1] and the publication of an
> informational RFC (pending IESG approval), I no longer see value in a
> standard closely based on the 1.0 specification, which was the original
> intention of this WG. This is also reflected by the recent interest in the
> WRAP proposal [2].
>
> Instead, I think we should develop two specifications that while closely in
> line with the original plan, represent a significant shift. In other words,
> An RFC 2617 Authorization header called 'Token' for authenticating requests
> with token-based credentials. Tokens (with optional shared-secret) are
> usually used in place of other credentials (usernames, etc.) and represent
> some combination of scope and authorization. The token method will include
> an extensible signature-based option based on the HMAC-SHA1 method, and a
> bearer token (with optional secret) option based on the PLAINTEXT method.
> The RSA option will be dropped.
>
> 2. OAuth 2.0
>
> A specification based on the browser-redirection flow described in OAuth
> 1.0 as well as new methods defined in WRAP (I-D submission pending). OAuth
> will be redefined to cover the authorization component only, and will no
> longer be bound to a single authentication method. This will make OAuth
> immediately useful for other protocols than HTTP (while HTTP will be used to
> obtain tokens, tokens will be useful in other protocols, not just with the
> HTTP and Token method).
>
> ---
>
> spirit and the understanding reached when we created the working group.
>
> I would like to ask:
>

---

From: John Panzer <[email-masked]>
Date: Mon, 30 Nov 2009 09:49:23 -0800

On Sun, Nov 29, 2009 at 11:34 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> OAuth community. But also because the Plain and MAC versions are based on a
> simple symmetric shared secret, while PK requires more. This means we will
> need to support different types of tokens. While I am open to this if
> needed, it seems to add a significant complexity. Also, part 2 will then
> need to be able to provision both symmetric and asymmetric secrets which
> adds to the complexity there.
>

To clarify:  I think there is significant value to RSA used in (a profile
of?) step 2 in order to bootstrap shared secrets.  This proposal is just
about narrowing the scope of Token Auth to not support public key
signatures, not about dropping RSA more generally, right?

---

From: Brian Eaton <[email-masked]>
Date: Mon, 30 Nov 2009 09:52:08 -0800

> standardizing on RSA in the next revision.

Here's how I'd like to see the public-key vs HMAC vs bearer-token
thing rationalized...

public key: used for bootstrapping trust.  The output of this
bootstrap is a token, and possibly a token secret.
bearer token: simple way of conveying authorization along with requests.
hmac token: higher security way of conveying authorization.

Thoughts on dividing up the problem space in that fashion?  Would it
actually work for most use cases, or do we really need public key
signing on every single request?

Cheers,
Brian

---

From: Richard Barnes <[email-masked]>
Date: Mon, 30 Nov 2009 07:55:07 -1000

Jon,

One technical point: You don't do appreciably more public-key  
operations to do a TLS negotiation as you do to sign an OAuth request,  
since the actual encryption of message is done with a symmetric  
algorithm (RSA is only used to protect the secrets in the negotiation).

--Richard

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 30 Nov 2009 17:57:59 +0000

While I think the general goal seems ok, and perhaps even better,
I do wonder whether its reasonable to re-charter a WG that has
never formally met face to face, nor met any of its current
milestones.

It may be, I'm just not sure, but what's the reason for not
finishing OAuth 1.1 first? (The fact that you "see no value"
doesn't explain it to me at least.)

I also find the following a bit puzzling:

Eran Hammer-Lahav wrote:
> Keep in mind that we are not going to include token structure in scope.
> We are simply proposing a method in which the token is a string, leaving
> it up to other efforts to give it structure if needed.

What other efforts? How would the implementer of an RFC achieve
interoperability? Wouldn't we need to be able to answer that before
proceeding?

> - Is this approach favorable by the group?

Maybe.

> - Do we need to adjust the language in the charter to support?

Definitely IMO. The current charter talks about striving to
maintain backwards compatibility etc.

Ta,
S.

---

From: Brian Eaton <[email-masked]>
Date: Mon, 30 Nov 2009 10:03:19 -0800

On Mon, Nov 30, 2009 at 9:55 AM, Richard Barnes <[email-masked]> wrote:
> One technical point: You don't do appreciably more public-key operations to
> do a TLS negotiation as you do to sign an OAuth request, since the actual
> encryption of message is done with a symmetric algorithm (RSA is only used
> to protect the secrets in the negotiation).

In fact TLS is far cheaper because it caches the results of the
initial RSA negotiation.

Cheers,
Brian

---

From: Richard Barnes <[email-masked]>
Date: Mon, 30 Nov 2009 08:08:02 -1000

Yep.  There are also things like hardware accelerators already out  
there for TLS.

On the other hand, you do save yourself the symmetric crypto if you  
really do just use the RSA signature for authentication.  There may be  
some other advantages (I haven't thought much about it), so I'm not  
eager to write off RSA yet.

--Richard

On Nov 30, 2009, at 8:03 AM, Brian Eaton wrote:

>> operations to

---

From: Richard Barnes <[email-masked]>
Date: Mon, 30 Nov 2009 08:10:46 -1000

It's unclear to me that token values need to be protected or involved  
in the crypto at all.  They're always bound to an identity (of the  
Client/Consumer or the ResourceOwner/User) that the Server should  
authenticate, so there's no additional authentication to be done  
beyond presenting the token to the Server.  Protecting the token from  
theft is also not an issue as long as the Server authenticates the  
requestor, since only an authenticated Client/RO can make use of the  
token.

Suggest just making "token" an opaque field in the authentication.   
That gives us the flexibility to define the token (formats, etc)  
elsewhere, and removes the interaction between tokens and crypto.

--Richard

---

From: Brian Eaton <[email-masked]>
Date: Mon, 30 Nov 2009 10:13:03 -0800

On Mon, Nov 30, 2009 at 10:10 AM, Richard Barnes <[email-masked]> wrote:
> Protecting the token from theft is also not an issue as long as the
> Server authenticates the requestor, since only an authenticated Client/RO
> can make use of the token.

This seems somewhat circular.  How is the requester being
authenticated if not with the token?

---

From: John Kemp <[email-masked]>
Date: Mon, 30 Nov 2009 13:21:54 -0500

> authenticated if not with the token?

Just because a token was earlier presented to something claiming a 
particular identity doesn't mean (without accounting for external 
factors) that the thing presenting the token at this time has the same 
identity as the original token requester.

- johnk

---

From: "Moore, Jonathan (CIM)" <[email-masked]>
Date: Mon, 30 Nov 2009 13:22:24 -0500

Thanks for the technical corrections; I think I failed to make my main
point when I brought up CPU efficiency (although I'd still prefer not to
encrypt my response bodies if I don't have to, even with symmetric
keys...).

I think Richard sums this up nicely, though. For us, the major
advantages of using RSA for authentication only are for
operational/management issues. I find it hard to believe that we'd be
the only organization that preferred exchanging and verifying public
keys with a partner over transmitting shared secrets.

Jon

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Monday, November 30, 2009 1:08 PM
To: Brian Eaton
Cc: Moore, Jonathan (CIM); [email-masked]
Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 /
Charter)

--Richard

---

From: John Kemp <[email-masked]>
Date: Mon, 30 Nov 2009 13:25:13 -0500

Brian Eaton wrote:

> public key: used for bootstrapping trust.

What do you mean by "bootstrapping trust"?

>  The output of this

Is there not some "bootstrapping" here too? Don't I get a token in 
response to something else (username/password?) How is that trust 
conveyed once this bootstrap process is over?

- johnk

---

From: Brian Eaton <[email-masked]>
Date: Mon, 30 Nov 2009 10:36:05 -0800

On Mon, Nov 30, 2009 at 10:25 AM, John Kemp <[email-masked]> wrote:
> particular identity doesn't mean (without accounting for external factors)
> that the thing presenting the token at this time has the same identity as
> the original token requester.

Yep.  I'm wondering whether those "external factors" in fact need to
be built in to OAuth.  I don't think they do.

> What do you mean by "bootstrapping trust"?

I probably should have said "bootstrapping authentication".  What I
mean is that public key cryptography provides a technical foundation
for authenticating entities without having them share a secret in
advance.

That's a common problem, and I think OAuth needs to be compatible with
solutions to that problem.

> Is there not some "bootstrapping" here too? Don't I get a token in response
> to something else (username/password?) How is that trust conveyed once this
> bootstrap process is over?

Sure.  There are lots of ways to bootstrap a token.  Here are some
concrete examples of what I mean:

Username + password: used to boostrap a session cookie (a bearer token)

SAML web single sign on: public-key signed SAML assertion is used to
bootstrap a session cookie.

OAuth 3-legged delegation flow: uses an authorization token + some
sort of client authentication + some sort of end-user authentication
to boostrap an OAuth access token

The common thread in all of these is that the output of the
bootstrapping is a session token of some type.

Cheers,
Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 30 Nov 2009 13:50:57 -0500

Hmm, not a good time to point that out. That part of te protocol turns
out to be problematic

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: Dick Hardt <[email-masked]>
Date: Mon, 30 Nov 2009 19:09:23 +0000

> keys with a partner over transmitting shared secrets.

TLS uses public keys as well. In your original post ...

>  At least in

Do you already have PKI with your partners setup?

I'm surprised you would rather manage your own PKI rather then use SSL. 

-- Dick

---

From: John Kemp <[email-masked]>
Date: Mon, 30 Nov 2009 14:15:18 -0500

> be built in to OAuth.  I don't think they do.

Yes, I think I agree, but we should probably note in the specification 
how these external factors are related, and which ones are pertinent to 
OAuth scenarios.

> solutions to that problem.

Agreed.

> bootstrapping is a session token of some type.

Right - so we start off with one entity being directly authenticated by 
another. This results in the production of a token and optionally a 
method of binding the token to an arbitrary message which may also 
authenticate (essentially independently of the token) the entity 
presenting the token. Would you then also need to allow the association 
of the entity presenting the token with that which acquired the token?

- johnk

---

From: Dick Hardt <[email-masked]>
Date: Mon, 30 Nov 2009 19:24:51 +0000

On 2009-11-30, at 9:15 AM, John Kemp wrote:

> 
> Right - so we start off with one entity being directly authenticated by another. This results in the production of a token and optionally a method of binding the token to an arbitrary message which may also authenticate (essentially independently of the token) the entity presenting the token. Would you then also need to allow the association of the entity presenting the token with that which acquired the token?

In a claims based approach, the Client may only need to prove is is authorized and that the claim is authentic in order to have access to a Protected Resource. The Client may not have identified itself to the Protected Resource. The claim(s) would be contained in the token.

-- Dick

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 30 Nov 2009 12:25:59 -0700

This is a discussion worth having now.

1. We are going to drop some use cases for the sake of simplicity. This will not prevent extensions, and a PK signature method might be something to standardize, but there is a lot more to it to make it useful including key rotation, and the initial exchange of credentials. Obtaining and managing a token-PK pair is more complex than a simple token-secret pair.

2. There is no requirement for 2.0 to support every existing use case for 1.0. This is why I put so much effort into the 1.0 RFC - so you can still use it when appropriate. If 1.0 provides a useful RSA-SHA1 method for doing 2-legged, use it. If it is not sufficient or has problems, we need to know about it. So far, the vast majority of development experience comes from the HMAC-SHA1 method. The RSA method was intentionally underspecified as no one had any real interest in it at the time (except for Google, which since then deployed HMAC as well).

3. I will leave it up to the security experts to figure out if a PK option in the *authentication* spec is worth having, compared to TLS/SSL. OAuth did not require TLS because it was designed to be friendly to small sites looking to deploy an API without having to deal with certificates. The performance overhead wasn't really the main issue, it was practicality. For example, I would like to be able to write a Wordpress plugin that exposes an address book API using OAuth, without being required to enable SSL on my blog.

4. We are still very likely to have a PK-based method for obtaining *authorization* (a token). So PK will be still available for obtaining a token. I know this does not address the 2-legged scenario, but whatever we come up there should be the same with whatever we may end up including in the authentication part.

EHL

> From: Moore, Jonathan (CIM) [mailto:[email-masked]]
> Sent: Monday, November 30, 2009 6:22 AM
> To: Eran Hammer-Lahav; Paul C. Bryan
> Cc: [email-masked]
> Subject: Re: keeping support for RSA (Was: RE: [OAUTH-WG] OAuth 2.0 /
> Charter)
> 
> Ok, I'll ask for it then! Our main use cases for OAuth 1.0 have been for 2-
> legged, server-to-server integrations with known third parties. Public key
> cryptography offers a lot of advantages here in terms of ease of properly
> making a secure association between organizations. At least in our shop, it's
> considerably easier for us to deal with PKI than it is to set up SSL endpoints
> and/or run internal CAs.
> 
> Also, and especially when the response *body* does not require privacy, I'd
> much rather spend my CPU cycles doing public-key cryptography on the HTTP
> headers than encrypting an entire response payload via SSL. I also lose the
> benefits of HTTP intermediaries when I have to tunnel over SSL.
> 
> I'm happy to participate here to work to keep this support in OAuth 2.0 (I'm
> just coming up to speed on the WG here).
> 
> Thanks,
> Jon
> ........
> Jon Moore
> on a simple symmetric shared secret, while PK requires more. This means we
> will need to support different types of tokens. While I am open to this if
> needed, it seems to add a significant complexity. Also, part 2 will then need
> to be able to provision both symmetric and asymmetric secrets which adds to
> the complexity there.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 30 Nov 2009 12:32:10 -0700

The issue with RSA-SHA1-like method isn't the signature or crypto. Those are trivial to spec out. The issue is everything else we didn't cover in 1.0 including key management and rotation, and how to establish it.

We had rough consensus about dropping the client credentials (consumer key) from protected resources requests. This means you may use client credentials to request a token, but once you have the token, you don't need to use the client credentials anymore. The implications of this are that any PK-based method will need to work at the token level, not the client level.

With this approach, it will be easy to include a PK method alongside an HMAC method, but it is not clear how the secret portion of the token pair will be obtained and managed. My limited understanding suggests that issuing a token-secret pair isn't the same as a token-Private Key pair. Maybe I'm wrong and it can be made as trivial.

And no, there will be nothing to prevent such an extension.

EHL

> From: Hans Granqvist [mailto:[email-masked]]
> Sent: Monday, November 30, 2009 9:31 AM
> To: OAuth WG ([email-masked])
> Cc: Eran Hammer-Lahav; Pelle Braendgaard
> It's tricky. If you allow only MACs, you have to forgo no only RSA (and ECC...)
> but also potentially traditional symmetric key schemes -- their usability
> notwithstanding.
> 
> On the other hand, if you try to cover all possible key schemes, it quickly
> becomes unmanageable.
> 
> Eran, is there a way to define what you want and leave it open for, say an
> RSA extension, as long as it can be represented as a string, such as
> {ALGORITHM}:{STRING}, and where any extra protocol flows are out of this
> specification's scope?
> 
> -Hans
> 
> 
> >>> 1. Why drop RSA? It seems some form of public key cryptography will
> >>> be necessary/useful to make web-based-attribute-containing tokens
> >>> Internet- scalable.
> >>
> >>> 2. Is it an objective to have the Token auth-scheme contain
> >>> extension points so that new token formats can be introduced without
> >>> need to redefine the scheme or draft a new one?
> >>
> >> Yes, but see above.
> >>
> >> EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 30 Nov 2009 12:33:15 -0700

SWT is one.

http://groups.google.com/group/oauth-wrap-wg

EHL

From: Greg Brail [mailto:[email-masked]]
Sent: Monday, November 30, 2009 9:35 AM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email-masked])
Subject: RE: OAuth 2.0 / Charter

Thanks for the clarification.

I do think that a standard token structure would be a good thing for the Internet in general. Is there another effort I should be following regarding the token structure itself?

________________________________
From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Monday, November 30, 2009 2:36 AM
To: Greg Brail
Cc: OAuth WG ([email-masked])
Subject: RE: OAuth 2.0 / Charter

EHL

                                                            greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Sunday, November 29, 2009 2:59 AM
To: Peter Saint-Andre ([email-masked]); Lisa Dusseault ([email-masked])
Cc: OAuth WG ([email-masked])
Subject: [OAUTH-WG] OAuth 2.0 / Charter

2. OAuth 2.0

---

I would like to ask:

EHL

OAuth mailing list

---

From: Dick Hardt <[email-masked]>
Date: Mon, 30 Nov 2009 19:57:05 +0000

> 3. I will leave it up to the security experts to figure out if a PK option in the *authentication* spec is worth having, compared to TLS/SSL. OAuth did not require TLS because it was designed to be…

Are there implementations of Wordpress plugins using OAuth? ie., was there a real market need for this, or just a perceived need?

If you don't have SSL on your blog management endpoint, then your blog credentials are being transported in the clear. I don't have SSL on my Wordpress blogs, and I'm ok with the risk given the tradeoffs. It seems like many other people are as well currently. 

While I agree it is desirable to improve security, is there real demand for it? 

In choosing where to put efforts, would it be "better" to drive down the barriers to deploying SSL?

-- Dick

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 30 Nov 2009 12:58:51 -0700

<hat type='chair'/>

> While I think the general goal seems ok, and perhaps even better,

I do think it is worthwhile to have a discussion about the proper
"general goal" for this WG, especially given the changing landscape
regarding OAuth[-ish] technologies.

> never formally met face to face, 

The chairs take responsibility for the lack of a meeting, but I can
guarantee you that the group will meet at IETF 77.

> nor met any of its current
> milestones.

Given that the WG was chartered on May 13, it was perhaps a bit
aggressive to "Submit 'OAuth: HTTP Authorization Delegation Protocol' as
working group item" in Apr 2009. :)

Based on list discussion in May and June, we came to consensus to split
draft-hammer-oauth into two specifications, which Eran did in early
July, resulting in draft-ietf-oauth-authentication and
draft-ietf-oauth-web-delegation as WG items. We've had quite a bit of
discussion about those on the list, but it seems to me that the
discussion here and elsewhere has led to a desire for something more
than a simple, backwards-compatible specification of "OAuth 1.1" as
described in the charter. In particular, the scope of "OAuth 1.1"
appears to have been limited to improving terminology, embodying good
security practices, promoting interoperability, and providing guidelines
for extensibility.

> doesn't explain it to me at least.)

I agree that we need to get the reasons out on the table so that we can
have an open discussion about problems and objectives.

> interoperability? Wouldn't we need to be able to answer that before

Those are good questions.

> maintain backwards compatibility etc.

The charter also says:

  However, changes that are not backwards
  compatible might be accepted if the group determines that
  the changes are required to meet the group's technical
  objectives and the group clearly documents the reasons for
  making them.

That implies the need to, above all, clarify the group's technical
objectives. IMHO the problem statement is not fully clear in the
existing charter, and furthermore it appears that some people now might
be trying to solve related but somewhat different problems with OAuth
(or something similar enough to OAuth that it can retain the name). That
might be either exciting or worrisome, depending on your perspective.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 30 Nov 2009 13:06:05 -0700

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Monday, November 30, 2009 9:58 AM
> To: Eran Hammer-Lahav
> While I think the general goal seems ok, and perhaps even better, I do
> wonder whether its reasonable to re-charter a WG that has never formally
> met face to face, nor met any of its current milestones.

This is a valid concern.

I personally consider face to face meetings to be over rated and hardly ever worth the effort. Meetings are great for people involved in many IETF efforts, but I believe the majority of active WG members are not likely to travel more than a couple hours for a 2-hour meeting. Of course, this is all up to the chair to decide.

> It may be, I'm just not sure, but what's the reason for not finishing OAuth 1.1
> first? (The fact that you "see no value"

The people who cared most about this approach didn't really bother to show up to the table. The 1.0 community for the most part has shown no interest in this work or the value of it (patching up 1.0). I am not interest in working on 1.1 as an editor or otherwise. It would be a waste of my time. I think the question is, who here is interested in finishing 1.1 as currently chartered? Also, who is going to implement it?

Instead, I spend a significant effort to clean up 1.0 and make it useful and presentable for those wishing to use it. I think that in order to fix OAuth and reach the right balance of security and interop, we need a different approach that is not backward compatible. I never cared much for the backward compatibility argument, which proved to be wrong when 50 companies upgraded their OAuth implementation practically overnight when a security problem was found.

> > We are simply proposing a method in which the token is a string,
> > leaving it up to other efforts to give it structure if needed.
> 

No. The current model isn't changing, and tokens are still being issued by the server. Therefore, only the server needs to understand its structure and no interop is affected. Extending the model to self-issued tokens is certainly possible but outside the proposed scope. It would be vastly premature to standardize token structures at this point.

EHL

---

From: Prateek Mishra <[email-masked]>
Date: Mon, 30 Nov 2009 15:06:43 -0500

Would a SAML assertion be an example of a "standard token structure"?
> *From:* Greg Brail [mailto:[email-masked]]
> *Sent:* Monday, November 30, 2009 9:35 AM
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG ([email-masked])
> *Subject:* RE: OAuth 2.0 / Charter
>
> I do think that a standard token structure would be a good thing for 
> the Internet in general. Is there another effort I should be following 
> regarding the token structure itself?
>
> ------------------------------------------------------------------------
>
> *From:* Eran Hammer-Lahav [mailto:[email-masked]]
> *Sent:* Monday, November 30, 2009 2:36 AM
> *To:* Greg Brail
> *Cc:* OAuth WG ([email-masked])
> *Subject:* RE: OAuth 2.0 / Charter
>
> Keep in mind that we are not going to include token structure in 
> scope. We are simply proposing a method in which the token is a 
> string, leaving it up to other efforts to give it structure if needed.
>
> EHL
>
> *From:* Greg Brail [mailto:[email-masked]]
> *Sent:* Sunday, November 29, 2009 9:05 PM
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG ([email-masked])
> *Subject:* RE: OAuth 2.0 / Charter
>
> I’ve been following this discussion for a while now as a relative 
> newcomer and I think this is a great idea. Forgive me if all you guys 
> have reached this conclusion already:
>
> · As a “more secure” replacement for username / password 
> authentication in web services APIs like Amazon’s
>
> · As a way for the developer of an API to understand which developer’s 
> applications are being used against the API, when it is less important 
> to identify the actual user (for instance, the classical “API key” use 
> case, or “two-legged OAuth”)
>
> · As a way for the developer of a mobile app to ensure that only that 
> app can make use of a particular web service, even if it is not 
> important to identify the actual user
>
> · Lots of others I’m sure I’m missing
>
> The sooner there is some movement towards a standard “token,” the 
> sooner we will have token support in a variety of programming 
> environments. Plus, a standard token will reduce the propensity of web 
> services builders to design their own tokens, with varying levels of 
> security.
>
> Plus, the OAuth flow has clearly proven to be useful and it deserves 
> to be a standard that makes use of the standard token.
>
> On the design of the token itself, I hope that it will have a place 
> for one, two, or even more combinations of keys and secrets, so that 
> it can handle simple use cases, more complex use cases such as OAuth, 
> and even those that require three or more separate identifiers for a 
> request.
>
> greg
>
> requests with token-based credentials. Tokens (with optional 
> shared-secret) are usually used in place of other credentials 
> (usernames, etc.) and represent some combination of scope and 
> authorization. The token method will include an extensible 
> signature-based option based on the HMAC-SHA1 method, and a bearer 
> token (with optional secret) option based on the PLAINTEXT method. The 
> RSA option will be dropped.
>
> 2. OAuth 2.0
>
> [email-masked] <mailto:[email-masked]>
>
> ------------------------------------------------------------------------
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 30 Nov 2009 13:40:09 -0700

> From: Dick Hardt [mailto:[email-masked]]
> Sent: Monday, November 30, 2009 11:57 AM
> To: Eran Hammer-Lahav
> Cc: Moore, Jonathan (CIM); Paul C. Bryan; [email-masked]
> > 3. I will leave it up to the security experts to figure out if a PK option in the
> *authentication* spec is worth having, compared to TLS/SSL. OAuth did not
> require TLS because it was designed to be friendly to small sites looking to
> deploy an API without having to deal with certificates. The performance
> overhead wasn't really the main issue, it was practicality. For example, I
> would like to be able to write a Wordpress plugin that exposes an address
> book API using OAuth, without being required to enable SSL on my blog.
> 
> Are there implementations of Wordpress plugins using OAuth? ie., was there
> a real market need for this, or just a perceived need?

Everything I'm working on or involved in (discovery, webfinger, portable contacts, content sharing, etc.) is heading this way. It is critical that OAuth will not create a barrier to entry for these technologies. For example, we are now discussing how to manage access to machine-readable profiles for people in webfinger. This technology will only work if it is easily available to self-hosted sites that deserve to be able to implement the same protocols the big guys get to push.

> If you don't have SSL on your blog management endpoint, then your blog
> credentials are being transported in the clear. I don't have SSL on my
> Wordpress blogs, and I'm ok with the risk given the tradeoffs. It seems like
> many other people are as well currently.
> 

This is clearly outside the scope of this work... :-)

I doubt this will become simpler and cheaper anytime soon.

The bottom line is that the new proposal separate the two, allowing people who plan to use SSL across the board to focus on the other stuff. If OAuth 1.0 requires SSL, it will accomplish nothing but a fork in the community and two competing solutions. Instead, my proposal makes it modular and allows everyone to play along.

EHL

---

From: John Panzer <[email-masked]>
Date: Mon, 30 Nov 2009 12:49:27 -0800

On Mon, Nov 30, 2009 at 12:40 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> Everything I'm working on or involved in (discovery, webfinger, portable
> contacts, content sharing, etc.) is heading this way. It is critical that
> OAuth will not create a barrier to entry for these technologies. For
> example, we are now discussing how to manage access to machine-readable
> profiles for people in webfinger. This technology will only work if it is
> easily available to self-hosted sites that deserve to be able to implement
> the same protocols the big guys get to push.
>
> The bottom line is that the new proposal separate the two, allowing people
> who plan to use SSL across the board to focus on the other stuff. If OAuth
> 1.0 requires SSL, it will accomplish nothing but a fork in the community and
> two competing solutions. Instead, my proposal makes it modular and allows
> everyone to play along.
>

I agree with Eran's point that requiring TLS for OAuth "authentication"
(Token, in 2.0 proposal) to work would be a nonstarter and I would vote
against it.

However, this is a bit of a straw man, since that's not what Dick suggested.
 He suggested that TLS need not be required for all OAuth scenarios and I
also agree with that.

So, I'm in the happy position of agreeing with everyone on this thread!

---

From: Ben Laurie <[email-masked]>
Date: Mon, 30 Nov 2009 13:10:21 -0800

> Hmm, not a good time to point that out. That part of te protocol turns

Actually not. Renegotiation is problematic. Session resumption is not.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 30 Nov 2009 14:17:07 -0700

During the charter discussions and earlier during the BOF discussions, the consensus was that any effort to address the general problem from scratch was doomed. The IETF and other bodies have a very poor track record of successfully creating new security technologies with wide adoption. OAuth represented a rare opportunity of using the community work to bootstrap a standards track effort.

Different people take that to mean different things. For some, the goal should be to rubber stamp 1.0 or as close to that as possible. To others, this means taking whatever they feel is the core component of the protocol and reusing it (from the signature methods to the web-redirection flow).

To me, the most useful part of OAuth for the purpose of creating new work is the model, not the technical details. This is not to imply that the model is better than others, just that we have consensus on that, and it is the hardest part to agree on. The OAuth model includes some specific choices:

1. Resource owner credentials are not shared with third parties. Instead, a token is used to represent a specific access scope.
2. Tokens are issued by the server, not by the resource owner. OAuth tokens are treated as opaque strings, and while structured tokens are possible, they are external to the model.
3. Token authentication does not require SSL/TLS, but is fully compatible with it.

I would strongly caution this working group from reopening these basic elements as it is more likely to lead to a forking of this effort than any successful specification. OAuth's greatest value is the compromise it represents in its design. Give up that and we are back to square one. I have no interest in starting from scratch or a different base technology.

The main issue with the current charter is the backward-compatibility section, not the 1.1 label. It would be a mockery of process and common sense to justify each of the proposed changes as required for security and interoperability and worth breaking compatibility. None of this matters once we change a single thing, and we already know we are going to.

My proposal doesn't change the core model. It cleans up the authentication part by simplifying it and making it more extensible and it proposes to extend the set of available methods to obtain a token from a single redirection-based process to a few other options.

We can certainly stretch the existing charter by using our mandate to create a new authenticate scheme and focus on that, calling it Token Authentication. Then we can have this discussion about how much to add to the single delegation method provided. I leave this up to the chair to decide what is best.

My focus is now on producing a draft for the Token Authentication method which is very much in line with the charter and based on WG discussions from a couple of months ago.

EHL

> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Monday, November 30, 2009 11:59 AM
> To: Stephen Farrell
> Cc: Eran Hammer-Lahav; OAuth WG ([email-masked])

---

From: John Panzer <[email-masked]>
Date: Mon, 30 Nov 2009 13:46:19 -0800

FWIW, I agree with Eran's three point model, and on not re-debating these
core ideas absent some compelling reason.  My take on the strategy that
motivates them: OAuth's intent is to provide a simple, scalable,
interoperable web API auth mechanism that both services and other open
standards will build upon.  It also raises the current bar for interoperable
auth from the current state of the practice.  Non-backwards-compatible
changes are warranted if they are necessary to meet these goals (and of
course detailed technical justifications need to be provided as well.)

On Mon, Nov 30, 2009 at 1:17 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> During the charter discussions and earlier during the BOF discussions, the
> consensus was that any effort to address the general problem from scratch
> was doomed. The IETF and other bodies have a very poor track record of
> successfully creating new security technologies with wide adoption. OAuth
> represented a rare opportunity of using the community work to bootstrap a
> standards track effort.
>
> Different people take that to mean different things. For some, the goal
> should be to rubber stamp 1.0 or as close to that as possible. To others,
> this means taking whatever they feel is the core component of the protocol
> and reusing it (from the signature methods to the web-redirection flow).
>
> To me, the most useful part of OAuth for the purpose of creating new work
> is the model, not the technical details. This is not to imply that the model
> is better than others, just that we have consensus on that, and it is the
> hardest part to agree on. The OAuth model includes some specific choices:
>
> 1. Resource owner credentials are not shared with third parties. Instead, a
> token is used to represent a specific access scope.
> 2. Tokens are issued by the server, not by the resource owner. OAuth tokens
> are treated as opaque strings, and while structured tokens are possible,
> they are external to the model.
> I would strongly caution this working group from reopening these basic
> elements as it is more likely to lead to a forking of this effort than any
> successful specification. OAuth's greatest value is the compromise it
> represents in its design. Give up that and we are back to square one. I have
> no interest in starting from scratch or a different base technology.
>
> The main issue with the current charter is the backward-compatibility
> section, not the 1.1 label. It would be a mockery of process and common
> sense to justify each of the proposed changes as required for security and
> interoperability and worth breaking compatibility. None of this matters once
> we change a single thing, and we already know we are going to.
>
> My proposal doesn't change the core model. It cleans up the authentication
> part by simplifying it and making it more extensible and it proposes to
> extend the set of available methods to obtain a token from a single
> redirection-based process to a few other options.
>
> We can certainly stretch the existing charter by using our mandate to
> create a new authenticate scheme and focus on that, calling it Token
> Authentication. Then we can have this discussion about how much to add to
> the single delegation method provided. I leave this up to the chair to
> decide what is best.
>
> My focus is now on producing a draft for the Token Authentication method
> which is very much in line with the charter and based on WG discussions from
> a couple of months ago.
>
> EHL
>
>
> scope.
> leaving

---

From: Brian Eaton <[email-masked]>
Date: Mon, 30 Nov 2009 13:53:09 -0800

On Mon, Nov 30, 2009 at 11:25 AM, Eran Hammer-Lahav <[email-masked]> wrote:
>
> 4. We are still very likely to have a PK-based method for obtaining *authorization* (a token). So
> PK will be still available for obtaining a token. I know this does not address the 2-legged
> scenario, but whatever we come up there should be the same with whatever we may end
> up including in the authentication part.

This does actually address the two-legged scenario quite nicely.

Client sends PK-signed message to Authorization Server.
Authorization Server returns token.
Client uses token.

Cheers,
Brian

---

From: Brian Eaton <[email-masked]>
Date: Mon, 30 Nov 2009 13:56:32 -0800

On Mon, Nov 30, 2009 at 11:25 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> 1. We are going to drop some use cases for the sake of simplicity. This will not prevent
> extensions, and a PK signature method might be something to standardize, but there i
> a lot more to it to make it useful including key rotation, and the initial exchange of
> credentials.

In my experience, most SAML deployments use self-signed keys, with
out-of-band key management.  Not having automated key management is
not a barrier to adoption of public key, nor does it make public key
useless.

> Obtaining and managing a token-PK pair is more complex than a simple
> token-secret pair.

This I agree with 100%.

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 30 Nov 2009 14:58:38 -0700

I think what most people miss about this is that addition of a new method to obtain a *token* without a third party (resource owner, etc.) present. So instead of the current way OAuth is used for 2-legged, as a dumb substitution for Basic auth, this new approach works the same way across the two use cases (2, 3-legged), by always requiring the exchange of credentials for a token, even for 2-legged.

And as stated above, this will require some other means to obtain a token without the use of browser redirection and user authorization.

EHL

> From: Brian Eaton [mailto:[email-masked]]
> Sent: Monday, November 30, 2009 1:53 PM
> To: Eran Hammer-Lahav
> > 4. We are still very likely to have a PK-based method for obtaining
> > *authorization* (a token). So PK will be still available for obtaining
> > a token. I know this does not address the 2-legged scenario, but
> > whatever we come up there should be the same with whatever we may
> end up including in the authentication part.
>

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 30 Nov 2009 19:22:54 -0500

First, I second Jonathan's motion.

I thought that we had discussed this issue, and it appeared to me that 
there was an agreement on the necessity of the signatures. Then I raised 
the issue of limiting ourselves to RSA (vs. ECC or other public-key 
mechanisms), and there was a good discussion of this subject, too. I 
thought that the outcome of it was that we keep RSA mandatory and, in 
addition, allow other mechanisms. Maybe I have misinterpreted the 
outcome of that discussion?

Igor

Moore, Jonathan (CIM) wrote:
>> so that new token formats can be introduced without need to redefine
>>     
> the
>

---

From: Pelle Braendgaard <[email-masked]>
Date: Mon, 30 Nov 2009 22:08:34 -0500

I agree completely with these steps as well. While OAuth has had a few
implementation difficulties that I think Eran has done a good job of
fixing in the revised 1.0 spec there is a clear danger for OAuth 2.0
to stray to much from the original ideas.

If we add too many different variations and features into the standard
we risk becoming WS-deathstar 2.0 and no small developers will deal
with it.

Of course our respective companies all have specific use cases we
would like to implement like me wanting to keep some sort of generic
model for asymmetric signing in the standard. It would really help us
by not including those in the base standard and having various
extensions outside.

For example as much as I don't like the OAuth Session Extension for
the additional complexity it adds for developers, I am much happier
with it being an extension where a vendor decides if they are willing
to add a complexity tax for their client developers. It is their
choice.

If for the sake of simplicity it would be better create some kind of
simple optional public key signing into an extension, then I would be
for it.

So as a general approach keep it simple.

Pelle

I think the idea of splitting the standard up in two as suggested
really helps this approach.

---

From: Leah Culver <[email-masked]>
Date: Mon, 30 Nov 2009 20:16:52 -0800

> we risk becoming WS-deathstar 2.0 and no small developers will deal
http://www.dailymotion.com/video/x6woyj_death-star-over-san-francisco_travel

---

From: Pelle Braendgaard <[email-masked]>
Date: Mon, 30 Nov 2009 23:32:15 -0500

I'm in agreement with this as well. We should not attempt any kind of
key management or anything here, but some kind of method of signing
which would theoretically work with any public/private key signing
solution. Once the pattern for RSA is defined is there it would just
mean changing over the signature type parameter for future algorithms.

P

On Mon, Nov 30, 2009 at 7:22 PM, Igor Faynberg
<[email-masked]> wrote:
> I thought that we had discussed this issue, and it appeared to me that there
> was an agreement on the necessity of the signatures. Then I raised the issue
> of limiting ourselves to RSA (vs. ECC or other public-key mechanisms), and
> there was a good discussion of this subject, too. I thought that the outcome
> of it was that we keep RSA mandatory and, in addition, allow other
> mechanisms. Maybe I have misinterpreted the outcome of that discussion?
>
> Igor
>
>
>