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 >
- [OAUTH-WG] Using Referred Token Binding ID for To… Mike Jones
- Re: [OAUTH-WG] Using Referred Token Binding ID fo… Torsten Lodderstedt
- Re: [OAUTH-WG] Using Referred Token Binding ID fo… Mike Jones
- Re: [OAUTH-WG] Using Referred Token Binding ID fo… Torsten Lodderstedt