Re: [OAUTH-WG] Using Referred Token Binding ID for Token Binding of Access Tokens

Torsten Lodderstedt <torsten@lodderstedt.net> Sun, 13 November 2016 08:18 UTC

Return-Path: <torsten@lodderstedt.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 83FC4129477 for <oauth@ietfa.amsl.com>; Sun, 13 Nov 2016 00:18:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.111
X-Spam-Level:
X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbtQpG1HkAqM for <oauth@ietfa.amsl.com>; Sun, 13 Nov 2016 00:18:18 -0800 (PST)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69CB9129431 for <oauth@ietf.org>; Sun, 13 Nov 2016 00:18:18 -0800 (PST)
Received: from [58.120.104.2] (helo=[192.168.101.95]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <torsten@lodderstedt.net>) id 1c5pzT-00055s-1w; Sun, 13 Nov 2016 09:18:15 +0100
To: Mike Jones <Michael.Jones@microsoft.com>, "oauth@ietf.org" <oauth@ietf.org>
References: <CO2PR03MB2358D7F80F3AB286A38082F6F5F70@CO2PR03MB2358.namprd03.prod.outlook.com> <5827FEA5.5090906@lodderstedt.net> <CO2PR03MB235848A7FA8FDC21AA53C468F5BD0@CO2PR03MB2358.namprd03.prod.outlook.com>
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-ID: <582821C3.8090005@lodderstedt.net>
Date: Sun, 13 Nov 2016 17:18:11 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <CO2PR03MB235848A7FA8FDC21AA53C468F5BD0@CO2PR03MB2358.namprd03.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------000501090606060608040307"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/3-9vmLnFtdFQlYWge0231PKgUrs>
Subject: Re: [OAUTH-WG] Using Referred Token Binding ID for Token Binding of Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 13 Nov 2016 08:18:21 -0000

thanks. So the underlying implementation is supposed to create the 
signed data (TokenBindingMessage) and the client (or library) is 
supposed to create the header?

Am 13.11.2016 um 15:43 schrieb Mike Jones:
>
> The HTTP header is described in 
> https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section-2 
> where it talks about a Sec-Token-Binding Header Field with a 
> TokenBindingMessage with a TokenBinding structure with 
> TokenBindingType of referred_token_binding.
>
> The example is a good idea.
>
> -- Mike
>
> *From:*Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> *Sent:* Sunday, November 13, 2016 2:48 PM
> *To:* Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Using Referred Token Binding ID for Token 
> Binding of Access Tokens
>
> Hi Mike,
>
> does this mean the binding ID is indicated to the authorization server 
> via a respective HTTP header? I'm asking because I didn't find the 
> respective parameter in the draft.
>
> Could you add a HTTP request example? I think that would help a lot to 
> better understand the mechanism.
>
> best regards,
> Torsten.
>
> Am 20.09.2016 um 21:16 schrieb Mike Jones:
>
>     The OAuth Token Binding specification has been revised to use the
>     Referred Token Binding ID when performing token binding of access
>     tokens.  This was enabled by the Implementation Considerations in
>     the Token Binding HTTPS specification being added to make it clear
>     that Token Binding implementations will enable using the Referred
>     Token Binding ID in this manner.  Protected Resource Metadata was
>     also defined.
>
>     Thanks to Brian Campbell for clarifications on the differences
>     between token binding of access tokens issued from the
>     authorization endpoint versus those issued from the token endpoint.
>
>     The specification is available at:
>
>     ·http://tools.ietf.org/html/draft-ietf-oauth-token-binding-01
>
>     An HTML-formatted version is also available at:
>
>     ·http://self-issued.info/docs/draft-ietf-oauth-token-binding-01.html
>
>     -- Mike
>
>     P.S.  This notice was also posted at
>     http://self-issued.info/?p=1610 <http://self-issued.info/?p=1610>
>     and as @selfissued <https://twitter.com/selfissued>.
>
>
>
>
>     _______________________________________________
>
>     OAuth mailing list
>
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>
>     https://www.ietf.org/mailman/listinfo/oauth
>