Subject: [OAUTH-WG] What is 4-legged OAuth?

From: Richard Barnes <[email-masked]>
Date: Wed, 29 Jul 2009 09:54:54 +0200

There has been a lot of talk about many-legged OAuth usages.  I think 
most people are familiar with the authentication and delegation (2- and 
3-legged) cases.  Could someone summarize the 4-legged case?

Thanks,
--Richard

---

From: Lucy Lynch <[email-masked]>
Date: Wed, 29 Jul 2009 01:07:58 -0700 (PDT)

On Wed, 29 Jul 2009, Richard Barnes wrote:

> There has been a lot of talk about many-legged OAuth usages.  I think most 
> people are familiar with the authentication and delegation (2- and 3-legged) 
> cases.  Could someone summarize the 4-legged case?

Richard -

You might want to look at Eve Maler's message (and blog posts)
concerning ProtectServe

http://www.google.com/url?sa=t&source=web&ct=res&cd=4&url=http%3A%2F%2Fgroups.google.com%2Fgroup%2Foauth-extensions%2Fbrowse_thread%2Fthread%2F35992a5955216d66&ei=nwFwSoOyCZCi_gbV8uiiCQ&rct=j&q=oauth+multi-legged+site%3Agoogle.com&usg=AFQjCNHHccgokFB3WTyy5kjiat84hkXCoA

<snippet>

If you’re an OAuth aficionado, ProtectServe is something like four-legged 
OAuth or higher-order OAuth, with the effect of separating out an 
authorization job for the Relationship Manager that today’s OAuth SPs do 
all by themselves.

</snippet>

- Lucy

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

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 29 Jul 2009 04:23:15 -0400

Richard,

This is what we plan to do in an I-D, which we should submit prior to the next
meeting.

Igor

---

From: Richard Barnes <[email-masked]>
Date: Wed, 29 Jul 2009 10:49:17 +0200

Such a draft would be greatly appreciated.  More so if it could be done 
slightly sooner than October :)

--Richard

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 Jul 2009 11:10:03 +0200

Thanks, Igor! That sounds very helpful.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 Jul 2009 11:12:31 +0200

> 3-legged) cases.  Could someone summarize the 4-legged case?

One thing we discussed this morning was that all this talk of legs is
confusing. I think we had rough consensus on something like the
following terminology...

"two-legged" = authentication

"three-legged" = single-layer delegation

"four-legged" (and more) = multi-layer delegation

Peter

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

---

From: Richard Barnes <[email-masked]>
Date: Wed, 29 Jul 2009 11:25:46 +0200

That of course raises another point that I'm not clear on: Why is the 
3-legged case not composable?  Once an authorization has been delegated 
to the Client, it seems like the Client could in principle act as a 
Resource Owner for that authorization, so that he could delegate to the 
next tier.

There may be a desire for the RO to be able to flag that the Client can 
sub-delegate his delegated authorization, but that would seem to be an 
issue of the scope of the authorization, which has been outside the 
scope of the protocol.

--Richard

Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkpwEn8ACgkQNL8k5A2w/vys3ACcC+KNd7w54eOX4dDCgJ+S0KDD
> p2kAoIgFWSiyL1DalicnIlTnPtCWgD9q
> =At+M
> -----END PGP SIGNATURE-----
>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 29 Jul 2009 11:59:32 +0200

On 29 Jul 2009, at 11:25, Richard Barnes wrote:

> That of course raises another point that I'm not clear on: Why is  
> the 3-legged case not composable?  Once an authorization has been  
> delegated to the Client, it seems like the Client could in principle  
> act as a Resource Owner for that authorization, so that he could  
> delegate to the next tier.
>
> There may be a desire for the RO to be able to flag that the Client  
> can sub-delegate his delegated authorization, but that would seem to  
> be an issue of the scope of the authorization, which has been  
> outside the scope of the protocol.

