Subject: [oauth] OAuth only for HTTP request signing?

From: Onyx Raven <[email-masked]>
Date: Thu, 5 Feb 2009 10:12:36 -0700

I see the following line in the ITEF charter:

 * A mechanism for signing HTTP requests with the token-secret pair

Is the 'core' OAuth specification going to be limited only to HTTP, or
is there opportunity and reason to make it a general method of signing
method, resource and parameters of a programmatic request for the
purpose of consumer authorization and user credential delegation?

It seems like other protocols could use the same signing and
delegation methodology (probably with some hybrid using HTTP), but may
not be 'traditional' HTTP (eg, XMPP
http://xmpp.org/extensions/xep-0235.html) during requests. Or, would
the 'extensions' go the other way, defining how other protocols might
use the same methods, or in a generic sense?

I guess I wonder if defining only HTTP and not calling out generic
usage could make using OAuth in other areas somewhat more difficult
from a standards perspective.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 5 Feb 2009 13:08:07 -0700

While I can certainly appreciate the usefulness of making OAuth
protocol-agnostic, this must stay outside the scope of this WG.

The OAuth signature workflow is completely HTTP based. The HTTP method,
host, and dereferenced URI are used to build the base string. The token
exchange workflow defines an HTTP interaction.

My main objection to even considering this, is the fact that without fully
understanding the security context of the protocol, we will not be able to
address it. Trying to apply the principals of OAuth to other protocols is
simply not practical. This suggests that for XMPP to use an OAuth-like
protocol, it needs to define its own binding.

The only useful aspect of OAuth to other protocols is allowing them to use
access tokens (and secrets) for accessing resources. There is nothing in the
current spec to prevent that. It would be impractical for us to address
that.

EHL

---

From: Tom Scavo <[email-masked]>
Date: Thu, 5 Feb 2009 14:19:52 -0600

On Thu, Feb 5, 2009 at 2:08 PM, Eran Hammer-Lahav <[email-masked]> wrote:
>
> Trying to apply the principals of OAuth to other protocols is

Indeed, SAML has profiled the "SimpleSign" binding:

http://wiki.oasis-open.org/security/SimpleSignBinding

SimpleSign is similar to OAuth, if only in spirit.

Tom

---

From: Seth Fitzsimmons <[email-masked]>
Date: Thu, 5 Feb 2009 12:52:10 -0800

> exchange workflow defines an HTTP interaction.

I beg to differ on the signature workflow.  The base string is
constructed of *a* method (e.g. 'iq') and something standing in for a
URI (either an actual URI or something resembling
[email-masked][email-masked]').  Beyond those substitutions, the
rest of the signature generation is exactly the same.

XMPP (XEP-0235) assumes that tokens are exchanged out of band, leaving
that mechanism in HTTP.

> protocol, it needs to define its own binding.

How do you mean 'binding'?

> current spec to prevent that. It would be impractical for us to address

To me, the most useful aspect of OAuth when applied to other protocols
is a clearly defined way to generate signatures given constituent
components.

seth

---

From: John Kemp <[email-masked]>
Date: Thu, 5 Feb 2009 16:21:50 -0500

> XMPP (XEP-0235) assumes that tokens are exchanged out of band, leaving

Right. The point being that there are at least two potentially- 
independent parts to OAuth - a set of signature mechanisms (RSA-SHA1,  
HMAC-SHA1, PLAINTEXT), and an HTTP-based protocol for token exchange.

[...]

> is a clearly defined way to generate signatures given constituent

I think it's certainly reasonable to suggest that the signature  
mechanisms be defined so as to be useful in contexts other than HTTP.  
Which apparently already worked well-enough for XMPP with OAuth 1.0.

- johnk

---

From: Onyx Raven <[email-masked]>
Date: Thu, 5 Feb 2009 14:37:47 -0700

So, thats what I was trying to get at.  I agree that the excepted
token consumer-request -> sp-auth -> consumer-access process should be
HTTP based as it is defined now.  It was really more about the
consumer -> sp request signing (with delegated access), which like
below, could be XMPP, IRC, proprietary game protocols, etc.  At a
basic level, signature signing is defined as
METHOD&RESOURCE&PARAMETERS (where parameters are key/value pairs
structured in www-form-urlencoded style).

But like I said before, as long as the core standard has acceptable
wording for other consumer -> sp request protocols to hook into, thats
what matters there.  I just wanted to be sure we didn't get locked
into something we might want alternatives to in the future.

On Thu, Feb 5, 2009 at 2:21 PM, John Kemp <[email-masked]> wrote:
> Right. The point being that there are at least two potentially-independent
> parts to OAuth - a set of signature mechanisms (RSA-SHA1, HMAC-SHA1,
> PLAINTEXT), and an HTTP-based protocol for token exchange.
>
> [...]
>
>>
> I think it's certainly reasonable to suggest that the signature mechanisms
> be defined so as to be useful in contexts other than HTTP. Which apparently
> already worked well-enough for XMPP with OAuth 1.0.
>
> - johnk
>

---

From: Onyx Raven <[email-masked]>
Date: Thu, 5 Feb 2009 14:39:56 -0700

Sorry, I got ahead of myself about the signature/signing -
METHOD&RESOURCE&PARAMETERS, hashed with one of the accepted methods
(RSA-SHA1, HMAC-SHA1, PLAINTEXT).

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 5 Feb 2009 14:44:13 -0700

> How do you mean 'binding'?

What to put in the each of the string components, how to send the signature
and parameters, etc. The SBS 'method' in Core 1.0 is well defined to be an
HTTP method, uppercase, etc. Does XMPP uses HTTP methods?

My objection is purely from security perspective. If the security experts in
the room want to take a different position, I'll defer to them. But my
assumption is that we are looking specifically at HTTP and how HTTP requests
can be made securely (under the conditions defined by this use case).

I know little of XMPP, as one example, to say that its characteristics are
similar enough to HTTP to have the same security considerations.

In addition, it is unclear to me that OAuth is the appropriate approach to
delegation in XMPP and other protocols. It *was not* developed with such use
cases in mind.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 5 Feb 2009 14:50:47 -0700

The fact the signature base string today is compatible with XMPP (but taking a liberal view of the workflow), is mostly luck. It just happened that a solution that was optimized for HTTP seems to work well for XMPP with some clarifications.

It is very likely that we will be defining a new signature method. If non-HTTP considerations will make it any more complex than it has to be, I will find it problematic. If it doesn't, great. I am happy to allow the charter to "review the applicability of existing and new signature methods to protocols other than HTTP", but that is where I think we should draw a line.

The charter should allow a signature method that does not support XMPP, if it makes HTTP better. In other words, I am against putting any other protocol at equal consideration as HTTP.

EHL

On 2/5/09 1:37 PM, "Onyx Raven" <[email-masked]> wrote:

---

From: Will Norris <[email-masked]>
Date: Thu, 5 Feb 2009 13:58:28 -0800

Eran,

Is the plan to put the existing SBS stuff in IETF OAuth Core or in a  
separate HTTP binding?  Perhaps that would be a reasonable compromise,  
leaving OAuth Core protocol agnostic.  Of course, the WG could only be  
responsible for creating the HTTP binding, not any other protocol.   
But it would leave OAuth Core flexible enough to support future  
protocol bindings in the future without modification.

Or am I missing something?

-will

On Feb 5, 2009, at 1:50 PM, Eran Hammer-Lahav wrote:

> The fact the signature base string today is compatible with XMPP  
> (but taking a liberal view of the workflow), is mostly luck. It just  
> happened that a solution that was optimized for HTTP seems to work  
> well for XMPP with some clarifications.
>
> It is very likely that we will be defining a new signature method.  
> If non-HTTP considerations will make it any more complex than it has  
> to be, I will find it problematic. If it doesn't, great. I am happy  
> to allow the charter to "review the applicability of existing and  
> new signature methods to protocols other than HTTP", but that is  
> where I think we should draw a line.
>
> The charter should allow a signature method that does not support  
> XMPP, if it makes HTTP better. In other words, I am against putting  
> any other protocol at equal consideration as HTTP.
>
> EHL
>
>
>> independent
>> mechanisms
> _______________________________________________
> oauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 5 Feb 2009 15:08:52 -0700

The proposal is to the OAuth Core 1.0, bring it to IETF security standards,
make interop better defined, and be done. The closer we stay to Core 1.0 the
better (as long as security and interop are not compromised). That is the
general idea, at least my reasons for starting this effort.

It seems silly to me to try and separate the transport from the protocol,
given this protocol was explicitly created to address shortcomings in the
HTTP transport.

Security and interop dictates a tightly defined relationship to the
transport layer.

EHL

---

From: Seth Fitzsimmons <[email-masked]>
Date: Thu, 5 Feb 2009 14:22:22 -0800

> HTTP method, uppercase, etc. Does XMPP uses HTTP methods?

No, but the XEP slots in message types in its place (iq / message).
We were looking at method as "verb" or "action".  HTTP methods are
typically uppercase, hence that particular normalization.

Any chance we could aim to create a generic SBS (e.g.
verb&context&parameters) and define a binding for HTTP only (leaving
bindings to other protocols up to them)?

> similar enough to HTTP to have the same security considerations.

Leaving "parameters" open allows other protocols to designate which
core parameters are necessary (e.g. nonce/timestamp aren't necessary
assuming TLS for XMPP, but they're in there because that assumption
can't be made).  Certainly security considerations will define the
binding, but needn't be part of the core.

> delegation in XMPP and other protocols. It *was not* developed with such use

Sure, it was coincidental, but that it was possible was due to the
perceived flexibility of the signature base string.

Do you consider the definition of the signing process part of the
protocol, the transport, or something else?

seth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 5 Feb 2009 16:31:23 -0700

> bindings to other protocols up to them)?

Aim, sure. Define it as a goal or requirement of the WG in the charter... I
rather not. If we do, it should be a non-binding goal to allow other
transport binding for using OAuth token-secret pairs in other protocols.

If someone wants to offer a language for the charter with regard to such
non-binding approach, I would be happy to consider.

> protocol, the transport, or something else?

Well, I consider it as a replacement/addition to RFC 2617. If you consider
2617 part of HTTP, than I consider OAuth part of the transport. If you
consider 2617 closer to the application layer, I'm ok with that too.

In other words, I consider OAuth as an HTTP specific protocol. So I don't
really need to define it in a modular with respect to other transports.
Within the HTTP use case, I still consider it modular where the way you
obtain an Access Token is separate from how to authenticate using that
token.

EHL

---

From: Hubert Le Van Gong <[email-masked]>
Date: Fri, 6 Feb 2009 09:39:03 +0100

Although it could be interesting to have the signature mechanism made protocol
agnostic, I agree with your approach. However as mentioned previously, the
OAuth Core 1.0 is composed of 2 independent components (the protocol
and the signature mechanism).

I would propose to target 2 separate documents, one being the OAuth protocol
and the other one addressing security mechanisms (i.e. the signature mech).

There are several initiatives out there that either contemplate or have already
chosen to adopt the OAuth signature mechanism since it fulfills a void in the
current HTTP world.

Does this seem reasonable?

Cheers,
Hubert

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 6 Feb 2009 09:43:13 -0700

I am extremely hesitant to make this an official charter request but this was exactly my plan when I submitted draft-hammer-oauth. At the time I assumed this will be an Informational track individual submission.

The thing is, if you break the spec into two documents, what you are end up creating is:

1. An alternative to RFC 2617
2. An extension to 2617 for delegation

If you bundle them into a single document, #1 becomes less official as a direct alternative to 2617, even though some people may choose to use it that way (which is currently the case with deployment of 2-legged OAuth).

The fear is that if we charter this work to produce two documents, we position OAuth as a replacement to 2617. If we charter this work to produce one document, we position OAuth as an extension of 2617 that is use-case specific. While this might sound like silly semantic games, it is actually very important.

Replacement of 2617 has a much wider scope than the current OAuth charter. It brings in a lot more requirements, and at the same time, opens the door to a much greater deviation from Core 1.0. If we focus on the delegation use case, we may or may not come up with a 2-legged solution that will be acceptable to the security community as a replacement of 2617. But it will be acceptable for this specific use case.

If we focus on first replacing 2617, we will have to accept the likelihood of further breaking away from Core 1.0 - something a majority of people here strongly objected to. This was also the general agreement at the OAuth BoF (not replacing 2617, but that competition is not necessarily a bad thing).

EHL

> -----Original Message-----
> From: Hubert Le Van Gong [mailto:[email-masked]]
> Sent: Friday, February 06, 2009 12:39 AM
> To: Eran Hammer-Lahav
> Cc: Will Norris; Onyx Raven; [email-masked]
> Subject: Re: [oauth] OAuth only for HTTP request signing?
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 17 Feb 2009 10:48:23 +0200

I am happy to add text that says something like "The applicability of
existing and new signature methods to protocols other than HTTP will be
investigated."

However, I am reluctant to extend the current charter text to
potentially unknown protocols. Even new XMPP extensions regarding OAuth
cannot be developed within this group. 

I think that the statement above is the best we can do. If someone has
the time and the energy to look at various other protocols where OAuth
could be used with then I am sure the group would be happy about any
feedback of potential problems, which can then be dealt with. 

Ciao
Hannes

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Eran Hammer-Lahav
	Sent: 05 February, 2009 23:51
	To: Onyx Raven; John Kemp
	Cc: [email-masked]
	Subject: Re: [oauth] OAuth only for HTTP request signing?

	The fact the signature base string today is compatible with XMPP
(but taking a liberal view of the workflow), is mostly luck. It just
happened that a solution that was optimized for HTTP seems to work well
for XMPP with some clarifications.
	
	It is very likely that we will be defining a new signature
method. If non-HTTP considerations will make it any more complex than it
has to be, I will find it problematic. If it doesn't, great. I am happy
to allow the charter to "review the applicability of existing and new
signature methods to protocols other than HTTP", but that is where I
think we should draw a line.
	
	The charter should allow a signature method that does not
support XMPP, if it makes HTTP better. In other words, I am against
putting any other protocol at equal consideration as HTTP.
	
	EHL

		So, thats what I was trying to get at.  I agree that the
excepted
		token consumer-request -> sp-auth -> consumer-access
process should be
		HTTP based as it is defined now.  It was really more
about the
		consumer -> sp request signing (with delegated access),
which like
		below, could be XMPP, IRC, proprietary game protocols,
etc.  At a
		basic level, signature signing is defined as
		METHOD&RESOURCE&PARAMETERS (where parameters are
key/value pairs
		structured in www-form-urlencoded style).
		
		But like I said before, as long as the core standard has
acceptable
		wording for other consumer -> sp request protocols to
hook into, thats
		what matters there.  I just wanted to be sure we didn't
get locked
		into something we might want alternatives to in the
future.