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
- [OAUTH-WG] Signatures...what are we trying to sol… David Recordon
- Re: [OAUTH-WG] Signatures...what are we trying to… George Fletcher
- Re: [OAUTH-WG] Signatures...what are we trying to… Zeltsan, Zachary (Zachary)
- Re: [OAUTH-WG] Signatures...what are we trying to… William Mills
- Re: [OAUTH-WG] Signatures...what are we trying to… George Fletcher
- [OAUTH-WG] Signatures don't solve that problem (w… Freeman, Tim
- Re: [OAUTH-WG] Signatures don't solve that proble… George Fletcher
- Re: [OAUTH-WG] Signatures don't solve that proble… Igor Faynberg
- Re: [OAUTH-WG] Signatures don't solve that proble… Zeltsan, Zachary (Zachary)
- Re: [OAUTH-WG] Signatures don't solve that proble… Freeman, Tim
- Re: [OAUTH-WG] Signatures...what are we trying to… Prateek Mishra
- Re: [OAUTH-WG] Signatures...what are we trying to… George Fletcher
- Re: [OAUTH-WG] Signatures...what are we trying to… Freeman, Tim