[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [212.227.17.20]) (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 [141.58.59.198] ([141.58.59.198]) by mail.gmx.com (mrgmx102 [212.227.17.168]) 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
- [OAUTH-WG] OAUTB for Access Token in Implicit Gra… pedram.h
- Re: [OAUTH-WG] OAUTB for Access Token in Implicit… Brian Campbell
- Re: [OAUTH-WG] OAUTB for Access Token in Implicit… Daniel Fett
- Re: [OAUTH-WG] OAUTB for Access Token in Implicit… Brian Campbell
- Re: [OAUTH-WG] OAUTB for Access Token in Implicit… Daniel Fett