Subject: Re: [OAUTH-WG] why are we signing?

From: John Panzer <[email-masked]>
Date: Tue, 1 Dec 2009 08:52:40 -0800

On Mon, Nov 30, 2009 at 2:32 PM, Mike Malone <[email-masked]> wrote:

> On Mon, Nov 30, 2009 at 11:17 AM, Dick Hardt <[email-masked]>
> wrote:
> >
> > On 2009-11-13, at 7:21 AM, Eran Hammer-Lahav wrote:
> >>
> >> I for one, see great value in offering some form of crypto-based
> security for cases where TLS is not suitable.
> >
> > Are these use cases enumerated somewhere?
>
> I'm not completely opposed to the TLS route, but since you asked...
> off the top of my head, here are a couple drawbacks to using TLS
> instead of signing:
>  - Bigger burden on developers who need to debug this stuff (i.e.,
> you can't sniff your own traffic to debug requests & responses).
>  - Properly setting up TLS can be complicated and expensive. For
> developers who don't have a lot of ops skills the barrier may be too
> high.
>  - You can no longer pass around signed URLs as another level of
> delegation (a use case that I use regularly for making XHR & POST
> requests from the browser). This could be a non-issue if some other
> mechanism for fourth-party delegation existed.
>
> Can you elaborate on the above?  For OAuth, signatures (bound to a
particular Consumer Secret that can't be leaked to subcontractors) is a
barrier to multi-level delegation.

> If we were coming up with a more secure replacement for browser-based
> HTTP basic auth (and looking at Aza Raskin's work with identity in
> Firefox, OAuth in the browser doesn't appear to be that far off) would
> you want to mandate that all auth'd HTTP traffic use TLS? Not sure if
> the answer is yes or no, but I'm guessing many of the
> advantages/drawbacks will be the same.
>
> Mike
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Mike Malone <[email-masked]>
Date: Tue, 1 Dec 2009 10:22:38 -0800

> barrier to multi-level delegation.

Right, but you can do poor-man's delegation by signing a URL and
passing it off to a third (er, fourth) party to use. I've seen this
most often with web apps, where the app (the OAuth Consumer) wants to
make a request to the Provider directly from the browser (e.g.,
POSTing a large file). They can't sign the URL in javascript without
compromising the Consumer Secret, so the the URL is signed server side
and passed to the browser for use.

Mike

---

From: John Panzer <[email-masked]>
Date: Tue, 1 Dec 2009 10:34:05 -0800

> and passed to the browser for use.

That's the reverse (proxy authorization) -- the client is relying on the
proxy to do the signing, and the proxy has to figure out based on other
stuff (browser cookies, magic incantations) whether _its_ client is
authorized.  This is the OAuth Proxy model.

I thought you were talking about being able to get user consent for service
X to do something, but then service X sub-contracts out some of the work to
service Y, perhaps run by a separate organization.  Y can call-back to X to
do its work, neatly defeating some of the purpose of sub-contracting work
out as everything flows through X anyway.  Or X could hand a signed URL to
Y, but then Y can only deal with what was actually signed, and can't vary
the parameters, again defeating much of the purpose of subcontracting.
 Also, isn't there a nonce in there?  So Y can only make one call with that
URL before returning to the well.

It'd be much better to (in an extension!) be able to say "Give me a token
just like the one I have, but read-only, and only valid for 3 minutes, and
I'm going to let another service use it" and get a restricted token to hand
off to a sub-contractor[1].

In any case, I don't see how signing the URL helps with doing something
along these lines, and I think if it does anything at all it hurts (because
of inclusion of things like nonces and timestamps).  Yeah, there are some
basic use cases for it, like getting access to a read-only feed (capability
URLs) but those can be accomplished quite as well and more simply with
bearer tokens IMHO.

John

[1] I am going on strike and refusing to go beyond "third party" as there
are actually an infinite number of parties and use cases here and I can't
keep them straight any more.

---

From: Dick Hardt <[email-masked]>
Date: Tue, 1 Dec 2009 18:52:40 +0000

Thanks for the response Mike,  comments inline ... 

On 2009-11-30, at 12:32 PM, Mike Malone wrote:

> On Mon, Nov 30, 2009 at 11:17 AM, Dick Hardt <[email-masked]> wrote:
>> 
>>> I for one, see great value in offering some form of crypto-based security for cases where TLS is not suitable.
>> 

These sound barriers to a developer using TLS as opposed to use cases where TLS is not suitable.

OAuth 1.0A has similar burdens compared to getting the user's username and password.
- find a library for OAuth for your platform and install it (which may not be possible in a shared hosting environment)
- acquire a Consumer Key and Secret and store it somewhere secure

> mechanism for fourth-party delegation existed.

I don't understand this use case. Would you be able to provide a pointer to a description somewhere?

---

From: Mike Malone <[email-masked]>
Date: Tue, 1 Dec 2009 11:01:37 -0800

> authorized.  This is the OAuth Proxy model.

Yea sort of. It's proxying the signing, but it's not proxying the
actual request.

> URL before returning to the well.

All true. The use case where this becomes incredibly useful (despite
the limitations you mentioned) is for allowing file uploads from the
browser without the Consumer proxying everything. Since OAuth doesn't
sign a multipart/form-data body you can vary that without a problem.
And since the file upload typically takes some time, asking the
Consumer for a signed URL for each request isn't much of a burden.

> off to a sub-contractor[1].

Yes. I want that.

> URLs) but those can be accomplished quite as well and more simply with

Yea, an extension would be nice. I guess what I'm saying is that
whatever we do moving forward should at least keep the basic level of
delegation we have, however naive and broken it is, because it's
useful.

> keep them straight any more.

Thank god.

Mike

---

From: George Fletcher <[email-masked]>
Date: Tue, 01 Dec 2009 14:21:20 -0500

In addition to the use case Mike gave, I have seen at least two other 
use cases of having the "proxy" sign the URL and then present over HTTP.
1. an iGoogle gadget that wants to launch an iframe with a URL that 
carries specific identity & authorized rights
2. a rich/desktop application want to launch a browser in an 
authenticated/authorized state (i.e. client-to-browser SSO)

I also haven't seen anyone bring up the "restricted device" use case 
yet:) I do work with a product team that refuses to use SSL because of 
the memory, load time, and CPU requirements. Curious if any in the 
mobile device environment see the requirement of SSL an issue? 
Potentially not given most devices these days have a browser.

Thanks,
George

---

From: Brian Eaton <[email-masked]>
Date: Tue, 1 Dec 2009 15:31:38 -0800

On Tue, Dec 1, 2009 at 11:21 AM, George Fletcher <[email-masked]> wrote:
> In addition to the use case Mike gave, I have seen at least two other use
> cases of having the "proxy" sign the URL and then present over HTTP.
> 1. an iGoogle gadget that wants to launch an iframe with a URL that carries
> specific identity & authorized rights

OK, so now we're up to 7 (8?) different use cases where "OAuth"
signatures are being used.  Some others are listed here:

http://www.ietf.org/mail-archive/web/oauth/current/msg00544.html

... most of them still inventing their own signature base strings,
which I find either amusing or tragic depending on my mood. =)

