[OAUTH-WG] notes from OAuth & Token Binding side-meeting @IETF-95 ?
=JeffH <Jeff.Hodges@KingsMountain.com> Thu, 28 April 2016 17:55 UTC
Return-Path: <Jeff.Hodges@kingsmountain.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 7AA6B12D90F for <oauth@ietfa.amsl.com>; Thu, 28 Apr 2016 10:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.com
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 5fAKQhUGpXiS for <oauth@ietfa.amsl.com>; Thu, 28 Apr 2016 10:55:24 -0700 (PDT)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id B08D512D8D7 for <oauth@ietf.org>; Thu, 28 Apr 2016 10:55:24 -0700 (PDT)
Received: (qmail 10359 invoked by uid 0); 28 Apr 2016 17:55:24 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy8.mail.unifiedlayer.com with SMTP; 28 Apr 2016 17:55:24 -0000
Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id ntvK1s0192UhLwi01tvN7F; Thu, 28 Apr 2016 11:55:23 -0600
X-Authority-Analysis: v=2.1 cv=G/WPTbU5 c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=xKbBrD9yMjQA:10 a=kziv93cY1bsA:10 a=is3RsFX7AAAA:8 a=48vgC7mUAAAA:8 a=D7VcmPz0k-Jh5F6QR4oA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:To:Subject:From; bh=m4PXFvmo3gWkZwT3PLVlZnx3B5ln+IwqQpgiE+WSit8=; b=qKaUHQ+CcfcEg8bsAm/0Xk1BV4 +LNpu0Dqe3sTqduRNpCIf7mWntoWmKT/RFqjhNJVEXeipVz9d4jYyH+vmDVhoj76yee7/v/EQMYBx tIGg+NDBkmxwF105u1aSMGzKB;
Received: from [70.197.4.93] (port=12686 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1avq9p-0005oY-3C for oauth@ietf.org; Thu, 28 Apr 2016 11:55:21 -0600
From: =JeffH <Jeff.Hodges@KingsMountain.com>
To: IETF OAuth WG <oauth@ietf.org>
Message-ID: <57224E7F.6080801@KingsMountain.com>
Date: Thu, 28 Apr 2016 10:55:11 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.197.4.93 authed with jeff.hodges+kingsmountain.com}
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/AerEoNuzAdKaHeHfFBZj9GSPldk>
Subject: [OAUTH-WG] notes from OAuth & Token Binding side-meeting @IETF-95 ?
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: Thu, 28 Apr 2016 17:55:26 -0000
I don't see any notes posted here <openid-specs-ab@lists.openid.net> In case it is helpful, I was taking personal notes mostly from the Token Binding perspective, and noted.. * it seems that oauth folk will need to write their own oauth token binding spec rather than re-use the -tokbind-https spec [1] * it may be the case that the semantics are equivalent to referred_token_binding type and so there may be no need to invent a new TBType * we ought to explain better in -tokbind-protocol [2] the separation of the proof-of-possesion & the allocation of Token Binding IDs (TBIDs), and the incorporation of TBIDs in app-layer objects, eg OAuth tokens, HTTP cookies, etc. HTH, =JeffH [1] https://tools.ietf.org/html/draft-ietf-tokbind-https [2] https://tools.ietf.org/html/draft-ietf-tokbind-protocol