Subject: Re: [oauth] OAUTH Charter Proposal

From: George Fletcher <[email-masked]>
Date: Mon, 02 Feb 2009 08:47:00 -0500

Not wanting to start a huge debate... but within the OAuth community 
we've made the distinction between Authentication and Authorization, 
with OAuth being an API Authorization protocol and leaving 
Authentication out of scope.

Is this charter planning to tackle authentication as well as 
authorization? The statement...
> OAuth consist of:
>   * A mechanism for exchanging a user's credentials for a token-secret pair
>   
has me a little confused.  I would word this as...

* A mechanism that allows a user to authorize API access via a 
token-secret pair

Thanks,
George

Hannes Tschofenig wrote:
> Hi all, 
>
> After a chat with Lisa I got in touch with Eran to slightly revise the
> charter text that Sam and Mark put together for the last IETF meeting.
>
> It should addresses some of the comments provided during the BOF. Your
> feedback is welcome. 
>
> Ciao
> Hannes
>
> -------------------------------------
>
> Open Authentication Protocol (oauth)
>
> Last Modified: 2009-01-30
>
> Chair(s):
>
> TBD
>
> Applications Area Director(s):
>
> Chris Newman <[email-masked]> 
> Lisa Dusseault <[email-masked]> 
>
> Applications Area Advisor:
>
> TBD
>
> Mailing Lists:
>
> https://www.ietf.org/mailman/listinfo/oauth
>
> Description of Working Group:
>
> OAuth allows a user to grant a third-party Web site or application access to
> their resources, without revealing their credentials, or even their
> identity. For example, a photo-sharing site that supports OAuth would allow
> its users to use a third-party printing Web site to access their private
> pictures, without gaining full control of the user account.
>
> OAuth consist of:
>   * A mechanism for exchanging a user's credentials for a token-secret pair
> which can be used by a third party to access resources on their behalf
>   * A mechanism for signing HTTP requests with the token-secret pair
>
> The Working Group will produce one or more documents suitable for
> consideration as Proposed Standard, based upon the OAuth I-D, that will:
>   * Align OAuth with the Internet and Web architectures, best practices and
> terminology
>   * Assure good security practice, or document gaps in its capabilities
>   * Promote interoperability
>
> This specifically means that as a starting point for the working group the
> OAuth 1.0 specification is used and the  
> available extension points are going to be utilized. It seems desireable to
> profile OAuth 1.0 in a way that produces a specification that is a backwards
> compatible profile, i.e. any OAUTH 1.0 and the specification produced by
> this group must support a basic set of features to guarantee
> interoperability. 
>
> Furthermore, Oauth 1.0 defines three signature methods used to protect
> requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on
> new signature methods in case the existing mechanisms do not fulfill the
> security requirements. Existing signature methods will not be modified but
> may be dropped as part of the backwards compatible profiling activity.
>
> In doing so, it should consider:
>   * Implementer experience
>   * Existing uses of OAuth
>   * Ability to achieve broad impementation
>   * Ability to address broader use cases than may be contemplated by the
> original authors
>   * Impact on the Internet and Web
>
> The Working Group is not tasked with defining a generally applicable HTTP
> Authentication mechanism (i.e., browser-based "2-leg" scenerio), and should
> consider this work out of scope in its discussions. However, if the
> deliverables are able to be factored in such a way that this is a byproduct,
> or such a scenario could be addressed by additional future work, the Working
> Group may choose to do so.
>
> After delivering OAuth, the Working Group MAY consider defining additional
> functions and/or extensions, for example 
> (but not limited to):
>   * Discovery of authentication configuration
>   * Message integrity
>   * Recommendations regarding the structure of the token 
>
> Goals and Milestones:
>
> 12/2009     Submit document(s) suitable for publication as standards-track
> RFCs.
>
> _______________________________________________
> oauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>   
_______________________________________________
oauth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Hubert Le Van Gong <[email-masked]>
Date: Mon, 2 Feb 2009 15:24:27 +0100

