Re: [OAUTH-WG] Holder-of-the-Key for OAuth

Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 11 July 2012 10:48 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50B721F85A0 for <oauth@ietfa.amsl.com>; Wed, 11 Jul 2012 03:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.384
X-Spam-Level:
X-Spam-Status: No, score=-102.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTeT-wsGp1qd for <oauth@ietfa.amsl.com>; Wed, 11 Jul 2012 03:48:26 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 6E95A21F8569 for <oauth@ietf.org>; Wed, 11 Jul 2012 03:48:25 -0700 (PDT)
Received: (qmail invoked by alias); 11 Jul 2012 10:48:54 -0000
Received: from unknown (EHLO [10.255.128.232]) [194.251.119.201] by mail.gmx.net (mp001) with SMTP; 11 Jul 2012 12:48:54 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18LjGM1bQELQP75WF0L4zibL8GibpmnDhmW6gS1DK SrEUn2agGtUyGo
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="windows-1252"
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
In-Reply-To: <E105DB5B-CFDB-442F-A90A-39F08A4D74E8@ve7jtb.com>
Date: Wed, 11 Jul 2012 13:48:49 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <208DC624-7422-4166-B579-9328F09218D1@gmx.net>
References: <8FB1BC31-D183-47A0-9792-4FDF460AFAA1@gmx.net> <255B9BB34FB7D647A506DC292726F6E114F7977420@WSMSG3153V.srv.dir.telstra.com> <1341939214.6093.YahooMailNeo@web31811.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E114F7977D9C@WSMSG3153V.srv.dir.telstra.com> <ED7B5A28-B1FA-40AF-9916-4A272BA56F4A@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F7A12C10@WSMSG3153V.srv.dir.telstra.com> <E105DB5B-CFDB-442F-A90A-39F08A4D74E8@ve7jtb.com>
To: John Bradley <ve7jtb@ve7jtb.com>
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 11 Jul 2012 10:48:26 -0000

It is certainly a plus that we can now make use of the JSON work. This will improve interoperability and avoid making implementation mistakes if developers use libraries (with the JOSE features). 
 
On Jul 11, 2012, at 1:37 PM, John Bradley wrote:

> The POST of a signed blob would work with JOSE or CMS signing the blob.
> 
> I suspect that would be more of a application level signing than OAuth though.
> Though worth talking about.
> 
> I suspect a OAuth level signing might look a bit like HMAC.
> 
> The access_token might be:
> 1 a JWT including a JWK structure for the proof key (public key or key reference).
> 2 a opaque token that is used by the Protected resource to look up the actual token via a STS like mechanism.   
> 3 a SAML token in JOSE is also a possibility for some people.
> 
> The above choice should be opaque to the client.
> 
> For asymmetric binding the key to TLS seems like a good idea.  There are however many practical key management issues that clients may have (especially if multiple keys are used) and it may not be end to end.  
> 
> Another OAuth binding might be to use a token collection.  One being the access token and another being a JWT/JWS containing one or more hashes of the HTTP message or message components.
> 
> I don't want to reinvent SOAP, or WS-Security, however I also don't want to reject all of the use-cases out of hand.
> 
> The common uses need to be dead simple for clients.
> 
> John B.
> 
> 
> 
> On 2012-07-11, at 3:37 AM, Manger, James H wrote:
> 
>>>> John Bradley wrote:
>>>>> I suspect that we will need two OAuth bindings. One for TLS and one for signed message.
>>>> 
>>>> I agree. For instance, set “token_type”:”tls_client_cert” when the client has to use TLS; set “token_type”:”cms” when the client has to digitally sign messages using Crypto Message Syntax (CMS); ….
>> 
>>> Perhaps JWT/JOSE rather than CMS:)
>>> 
>>> Though there will need to be discussions about what part of the message needs to be signed.
>> 
>> I was about to list JOSE as the example, but baulked precisely because of this issue. It wasn't obvious how a request to a protected resource would be wrapped in a JOSE message. At least with CMS (or WS-*, or XML DSig, or SOAP…) you can guess that the request is a POST of a signed blob.
>> 
>> --
>> James Manger
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth