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

"Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com> Tue, 28 September 2010 16:26 UTC

Return-Path: <zachary.zeltsan@alcatel-lucent.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 0015D3A6D6C for <oauth@core3.amsl.com>; Tue, 28 Sep 2010 09:26:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.561
X-Spam-Level:
X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, 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 PMUDxm470Ivi for <oauth@core3.amsl.com>; Tue, 28 Sep 2010 09:26:32 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 0C92E3A6D4F for <oauth@ietf.org>; Tue, 28 Sep 2010 09:26:31 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o8SGRCT3024427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Sep 2010 11:27:12 -0500 (CDT)
Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o8SGRBNT022927 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 Sep 2010 11:27:11 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 28 Sep 2010 11:27:11 -0500
From: "Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com>
To: "'George Fletcher'" <gffletch@aol.com>, OAuth WG <oauth@ietf.org>
Date: Tue, 28 Sep 2010 11:27:11 -0500
Thread-Topic: [OAUTH-WG] Signatures...what are we trying to solve?
Thread-Index: ActfI6PIprftv1XyRgeO1VixwDEwbgABUBFQ
Message-ID: <5710F82C0E73B04FA559560098BF95B124FB233412@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References: <AANLkTimERshG-ndU8_uc0NJhx6ree6d8kxYj=EVeHpmA@mail.gmail.com> <4CA20BFC.90704@aol.com>
In-Reply-To: <4CA20BFC.90704@aol.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_5710F82C0E73B04FA559560098BF95B124FB233412USNAVSXCHMBSA_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
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: Tue, 28 Sep 2010 16:26:34 -0000

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