I'm afraid that, unless you define a very clear procedure for that  
delegation, the whole protocol would
be signed as breaking privacy (and I think it can probably be the  
case). Having written and implemented
a delegated authorization profile for SAML, I can tell preserving  
privacy is not easy at all in the moment
you allow delegations to be stacked, and other solutions, like the  
external services depicted by
ProtectServe do scalemuch better.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez

Red.es - RedIRIS
The Spanish NREN

e-mail: [email-masked]
jid:        [email-masked]
Tel:    +34 955 056 621
Mobile: +34 669 898 094
-----------------------------------------

---

From: Richard Barnes <[email-masked]>
Date: Wed, 29 Jul 2009 12:33:55 +0200

Diego,

Having a well-defined procedure for delegation was the point of OAuth in 
the first place!  I'm just not clear on what risks you introduce by 
re-using it to sub-delegate; none are immediately clear to me.

--Richard

Diego R. Lopez wrote:
>> 3-legged case not composable?  Once an authorization has been 
>> be an issue of the scope of the authorization, which has been outside 
>> the scope of the protocol.
> 
> 
> be signed as breaking privacy (and I think it can probably be the case). 
> Having written and implemented

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 29 Jul 2009 13:25:10 +0200

Richard,

On 29 Jul 2009, at 12:33, Richard Barnes wrote:
> Having a well-defined procedure for delegation was the point of  
> OAuth in the first place!  I'm just not clear on what risks you  
> introduce by re-using it to sub-delegate; none are immediately clear  
> to me.

If I have understood you well, what you proposed is to allow clients  
to forward their authorization tokens
to other potential clients. To do so, you can make it with or without  
user explicit consent. In the first case,
unless you send back the user to the SP (what would be exactly the  
same as the three-legged case with just
a shorter path in user interactions) you are allowing a third party to  
ask the user to take decisions on
access to the SP, and this seems to me a clear path for phishing. In  
the second case, you are simply
transmitting the authotization without the explicit user consent, and  
that would break several privacy
protecting laws (at least, here in the EU)

Furthermore, since traceability is a essential requirement for any  
access control infrastructure,
the unconstrained delegation would require a strict control of the  
potential clients that can share
a token at the SP, including a detailed check of who is using the  
token and from whom it was generated,
and this requires as well the ability of tracing the delegation path  
up to the original client, implying
that tokens must be augmented with traces of the delegations, and  
you'll agree in that this won't scale.

Be goode,

Dr Diego R. Lopez

Red.es - RedIRIS
The Spanish NREN

---

From: Richard Barnes <[email-masked]>
Date: Wed, 29 Jul 2009 14:07:16 +0200

You're misunderstanding what I'm proposing.  Let me try to state what 
I'm thinking more clearly.  For consistency, I'll use terms from 
draft-barnes-oauth-model.

I'm not proposing that one client simply pass its access token to some 
other potential client -- you're absolutely correct that that doesn't 
provide the user approval or traceability that you would want.

What I'm talking about is doing the *entire* OAuth delegation procedure 
twice: First with the User as RO and Client1 as Client, then again with 
Client1 as RO and Client2 as Client (the Server being the same the whole 
time).  In graphic form:

                                 +----------+            --+
                                 | Resource |              |
                                 | Owner 1  |              |
                                 +----------+              |
                                      ^|                   | OAuth 1 

                                      ||                   |
                              req-tk-1||ver-tk-1           |
                                      |V                   |
                                 +----------+----------+   |
       +-----------req-tk-1----->| Client   = Resource | --+
       | +---------acc-tk-1----->| 1          Owner 2  | --+
       | |                       +----------+----------+   | 

  +----------+                        ^|                   |
  | Server   |                        ||                   |
  |          |                req-tk-2||ver-tk-2           | OAuth 2 

  +----------+                        |V                   |
       | |                       +----------+              |
       | +---------req-tk-2----->| Client   |              |
       +-----------acc-tk 2----->| 2        |              |
                                 +----------+            --+ 