> I also haven't seen anyone bring up the "restricted device" use case yet:) I
> do work with a product team that refuses to use SSL because of the memory,
> load time, and CPU requirements.

So what do these folks deem to be acceptable, security-wise?

(I'll put my money on "short-lived bearer token that is automatically
refreshed at intervals"... =)

> Curious if any in the mobile device
> environment see the requirement of SSL an issue? Potentially not given most
> devices these days have a browser.

I hear this now and again, but every time I've looked at it seriously
it's turned out to be a non-issue.

Cheers,
Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 01 Dec 2009 19:58:10 -0700

<hat type='individual'/>

On 11/30/09 1:27 PM, Eran Hammer-Lahav wrote:
> OAuth is being proposed as a generally useful method for securing API
> calls. I expect many open source libraries to implement it on the
> server side and use it for blog plugins, widgets, and other highly
> distributed software. If OAuth required the use of TLS, it would
> simply be ignored by all those applications which will likely
> continue using Basic.
> 
> With all due respect to big companies, their resources, and ability
> to effortlessly deploy SSL/TLS, it is still an expensive and complex
> process for more developers deploying small scale server components.

With all due respect, I think it can be harder for big companies to
deploy TLS -- they have a lot more users, need more hardware (special
SSL accelerators and the like), have more layers of employees (so it can
be more difficult to find the person who controls the hostmaster or
whois-listed email address), etc.

Getting a Class 1 cert from the likes of StartSSL is easy as pie these
days. IMHO there is no excuse for not deploying SSL if you care one whit
about security. The problem is that too many small-scale developers (and
big companies!) simply don't care.

Peter

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 1 Dec 2009 20:08:45 -0700

> -----Original Message-----
> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Tuesday, December 01, 2009 6:58 PM
> To: Eran Hammer-Lahav
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); ext Dick Hardt; [email-masked]
> Subject: Re: [OAUTH-WG] why are we signing?
> 
> <hat type='individual'/>
> 