Hi Hannes,

Thanks for updating the charter. Some comments below.

"It seems desireable to profile OAuth 1.0 in a way that produces
a specification that is a backwards compatible profile, i.e. any
OAUTH 1.0 and the specification produced by this group must
support a basic set of features to guarantee interoperability."

- Profiling usually means to constrain further an existing specification.
  This seems to contradict the part of the charter that talks of
  supporting broader use cases beyond the original scope...?
  What did you mean there?

- I would argue that there is no guaranteed interoperability in the
  current OAuth 1.0 spec. We need to address this. The security report
  Sam (Hartman) created highlights a few things that should
  be done:
  (1) mandatory-to-implement algorithm(s) for security
  (2) interoperable way to find the lifetime of a request or
      access-token
  (3) description of how a service uses OAuth

I had the same comment as George just sent on AuthZ vs. AuthN

Cheers,
Hubert

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 2 Feb 2009 16:33:41 +0200

Sounds good to me. 

Thanks, George. 

>-----Original Message-----
>From: George Fletcher [mailto:[email-masked]] 
>Sent: 02 February, 2009 15:47
>To: Hannes Tschofenig
>Cc: [email-masked]
>Subject: Re: [oauth] OAUTH Charter Proposal
>
>Not wanting to start a huge debate... but within the OAuth 
>community we've made the distinction between Authentication 
>and Authorization, with OAuth being an API Authorization 
>protocol and leaving Authentication out of scope.
>
>>   * A mechanism for exchanging a user's credentials for a 
>token-secret 
>> pair
>>   
>> OAuth allows a user to grant a third-party Web site or application 
>> access to their resources, without revealing their credentials, or 
>> even their identity. For example, a photo-sharing site that supports 
>> OAuth would allow its users to use a third-party printing 
>Web site to 
>> access their private pictures, without gaining full control 
>of the user account.
>>
>> OAuth consist of:
>>   * A mechanism for exchanging a user's credentials for a 
>token-secret 
>> pair which can be used by a third party to access resources 
>on their behalf
>>   * Align OAuth with the Internet and Web architectures, best 
>> practices and terminology
>> This specifically means that as a starting point for the 
>working group 
>> the OAuth 1.0 specification is used and the available 
>extension points 
>> are going to be utilized. It seems desireable to profile 
>OAuth 1.0 in 
>> a way that produces a specification that is a backwards compatible 
>> profile, i.e. any OAUTH 1.0 and the specification produced by this 
>> group must support a basic set of features to guarantee 
>> interoperability.
>>
>> requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will 
>> work on new signature methods in case the existing mechanisms do not 
>> fulfill the security requirements. Existing signature 
>methods will not 
>> be modified but may be dropped as part of the backwards 
>compatible profiling activity.
>>
>>   * Ability to address broader use cases than may be contemplated by 
>> the original authors
>> The Working Group is not tasked with defining a generally applicable 
>> HTTP Authentication mechanism (i.e., browser-based "2-leg" 
>scenerio), 
>> and should consider this work out of scope in its discussions. 
>> However, if the deliverables are able to be factored in such a way 
>> that this is a byproduct, or such a scenario could be addressed by 
>> additional future work, the Working Group may choose to do so.
>>
>> After delivering OAuth, the Working Group MAY consider defining 
>> additional functions and/or extensions, for example (but not limited 
>> to):

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 2 Feb 2009 16:50:50 +0200

Hi Hubert, 

>"It seems desireable to profile OAuth 1.0 in a way that 
>produces a specification that is a backwards compatible 
>profile, i.e. any OAUTH 1.0 and the specification produced by 
>interoperability."

When multiple options are provided then indicating which onces are mandatory
to implement is something that I call profiling. When the profiled version
is run against Oauth 1.0 it would still interoperate (in some sense; if that
particular Oauth 1.0 implementation had implemented all options). You
mention this aspect of improving interoperability in your next paragraph
below as well. 