Doing this would enable accountable sub-delegation, since all the 
delegations are made through the Server.

The one thing that's not immediately clear is how you fit user consent 
for the sub-delegation into this picture.  But there's an easy answer 
there too: Permission to sub-delegate is just another permission that 
can be delegated via OAuth.  In the above example, Client1 would have to 
receive permission to sub-delegate to Client2 in his initial 
transaction.  You could also imagine a three-OAuth model, where:
1. OAuth1: RO grants Client1 permission to access resources
2. Client1 requests permission to sub-delegate to Client2
3. OAuth2: RO grants Client1 permission to sub-delegate to Client2
4. OAuth3: Client 1 grants Client2 permission to access resources

Either way, these are just concatenations of OAuth transactions.  What's 
missing, besides an informational document to describe how this works?

--Richard

Diego R. Lopez wrote:
>> Having a well-defined procedure for delegation was the point of OAuth 
>> in the first place!  I'm just not clear on what risks you introduce by 
> If I have understood you well, what you proposed is to allow clients to 
> forward their authorization tokens
> unless you send back the user to the SP (what would be exactly the same 
> as the three-legged case with just
> access to the SP, and this seems to me a clear path for phishing. In the 
> second case, you are simply
> a token at the SP, including a detailed check of who is using the token 
> and from whom it was generated,
> and this requires as well the ability of tracing the delegation path up 
> to the original client, implying
> that tokens must be augmented with traces of the delegations, and you'll 
> agree in that this won't scale.
> 
> Be goode,
> --

---

From: Eve Maler <[email-masked]>
Date: Wed, 29 Jul 2009 07:22:27 -0700

Hi folks-- I'm attending a conference in a different time zone, and so  
just saw this thread.  Richard's idea of composing multiple instances  
of OAuth to get higher-order effects is great.  It's not more legs,  
it's more instances of "three-legged" OAuth.  Generating new solutions  
out of the same pieces is valuable.

Regarding the discussion of "four-legged" OAuth, there are quite a few  
ways to add a true fourth party/entity (that's better than talking  
about "legs", I think), and it all depends on use cases.  Lucy, thanks  
for mentioning ProtectServe!  The idea here is to externalize the  
authorization decision itself into a fourth entity called an  
"authorization manager", which helps the user globally manage a  
complicated authz picture.  ProtectServe *uses* OAuth in a couple of  
places but adds functionality, such as letting the user impose  
"contract terms" on the Consumer in accepting data and accessing  
services.  We have found that OAuth isn't directly suitable for use in  
one of the two places because of a correlation/privacy issue, so  
that's one piece of feedback we can provide in terms of leveraging  
OAuth for new purposes -- we had to veer away from OAuth compliance.

I've just started a group called "user-managed access" (UMA) to  
incubate a ProtectServe spec and implementations, with a goal of  
contributing the work to IETF.  Interested folks are welcome to come  
on in.

Regarding the list of potential new use cases etc. discussed at the  
breakfast BOF: A lot of these are interesting and timely.  I ran a  
Project Concordia workshop on Monday where authorization was the big  
theme of the day, and a lot of "hybrid" scenarios involving OAuth  
subsequently came up.  Maybe the OAuth and Concordia communities can  
work together where there's interest.

Current best source of info about ProtectServe:
   http://www.xmlgrrl.com/blog/categories/protectserve/
A post that may help illustrate the entities I'm talking about:
   http://www.xmlgrrl.com/blog/archives/2009/04/05/relationship-authorization-make-up-your-mind/
Info on new UMA group:
   http://kantarainitiative.org/confluence/display/uma/Home
Concordia post-workshop telecon notes:
   http://lists.projectconcordia.org/pipermail/community/2009-July/002074.html

Thanks,

	Eve

On 29 Jul 2009, at 5:07 AM, Richard Barnes wrote:

> You're misunderstanding what I'm proposing.  Let me try to state  
> what I'm thinking more clearly.  For consistency, I'll use terms  
> from draft-barnes-oauth-model.
>
> I'm not proposing that one client simply pass its access token to  
> some other potential client -- you're absolutely correct that that  
> doesn't provide the user approval or traceability that you would want.
>
> What I'm talking about is doing the *entire* OAuth delegation  
> procedure twice: First with the User as RO and Client1 as Client,  
> then again with Client1 as RO and Client2 as Client (the Server  
> being the same the whole time).  In graphic form:
>
>                                +----------+            --+
>                                | Resource |              |
>                                | Owner 1  |              |
>                                +----------+              |
>                                     ^|                   | OAuth 1
>                                     ||                   |
>                             req-tk-1||ver-tk-1           |
>                                     |V                   |
> The one thing that's not immediately clear is how you fit user  
> consent for the sub-delegation into this picture.  But there's an  
> easy answer there too: Permission to sub-delegate is just another  
> permission that can be delegated via OAuth.  In the above example,  
> Client1 would have to receive permission to sub-delegate to Client2  
> in his initial transaction.  You could also imagine a three-OAuth  
> model, where:
> Either way, these are just concatenations of OAuth transactions.   
> What's missing, besides an informational document to describe how  
> this works?
>
> --Richard
>
>
>
> Diego R. Lopez wrote:
>> Richard,
>>> introduce by re-using it to sub-delegate; none are immediately  
>>> clear to me.
>> If I have understood you well, what you proposed is to allow  
>> clients to forward their authorization tokens
>> to other potential clients. To do so, you can make it with or  
>> without user explicit consent. In the first case,
>> a shorter path in user interactions) you are allowing a third party  
>> to ask the user to take decisions on
>> access to the SP, and this seems to me a clear path for phishing.  
>> In the second case, you are simply
>> transmitting the authotization without the explicit user consent,  
>> and that would break several privacy
>> and this requires as well the ability of tracing the delegation  
>> path up to the original client, implying

