Return-Path: 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 2ED1E3A6FD9 for ; Mon, 4 Oct 2010 09:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.391 X-Spam-Level: X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[AWL=-1.277, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, 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 lCgnIDAnkhZ6 for ; Mon, 4 Oct 2010 09:19:35 -0700 (PDT) Received: from imr-db03.mx.aol.com (imr-db03.mx.aol.com [205.188.91.97]) by core3.amsl.com (Postfix) with ESMTP id 2BB813A6CAB for ; Mon, 4 Oct 2010 09:19:35 -0700 (PDT) Received: from mtaout-da02.r1000.mx.aol.com (mtaout-da02.r1000.mx.aol.com [172.29.51.130]) by imr-db03.mx.aol.com (8.14.1/8.14.1) with ESMTP id o94GJxu7015788; Mon, 4 Oct 2010 12:19:59 -0400 Received: from palantir.local (unknown [10.181.183.108]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da02.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 5EF47E000087; Mon, 4 Oct 2010 12:19:58 -0400 (EDT) Message-ID: <4CA9FEAC.8090407@aol.com> Date: Mon, 04 Oct 2010 12:19:56 -0400 From: George Fletcher 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: "Zeltsan, Zachary (Zachary)" References: <4CA20BFC.90704@aol.com> <5710F82C0E73B04FA559560098BF95B124FB233412@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <5710F82C0E73B04FA559560098BF95B124FB233412@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------010205030904060000090408" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:466027680:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33824ca9feae4517 X-AOL-IP: 10.181.183.108 Cc: OAuth WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 16:19:40 -0000 This is a multi-part message in MIME format. --------------010205030904060000090408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 > https://www.ietf.org/mailman/listinfo/oauth > --------------010205030904060000090408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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
https://www.ietf.org/mailman/listinfo/oauth

 


--------------010205030904060000090408--