Either way you are making my point, sorta.

> big companies!) simply don't care.

Don't care, don't need that much security, don't understand it, etc. Bottom line is that requiring SSL is certain to fork this work if not done right.

And BTW, I was the one arguing for mandating SSL in 1.0 when obtaining tokens. I lost.

EHL

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 01 Dec 2009 20:11:54 -0700

<hat type='individual'/>

On 12/1/09 8:08 PM, Eran Hammer-Lahav wrote:
> 
>> -----Original Message----- From: Peter Saint-Andre
>> [mailto:[email-masked]] Sent: Tuesday, December 01, 2009 6:58
>> PM To: Eran Hammer-Lahav Cc: Tschofenig, Hannes (NSN - FI/Espoo);
>> ext Dick Hardt; [email-masked] Subject: Re: [OAUTH-WG] why are we
>> signing?
>> 
>> <hat type='individual'/>
>> 
>>> OAuth is being proposed as a generally useful method for securing
>>> API calls. I expect many open source libraries to implement it on
>>> the server side and use it for blog plugins, widgets, and other
>>> highly distributed software. If OAuth required the use of TLS, it
>>> would simply be ignored by all those applications which will
>>> likely continue using Basic.
>>> 
>>> With all due respect to big companies, their resources, and
>>> ability to effortlessly deploy SSL/TLS, it is still an expensive
>>> and complex process for more developers deploying small scale
>>> server components.
>>  deploy TLS -- they have a lot more users, need more hardware
>> (special SSL accelerators and the like), have more layers of
>> employees (so it can be more difficult to find the person who
>> controls the hostmaster or whois-listed email address), etc.
> 
>> Getting a Class 1 cert from the likes of StartSSL is easy as pie
>> these days. IMHO there is no excuse for not deploying SSL if you
>> care one whit about security. The problem is that too many
>> small-scale developers (and big companies!) simply don't care.
> 
> Don't care, don't need that much security, don't understand it, etc.
> Bottom line is that requiring SSL is certain to fork this work if not
> done right.

o/~ don't know much about security... o/~

> obtaining tokens. I lost.

Right, because people are lazy.

In any case, if the big companies take the lead and require encrypted
connections, then everyone else will follow. This is more of a cultural
issue than a technical issue.

Peter

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

---

From: Brian Eaton <[email-masked]>
Date: Tue, 1 Dec 2009 19:46:37 -0800

> Don't care, don't need that much security, don't understand it, etc. Bottom line is that requiring SSL is certain to fork this work if not done right.

Note, however, that someone who can't get SSL working and still
deploys OAuth has basically no security against eavesdroppers or MITM
attacks, and certainly can't expect OAuth to provide it.  The issues
are in the token issuance phase: these organizations are sending user
passwords and session cookies in clear text!  OAuth is the least of
their security concerns,