Eve Maler                                          eve.maler @ sun.com
Emerging Technologies Director                    cell +1 425 345 6756
Sun Microsystems Identity Software                www.xmlgrrl.com/blog

---

From: Jim Meyer <[email-masked]>
Date: Wed, 29 Jul 2009 10:04:25 -0700

+1 for discussing these as "two-party", "three-party", etc. rather  
than "*-legged" or the number of delegations involved. It seems to  
lead directly to the question, "Who are the parties and what are their  
roles?" which lends focus and clarity to the explanation.

--j

On Jul 29, 2009, at 7:22 AM, Eve Maler wrote:

> Regarding the discussion of "four-legged" OAuth, there are quite a  
> few ways to add a true fourth party/entity (that's better than  
> talking about "legs", I think),

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 29 Jul 2009 18:34:15 +0200

Hi Richard,

On 29 Jul 2009, at 14:07, Richard Barnes wrote:

> being the same the whole time).  In graphic form: . . .

Agreed. I totally misunderstood your first statement, probably because  
the fourth leg idea misled me. Looking
at it now, it totally makes sense, though I'd say is more a chained- 
three-legged than a four-legged model...

> delegations are made through the Server.

Indeed.

> 4. OAuth3: Client 1 grants Client2 permission to access resources

Or a fourth or a fitfth or... That's why I think that calling it  
"chained" would be better.

> What's missing, besides an informational document to describe how  

Nothing, I'd say... Anyway, I still have a couple of concerns about  
usability and transitivity. Usability in
this context is very much connected to practical security and to the  
requirement for informed consent: I think
that the way in which confirmation for delegation and its limits are  
presented to the user is a key aspect, and
should be stressed in the discussion of security aspects. Second, I  
assume that the permission for delegation
can only be granted by the first transaction, so further delegations  
in delegated transactions should be
explicitly prohibited.

Be goode,

Dr Diego R. Lopez

Red.es - RedIRIS
The Spanish NREN