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

George Fletcher <gffletch@aol.com> Thu, 07 October 2010 14:11 UTC

Return-Path: <gffletch@aol.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 1619F3A6F5B for <oauth@core3.amsl.com>; Thu, 7 Oct 2010 07:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.288
X-Spam-Level:
X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=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 ldSTLhWbs0lD for <oauth@core3.amsl.com>; Thu, 7 Oct 2010 07:11:49 -0700 (PDT)
Received: from imr-ma06.mx.aol.com (imr-ma06.mx.aol.com [64.12.78.142]) by core3.amsl.com (Postfix) with ESMTP id BA4B23A6F34 for <oauth@ietf.org>; Thu, 7 Oct 2010 07:11:48 -0700 (PDT)
Received: from mtaout-da06.r1000.mx.aol.com (mtaout-da06.r1000.mx.aol.com [172.29.51.134]) by imr-ma06.mx.aol.com (8.14.1/8.14.1) with ESMTP id o97ECSS5015006; Thu, 7 Oct 2010 10:12:28 -0400
Received: from palantir.local (unknown [10.172.2.114]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da06.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 11252E0000EA; Thu, 7 Oct 2010 10:12:22 -0400 (EDT)
Message-ID: <4CADD544.9070100@aol.com>
Date: Thu, 07 Oct 2010 10:12:20 -0400
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: Prateek Mishra <prateek.mishra@oracle.com>
References: <AANLkTimERshG-ndU8_uc0NJhx6ree6d8kxYj=EVeHpmA@mail.gmail.com> <4CA20BFC.90704@aol.com> <5710F82C0E73B04FA559560098BF95B124FB233412@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4CA9FEAC.8090407@aol.com> <4CADD1C7.8050205@oracle.com>
In-Reply-To: <4CADD1C7.8050205@oracle.com>
Content-Type: multipart/alternative; boundary="------------020709050403040003010706"
x-aol-global-disposition: G
X-AOL-SCOLL-SCORE: 0:2:472980608:93952408
X-AOL-SCOLL-URL_COUNT: 0
x-aol-sid: 3039ac1d33864cadd54670bc
X-AOL-IP: 10.172.2.114
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 14:11:53 -0000

  Hi Prateek,

I think that message signing has a number of benefits. The one you state 
is as important as any others. I was just writing up one use case as a 
justification for signatures. Not trying to cover them all:)

Looking forward to your feedback.

Thanks,
George

On 10/7/10 9:57 AM, Prateek Mishra wrote:
> 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