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

Daniel Fett <daniel.fett@sec.uni-stuttgart.de> Wed, 23 May 2018 16:27 UTC

Return-Path: <daniel.fett@sec.uni-stuttgart.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 31B0F1275AB for <oauth@ietfa.amsl.com>; Wed, 23 May 2018 09:27:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni-stuttgart.de
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 zMXpT0KGcez3 for <oauth@ietfa.amsl.com>; Wed, 23 May 2018 09:27:09 -0700 (PDT)
Received: from mxex2.tik.uni-stuttgart.de (mxex2.tik.uni-stuttgart.de [IPv6:2001:7c0:2041:24::a:2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DC4B127286 for <oauth@ietf.org>; Wed, 23 May 2018 09:27:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mxex2.tik.uni-stuttgart.de (Postfix) with ESMTP id 3D729793CD; Wed, 23 May 2018 18:27:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=uni-stuttgart.de; h=content-language:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject:received:received; s=dkim; i= @sec.uni-stuttgart.de; t=1527092824; x=1528831625; bh=C/nXQ62cHb 36YgDa5xZZSs+TPQ8gt05tiwgNZjClxxQ=; b=sx3z51gHiZ+LJGdtDyoakn1mNL CYAI5SDsL0b/T8+VZ/obq0kF5nfxN34yJGBE8HiZUYpUTeM9Nxgx4Giq3WkhQ4qH +MaV/SKBlDF6qAmjpXqcrdntERmncYb8CUqBREiBtO26/Kb3YcFANAjPCiolXPj8 sw8yxbAWG0QRODzBiaSASRagxUodCT6A9XBF2sZoJbAJhHxxWTD4yeVQP+GLRP64 bfQbgp9Eu/uBH9hWtOpG3T0TRHDvl9zhSh3qzlU/qsPhJAaLOXP8j4hNIz+j6GWr 5REagpdCAKCmzoYmIaLmJ6M4Mgym9QLr9QvjbUzLjpSj56TUCK3JoRR3fNaA==
X-Virus-Scanned: USTUTT mailrelay AV services at mxex2.tik.uni-stuttgart.de
Received: from mxex2.tik.uni-stuttgart.de ([127.0.0.1]) by localhost (mxex2.tik.uni-stuttgart.de [127.0.0.1]) (amavisd-new, port 10031) with ESMTP id bmKJmLSlxyG9; Wed, 23 May 2018 18:27:04 +0200 (CEST)
Received: from [IPv6:2001:7c0:2015:182::1:32] (unknown [IPv6:2001:7c0:2015:182::1:32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mxex2.tik.uni-stuttgart.de (Postfix) with ESMTPSA; Wed, 23 May 2018 18:27:03 +0200 (CEST)
To: oauth@ietf.org
References: <df0f8268-13a8-90d7-fc40-32e5b7371cc9@gmx.de> <CA+k3eCRT-Paqq5_jLFNpH9n6Se6K+dOcvD+o2-99zBAcPHedmg@mail.gmail.com>
From: Daniel Fett <daniel.fett@sec.uni-stuttgart.de>
Openpgp: preference=signencrypt
Autocrypt: addr=daniel.fett@sec.uni-stuttgart.de; prefer-encrypt=mutual; keydata= xsFNBFbu2RUBEAC3F5+IMjFcXSj46xS8QQe6d/FAb+7IkkOdFKrINhgCialH4enWB2V3ykOX xESdrchRBCLoePyNmoJdFTijGxBMGNqSKU9rrppF5uvPFv/qIvCaBDAjFXR+qshsHjsMxTNH 67kuhkFQczKQHs4KVICG/gnssC3iejrk6Mav0MIJKXXdz6bUQPDyUTD+LsyHJ7vNfkfitnO4 rbD+kEZ0n14dQqp+c91b7X5KZVTt1c3d/N1kbruS29SlIDUJSHV0AdDZmP6wuH5a9XUIlDkP mM2bncIry3xiXWolYf3BJigxYg1XwVMYBdsrVg4kID5WY1RCHns07cDGluERcurjj3QHjToL T7VemcnFVzSphjjisi9a1QfRYCPf5xw5L8IjsAuNTBLv2DXKtL6Mf5Tv9BAZPD2em0rNS5n/ M7S6D2AAxIt9BQQ4aS16faI0gfUspj09RLdHANwOcLUPu+OE+O2IdgglBQLkadwLj9aY0ncE 8GhqFWcQ9xbtvHAljYaz5VmsOnjsadfGD8xW+QtWeFc8mfq7PncRjrc0Ywtb8TKeXkLHUQoT 4v2ilXisfOhryVj6/GuQvDjKKyUBW1tQPxei4n/W0zBC4LWehmwCH+WrFt+mTh3uHSyy9VbR FYmY6MBBMUpHHVQ3AVLgxoldu/yX/ery+fdE8MeScAWg+WE5rQARAQABzSBEYW5pZWwgRmV0 dCA8ZmV0dEBkYW5pZWxmZXR0LmRlPsLBgAQTAQgAKgIbAwUJC0c1AAULCQgHAwUVCgkICwUW AgMBAAIeAQIXgAUCVu7cmAIZAQAKCRBYD1kOlZ2qqXCPD/wLpgL6j51OUlGzLaA+Xt+QzX/v qUiHJsvv1mEnyofk/3pGr7ce/1UNp7e8/W2JnnHvz4RBaNkn07DFyOvrVNXiMyU6mKWvG6xw Ri5Qc2t1Cup+mXlNc5fxlZGnwOYXZJErYVTPodkFlbb6LKUMyg6v2P7ZEvw4YyPh7WpV5ujF VVkYBSLviNCjVwKr8WlJJlVI4uvHZshnX85lVpRNcF+Hqf7IhnJzCQ5bUNnV7aKc4WPNw7L6 EquuCAl6JGKdeV2M+S5UVN9Eaa/CQxJf8X9I3SVgWCGQ/gLt0x1oKt6oFMECJcH2LDFOJyWv 61AUIzqCdRiTUagdc+7sn2OFbbjhKin9x+Qq6pyoXa6ZcpEuyBoAy+hNU8RAXcPgvEBy4Bwx BYQ9S3uQmBx/TcYgSUbBwBhvIYRVM5DfBefolj3HyUlvHx8JO8scbdcVl+v1+f9d5x4YS16t bWNe7awE6UWM2I02+uv7SI2ieJ2zQsOulDTEYVYjWcu0hBH24K53wniyh3JHzu6RVCgewx4P 6H2WHOSVf2p9ppuIrbWh7J6pp9nFdDXESKxH3GO5LooLamGugSlRwdgsqxY0O4BbCpKIpfe8 31peA+7qbh1f4TXHo/ZQE8fZ2s4VN5XR5J5/yjfqY2pWDy1XocixzXboLAcuzGmZNutS46eH Azjo2CxTa87BTQRW7tkVARAA1cAIBWNxYj/QE7RcOHGgr8xXcKWk/wwTWgLvjEbp5tqMl3Jk EwD1Iajz1s+Qp7U+U4UqyI+ZSfm03bYFYlTyKaS2esiM+Incutg18N943xwGNc6csyNoW5/f xbDQ4hoMKsod9zjfvxpA8xLg8gjuPKi5Y698K7qDCCfGvo6e67qwFWIvrB7cv/NAoaVd1OPI 79nt2H5yWo0PE2Kd2yAMnWJ/3clLR6X4jqkmpoc2uEPE6aM7iQ6SCx7rMFP9W9OvovnzVksS dh65JRkiA3DTUWBxZM6h/oEERBTr9Q/JYXXugO300loterwBVu0ymBHdAjIlxpetFwZu/Wlb nymC4VSxGPS/+mJ9Lnh3WWjVEcP5F9WgqmfJ49BNqOjmgZ9u9VYV8R9fOaYvtPFTdGTYT9iw JYic/0xt9NcW/hRkff0UHdiN/BrTxbHVI7Qf4MLBK/+VtqVi0MLs7U80/2fPRebTq4yQ6aoY 7hErExrJ7TgTmZghsBJTd2cmau26Kb7stLJ4ySADcyrsADl03MNoj8QqVuO8HXx2InM18sHP xldjovv8dhmj7uiKmMPAqq5f8pA5bcA/EQ6S+ItjjohSLiYQtq6UgDPlt4tIA9nCfx+cGi6f o4sJE0InaQLinm0USp0zE+slpqXGwjzeFSTioL81cDGhN3dcCK94VsntblsAEQEAAcLBZQQY AQgADwUCVu7ZFQIbDAUJC0c1AAAKCRBYD1kOlZ2qqdnTD/9fOyWwdhOv4ehtR8ShfhM1FAc8 bWMfCrxTpI4baPM4fqIFgMAJ9iQ0FF6cB0zQjDwsWNC+3t+2JdiNeM8FB7s4bbJlhjaavzKK 77Kbf4WpVs7ge0+Zghc2qHRg/SQeC1G26GzSZDDWzDHFZX0va8H0KmT/tHJYD263CIcff/E9 WXT/22rrgYvuQXPIOBzON9WqUkCAvPA19xuBsDQSbXkXwiPsZRqmyktjc8GQn1iemQ/dzlU/ e6ORNrPcK15kUyPyJMaZf+6QJ8EivUyg+pTXicEcghWNYHXxop4k0y+bsay0cBN2lmNu7UEF qhO8HQmp2jrwZXFZD/fbZukXFHNWvNsvQ55flUfajPZhUokXHskkerbq6ZCS58HkWl0tqSIb 5TxNfP0zjcrlDBc8sF6UHXgNR1oUXypGOAq4iHeJNVpI4aQm/PufmeGExx6lPtJxJ9jOs5gD rYRuBfa1cJznEPNbIe0/eCv5qDpf95csdGJhM418x2xeg58PbmBByS9MXOGFtli0K9sxIej/ YdA94hlk/R9ViIPDuqDxz0PP+IRFVVOQhOprSnG8cV31oOe00e1bIBH3ttdsgp3AHqz/zlfF kZt27s1VH+aRF4STntrU97dNmxrgjq8zUZ7VgYjq8KqLg0BsDRIy4b/AnptYh6E4oE74gKCo Qoim4V9DGw==
Message-ID: <b18d8187-d011-2b40-3055-e0c5ef8f564d@sec.uni-stuttgart.de>
Date: Wed, 23 May 2018 18:27:19 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Thunderbird/57.0
MIME-Version: 1.0
In-Reply-To: <CA+k3eCRT-Paqq5_jLFNpH9n6Se6K+dOcvD+o2-99zBAcPHedmg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------1387D533FC31477A3C23913F"
Content-Language: de-DE
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/JNA3rd7PleluIi5OOe2HNpKbpxY>
Subject: Re: [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: Wed, 23 May 2018 16:27:12 -0000

Thanks Brian! Pedram and I are still not completely sure whether we
fully understand the setting here...

Am 15.05.18 um 00:22 schrieb Brian Campbell:
> Typically when an access token is issued via the implicit grant
> directly from the authorization endpoint, it is for a client that is
> running as script in the user-agent. The AS binds the access token to
> the referred token binding, which would be the token binding between
> the user-agent (where the client is) and the protected resource. 
>
> It does mean that a hybrid style client couldn't pass the access token
> from its script front-end in the user-agent to its server backed
> (well, it could pass it but the server side couldn't use it because of
> the binding).

Section 3.1 says "For access tokens returned directly from the
authorization endpoint,
   such as with the implicit grant defined in Section 4.2 of OAuth 2.0
   [RFC6749], 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 in the "Sec-Token-Binding" header, and is
   used to Token Bind the access token."


Just to clarify: This implies that there must be an HTTP(S) request from
the browser to the protected resource which then gets redirected to the
authorization endpoint. Is that correct?

- Daniel


-- 
SEC - Institute of Information Security
University of Stuttgart
Phone +49 711 685 88468
Universitätsstraße 38 - 70569 Stuttgart - Room 2.434