[OAUTH-WG] OAUTB for Access Token in Implicit Grant

pedram.h@gmx.de Mon, 14 May 2018 12:46 UTC

Return-Path: <pedram.h@gmx.de>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 24919124239 for <oauth@ietfa.amsl.com>; Mon, 14 May 2018 05:46:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id b6EKSVjfXYwP for <oauth@ietfa.amsl.com>; Mon, 14 May 2018 05:46:56 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0207512DB6B for <oauth@ietf.org>; Mon, 14 May 2018 05:46:55 -0700 (PDT)
Received: from [] ([]) by mail.gmx.com (mrgmx102 []) with ESMTPSA (Nemesis) id 0M96Jd-1f84O13vQL-00CVGQ for <oauth@ietf.org>; Mon, 14 May 2018 14:46:53 +0200
To: oauth@ietf.org
From: pedram.h@gmx.de
Message-ID: <df0f8268-13a8-90d7-fc40-32e5b7371cc9@gmx.de>
Date: Mon, 14 May 2018 14:46:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------7501F0E4A4881930DD4FDF5F"
Content-Language: en-US
X-Provags-ID: V03:K1:UYQhQo6v7byUrKT5yRFWjzlc6LTL5oRQT7osicQ77wUipGdz7th Qsf/WCqA7evzlr/gOCam/49K7g+X7rz/zbFUhOFT2rvxevYaqFMKhzSJy3lPaNhnCYW2EIe T/evBtZCYj26k7GoCBjMrQJrp8Y75TsGqPkMuZyfW9dnksUMr1RwAB20wZdegE4kNElcZSJ Vjdhuagc6VEgeCiWTE+6g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:7WGvYPt9X/U=:wRVA6yxxiePtnow4OwzfT2 jYbuDqBtyytnJuk48+D0f5TxKeG9KtkK6KQxx6Ap4l3yCQS+rSF7Pg74NDrxsQZZnzE0c1o0p J3CnAR6qWUxvZKtYpHPQVOX0hTU2sU5EvQkXlJ5LvJN5dfvPBQF/JEq7sx1zKCaVlHNE9iz7G aWuLru+4Z7u6eYxFE8pd3QZIbspuPIcWhpx34s/gmvsPUqYAXjb/DFUhD5gx2X7z6F8hrxS9n l0nzFzxkjUbl+/+j4kgCqwLrG1f8zSXTTuGyHKCD+39z+toZ8a6D2iZZZOm/uDVJ5RkK1laS/ fYVtXoE8RyFWDQiSIHu92/aFNO6Ry1pXswOd+BNh1BPVgKvaDP+nqy8XoABvlCPH4mhWpMX2M 6QOZKksZ4YC2NHkAvs4Awarmp9aGyM8lz6DKpABugCSFRne/tE0mT/2BLGBQaYBXoQOhkjUhc u/Qf+YSNPe/HIVKoILvojpNWXo9HxiACcyLC7vh1KAgYiH5DZOVa5ADpqpo8ABey2TnvDEE9c 9Kx728Kdsbvb7dHWbkJ020JUQDKd6CjUaW9DR9btb7wjX9AA6UKqCBDXN4nJhp12oiYpIfyPM K8kM7QBrubH83xuLGYaFYj1LrC5VX6SOTP1pILNBR+fN+9ROajn5OsnrkExfdCPJBak8/bqqQ H7oFmRRSguXD6W0T696yNLUeBPrMNQASPeuQf7MGkDXXJZRK8l37iLPBG9EprDYHM4bNvv65G +Vf/15TgO4kOH95Jrl2lgBX2atqeoYvCFLEeg3gWqMD1g++XGP4FYl31cb1pjW3xTBttFJ2Zw UFjk36M
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/BFtR_Sd0EpLUVEYU27vHGgbCRHo>
Subject: [OAUTH-WG] OAUTB for Access Token in Implicit Grant
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 14 May 2018 12:46:58 -0000

Dear all,
We are currently modeling part 1 and part 2 of the OpenID Financial API 
in the FKS Web Model and have a few questions regarding the OAuth 2.0 
Token Binding.
In section 3.1. of draft-ietf-oauth-token-binding-06, it is not very 
clear how an Access Token issued from the Authorization Endpoint is 
Token Bound. Is this intended to be the same as an AC issued for a web 
server client? It seems that the user-agent sends both the Provided and 
Referred Token Bindings to the AS, which means that the AS can bind the 
Access Token to the Referred Token Binding, which is the Token Binding 
between the user-agent and the client.
However, the Access Token is not used by the user-agent, which means 
that the client can only send the Token Binding ID used by the 
user-agent (which essentially is the public key) to the Resource Server.
Is this the intended flow of the Token Binding? Because the first 
paragraph of 3.1 says that the "Token Binding ID of the client's TLS 
channel to the protected resource is sent with the authorization request 
as the Referred Token Binding ID", but we assume that the user-agent 
reveals the TB-ID of its own channel to the client.
Best regards,
Pedram Hosseyni