The sentence about "Ability to address broader use cases than may be
contemplated by the original authors" can be more seen as a "we leave room
for extensions that offer additional use cases" phrase.

>  (3) description of how a service uses OAuth

These things sound good to me. I guess you don't want to list them in the
charter itself, right? 

Ciao
Hannes

>> pair which can be used by a third party to access resources on their 
>> behalf
>practices 
>> and terminology

---

From: Hubert Le Van Gong <[email-masked]>
Date: Mon, 2 Feb 2009 16:14:07 +0100

Hi Hannes,

Thanks for the clarification; I understand what was meant.
I would note however that this paragraph mixes 2 distinct
issues: backward compatibility and interoperability.
We want to promote both but not necessarily at the
expense of one of them (and security as well).
For instance, it is recommended that at least one security
algorithm is made mandatory. If we mandate backward
compatibility then that algorithm can only be one of the
algorithms already defined in OAuth 1.0 which, as noted
in older email threads, is not a good idea.
IMHO ensuring interoperability & good security of the
to-be IETF spec is, in fine, paramount to ensuring
100% backward compatibility (of course a solution
could be to mandate at least 2 security algos, one from
the 1.0 spec and another more future-proof).

These considerations may not need to appear in
the charter but I think it is important to be as clear
as possible on the intent of the charter.

Cheers,
Hubert

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 2 Feb 2009 09:15:05 -0700

How is exchanging credentials equal to authentication?

I would not want to use the term API in the charter. While this is the current use case, I view OAuth as part of the 2617 family, and can be used for any HTTP request. I do not think most people consider every HTTP request an API call.

EHL

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of George Fletcher
> Sent: Monday, February 02, 2009 5:47 AM
> To: Hannes Tschofenig
> Cc: [email-masked]
> access to
> practices and
> work on
> the
> HTTP
> additional

---

From: Blaine Cook <[email-masked]>
Date: Mon, 2 Feb 2009 16:42:36 +0000

> How is exchanging credentials equal to authentication?

By exchanging the credentials in a verifiable way (i.e., with secrets
& signing), you're authenticating the consumer as acting on behalf of
the user. If we weren't trying to do *authenticated* requests, then
there wouldn't be any point in hiding (or having) secrets.

> I would not want to use the term API in the charter. While this is the current use case, I view OAuth as part of the 2617 family, and can be used for any HTTP request. I do not think most people co…

+1 - perhaps the more general "Interface" makes sense? I think OAuth
is actually a bit more general than 2617, in that it's possible to use
it across transport protocols (though in general we should be
targeting HTTP first).

b.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 2 Feb 2009 10:01:19 -0700

Of course you are authenticating the credentials, but the spec does not tell you how to do it. Following this logic, every spec in the world with dependency on authentication will fall under this category...

