[Wg-uma] [Fwd: [OAUTH-WG] Draft Using OAuth for Recursive Delegation]

Eve Maler eve at xmlgrrl.com
Tue Sep 8 09:41:57 PDT 2009


Thanks, George -- do you (or does anyone else) have any comments on  
how this should/could influence our work, or vice versa?  Is this a  
matter of having a special single specialized set of terms/conditions  
that gets conveyed to the Client?

	Eve

On 8 Sep 2009, at 7:59 AM, George Fletcher wrote:

> For those not on the OAuth IETF list.
>
> -------- Original Message --------
> Subject: 	[OAUTH-WG] Draft Using OAuth for Recursive Delegation
> Date: 	Fri, 4 Sep 2009 15:18:58 -0500
> From: 	Zeltsan, Zachary (Zachary) <zeltsan at alcatel-lucent.com>
> To: 	oauth at ietf.org <oauth at ietf.org>
> CC: 	Vrancken, Bart Bv (Bart) <bart.bv.vrancken at alcatel-lucent.be>
>
>
>
> Following up on the discussion on the subject known as "four-legged"  
> authorization, we have prepared a draft describing a use case for re- 
> delegation of authorization.
> I have just submitted the draft to the IETF (it is also attached).  
> Your comments are welcome.
> Zachary Zeltsan
>
>
> OAUTH WG                                                     B.  
> Vrancken
> Internet-Draft                                                Z.  
> Zeltsan
> Intended status: Informational                            Alcatel- 
> Lucent
> Expires: March 5, 2010                                    September  
> 2009
>
>
>                  Using OAuth for Recursive Delegation
>                  draft-vrancken-oauth-redelegation-00
>
> Status of this Memo
>
>   This Internet-Draft is submitted to IETF in full conformance with  
> the
>   provisions of BCP 78 and BCP 79.
>
>   Internet-Drafts are working documents of the Internet Engineering
>   Task Force (IETF), its areas, and its working groups.  Note that
>   other groups may also distribute working documents as Internet-
>   Drafts.
>
>   Internet-Drafts are draft documents valid for a maximum of six  
> months
>   and may be updated, replaced, or obsoleted by other documents at any
>   time.  It is inappropriate to use Internet-Drafts as reference
>   material or to cite them other than as "work in progress."
>
>   The list of current Internet-Drafts can be accessed at
>   http://www.ietf.org/ietf/1id-abstracts.txt.
>
>   The list of Internet-Draft Shadow Directories can be accessed at
>   http://www.ietf.org/shadow.html.
>
>   This Internet-Draft will expire on March 5, 2010.
>
> Copyright Notice
>
>   Copyright (c) 2009 IETF Trust and the persons identified as the
>   document authors.  All rights reserved.
>
>   This document is subject to BCP 78 and the IETF Trust's Legal
>   Provisions Relating to IETF Documents in effect on the date of
>   publication of this document (http://trustee.ietf.org/license-info).
>   Please review these documents carefully, as they describe your  
> rights
>   and restrictions with respect to this document.
>
> Abstract
>
>   This document describes a use case for delegating authorization by a
>   Resource Owner to another user via a Client using the OAuth  
> protocol.
>   OAuth allows Clients to access server resources on behalf of another
>
>
>
> Vrancken & Zeltsan        Expires March 5, 2010                  
> [Page 1]
>
> Internet-Draft    Using OAuth for Recursive Delegation    September  
> 2009
>
>
>   party (such as a different Client or an end-user).  This document
>   describes the use of OAuth for delegating one Client's authorization
>   to another Client - a scenario, which is also known as four-legged
>   authorization.
>
>
> Table of Contents
>
>   1.   
> Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
>   2.  Notational  
> Conventions . . . . . . . . . . . . . . . . . . . .  3
>   3.  Use of the OAuth protocol for re-delegation of the access
>       rights for a protected  
> resource  . . . . . . . . . . . . . . .  3
>     3.1.  Redirection-Based  
> Authorization  . . . . . . . . . . . . .  4
>     3.2.  The Resource Owner authorizes a first Client to share
>           a  
> resource . . . . . . . . . . . . . . . . . . . . . . . .  4
>     3.3.  The first Client authorizes access to the resource by
>           the second  
> Client  . . . . . . . . . . . . . . . . . . . .  5
>   4.  Multi-layered delegation of  
> authorization  . . . . . . . . . .  8
>   5.  Security  
> Considerations  . . . . . . . . . . . . . . . . . . .  8
>     5.1.  Unlimited recursive  
> delegation . . . . . . . . . . . . . .  8
>     5.2.  Phishing  
> Attack  . . . . . . . . . . . . . . . . . . . . .  9
>   6.  IANA  
> Considerations  . . . . . . . . . . . . . . . . . . . . .  9
>   7.   
> Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
>   8.   
> References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
>     8.1.  Normative  
> References . . . . . . . . . . . . . . . . . . .  9
>     8.2.  Informative References . . . . . . . . . . . . . . . . . .  
> 10
>   Appendix A.  Terminology . . . . . . . . . . . . . . . . . . . . .  
> 10
>   Appendix B.  Other examples  . . . . . . . . . . . . . . . . . . .  
> 11
>   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  
> 11
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Vrancken & Zeltsan        Expires March 5, 2010                  
> [Page 2]
>
> Internet-Draft    Using OAuth for Recursive Delegation    September  
> 2009
>
>
> 1.  Introduction
>
>   The need for documenting a use case for the OAuth multi-layered
>   authorization was discussed on the OAuth mailing list and at the bar
>   BoF meeting at the IETF 75.  This Internet Draft describes such a  
> use
>   case.  We propose this document as a work item of the OAuth working
>   group.  Depending on the group's decision it can become a part of
>   another Internet Draft or a separate document.
>
>
> 2.  Notational Conventions
>
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in [RFC2119].
>
>
> 3.  Use of the OAuth protocol for re-delegation of the access rights  
> for
>    a protected resource
>
>   The OAuth protocol provides a method for servers to allow third- 
> party
>   access to protected resources without forcing their end-users to
>   reveal their authentication credentials.  This method can be  
> employed
>   to support organizing and sharing information among the end-users.
>
>   For example, a Web user (Resource Owner) can grant data access to a
>   pre-defined set of users.  This can be done with the use of a  
> special
>   OAuth Client - content manager - which serves as a proxy between the
>   end-users and the Web servers that host the resources related to the
>   project.  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.  The content manager may also enable
>   searching of the related materials.
>
>   The methods for managing user information are out of the scope of
>   this document.  The document describes how such content manager
>   authorizes user access to the resources using the OAuth protocol.
>
>   As far as authorization is concerned, the content manager and the
>   user with whom the Resource Owner shares a resource are the OAuth
>   Clients as defined in [draft-ietf-oauth-authentication].  In this
>   document the content manager, which has been authorized by a  
> Resource
>   Owner to share a resource with a user is called first Client.  The
>   user with whom the resource is to be shared is referred to as a
>   second Client.
>
>   This document describes the use of OAuth for enabling sharing a
>
>
>
> Vrancken & Zeltsan        Expires March 5, 2010                  
> [Page 3]
>
> Internet-Draft    Using OAuth for Recursive Delegation    September  
> 2009
>
>
>   resource under the following scenario:
>
>   o  First Client has been authorized by the Resource Owner, to  
> share a
>      resource (e.g., file) with a second Client.
>
>   o  The first Client has obtained access token credentials for the
>      resource.
>
>   o  The first Client enables the second Client to access the resource
>      without getting the Resource Owner involved in authorization
>      process.
>
> 3.1.  Redirection-Based Authorization
>
>   OAuth uses a set of token credentials to represent the authorization
>   granted to the Client by the Resource Owner.  Typically, token
>   credentials are issued by the Server at the Resource Owner's  
> request,
>   after authenticating the Resource Owner's identity using its Server
>   credentials (usually a username and password pair).
>
>   The specification [draft-ietf-oauth-web-delegation] defines a method
>   for provisioning the token credentials with the use of the HTTP
>   redirection and the Resource Owner's user agent.  This document
>   describes how the method can be expanded to allow a Client to  
> share a
>   resource with another Client after obtaining the Resource Owner's
>   authorization to do so.
>
>   The specification [draft-ietf-oauth-web-delegation] defines the
>   following URIs of a Web Server:
>
>   o  Temporary Credential Request
>
>   o  Resource Owner Authorization
>
>   o  Token Request
>
>   It also defines the HTTP methods (GET, POST, etc.) used to make the
>   requests.  This specification relies on these definitions.
>
>   The method in which the server advertises its three endpoints is
>   beyond the scope of [draft-ietf-oauth-web-delegation] and this
>   document.
>
> 3.2.  The Resource Owner authorizes a first Client to share a resource
>
>   In the initial stage of the authorization procedure, the Resource
>   Owner authorizes a Client to share the resource with another user 
> (who
>   is just another Client in terms of
>
>
>
> Vrancken & Zeltsan        Expires March 5, 2010                  
> [Page 4]
>
> Internet-Draft    Using OAuth for Recursive Delegation    September  
> 2009
>
>
>   [draft-ietf-oauth-web-delegation]).
>
>   The first Client obtains (after the Resource Owner's authorization)
>   token credentials that allow it to access (e.g., read, update) the
>   resource.  In the described use case the access rights include a
>   right to re-delegate (i.e., to proxy) the obtained authorization.
>   The first Client, which does not need to access the resource, will
>   use the credentials for authenticating to the Server and authorizing
>   access by the second Client.
>
>   The first Client obtains token credentials using a mechanism
>   specified in [draft-ietf-oauth-web-delegation].  The steps that
>   follow are illustrated by Figure 1 below and described in the next
>   section.
>
> 3.3.  The first Client authorizes access to the resource by the second
>      Client
>
>   This section describes the steps of the procedure that follow the
>   initial steps:
>
>   o  Resource Owner has requested the first Client to share a resource
>      with another user - a second Client
>
>   o  The first Client has obtained the token credentials from the
>      Server for the resource.
>
>
>    +-------------+                +----------+       +------------+
>    |  1st Client |                |Web server|       |2nd Clientt |
>    +------+------+                +-----+----+       +------+-----+
>           | 1. 1st Client notifies the  |                   |
>           | 2nd Client of               |                   |
>           | the resource sharing        |                   |
>           |-----------------------------+------------------>|
>           |                             |                   |
>           |                             |                   |
>           |                             |2. Request resource|
>           |                             |<------------------|
>           |                             |                   |
>           |                             |3. 401, auth. fail |
>           |                             |------------------>|
>           |                             |                   |
>           |                             |                   |
>           |                             | 4. Establish      |
>           |                             | consumer_key and  |
>           |                             | secret            |
>           |                             |<----------------->|
>
>
>
> Vrancken & Zeltsan        Expires March 5, 2010                  
> [Page 5]
>
> Internet-Draft    Using OAuth for Recursive Delegation    September  
> 2009
>
>
>           |                             |                   |
>           |                             |5. Request         |
>           |                             |temporary          |
>           |                             |credentials        |
>           |                             |<------------------|
>           |                             |                   |
>           |                             |                   |
>           |                             |                   |
>           |                             |6. Temporary       |
>           |                             |credentials (token |
>           |7. 2nd Client asks the 1st   |T, secret Ts)      |
>           |Client to grant access to the|------------------>|
>           |resource on the Web server.  |                   |
>           |The request includes T       |                   |
>          ||<----------------------------+-------------------|
>          || 7.                          |                   |
>          v|---------------------------->|                   |
>           |                             |                   |
>           |                      +------+------+            |
>           |                      |             |            |
>           |                      |Authenticate |            |
>           |                      |and get      |            |
>           |                      |authorization|            |
>           |                      +------+------+            |
>           |                             |                   |
>           |8. Redirect 1st Client back  |                   |
>           |to the  2nd                  |                   |
>          ||<----------------------------|                   |
>          ||                             |                   |
>          ||8.                           |                   |
>          v+-----------------------------+------------------>|
>           |                             |                   |
>                                         |                   |
>                                         |9. Request token   |
>                                         |credentials        |
>                                         |<------------------|
>                                         |10. Get token      |
>                                         |credentials        |
>                                         +------------------>|
>                                         |11. Request        |
>                                         |resource           |
>                                         |<------------------|
>                                         |                   |
>                                         | 12. Provide the   |
>                                         | resource          |
>                                         +------------------>|
>
>
>
>
>
> Vrancken & Zeltsan        Expires March 5, 2010                  
> [Page 6]
>
> Internet-Draft    Using OAuth for Recursive Delegation    September  
> 2009
>
>
>   Figure 1 - Authorization by the first Client of the second Client to
>                        obtain access to a resource
>
>   1.   The first Client notifies the second Client that a resource
>        available for sharing on the server.  The first client MUST
>        provide full path URL to the resource on the Web server.
>
>   2.   The second client requests access to the resource.
>
>   3.   The Web server responds with 401 HTTP error code denying access
>        to the protected resource.
>
>   4.   The second client establishes oauth_consumer_key and a shared
>        secret - the client credentials - as specified in
>        [draft-ietf-oauth-authentication].
>
>   5.   The second Client requests temporary credentials as specified  
> in
>        [draft-ietf-oauth-web-delegation].
>
>   6.   The second client receives from the Web server the temporary
>        credentials.
>
>   7.   The second Client asks the first Client to grant access to the
>        requested resource on the Web server.
>
>           After this step the first Client authenticates itself to the
>           Web server and authorizes (or denies) access to the resource
>           by the second Client.  To demonstrate that it has been
>           authorized by the Resource Owner to access the resource, the
>           first Client uses its token credentials obtained as a result
>           of the usual OAuth procedure.  To do that, the first Client
>           forms a request to the Web Server for the protected resource
>           as specified in [draft-ietf- oauth-authentication] and
>           [draft-ietf-oauth-delegation] with a modification.  The
>           purpose of the required modification is to inform the Web
>           Server that the first Client intends to use its token
>           credentials for proving that it is authorized by the  
> Resource
>           Owner to access the resource and for authorizing access by
>           another party, but not for getting the resource itself.
>
>   8.   After the first Client has authorized access to the resource  
> for
>        the second Client, the Web server sends a URL containing the
>        oauth_token and oauth_verifier parameters as specified in
>        [draft-ietf-oauth-web-delegation].
>
>           After this step the first client responds back to the second
>           client, confirming that the authorization has been done.
>
>
>
>
> Vrancken & Zeltsan        Expires March 5, 2010                  
> [Page 7]
>
> Internet-Draft    Using OAuth for Recursive Delegation    September  
> 2009
>
>
>   9.   The second Client requests the token credentials (specified in
>        [draft-ietf-oauth-web-delegation]).
>
>   10.  The Web server responds with the token credentials.
>
>   11.  The second Client requests access to the protected resource as
>        specified in [draft-ietf-oauth-web-delegation].
>
>   12.  After verification the Web Server satisfies the request.
>
>
> 4.  Multi-layered delegation of authorization
>
>   Section 3 describes how one Client (i.e., first Client) can grant
>   access to a resource to another Client (i.e., second Client).  The
>   described method can be extended for granting access by the Nth
>   Client to a client N+1.  In such a scenario each Client has to  
> have a
>   list of all Clients that are permitted to access the resource.
>
>   Indeed, the second Client, after obtaining authorization from the
>   first Client, can notify a third Client (assuming that it is on the
>   list) of the intent to share the resource (as did the first Client  
> in
>   step 1).  Then by repeating the rest of the procedure described in
>   section 3, the third Client can obtain authorization to the  
> resource.
>   The procedure can be repeated N times resulting in the recursive
>   delegation of authorization.
>
>   In general, the procedure allows a Client N+1 to demonstrate to the
>   Web server that it has been authorized by an Nth Client to access  
> the
>   resource.  Before making authorization the Nth Client MUST verify
>   that the Client N+1 is on the list of the Clients that are permitted
>   to access the resource.
>
>
> 5.  Security Considerations
>
>   As stated in [RFC2617], the greatest sources of risks are usually
>   found not in the core protocol itself but in policies and procedures
>   surrounding its use.  Implementers are strongly encouraged to assess
>   how this protocol addresses their security requirements.  Because of
>   the nature of multi-layer delegation, the same security
>   considerations are applicable as in the single-layer delegation
>   [draft-ietf-oauth-web-delegation].
>
> 5.1.  Unlimited recursive delegation
>
>   Resource owners should be able to decide if the client may use
>   recursive delegation.  Clients should inform the resource owner, at
>
>
>
> Vrancken & Zeltsan        Expires March 5, 2010                  
> [Page 8]
>
> Internet-Draft    Using OAuth for Recursive Delegation    September  
> 2009
>
>
>   who they would delegate permissions to.  A client may not delegate
>   recursively to anyone else than permitted by the user.  The resource
>   owner should only allow trustworthy clients to do the recursive
>   delegation.  The resource owner should be able to track all the
>   transactions to the protected resource from the different the
>   clients/users.  Resource owners should be able to complain about
>   clients that abuse this trust at the server.
>
> 5.2.  Phishing Attack
>
>   Security considerations related to the phishing attack are described
>   in [draft-ietf-oauth-web-delegation].
>
>
> 6.  IANA Considerations
>
>   This Internet Draft includes no request to IANA.
>
>
> 7.  Acknowledgements
>
>   The authors are grateful to Igor Faynberg and Hui-Lan Lu for their
>   invaluable help with preparing this document.
>
>
> 8.  References
>
> 8.1.  Normative References
>
>   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>              Requirement Levels", RFC 2119, March 1997.
>
>   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
>              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
>              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
>
>   [draft-ietf-oauth-authentication]
>              Hammer-Lahav, E., "The OAuth Protocol: Authentication",
>              draft-ietf-oauth-authentication-01.txt (work in  
> progress),
>              July 2009.
>
>   [draft-ietf-oauth-web-delegation]
>              Hammer-Lahav, E., "The OAuth Protocol: Web Delegation",
>              draft-ietf-oauth-web-delegation-01.txt (work in  
> progress),
>              July 2009.
>
>
>
>
>
>
> Vrancken & Zeltsan        Expires March 5, 2010                  
> [Page 9]
>
> Internet-Draft    Using OAuth for Recursive Delegation    September  
> 2009
>
>
> 8.2.  Informative References
>
>   [RFC2617]  Franks, P., Hallam-Baker, J., Hostetler, J., Lawrence,  
> S.,
>              Leach, P., Luotonen, A., and L. Stewart, "HTTP
>              Authentication: Basic and Digest Access Authentication",
>              RFC 2617, June 1999.
>
>
> Appendix A.  Terminology
>
>   The following terms are used in this document as defined in [draft-
>   ietf-oauth-authentication]:
>
>   Client
>      An HTTP client (per [RFC2616]) capable of making OAuth-
>      authenticated requests per [draft-ietf-oauth-authentication].
>
>   Server
>      An HTTP server (per [RFC2616]) capable of accepting OAuth-
>      authenticated requests per [draft-ietf-oauth-authentication].
>
>   Protected Resource
>      An access-restricted resource (per [RFC2616]) which can be
>      obtained from the server using an OAuth-authenticated request per
>      [draft-ietf-oauth-authentication].
>
>   Resource Owner
>      An entity capable of accessing and controlling protected  
> resources
>      by using credentials to authenticate with the server.
>
>   Token
>      An unique identifier issued by the server and used by the client
>      to associate authenticated requests with the resource owner whose
>      authorization is requested or has been obtained by the client.
>      Tokens have a matching shared-secret that is used by the client  
> to
>      establish its ownership of the token, and its authority to
>      represent the resource owner.
>
>   The following terms are defined in this document:
>
>   first Client
>      A Client that has been authorized to access a Protected Resource
>      by the Resource Owner.
>
>   second Client
>      A Client that has been authorized to access a Protected Resource
>      by the First Client.
>
>
>
>
> Vrancken & Zeltsan        Expires March 5, 2010                [Page  
> 10]
>
> Internet-Draft    Using OAuth for Recursive Delegation    September  
> 2009
>
>
> Appendix B.  Other examples
>
>   The Resource owner could delegate access and the right to delegate  
> to
>   a content manager.  The content manager could provide several third
>   party services, like a photo service.  The content manager could
>   delegate access to the photo service on behalf of the user, allowing
>   the photo service to get the protected resource directly from the
>   server.
>
>
> Authors' Addresses
>
>   Bart Vrancken
>   Alcatel-Lucent
>   Copernicuslaan 50
>   2018 Antwerp,
>   Belgium
>
>   Phone: +32 3 2409804
>   Email: Bart.bv.Vrancken at alcatel-lucent.be
>
>
>   Zachary Zeltsan
>   Alcatel-Lucent
>   600 Mountain Avenue
>   Murray Hill, New Jersy
>   USA
>
>   Phone: +1 908 582 2359
>   Email: zeltsan at alcatel-lucent.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Vrancken & Zeltsan        Expires March 5, 2010                [Page  
> 11]
>
>
> _______________________________________________
> OAuth mailing list
> OAuth at ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> 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




More information about the Wg-uma mailing list