Re: [OAUTH-WG] Signatures...what are we trying to solve?

Prateek Mishra <prateek.mishra@oracle.com> Thu, 07 October 2010 13:57 UTC

Return-Path: <prateek.mishra@oracle.com>
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 9901C3A705C for <oauth@core3.amsl.com>; Thu, 7 Oct 2010 06:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.156
X-Spam-Level:
X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 47dHKsR-LHdH for <oauth@core3.amsl.com>; Thu, 7 Oct 2010 06:57:52 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id D384E3A6FEA for <oauth@ietf.org>; Thu, 7 Oct 2010 06:57:51 -0700 (PDT)
Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o97DwoEd003719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Oct 2010 13:58:52 GMT
Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o97DH9YX029034; Thu, 7 Oct 2010 13:58:49 GMT
Received: from abhmt003.oracle.com by acsmt354.oracle.com with ESMTP id 663793261286459850; Thu, 07 Oct 2010 06:57:30 -0700
Received: from [192.168.1.4] (/209.6.179.100) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 07 Oct 2010 06:57:28 -0700
Message-ID: <4CADD1C7.8050205@oracle.com>
Date: Thu, 07 Oct 2010 09:57:27 -0400
From: Prateek Mishra <prateek.mishra@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: George Fletcher <gffletch@aol.com>
References: <AANLkTimERshG-ndU8_uc0NJhx6ree6d8kxYj=EVeHpmA@mail.gmail.com> <4CA20BFC.90704@aol.com> <5710F82C0E73B04FA559560098BF95B124FB233412@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4CA9FEAC.8090407@aol.com>
In-Reply-To: <4CA9FEAC.8090407@aol.com>
Content-Type: multipart/alternative; boundary="------------080703090003060608090501"
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Signatures...what are we trying to solve?
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: Thu, 07 Oct 2010 13:57:54 -0000

George,

I will comment at a later time on the details of your use-case.

But as far as signing the request for a protected resource (signature 
over access token, client_id, scope,  URL, request body) - isn't this 
requirement is a simple consequence of network architecture wherein an 
SSL connection may terminate quite early at the resource server site? 
There may be a good number of hops between SSL termination and the 
resource server. So I am not sure that we need a business use-case to 
justify the need for signatures as a means of addressing the threat that 
the message may altered at the resource server site, before it is 
presented to a particular resource server.

I guess this is a bit different from the motivation for request message 
signing you described in

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

