MIME-Version: 1.0
In-Reply-To: <df0f8268-13a8-90d7-fc40-32e5b7371cc9@gmx.de>
References: <df0f8268-13a8-90d7-fc40-32e5b7371cc9@gmx.de>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 14 May 2018 16:22:54 -0600
Message-ID: <CA+k3eCRT-Paqq5_jLFNpH9n6Se6K+dOcvD+o2-99zBAcPHedmg@mail.gmail.com>
To: pedram.h@gmx.de
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002c45ee056c31ef0e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/FkljlXdlANaPqPygLYLjKUwVPgo>
Subject: Re: [OAUTH-WG] OAUTB for Access Token in Implicit Grant
Precedence: list

--0000000000002c45ee056c31ef0e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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, <pedram.h@gmx.de> wrote:

> Dear all,
>
> We are currently modeling part 1 and part 2 of the OpenID Financial API i=
n
> 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 Tok=
en
> 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 (whi=
ch
> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--=20
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged=
=20
material for the sole use of the intended recipient(s). Any review, use,=20
distribution or disclosure by others is strictly prohibited.=C2=A0 If you h=
ave=20
received this communication in error, please notify the sender immediately=
=20
by e-mail and delete the message and any file attachments from your=20
computer. Thank you._

--0000000000002c45ee056c31ef0e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Typically when an access token is issued via the impl=
icit grant directly from the authorization endpoint, it is for a client tha=
t 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 us=
er-agent (where the client is) and the protected resource. <br></div><div><=
br></div><div>It does mean that a hybrid style client couldn&#39;t pass the=
 access token from its script front-end in the user-agent to its server bac=
ked (well, it could pass it but the=C2=A0server side couldn&#39;t use it be=
cause of the binding). <br></div></div><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">On Mon, May 14, 2018 at 6:46 AM,  <span dir=3D"ltr">&=
lt;<a href=3D"mailto:pedram.h@gmx.de" target=3D"_blank">pedram.h@gmx.de</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 =20

   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div style=3D"font-family:Verdana;font-size:12.0px">
      <div>
        <div>Dear all,</div>
        <div>=C2=A0</div>
        <div>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.</div>
        <div>=C2=A0</div>
        <div>In section 3.1. of draft-ietf-oauth-token-<wbr>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.</div>
        <div>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.</div>
        <div>=C2=A0</div>
        <div>Is this the intended flow of the Token Binding? Because the
          first paragraph of 3.1 says that the &quot;Token Binding ID of th=
e
          client&#39;s TLS channel to the protected resource is sent with
          the authorization request as the Referred Token Binding ID&quot;,
          but we assume that the user-agent reveals the TB-ID of its own
          channel to the client.</div>
        <div>=C2=A0</div>
        <div>Best regards,<br>
          Pedram Hosseyni</div>
      </div>
    </div>
  </div>

<br>______________________________<wbr>_________________<br>
OAuth mailing list<br>
<a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/oauth" rel=3D"noreferrer" =
target=3D"_blank">https://www.ietf.org/mailman/<wbr>listinfo/oauth</a><br>
<br></blockquote></div><br></div>

<br>
<i style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:ba=
seline;background:rgb(255,255,255);font-family:proxima-nova-zendesk,system-=
ui,-apple-system,system-ui,&quot;Segoe UI&quot;,Roboto,Oxygen-Sans,Ubuntu,C=
antarell,&quot;Helvetica Neue&quot;,Arial,sans-serif;color:rgb(85,85,85)"><=
span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:=
baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,=
-apple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,Roboto,Oxygen-Sans,Ub=
untu,Cantarell,&quot;Helvetica Neue&quot;,Arial,sans-serif;font-weight:600"=
><font size=3D"2">CONFIDENTIALITY NOTICE: This email may contain confidenti=
al and privileged material for the sole use of the intended recipient(s). A=
ny review, use, distribution or disclosure by others is strictly prohibited=
.=C2=A0 If you have received this communication in error, please notify the=
 sender immediately by e-mail and delete the message and any file attachmen=
ts from your computer. Thank you.</font></span></i>
--0000000000002c45ee056c31ef0e--