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

George Fletcher <> Thu, 07 October 2010 14:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1619F3A6F5B for <>; Thu, 7 Oct 2010 07:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.288
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ldSTLhWbs0lD for <>; Thu, 7 Oct 2010 07:11:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BA4B23A6F34 for <>; Thu, 7 Oct 2010 07:11:48 -0700 (PDT)
Received: from ( []) by (8.14.1/8.14.1) with ESMTP id o97ECSS5015006; Thu, 7 Oct 2010 10:12:28 -0400
Received: from palantir.local (unknown []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (MUA/Third Party Client Interface) with ESMTPSA id 11252E0000EA; Thu, 7 Oct 2010 10:12:22 -0400 (EDT)
Message-ID: <>
Date: Thu, 07 Oct 2010 10:12:20 -0400
From: George Fletcher <>
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: Prateek Mishra <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------020709050403040003010706"
x-aol-global-disposition: G
X-AOL-SCOLL-SCORE: 0:2:472980608:93952408
x-aol-sid: 3039ac1d33864cadd54670bc
Cc: OAuth WG <>
Subject: Re: [OAUTH-WG] Signatures...what are we trying to solve?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


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
> - 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 ( Alice's Primary Care Physician 
>> ( recommends that Alice see a sleep specialist 
>> ( Alice arrives at the sleep specialist's 
>> office and authorizes it to access her basic health data from her 
>> PCP. The application at verifies that Alice has 
>> authorized to access her health data as 
>> well as enforces that 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 manages authorization 
>> of access to Alice's participating health systems
>> * The application at can issues 
>> authorization tokens understood by Alice's participating health systems
>> * The application at stores Alice's basic health 
>> and prescription records
>> * The application at 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 
>> ( to the sleep specialist 
>> (
>> * The transfer of health data only occurs if the application at 
>> can verify that is the 
>> party requesting access and that the authorization token presented by 
>> is issued by the application at 
>> with a restricted audience of 
>> Requirements:
>> * The application at accesses 
>> to discover the location of the PCP system 
>> (XRD discovery)
>> * The application at requests Alice to 
>> authorize access to the application at 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 issues a token bound to 
>> for access to the application at 
>> Note that a signed token (JWT) can be used to 
>> prove who issued the token.
>> * The application at constructs a request 
>> (includes the token issued by to the 
>> application at
>> * The application at signs the request 
>> before sending it to
>> * The application at receives the request and 
>> verifies the signature
>> * The application at parses the message and finds 
>> the authorization token
>> * The application at verifies the signature of 
>> the authorization token
>> * The application at parses the authorization 
>> token and verifies that this token was issued to the application at 
>> * The application at retrieves the requested data 
>> and returns it to the application at
>> On 9/28/10 12:27 PM, Zeltsan, Zachary (Zachary) wrote:
>>> These use cases are not in the draft 
>>> Could you write them up?
>>> Thanks,
>>> Zachary
>>> ------------------------------------------------------------------------
>>> *From:* [] *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. 
>>> 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 mailing list