OAuth says "go get yourself authenticated and come back with something useful". The method in which the user authenticate against the Service Provider is completely out of scope. But obviously OAuth includes authentication in other areas such as authenticating tokens and potentially the identity of the Consumer and Service Provider (see Sam's review).

This continues debate regarding authz/n is silly. OAuth currently does not specify how to authenticate the end user. But it might (not likely in core) in the future, for example, if it supports structured tokens with self signing capabilities (the user can produce tokens and hand them over to the Consumer without SP involvement, but the ability to authenticate them). In this case the user technically authenticate itself via a certificate and the verification is delegated on from the Consumer to the Service Provider.

We need to separate the marketing from the technical architecture.

EHL

> From: Blaine Cook [mailto:[email-masked]]
> Sent: Monday, February 02, 2009 8:43 AM
> To: Eran Hammer-Lahav
> Cc: [email-masked]
> > I would not want to use the term API in the charter. While this is
> the current use case, I view OAuth as part of the 2617 family, and can
> be used for any HTTP request. I do not think most people consider every
> HTTP request an API call.
>

---

From: kellan <[email-masked]>
Date: Mon, 2 Feb 2009 12:02:32 -0500

George's concern that we not position ourselves as an AuthN
specification mirrors my own.

Also, when we talk about extensibility points we're talking about the
If-Not-Forbidden pattern, yes?

Lastly, and I'll admit this is a dumb question, is the inconsistent
capitalization to convey information, or are we still just in an early
draft?

-kellan

---

From: John Kemp <[email-masked]>
Date: Mon, 2 Feb 2009 12:09:06 -0500

> there wouldn't be any point in hiding (or having) secrets.

Right - we specify, for example, HMAC signing methods, used to ensure  
that the consumer and SP know the same key. The interesting discussion  
perhaps is about who is being authenticated, and by whom, at each point.

>> the current use case, I view OAuth as part of the 2617 family, and  
>> can be used for any HTTP request. I do not think most people  
>> consider every HTTP request an API call.
>

I agree, and would add that the RFC 2617-compatible mechanism we  
specified in OAuth 1.0 conveys more information than that pertaining  
only to the authentication of the user (behind the user-agent).

For now, it might be wise to be clear that we are unclear when  
describing this work ;)

- johnk

---

From: Blaine Cook <[email-masked]>
Date: Mon, 2 Feb 2009 17:48:56 +0000

On Mon, Feb 2, 2009 at 5:09 PM, John Kemp <[email-masked]> wrote:
> Right - we specify, for example, HMAC signing methods, used to ensure that
> the consumer and SP know the same key. The interesting discussion perhaps is
> about who is being authenticated, and by whom, at each point.

Having discussed this with a couple of people off-list, it seems to me
like the words "authentication" and "authorization" have too much
baggage associated with them to be of use in clearly defining what
OAuth is. I'm sure there are words for this stuff, but I like Eran's
comment the best:

"OAuth is a goddamn delegation protocol"

I'm happy using whatever terminology, and fully agree with John that
we should be clear that we are unclear on this. Which is totally fine,
and ultimately we know what we're trying to do, so nit-picking the
language isn't useful.

< concerns rescinded >

b.

---

From: George Fletcher <[email-masked]>
Date: Mon, 02 Feb 2009 13:05:04 -0500

> This continues debate regarding authz/n is silly. OAuth currently does not specify how to authenticate the end user. But it might (not likely in core) in the future, for example, if it supports str…
+1 to structured tokens

Does this need to get called out in the charter as a specific desire? Or 
do we just ensure it isn't precluded in the work that's done?

Thanks,
George

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Feb 2009 11:57:52 -0800

I think it is imnportant to discuss the charter here because the hardest part of this whole problem is working out what we are actually trying to achieve and arriving at consensus that we are all talking about the same thing.
 
We do not have to develop an authentication protocol for OAuth but we do need to understand what an authentication protocol does and what is meant by an authorization protocol.

Another feature of the discussion is that there are parts of OAUTH that people now want to use simply as platform and that has implications. Lots of people are talking about the need to sign pieces of http headers.

I don't think we need yet another Internet authentication protocol. 
 
What we do however need, and in particular I think OAuth requires to be explicable to lay people, is a uniform identifier to represent the party being authenticated and a standard human-readable presentation thereof.
 
Otherwise I fear that we will end up with yet more middle-ware that does not quite meet up at either end.

So let the user be authenticated by SAML, WS-Trust, HTTP-Auth, OpenID or whatever. But there has to be a clearly defined mental model of what that means.
 
Lets take SAML as a starting point since it has a consistent nomenclature that has considerable consensus.

We have an authentication protocol, that delivers a SAML assertion.
 
Regardless of what the specification might say, the actual semantics of a SAML authentication assertion (and indeed any delegated mechanism) are 'here is a partywhich I have authenticated as X by reference to mechanism Y which you can verifty by reference to credential Z."
 
