<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Filip,<br>
<br>
I think the difference is that rfc 7523:<br>
<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc7523#section-2.2">https://tools.ietf.org/html/rfc7523#section-2.2</a><br>
<br>
uses the token for client authentication.<br>
<br>
In the token exchange spec:<br>
<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-2.1">https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-2.1</a><br>
<br>
the client does its normal OAuth2 authentication (client-id,
client-secret<br>
i.e. NOT the token to be exchanged),<br>
and the token to be exchanged is provided as a parameter<br>
(
<pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;"> subject_token
REQUIRED.</pre>
)<br>
as the access token that is to be exchanged for the new token.<br>
<br>
At least that's my high-level takeaway based on looking thru the
token exchange<br>
spec and concluding that it is 99% likely to solve the problem as I
described<br>
in prev email.<br>
<br>
Thanks,<br>
Rich<br>
<br>
<br>
<div class="moz-cite-prefix">On 10/18/2017 12:50 PM, Filip Hanik
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CANXYgqGCoOE-U97LkExCuFnvngCUE_rUvX+UOr831y-rL+VJpw@mail.gmail.com">
<div dir="ltr">sounds similar to
<div><br>
<div><a
href="https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Djwt-2Dbearer-2D12&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=7xvhk8QK139ywuwS6n7vTLciT8RHKsdneSwso1169r4&s=c7JD8uopyJJoaWbHa4Z8e0I3bX4f3ggCc7BH_n-mPJs&e="
moz-do-not-send="true">https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-12</a><br>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Oct 18, 2017 at 9:41 AM, rich
levinson via Openid-specs-ab <span dir="ltr"><<a
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank" moz-do-not-send="true">openid-specs-ab@lists.openid.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> Hi Vladimir,<br>
<br>
Yes, I have reached the conclusion that "on-behalf-of"
will address the situation<br>
I am looking at and that "on-behalf-of" has now morphed
into token exchange:<br>
<a class="m_1564082914435183313moz-txt-link-freetext"
href="https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Dtoken-2Dexchange-2D09&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=7xvhk8QK139ywuwS6n7vTLciT8RHKsdneSwso1169r4&s=kZIyTo2crIB-5-lx4o_F9e61yLli1TjP1Nmm_S_mmRc&e="
target="_blank" moz-do-not-send="true">https://tools.ietf.org/html/<wbr>draft-ietf-oauth-token-<wbr>exchange-09</a><br>
<br>
The basic flow is as follows, building on the notation
used in the original proposal/question:<br>
<ol>
<li>oauth client sends access token to RS1.</li>
<li>RS1 validates the token and grants access.</li>
<li>RS1 sends its own client creds to az-svr, along w
access token and<br>
receives new access token to allow it to access RS2.</li>
<li>RS2 sends new access token to RS2.</li>
<li>RS2 validates new access token and grants access.</li>
</ol>
I think this is good solution, as it allows unlimited
chaining and callbacks, as long as<br>
az-svr is willing to grant the next access token.<br>
<br>
In addition, mutual TLS can, in parallel to any or all
steps in the chain separately, as<br>
each step consists of a call to az-svr to get token, then
call to RSn+1 to get downstream<br>
access.<br>
<br>
Thanks,<br>
Rich
<div>
<div class="h5"><br>
<br>
<br>
<div class="m_1564082914435183313moz-cite-prefix">On
10/18/2017 4:21 AM, Vladimir Dzhuvinov wrote:<br>
</div>
<blockquote type="cite"> On 17/10/17 22:33, rich
levinson via Openid-specs-ab wrote:<br>
<blockquote type="cite">Hi Linus, <br>
<br>
I agree there may be some issues introduced by
Mutual TLS. <br>
<br>
However, in principle, access tokens are bearer
tokens and there really is no <br>
implicit control on what entity is using the
access token. <br>
<br>
For example, if the oauth client trusts RS-1 to
deliver a service, then <br>
it should trust RS-1 to use the token to access
RS-2. <br>
<br>
Possibly Mutual TLS could be extended to cover the
RS-1<->RS-2 connection <br>
as well. <br>
</blockquote>
I don't see how mTLS could be extended to cover this
scenario. When the token is issued, it gets bound to
the client's certificate. The RS-1 is not present at
this point, so I see no direct way to for the AS to
add secondary binding to the RS-1 certificate.<br>
<br>
Did you look at token exchange?<br>
<br>
<pre>(draft-ietf-oauth-token-<wbr>exchange-09)</pre>
<br>
Vladimir<br>
<br>
<blockquote type="cite"> Thanks, <br>
Rich <br>
<br>
<br>
On 10/17/2017 3:19 PM, Linus Lewandowski wrote: <br>
<blockquote type="cite">Hi, <br>
<br>
This won't really be possible with Mutual TLS
<<a
class="m_1564082914435183313moz-txt-link-freetext"
href="https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draft-2Dietf-2Doauth-2Dmtls-2D03.html&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=7xvhk8QK139ywuwS6n7vTLciT8RHKsdneSwso1169r4&s=gDhERmH-a0O5odt7G5PaxBxbrb1P8Jln1KTTpfLR794&e="
target="_blank" moz-do-not-send="true">https://tools.ietf.org/id/<wbr>draft-ietf-oauth-mtls-03.html</a>
<a
class="m_1564082914435183313moz-txt-link-rfc2396E"
href="https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draft-2Dietf-2Doauth-2Dmtls-2D03.html&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=tb9zOhjteWWIATXzVc3HJCrh6hqsYhws1Yn11x8GiBg&s=GTdDEw8rKcAS_akoL4N2C8PYXbN8wG3H4JtBMenjwjA&e="
target="_blank" moz-do-not-send="true"><https://urldefense.<wbr>proofpoint.com/v2/url?u=https-<wbr>3A__tools.ietf.org_id_draft-<wbr>2Dietf-2Doauth-2Dmtls-2D03.<wbr>html&d=DwMFaQ&c=<wbr>RoP1YumCXCgaWHvlZYR8PQcxBKCX5Y<wbr>TpkKY057SbK10&r=<wbr>nNxUKneeZofWTyt9qclOUTeEg29NkE<wbr>kknFyDupoNiiA&m=<wbr>tb9zOhjteWWIATXzVc3HJCrh6hqsYh<wbr>ws1Yn11x8GiBg&s=GTdDEw8rKcAS_<wbr>akoL4N2C8PYXbN8wG3H4JtBMenjwjA<wbr>&e=></a>><br>
<br>
Without Mutual TLS, this means that RS-1 can
impersonate your app when talking to RS-2, and
RS-2 when talking to RS-1. Not ideal from the
security POV. <br>
<br>
Regards, <br>
Linus <br>
<br>
On Tue, Oct 17, 2017 at 9:04 PM rich levinson
via Openid-specs-ab <<a
class="m_1564082914435183313moz-txt-link-abbreviated"
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank" moz-do-not-send="true">openid-specs-ab@lists.openid.<wbr>net</a>
<a
class="m_1564082914435183313moz-txt-link-rfc2396E"
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank" moz-do-not-send="true"><mailto:openid-specs-ab@lists.<wbr>openid.net></a>>
wrote: <br>
<br>
Does anyone have guidance on validity of the
following scenario?: <br>
<br>
There is a Resource Server, RS-1, that,
in order to provide its service <br>
needs to also access a downstream
Resource Server RS-2. <br>
<br>
When the oauth client requests an access
token, it is granted an access token <br>
by the az-svr (that knows that both RS-1
and RS-2 must be used) that <br>
contains 2 audiences: RS-1 and RS-2. <br>
<br>
The oauth client uses the access token
to access RS-1. <br>
<br>
RS-1, in turn, uses the same access
token to access RS-2. <br>
<br>
The response is returned from RS-2 to
RS-1. <br>
RS-1 combines the response from RS-2 w
its own resp and <br>
returns the combined response to the
oauth client. <br>
<br>
Given that the token is a bearer token it
seems to me there is no reason why <br>
both the oauth client AND the RS-1 can't use
the access token to get what they <br>
need, w/o RS-1 having to register itself as
a separate client and get its own <br>
access token. <br>
<br>
So, the question is whether this is a
legitimate use case for a resource server <br>
to access downstream services. <br>
<br>
Thanks, <br>
Rich <br>
<br>
______________________________<wbr>_________________
<br>
Openid-specs-ab mailing list <br>
<a
class="m_1564082914435183313moz-txt-link-abbreviated"
href="mailto:Openid-specs-ab@lists.openid.net"
target="_blank" moz-do-not-send="true">Openid-specs-ab@lists.openid.<wbr>net</a>
<a
class="m_1564082914435183313moz-txt-link-rfc2396E"
href="mailto:Openid-specs-ab@lists.openid.net"
target="_blank" moz-do-not-send="true"><mailto:Openid-specs-ab@lists.<wbr>openid.net></a>
<br>
<a
class="m_1564082914435183313moz-txt-link-freetext"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=7xvhk8QK139ywuwS6n7vTLciT8RHKsdneSwso1169r4&s=UDWUcd16625QntA8fVqlpYzD_X8jrCZlm7J348VV28Y&e="
target="_blank" moz-do-not-send="true">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>ab</a>
<a
class="m_1564082914435183313moz-txt-link-rfc2396E"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=tb9zOhjteWWIATXzVc3HJCrh6hqsYhws1Yn11x8GiBg&s=6xTtGMr1rtCrSdJzSj_eq1FPnPRxDTIfb3jLJvIfKwY&e="
target="_blank" moz-do-not-send="true"><https://urldefense.<wbr>proofpoint.com/v2/url?u=http-<wbr>3A__lists.openid.net_mailman_<wbr>listinfo_openid-2Dspecs-2Dab&<wbr>d=DwMFaQ&c=<wbr>RoP1YumCXCgaWHvlZYR8PQcxBKCX5Y<wbr>TpkKY057SbK10&r=<wbr>nNxUKneeZofWTyt9qclOUTeEg29NkE<wbr>kknFyDupoNiiA&m=<wbr>tb9zOhjteWWIATXzVc3HJCrh6hqsYh<wbr>ws1Yn11x8GiBg&s=<wbr>6xTtGMr1rtCrSdJzSj_<wbr>eq1FPnPRxDTIfb3jLJvIfKwY&e=></a><br>
<br>
</blockquote>
<br>
<br>
<br>
<fieldset
class="m_1564082914435183313mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
Openid-specs-ab mailing list
<a class="m_1564082914435183313moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" moz-do-not-send="true">Openid-specs-ab@lists.openid.<wbr>net</a>
<a class="m_1564082914435183313moz-txt-link-freetext" href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=7xvhk8QK139ywuwS6n7vTLciT8RHKsdneSwso1169r4&s=UDWUcd16625QntA8fVqlpYzD_X8jrCZlm7J348VV28Y&e=" target="_blank" moz-do-not-send="true">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>ab</a>
</pre>
</blockquote>
<br>
</blockquote>
<br>
</div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net"
moz-do-not-send="true">Openid-specs-ab@lists.openid.<wbr>net</a><br>
<a
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=7xvhk8QK139ywuwS6n7vTLciT8RHKsdneSwso1169r4&s=UDWUcd16625QntA8fVqlpYzD_X8jrCZlm7J348VV28Y&e="
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>ab</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>