- prateek
> Hi Zachary,
>
> Here is a use case for signed messages. I've tried to keep this in the 
> format of the other OAuth use cases. Please contact me off-list if 
> there are editorial changes required. I've include the list to see if 
> others have feed back on this use case.
>
> Thanks,
> George
>
> Use case: Signed Messages
>
> Description:
>
> Alice manages all her personal health records in her personal health 
> data store (www.myhealth.example.com). Alice's Primary Care Physician 
> (www.pcp.example.com) recommends that Alice see a sleep specialist 
> (www.sleepwell.example.com). Alice arrives at the sleep specialist's 
> office and authorizes it to access her basic health data from her PCP. 
> The application at www.pcp.example.com verifies that Alice has 
> authorized www.sleepwell.example.com to access her health data as well 
> as enforces that www.sleepwell.example.com is the only application 
> that can retrieve that data with that specific authorization.
>
> Pre-conditions:
>
> * Alice has a personal health data store that allows for discovery of 
> her participating health systems (e.g. psychiatrist, sleep specialist, 
> pcp, orthodontist, ophthalmologist, etc).
> * The application at www.myhealth.example.com manages authorization of 
> access to Alice's participating health systems
> * The application at www.myhealth.example.com can issues authorization 
> tokens understood by Alice's participating health systems
> * The application at www.pcp.example.com stores Alice's basic health 
> and prescription records
> * The application at www.sleepwell.com stores results of Alice's sleep 
> tests
>
>
> Post-conditions:
> * A successful procedure results in just the information that Alice 
> authorized being transferred from the Primary Care Physician 
> (www.pcp.example.com) to the sleep specialist (www.sleepwell.example.com).
> * The transfer of health data only occurs if the application at 
> www.pcp.example.com can verify that www.sleepwell.example.com is the 
> party requesting access and that the authorization token presented by 
> www.sleepwell.example.com is issued by the application at 
> www.myhealth.example.com with a restricted audience of 
> www.sleepwell.example.com
>
> Requirements:
> * The application at www.sleepwell.example.com accesses 
> www.myhealth.example.com to discover the location of the PCP system 
> (XRD discovery)
> * The application at www.sleepwell.example.com requests Alice to 
> authorize access to the application at www.pcp.example.com for the 
> purpose of retrieving basic health data (e.g. date-of-birth, weight, 
> height, etc). The mechanism Alice uses to authorize this access is out 
> of scope for this use case.
> * The application at www.myhealth.example.com issues a token bound to 
> www.sleepwell.example.com for access to the application at 
> www.pcp.example.com. Note that a signed token (JWT) can be used to 
> prove who issued the token.
> * The application at www.sleepwell.example.com constructs a request 
> (includes the token issued by www.myhealth.example.com) to the 
> application at www.pcp.example.com
> * The application at www.sleepwell.example.com signs the request 
> before sending it to www.pcp.example.com
> * The application at www.pcp.example.com receives the request and 
> verifies the signature
> * The application at www.pcp.example.com parses the message and finds 
> the authorization token
> * The application at www.pcp.example.com verifies the signature of the 
> authorization token
> * The application at www.pcp.example.com parses the authorization 
> token and verifies that this token was issued to the application at 
> www.sleepwell.com
> * The application at www.pcp.example.com retrieves the requested data 
> and returns it to the application at www.sleepwell.example.com
>
>
>
> On 9/28/10 12:27 PM, Zeltsan, Zachary (Zachary) wrote:
>>
>> These use cases are not in the draft 
>> https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth.
>>
>> Could you write them up?
>>
>>  
>>
>> Thanks,
>>
>> Zachary
>>
>>  
>>
>> ------------------------------------------------------------------------
>>
>> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On 
>> Behalf Of *George Fletcher
>> *Sent:* Tuesday, September 28, 2010 11:39 AM
>> *To:* OAuth WG
>> *Subject:* Re: [OAUTH-WG] Signatures...what are we trying to solve?
>>
>>  
>>
>> I think of the signature issues as falling into two classes... I 
>> think they map to your classification as well...
>>
>>     * *Signing tokens* is important for interoperability especially
>>       looking forward to a time when tokens issued by multiple
>>       Authorization Servers are accepted at a given host.
>>     * *Signing messages* is important because it provides a mechanism
>>       to ensure that the entity making the API call (and presenting
>>       an access token) is really the entity that is allowed to make
>>       the API call.
>>
>> Signing messages applies to the re-delegation use cases. I've heard 
>> the need for this class of use cases from both the hData (health 
>> data) community as well as the user managed access (UMA) community.
>>
>> Signing tokens covers both your second class of tokens as well as 
>> another use case that Eran has mentioned as well. Namely, a protected 
>> resource server honoring tokens from multiple Authorization Servers.
>>
>> These are the two classes of use cases that I'd like to see solved.
>>
>> Thanks,
>> George
>>
>>
>> On 9/28/10 12:58 AM, David Recordon wrote:
>>
>> If you know me then you'll know that I'm generally one of the last 
>> people to talk about Alice and Bob. That said, there are a lot of 
>> technical proposals flying across the list with very little shared 
>> understanding of the problem(s) we're trying to solve.
>>
>>  
>>
>> From what I've seen there are two distinct classes of signature use 
>> cases.
>>
>> 1) The first is where the HTTP request parameters must be part of the 
>> signature. An example is any OAuth 1.0a style API where you want to 
>> make sure that the HTTP POST your server just received isn't 
>> masquerading itself as a GET.
>>
>> 2) The second is where the HTTP request is orthogonal. An example 
>> is OpenSocial where the server is sending state information to the 
>> client such as what user is currently logged in.
>>
>>  
>>
>> The main practical example I have of the first use case is what 
>> Twitter wants to do with redelegation. In this case TweetDeck can't 
>> given TwitPic it's own bearer token, but needs to sign the POST 
>> request and pass that signature to TwitPic for it to include in the 
>> final API request to Twitter.
>>
>>  
>>
>> In terms of signing protected resource requests, I haven't heard 
>> anyone bring up specific and detailed needs for this recently.
>>
>>  
>>
>> JSON tokens pretty clearly make sense for the second class of 
>> signature use cases and it's actually a bit hard to argue why they 
>> would be a part of OAuth. Facebook shipped this a bit over a month 
>> ago for canvas applications. We include a `signed_request` parameter 
>> which is signature.base64url(JSON). Parsing it is 18 lines of PHP. 
>> http://developers.facebook.com/docs/authentication/canvas
>>
>>  
>>
>> This second class of use case will also be required by OpenID Connect 
>> where the server is signing identity information and sending it to 
>> the client. I imagine that OpenSocial will also still have it and 
>> wish to continue relying on public key algorithms.
>>
>>  
>>
>> So a few questions:
>>
>>  * Do we want to tackle both of these classes of signatures in OAuth?
>>
>>  * Why do you consider the second class part of OAuth versus 
>> something completely separate that might happen to include an OAuth 
>> access token?
>>
>>  * Is the Twitter redelegation use case the right focus for the first 
>> class?
>>
>>  * Is there an example of an OAuth 2.0 server that can't use bearer 
>> tokens for protected resource requests and thus requires signatures?
>>
>>  
>>
>> Thanks,
>>
>> --David
>>
>>  
>>
>>  
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>  
>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>