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

Brian Campbell <> Mon, 14 May 2018 22:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C87BE12E8D9 for <>; Mon, 14 May 2018 15:23:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ba5rgffaZBQL for <>; Mon, 14 May 2018 15:23:26 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4C29112E8D8 for <>; Mon, 14 May 2018 15:23:26 -0700 (PDT)
Received: by with SMTP id q72-v6so15142577itc.0 for <>; Mon, 14 May 2018 15:23:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zmzeeYFy2Ow0rs/R9vpqNZTPhXDfwEHSZwvm0EVAY8A=; b=jWRiM02wif/CDGBJ59T/PC2wLtQ/IX574TSQRK/CzPGXpkrAMEdELqv33NXsgkhelY D3Edmci9gE2NhOj+CpBpa3gd3rt+WBugXPoEXAdTru17Exl+bnbf8kpZ3y6Q/XMb6nS9 vncFMbY2vluksQiFU/Yu1dxzYGylNmycKbb6Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zmzeeYFy2Ow0rs/R9vpqNZTPhXDfwEHSZwvm0EVAY8A=; b=adspO1xwGmlAk/ntQdjuGpWrcaxqQ/szn+eh2yYRbOq6VAwuJafdBYpOCJ/+HANBSB TySo+6TM0kMjZ3BCBed1+SILvFcG3iPor8h+a8OP8GxTiCLA3jFhjtJZTm6NOayQd4G6 I2OOUSSvaAg94y78X07zuHIQ4mYVDTWmi1SJ4vWFdUWVHkyUhX1djShNp4jVzgoiDqP4 xC6jxzsqGaNhUkOL0UVMP1SiGEjzSZ099KIxj9wX0wTx5SQyJawMm976oHqx8torKuH1 6W3DwePpdE3ZlxzkDNGmXyWmevoeDgHHU8vHhPiaWRH5fmdx5wuL1YqSQ1TkvAFyhw0X iT7w==
X-Gm-Message-State: ALKqPwcBsaiDiVwz2SR2vIYRwdKgSCN43RKFa9jU3JD7WDHsGoD/P4uN +2JBigRhxEnDCWNeMQcLF9H3FpKqCONK98kROPAOlRnkPcxPAoYyiIcdvCF/UEZ5okpqC80Yoqq 1zCiWUx7owywnEw==
X-Google-Smtp-Source: AB8JxZpXvw7gMOib3EBo5wmg3xuvVAXFk1Hr3u66ifC4PnpZOZdTkkBVXPqK0PUh5w4SQi+mdxMX3Ud/MgWpzde1dvs=
X-Received: by 2002:a6b:8361:: with SMTP id f94-v6mr11863385iod.17.1526336605400; Mon, 14 May 2018 15:23:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Mon, 14 May 2018 15:22:54 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Brian Campbell <>
Date: Mon, 14 May 2018 16:22:54 -0600
Message-ID: <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="0000000000002c45ee056c31ef0e"
Archived-At: <>
Subject: Re: [OAUTH-WG] OAUTB for Access Token in Implicit Grant
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 May 2018 22:23:29 -0000

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).

On Mon, May 14, 2018 at 6:46 AM, <> wrote:

> 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 mailing list

_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._