In other words, the use of delegated authentication does not in fact remove the need for authentication, it merely changes the type of credential that the relying party is going to use.

Now one problem we punted on in SAML, that I now regret is the question of what the user identifier would be. This was left to the individual authentication federation. Which I view as a mistake because it means that we lack two critical pieces that are necessary to make the system work.
 
The first is discovery, say Alice is identfied by SSQW:eurtu.org/20/[email-masked]
 
That is a perfectly legal SAML identifier. Which is a problem. We left far too many options which would not have been so bad if we had made it very clear that there was a very strong preference for one particular form when we are dealling with users in an internet context.
 
       <saml:NameIdentifier
         Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
         [email-masked]
       </saml:NameIdentifier>

Now if we had only said use email addresses, and only email addresses we would have been only one step away from universal log-in.

All SAML is missing is an SRV identifier for locating an authentication server for a given identifier. If that is in place alice can use [email-masked] as her login identifier on any site whatsoever and the site can then go out and find that there is a SAML authentication assertion service at idp.example.com.
 
So if we simply say to all the authentication protocols out there that they can work with OAuth, if and only if they
 
1) Use an email address format identifier
2) Specify an SRV based discovery mechanism
 
That would of course mean that the group might well have to write a document describing the SRV bindings for a number of existing protocols that are out there, or rather for subsets of such protocols. But that is the general requirement for a new group.

We can argue about the precise shape of the box (i.e. the discovery mechanism, the identifier to be used) but I don't think we should argue about the need for such a box or the need to leave stuff out.
 
There are at least 4 different general purpose authentication frameworks out there and because they are all designed to be meta and all designed to be interoperable you can actually create cycles within cycles just like there are folk who run VMWare Linux in a VM Ware Windows in a VMWare Linux. 

After that, we can get down to the much harder problem of working out what an OAuth token should be called. Contrary to discussion in the group, I do not think it maps cleanly onto any concept in the existing nomenclature. Whch is probably why the discussion turns circular.
 
Moreover, folk should remember that this is a concept that was botched in pretty much every operating system design, especially UNIX. I don't know of any O/S which allows a user to easily and cleanly set up an access rule of the form 'Sendmail can manage mail on behalf of Fred' without granting more access than is necessary for the limited task. These schemes inevitably use the big hammer of root privilege which does not exist on the net. The problem is not that hard, it is unsolved because it was not necessary to solve it earlier.
 
What we are talking about here is a limited delegation of authority.
 
There are different ways of implementing a delegation of authority. One is to establish a new user account with the specified authentication access and privileges, the second is to add an ACL to the resource in question allowing a specified party to gain access.
 
Depending on which method of implementaion you chose, the OAuth statement will appear to be authorization or Authentication. But it is neither, it is a delegation of authority. If we try to call it authorization we end up having to find a new name for ACLs.

.

________________________________

From: [email-masked] on behalf of George Fletcher
Sent: Mon 2/2/2009 8:47 AM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [oauth] OAUTH Charter Proposal

Thanks,
George

---

From: Bill de hOra <[email-masked]>
Date: Mon, 02 Feb 2009 23:01:32 +0000

> It should addresses some of the comments provided during the BOF. Your

+1. My only concern is interop around the signing methods. Usually this 
requires a MUST for at least one signing mechanism.

Bill

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 5 Feb 2009 21:50:28 +0200

Hi Phillip, 
 
your mail has a lot of interesting thoughts about the history of SAML. 

To make my work easier, do you think we can improve the charter text
somehow? 

Ciao
Hannes

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Hallam-Baker, Phillip
	Sent: 02 February, 2009 21:58
	To: George Fletcher; Hannes Tschofenig
	Cc: [email-masked]
	Subject: Re: [oauth] OAUTH Charter Proposal

	I think it is imnportant to discuss the charter here because the
hardest part of this whole problem is working out what we are actually
trying to achieve and arriving at consensus that we are all talking about
the same thing.
	 
	We do not have to develop an authentication protocol for OAuth but
