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

[Prateek Mishra <[e-mail]>]

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:* [e-mail] [mailto:[e-mail]] *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
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>  
>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>