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

John Bradley <ve7jtb@ve7jtb.com> Wed, 11 July 2012 10:37 UTC

Return-Path: <ve7jtb@ve7jtb.com>
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 B048F21F8656 for <oauth@ietfa.amsl.com>; Wed, 11 Jul 2012 03:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 h6wqCPZXVLk2 for <oauth@ietfa.amsl.com>; Wed, 11 Jul 2012 03:37:33 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id B606021F860E for <oauth@ietf.org>; Wed, 11 Jul 2012 03:37:23 -0700 (PDT)
Received: by qaea16 with SMTP id a16so764134qae.10 for <oauth@ietf.org>; Wed, 11 Jul 2012 03:37:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=mOt92uF7FEZfUYWR6wSnz2gX3s6Uwt7yBYMTq1+Dii4=; b=ASROfffy3kUejmnriiGatoLxSMLgWbQLnhanXPtccEivLuKeXP1rE5CiQoNxw2OwaQ PHtMMSataTV+H4ZUUORs1XTPbKtXeweaoim6LSzTWvF2sxoXbJ+REyoCdCtxWwUy3kSf cCUFRRvccDRQizD3WgNPuO0DG0MVTntxGtTnCBrA8i9YIzGSUp5D/adk42U7QDIUOSp3 /5nneM7C4UiwKcyB4oNNPvzZp6trRIuRdqsL25lIYLRBQiaKlYZ6ZsWCDZduTS/44DDS SKpXaQKozkbO+a/noQNX8oVdHs+5FJFSU4i7q520YDmP09g3wr5aUNvB8BECF0cIC8jI XNSg==
Received: by 10.229.111.74 with SMTP id r10mr19668788qcp.24.1342003073595; Wed, 11 Jul 2012 03:37:53 -0700 (PDT)
Received: from [192.168.5.185] (ip-64-134-65-40.public.wayport.net. [64.134.65.40]) by mx.google.com with ESMTPS id et8sm2744321qab.9.2012.07.11.03.37.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Jul 2012 03:37:52 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="windows-1252"
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F7A12C10@WSMSG3153V.srv.dir.telstra.com>
Date: Wed, 11 Jul 2012 06:37:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <E105DB5B-CFDB-442F-A90A-39F08A4D74E8@ve7jtb.com>
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>
To: "Manger, James H" <James.H.Manger@team.telstra.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQm8fVNf3JLlbWfYbyGJtHKnj47CtFajE2RTZH9rnCWcfrcYdKZ4h6ReTKd17Qea5xt6DCd/
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:37:35 -0000

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