(Wearing my security geek hat, I think it's pretty reasonable for some
people to refuse to deploy SSL.  It's a business choice.  Security is
about managing risk, and in some cases the cost of getting SSL working
just isn't worth it.  And I'm completely fine with those folks
deploying OAuth without SSL as well.  There's no sense in putting a
bullet proof door on a house made of straw.)

Cheers,
Brian

---

From: Dick Hardt <[email-masked]>
Date: Wed, 2 Dec 2009 05:51:14 +0000

> passwords and session cookies in clear text!  OAuth is the least of

If the cost of SSL outweighs the risk of a security breach, then why would a developer deploying OAuth choose to sign their messages rather then use the simpler bearer token?

Peter Saint-Andre questioned why SSL was required in OAuth WRAP. I think that is a good question. Perhaps it should be RECOMMENDED, and deployments can make their own benefit analysis.

-- Dick

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 1 Dec 2009 23:04:23 -0700

<smiling but not joking>

I would like to make an official request to the chair for a consensus call on recommending SSL but keeping it optional in the various OAuth components. We can figure out how strong to make the language (or how scary), and we may make it mandatory in some flows/profiles, but I would like to be done with this discussion (for the n time).

If someone will want to raise new arguments, well, this is the IETF so who can stop them? :-)

EHL

> From: Dick Hardt [mailto:[email-masked]]
> Sent: Tuesday, December 01, 2009 9:51 PM
> To: Brian Eaton
> Cc: Eran Hammer-Lahav; Peter Saint-Andre; <[email-masked]>;
> Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
> Bottom line is that requiring SSL is certain to fork this work if not done right.
> >
> If the cost of SSL outweighs the risk of a security breach, then why would a
> developer deploying OAuth choose to sign their messages rather then use
> the simpler bearer token?
> 
> Peter Saint-Andre questioned why SSL was required in OAuth WRAP. I think
> that is a good question. Perhaps it should be RECOMMENDED, and
> deployments can make their own benefit analysis.
> 
> -- Dick

---

From: John Panzer <[email-masked]>
Date: Tue, 1 Dec 2009 22:39:55 -0800

I am not sure what the practical impact will be, but for what it's worth I
support the concept of recommending TLS (SHOULD, not MUST) in general, and
also the concept of moving forward.

Side note:  In prior IETF standards efforts I've been involved with, having
very specific spec language proposals to get consensus around was helpful.
 In this case that'd be premature but I think that getting to the point
where we can start doing that would help bring these discussions to closure
earlier, and make it stick.   (To change a prior consensus, new specific
language would need to be drafted that replaces the old language, and that
would need a new consensus; this is a much higher bar than just passively
opposing something).

Side note 2:  RFC 5023 (AtomPub) has a pair of paragraphs that are
pertinent, though you may need a standards wonk to interpret them properly.
 In many ways they're a cry for help :) :

> The type of authentication deployed is a local decision made by the server
> operator. Clients are likely to face authentication schemes that vary across
> server deployments. At a minimum, client and server implementations *must* be
> capable of being configured to use HTTP Basic Authentication [RFC2617]<#RFC2617> in
> conjunction with a connection made with TLS 1.0[RFC2246] <#RFC2246> or a
> subsequent standards-track version of TLS (such as [RFC4346] <#RFC4346>),
> supporting the conventions for using HTTP over TLS described in [RFC2818]<#RFC2818>
> .
>
> The choice of authentication mechanism will impact interoperability. The
> minimum level of security referenced above (Basic Authentication with TLS)
> is considered good practice for Internet applications at the time of
> publication of this specification and sufficient for establishing a baseline
> for interoperability. Implementers are encouraged to investigate and use
> alternative mechanisms regarded as equivalently good or better at the time
> of deployment. It is *recommended* that clients be implemented in such a
> way that new authentication schemes can be deployed.
>

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

On Tue, Dec 1, 2009 at 10:04 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> <smiling but not joking>
>
> I would like to make an official request to the chair for a consensus call
> on recommending SSL but keeping it optional in the various OAuth components.
> We can figure out how strong to make the language (or how scary), and we may
> make it mandatory in some flows/profiles, but I would like to be done with
> this discussion (for the n time).
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Dec 2009 09:48:27 +0000

I think we'll need an analysis of where we end up wanting TLS
for the protocols we produce. I wouldn't expect any big
surprises, but right now I don't think we can be sure since
things seems to be in flux to some extent.

Then, I'd be for saying that TLS MUST be used for those operations.
However, I can well believe that there may be some niches where
using TLS isn't easy, so I could live with something like: it MUST
be possible to use TLS, and that deployments SHOULD use it, with
guidance as to the type of scenario where we think TLS really
has to be turned on, and maybe text about why sometimes people
can't do that.

So I don't think we can finish this discussion at this stage.

S.

---

From: Prateek Mishra <[email-masked]>
Date: Wed, 02 Dec 2009 10:18:52 -0500

Stephen,

+1 from our side.

Here is a newbie question: does the IETF process require a discussion of 
threats and countermeasures
as part of the specification? - explaining the specific situations that 
rely on SSL or signing and what the consequences
of "turning it off" might be...

- prateek
>>>> On Tue, Dec 1, 2009 at 7:08 PM, Eran Hammer-Lahav
>>>>         
>>> <[email-masked]> wrote:
>>>

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Wed, 2 Dec 2009 10:15:57 -0600

On Tue, Dec 1, 2009 at 1:23 PM, Mike Malone  
<[email-masked]> wrote:
 
> > particular Consumer Secret that can't be leaked to 
> subcontractors) is 
> > a barrier to multi-level delegation.
> 
> Right, but you can do poor-man's delegation by signing a URL 
> and passing it off to a third (er, fourth) party to use. I've 
> seen this most often with web apps, where the app (the OAuth 
> Consumer) wants to make a request to the Provider directly 
> from the browser (e.g., POSTing a large file). They can't 
> sign the URL in javascript without compromising the Consumer 
> Secret, so the the URL is signed server side and passed to 
> the browser for use.

There is another way to do a multi-level delegation without revealing a client's secret. The method described in the draft
http://tools.ietf.org/html/draft-vrancken-oauth-redelegation-00
along with a use case for re-delegating authorization.
In my opinion, the multi-level delegation should be on a new charter. (This makes this message relevant to the thread with the subject "OAuth 2.0 / Charter")

> Mike
Zachary

---

From: John Panzer <[email-masked]>
Date: Wed, 2 Dec 2009 09:49:21 -0800

It requires a security considerations section :).
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

On Wed, Dec 2, 2009 at 7:18 AM, Prateek Mishra <[email-masked]>wrote:

>>> I would like to make an official request to the chair for a consensus
>>> call on recommending SSL but keeping it optional in the various OAuth
>>> components. We can figure out how strong to make the language (or how
>>> scary), and we may make it mandatory in some flows/profiles, but I would
>>> like to be done with this discussion (for the n time).
>>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 2 Dec 2009 11:19:38 -0700

And we are always looking for people to write those...

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Panzer
Sent: Wednesday, December 02, 2009 9:49 AM
To: Prateek Mishra
Cc: [email-masked]
Subject: Re: [OAUTH-WG] why are we signing?

It requires a security considerations section :).
--
John Panzer / Google
[email-masked]<mailto:[email-masked]> / abstractioneer.org<http://abstractioneer.org> / @jpanzer

On Wed, Dec 2, 2009 at 7:18 AM, Prateek Mishra <[email-masked]<mailto:[email-masked]>> wrote:
Stephen,

+1 from our side.

Here is a newbie question: does the IETF process require a discussion of threats and countermeasures
as part of the specification? - explaining the specific situations that rely on SSL or signing and what the consequences
of "turning it off" might be...

- prateek

S.

Eran Hammer-Lahav wrote:

<smiling but not joking>

EHL

