[Wg-uma] Fwd: [OAUTH-WG] [Fwd: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt]

Maciej Machulak m.p.machulak at newcastle.ac.uk
Fri Sep 11 08:05:57 PDT 2009


Hello,

Yes, yes. I'm rushing to write me thoughts :-)

Basically, I went through some of the things in the new OAuth IETF draft and I'm really looking forward to hearing more from Eran about their work on 4-legged Oauth.

After looking at it I think that we might have misunderstood some bits of this draft. As I see in the document the authorization decision process is indeed externalized from the Host (Web Server) to the Content Manager (1st Client). The 1st Client is used by a User to compose access control policies ("The content manager allows a user (the owner of the resources) to specify a set of the resources related to a project (E.g. by tagging) and a set of the users and their access rights in respect to the resources"). From what I see is that also the diagram from the new OAuth draft covers only STEP1 - STEP3 of the ProtectServe protocol. This is the reason why a user does not appear in the flow as a user is not necessary there (only if a 'real-time' consent needs to be considered).

I think that Diego is right stating that 1st Client in 4-legged OAuth is the AM in ProtectServe. Please note that the diagram from section 3.3 states that the presented flow follows initial steps: (1) Resources owner has requested the first Client to share a resource with another user - a second Client (2) The first Client has obtained the token credentials from the Server for the resource (both steps to me are an equivalent of our 'User introduces AM to Host and composes AC policies / defines terms).
Indeed, the 4-legged OAuth does not have the offer/acceptance cycle - a Requester does not have much choice to meet the terms; a policy composed by a User must clearly state what a particular Requester can do to a particular set of Resources.

Anyway, it's great that other people are looking in a very similar direction to UMA! I'll be happy to learn more about that and see how this affects our work (or how our work affects theirs;) ).

Diego: Thanks for attaching the discussion! I'm just starting to go through it carefully!

Cheers,
Maciej
________________________________________
From: wg-uma-bounces at kantarainitiative.org [wg-uma-bounces at kantarainitiative.org] On Behalf Of Eve Maler [eve at xmlgrrl.com]
Sent: 11 September 2009 15:54
To: Diego R. Lopez
Cc: WG UMA
Subject: Re: [Wg-uma] Fwd: [OAUTH-WG] [Fwd:     I-D     ACTION:draft-vrancken-oauth-redelegation-00.txt]

Maciej sent me some very interesting further analysis yesterday along
these lines, and I hope (hint, hint?) he'll be willing to share it
with our list -- and then I'm hoping OAuth list postings could follow
once we're all up to speed.  Also, Michael, did you learn anything
from your convo with Eran yesterday?

        Eve

On 11 Sep 2009, at 4:28 AM, Diego R. Lopez wrote:

> Hi,
>
> On 10 Sep 2009, at 17:06, Eve Maler wrote:
>> Interesting.  It would be great if you could briefly walk us
>> through your understanding of the redelegation draft on the call,
>> to make sure we're all up to speed...?  If we have ideas to
>> contribute to that discussion, what's the best way to do that?
>
>
> My apologies again for throwing this at you and not showing in the
> call, but I was nor allowed to make any kind of connection
> while flying from Vienna...
>
> Looking at the minutes of the call, I'd like to stress my idea that
> I see the multiple delegation OAuth profile as
> an opportunity of offering an enhanced user experience by combining
> an AM and a AM-aware First Client. This way,
> the access to certain resources matching common policies could be
> simplified, as the First Client could directly
> transfer credentials. In no way I was thinking of a possible
> substitution of an AM for the delegation schema.
>
> In what relates to the security concerns regarding delegation, I'm
> attaching the discussion I had with Richars Barnes
> on this issue some time ago. I guess that any comment we have on
> this can be forwarded to the oauth at ietf.org list.
>
> Be goode,
>
> 8
> <
> ---------------------------------------------------------------------------------------------------
> From: "Diego R. Lopez" <diego.lopez at rediris.es>
> To: Richard Barnes <rbarnes at bbn.com>
> Cc: Peter Saint-Andre <stpeter at stpeter.im>, "oauth at ietf.org" <oauth at ietf.org
> >
> Subject: Re: [OAUTH-WG] What is 4-legged OAuth?
> 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 scale much better.
>
> 8
> <
> ---------------------------------------------------------------------------------------------------
> From: Richard Barnes <rbarnes at bbn.com>
> To: "Diego R. Lopez" <diego.lopez at rediris.es>
> CC: Peter Saint-Andre <stpeter at stpeter.im>, "oauth at ietf.org" <oauth at ietf.org
> >
> Subject: Re: [OAUTH-WG] What is 4-legged OAuth?
> 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.
>
> 8
> <
> ---------------------------------------------------------------------------------------------------
> From: "Diego R. Lopez" <diego.lopez at rediris.es>
> To: Richard Barnes <rbarnes at bbn.com>
> Cc: Peter Saint-Andre <stpeter at stpeter.im>, "oauth at ietf.org" <oauth at ietf.org
> >
> Subject: Re: [OAUTH-WG] What is 4-legged OAuth?
> 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.
>
> 8
> <
> ---------------------------------------------------------------------------------------------------
> From: Richard Barnes <rbarnes at bbn.com>
> To: "Diego R. Lopez" <diego.lopez at rediris.es>
> CC: Peter Saint-Andre <stpeter at stpeter.im>, "oauth at ietf.org" <oauth at ietf.org
> >
> Subject: Re: [OAUTH-WG] What is 4-legged OAuth?
> 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?
>
> 8
> <
> ---------------------------------------------------------------------------------------------------
> From: "Diego R. Lopez" <diego.lopez at rediris.es>
> To: Richard Barnes <rbarnes at bbn.com>
> Cc: "oauth at ietf.org" <oauth at ietf.org>
> Subject: Re: [OAUTH-WG] What is 4-legged OAuth?
> Date: Wed, 29 Jul 2009 18:34:15 +0200
>
> Hi Richard,
>
> On 29 Jul 2009, at 14:07, 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: . . .
>
> 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...
>
> > Doing this would enable accountable sub-delegation, since all the
> > delegations are made through the Server.
>
> Indeed.
>
> > 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
>
> Or a fourth or a fitfth or... That's why I think that calling it
> "chained" would be better.
>
> > Either way, these are just concatenations of OAuth transactions.
> > What's missing, besides an informational document to describe how
> > this works?
>
> 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.
>
> 8
> <
> ---------------------------------------------------------------------------------------------------
>
> --
> "Esta vez no fallaremos, Doctor Infierno"
>
> Dr Diego R. Lopez
>
> Red.es - RedIRIS
> The Spanish NREN
>
> e-mail: diego.lopez at rediris.es
> jid:        diego.lopez at rediris.es
> Tel:    +34 955 056 621
> Mobile: +34 669 898 094
> -----------------------------------------
>
>
>
>
> _______________________________________________
> Wg-uma mailing list
> Wg-uma at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma_kantarainitiative.org


Eve Maler
eve at xmlgrrl.com
http://www.xmlgrrl.com/blog


_______________________________________________
Wg-uma mailing list
Wg-uma at kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma_kantarainitiative.org



More information about the Wg-uma mailing list