[OAUTH-WG] Delegation -- RE: SAML profile comments/questions from the SAML people

Thomas Hardjono <hardjono@MIT.EDU> Tue, 07 September 2010 20:24 UTC

Return-Path: <hardjono@mit.edu>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 102D23A6964 for <oauth@core3.amsl.com>; Tue, 7 Sep 2010 13:24:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.982
X-Spam-Level:
X-Spam-Status: No, score=-3.982 tagged_above=-999 required=5 tests=[AWL=-1.384, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcr-CbMYupvF for <oauth@core3.amsl.com>; Tue, 7 Sep 2010 13:24:33 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by core3.amsl.com (Postfix) with ESMTP id 163593A6960 for <oauth@ietf.org>; Tue, 7 Sep 2010 13:24:32 -0700 (PDT)
X-AuditID: 12074423-b7b19ae0000059ef-bb-4c869f82efa4
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-6.mit.edu (Symantec Brightmail Gateway) with SMTP id E3.16.23023.28F968C4; Tue, 7 Sep 2010 16:24:34 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id o87KOxVh016985; Tue, 7 Sep 2010 16:25:00 -0400
Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o87KOwe8010109; Tue, 7 Sep 2010 16:24:59 -0400
Received: from w92exhub9.exchange.mit.edu (18.7.73.17) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 7 Sep 2010 16:24:26 -0400
Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub9.exchange.mit.edu ([18.7.73.17]) with mapi; Tue, 7 Sep 2010 16:24:58 -0400
From: Thomas Hardjono <hardjono@MIT.EDU>
To: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 07 Sep 2010 16:24:55 -0400
Thread-Topic: Delegation -- RE: [OAUTH-WG] SAML profile comments/questions from the SAML people
Thread-Index: ActOyrjEqOpUWbWeS9qELuynHwl4lw==
Message-ID: <DADD7EAD88AB484D8CCC328D40214CCD01C253AA42@EXPO10.exchange.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] Delegation -- RE: SAML profile comments/questions from the SAML people
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Sep 2010 20:24:34 -0000

__________________________________________

> -----Original Message-----
> From: Brian Campbell [mailto:bcampbell@pingidentity.com]
> Sent: Wednesday, August 25, 2010 4:29 PM
> To: Thomas Hardjono
> Cc: oauth
> Subject: Re: [OAUTH-WG] SAML profile comments/questions from the SAML
> people
> 
> Again, sorry for the slow reply.
> 
> On Thu, Aug 19, 2010 at 1:52 PM, Thomas Hardjono <hardjono@mit.edu>
> wrote:
> 
> >  Does Oauth-v2 today allow
> > the Authorization Server to delegate/relegate the actual obtaining of
> > the access token to a 3rd Party?
> 
> I'm not sure I follow the question?

Brian, apologies for the delay.

What I meant to say is that User#1/Client#1 asks for 
an access token (to a given resource) with the
intention of later handing over the access-token to 
a different User#2/Client#2.

Ideally, this model could be extensible where
User#2/Client#2 asks the Auth Server to "swap" (re-issue)
this token for a different client_id (User#3/Client#3).

However, this bring us into space of role based access
control and permissions, which would somewhat complicate
the Oauth 2.0 authorization model :)

/thomas/