-----Original Message-----
From: Dick Hardt [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, December 01, 2009 9:51 PM
To: Brian Eaton
Cc: Eran Hammer-Lahav; Peter Saint-Andre; <[email-masked]<mailto:[email-masked]>>;
Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] why are we signing?

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

-- Dick

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

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

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

---

From: Richard Barnes <[email-masked]>
Date: Wed, 2 Dec 2009 09:39:39 -1000

Right.  Generally the expectation is that the Security Considerations  
section will discuss what the threats are against the protocol in  
question, how security features mitigate those threats, and what the  
risks are of not using those features.  At least that's what I look  
for when I do a SECDIR review :)

The authoritative guide is RFC 3552:
<http://tools.ietf.org/html/rfc3552>

--Richard

On Dec 2, 2009, at 7:49 AM, John Panzer wrote:

> On Wed, Dec 2, 2009 at 7:18 AM, Prateek Mishra <[email-masked] 
> > wrote:
> Stephen,
>
> +1 from our side.
>
> Here is a newbie question: does the IETF process require a  
> discussion of threats and countermeasures
> as part of the specification? - explaining the specific situations  
> that rely on SSL or signing and what the consequences
> I would like to make an official request to the chair for a  
> consensus call on recommending SSL but keeping it optional in the  
> various OAuth components. We can figure out how strong to make the  
> language (or how scary), and we may make it mandatory in some flows/ 
> profiles, but I would like to be done with this discussion (for the  
> n time).
>

---

From: Mike Malone <[email-masked]>
Date: Wed, 2 Dec 2009 11:57:42 -0800

> big companies!) simply don't care.

I'm far from an expert on TLS/PKI, but here's a thought (and I'm
pretty sure this has come up before)... If TLS is simpler than
signatures then why not just use PKI for everything. A lot of the
problems that have come up with OAuth are solved by PKI - client certs
replace tokens, you can delegate authority by creating
sub-certificates, the consumer provisioning problem is largely solved,
etc.

It seems like WRAP is using bits of PKI to solve half of the problem
and then re-inventing other bits of PKI for the other half. If TLS/PKI
is the solution, why not go whole hog?

Mike

---

From: John Panzer <[email-masked]>
Date: Wed, 2 Dec 2009 12:27:03 -0800

I think there are multiple positions here.  Just to be clear, my position
is:

A combination of optional TLS, required bearer tokens, and optional token
rotation (refresh) is sufficiently secure and deployable.  I believe that
mandatory TLS would unacceptably reduce deployability (and mandatory
dependence on certificate chains more so).

---

From: Dick Hardt <[email-masked]>
Date: Wed, 2 Dec 2009 21:14:30 +0000

> is the solution, why not go whole hog?

I'm confused by your PKI references to WRAP.

The token in WRAP is not just about identifying the Client, it also enables authorization.

In the implementations we (Microsoft) have done, the token contains all the claims that the Protected Resource needs to make an access control decision.

I hope to have the OAuth WRAP spec reformated as an I-D late next week.

-- Dick

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Dec 2009 14:40:07 -0700

<hat type='chair'/>

> So I don't think we can finish this discussion at this stage.

I think we can:

1. Software MUST implement TLS
2. Services should deploy TLS

Traditionally, RFCs enforce conformance requirements only on software
implementations, not on service deployments. And here there seems to be
enough variation in deployment land that "should deploy" is as far as we
can go.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Dec 2009 14:43:22 -0700

<hat type='chair'/>