we do need to understand what an authentication protocol does and what is
meant by an authorization protocol.

	Another feature of the discussion is that there are parts of OAUTH
that people now want to use simply as platform and that has implications.
Lots of people are talking about the need to sign pieces of http headers.

	 
	What we do however need, and in particular I think OAuth requires to
be explicable to lay people, is a uniform identifier to represent the party
being authenticated and a standard human-readable presentation thereof.
	 
	Otherwise I fear that we will end up with yet more middle-ware that
does not quite meet up at either end.

	So let the user be authenticated by SAML, WS-Trust, HTTP-Auth,
OpenID or whatever. But there has to be a clearly defined mental model of
what that means.
	 
	Lets take SAML as a starting point since it has a consistent
nomenclature that has considerable consensus.

	Regardless of what the specification might say, the actual semantics
of a SAML authentication assertion (and indeed any delegated mechanism) are
'here is a partywhich I have authenticated as X by reference to mechanism Y
which you can verifty by reference to credential Z."
	 
	In other words, the use of delegated authentication does not in fact
remove the need for authentication, it merely changes the type of credential
that the relying party is going to use.

	Now one problem we punted on in SAML, that I now regret is the
question of what the user identifier would be. This was left to the
individual authentication federation. Which I view as a mistake because it
means that we lack two critical pieces that are necessary to make the system
work.
	 
	The first is discovery, say Alice is identfied by
SSQW:eurtu.org/20/[email-masked]
	 
	That is a perfectly legal SAML identifier. Which is a problem. We
left far too many options which would not have been so bad if we had made it
very clear that there was a very strong preference for one particular form
when we are dealling with users in an internet context.
	 
	       <saml:NameIdentifier

	Now if we had only said use email addresses, and only email
addresses we would have been only one step away from universal log-in.

	All SAML is missing is an SRV identifier for locating an
authentication server for a given identifier. If that is in place alice can
use [email-masked] as her login identifier on any site whatsoever and the
site can then go out and find that there is a SAML authentication assertion
service at idp.example.com.
	 
	So if we simply say to all the authentication protocols out there
that they can work with OAuth, if and only if they

	That would of course mean that the group might well have to write a
document describing the SRV bindings for a number of existing protocols that
are out there, or rather for subsets of such protocols. But that is the
general requirement for a new group.

	We can argue about the precise shape of the box (i.e. the discovery
mechanism, the identifier to be used) but I don't think we should argue
about the need for such a box or the need to leave stuff out.
	 
	There are at least 4 different general purpose authentication
frameworks out there and because they are all designed to be meta and all
designed to be interoperable you can actually create cycles within cycles
just like there are folk who run VMWare Linux in a VM Ware Windows in a
VMWare Linux. 

	After that, we can get down to the much harder problem of working
out what an OAuth token should be called. Contrary to discussion in the
group, I do not think it maps cleanly onto any concept in the existing
nomenclature. Whch is probably why the discussion turns circular.
	 
	Moreover, folk should remember that this is a concept that was
botched in pretty much every operating system design, especially UNIX. I
don't know of any O/S which allows a user to easily and cleanly set up an
access rule of the form 'Sendmail can manage mail on behalf of Fred' without
granting more access than is necessary for the limited task. These schemes
inevitably use the big hammer of root privilege which does not exist on the
net. The problem is not that hard, it is unsolved because it was not
necessary to solve it earlier.

	There are different ways of implementing a delegation of authority.
One is to establish a new user account with the specified authentication
access and privileges, the second is to add an ACL to the resource in
question allowing a specified party to gain access.
	 
	Depending on which method of implementaion you chose, the OAuth
statement will appear to be authorization or Authentication. But it is
neither, it is a delegation of authority. If we try to call it authorization
we end up having to find a new name for ACLs.

	.

	
token-secret pair

	Thanks,
	George

access to
token-secret pair
practices and
additional