On 12/2/09 9:15 AM, Zeltsan, Zachary (Zachary) wrote:
> On Tue, Dec 1, 2009 at 1:23 PM, Mike Malone <[email-masked]>
> wrote:
> 
>>>> I'm not completely opposed to the TLS route, but since you
>>>> asked... off the top of my head, here are a couple drawbacks to
>>>> using TLS instead of signing: - Bigger burden on developers who
>>>> need to debug this stuff (i.e., you can't sniff your own
>>>> traffic to debug requests & responses). - Properly setting up
>>>> TLS can be complicated and expensive. For developers who don't
>>>> have a lot of ops skills the barrier
>> may be too
>>>> high. - You can no longer pass around signed URLs as another
>>>> level of delegation (a use case that I use regularly for making
>>>> XHR & POST requests from the browser). This could be a
>>>> non-issue if
>> some other
>>> Can you elaborate on the above?  For OAuth, signatures (bound to
>>> a particular Consumer Secret that can't be leaked to
>> subcontractors) is
>> most often with web apps, where the app (the OAuth Consumer) wants
>> to make a request to the Provider directly from the browser (e.g.,
>> POSTing a large file). They can't sign the URL in javascript
>> without compromising the Consumer Secret, so the the URL is signed
>> server side and passed to the browser for use.
> 
> There is another way to do a multi-level delegation without revealing
> a client's secret. The method described in the draft 
> http://tools.ietf.org/html/draft-vrancken-oauth-redelegation-00 along
> with a use case for re-delegating authorization. In my opinion, the
> multi-level delegation should be on a new charter. (This makes this
> message relevant to the thread with the subject "OAuth 2.0 /
> Charter")

Without getting into the whole issue of re-chartering (yet), I do think
it would be helpful to have more discussion about the draft you mention
(because we know that multi-level delegation, formerly known as
"four-legged auth", is something that people are interested in). Feel
free to start a separate thread about that, or reply to this message.

Peter

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 Dec 2009 22:21:07 +0000

> 2. Services should deploy TLS

Tend to agree. What I meant we couldn't yet do was say for exactly  
which operations we think TLS should be turned on, and what it means  
to not use TLS in those cases,
S.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Dec 2009 16:02:13 -0700

On 12/3/09 3:21 PM, Stephen Farrell wrote:
> Tend to agree. What I meant we couldn't yet do was say for exactly which
> operations we think TLS should be turned on, and what it means to not
> use TLS in those cases,

Agreed. I think we'll have a clearer picture of that in the next few
weeks, once the token auth and alternative delegation flow I-Ds are
submitted.

Peter

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

---

From: "Vrancken Bart bv" <[email-masked]>
Date: Fri, 4 Dec 2009 10:11:15 +0100

Hi folks,

An example of a case of multi-level delegation, formerly known as
"four-legged auth" is described in the ID
http://tools.ietf.org/html/draft-vrancken-oauth-redelegation-00 . If we
have a server that acts as a content manager or a mash-up for one or
multiple web services that uses OAuth and we want different clients to
connect to this server, with the standard, like it is today, we have 2
possibilities:
1. We distribute the OAuth credentials from the server to the different
client. (What is against the philosophy of OAuth and sometimes not even
possible)
2. We act as a proxy and the client can get all the content from our
server. (And why would we like to generate unnecessary internet traffic,
the idea of OAuth is to grant direct access)

If we assume that the server and the clients are part of 1 application
(act as one client/consumer) and we are not happy that credentials in
client applications could easily be hacked, the system described in the
ID will give some extra security. The hacked credentials are only valid
for one specific client. A policy could be that credentials on such
clients are more limited in time and limited in rights to improve the
security. The user mustn't be involved anymore to renew these
credentials, because the server could grant permission.

Another case could be that a user wants to grant a printing service (the
famous case in the original ID :-)) to have access to its private photos
stored at different photo sharing services, via a content manager. The
user shouldn't be bothered to go to the whole authorization flows again,
if the content manager could prove that he can act on the behalf of the
user.

These are just 2 cases, but I can assume there are a lot more...

Best regards,

Bart Vrancken

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Fri, 4 Dec 2009 06:39:47 -0600

> <hat type='chair'/>
[....] 
> Without getting into the whole issue of re-chartering (yet), 
> I do think it would be helpful to have more discussion about 
> the draft you mention (because we know that multi-level 
> delegation, formerly known as "four-legged auth", is 
> something that people are interested in). Feel free to start 
> a separate thread about that, or reply to this message.
> Peter

It is also my impression that there is interest in multi-level delegation. 
As you have suggested, Bart Vrancken has just started such a thread (Subject: multi-level delegation).

Zachary