<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 you may be right.<br>
<br>
So, what I think you are saying is that in use case 2.1: <br>
<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc7523#section-2.1">https://tools.ietf.org/html/rfc7523#section-2.1</a><br>
<br>
that, as indicated, client authentication is done by the usual
means<br>
(<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc6749#section-3.2.1">https://tools.ietf.org/html/rfc6749#section-3.2.1</a>),<br>
<br>
that the assertion parameter contains the original access token that<br>
the OAuth client provided when accessing RS1, and that as a result<br>
the az-svr will return an access token so that RS1 can access RS2,<br>
which is effectively what the chain scenario requires.<br>
<br>
If so, then I think that this is effectively the token exchange that
I am<br>
looking for.<br>
<br>
I will need to explore it in a bit more depth to ensure it meets all
our<br>
needs, but it sounds like it might work.<br>
<br>
Thanks,<br>
Rich<br>
<br>
<br>
<div class="moz-cite-prefix">On 10/19/2017 1:27 PM, Filip Hanik
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CANXYgqFZknZgSZPeeTa-ZbnkesQo6j--o4Pz+6EbPz_O47UUbA@mail.gmail.com">
<div dir="ltr"><a
class="gmail-m_6472311438304103791moz-txt-link-freetext"
href="https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7523-23section-2D2.1&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=EPe9k-VIR0ohjxFngF-JqWOPVZHEV2ZCABLRtdxrP48&s=pz0dshT3-quRewz0KqrgzeU4hdsyOiqM-x81aEpozJo&e="
target="_blank" style="font-size:12.8px"
moz-do-not-send="true">https://tools.ietf.org/html/rfc7523#section-2.1</a> and
section 2.2 are two different use cases.<br>
<div><br>
</div>
<div>in the main use case (section 2.1), the JWT token is the
assertion for the user's identity. Client authentication is
still done the same was as per <a
href="https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6749-23section-2D3.2.1&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=EPe9k-VIR0ohjxFngF-JqWOPVZHEV2ZCABLRtdxrP48&s=HViQju-y-Xmx0WVX8tlaZBpGNm-vN2PUvZHNmnRsg3o&e="
moz-do-not-send="true">https://tools.ietf.org/html/rfc6749#section-3.2.1</a></div>
<div><br>
</div>
<div>I would say that these two specs overlap very much. with
the token exchange being targeted at the generic Oauth2 eco
system, while rfc 7523 is a bit more specific to the OIDC
context.</div>
<div><br>
</div>
<div>Filip</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Oct 18, 2017 at 12:32 PM, rich
levinson <span dir="ltr"><<a
href="mailto:rich.levinson@oracle.com" target="_blank"
moz-do-not-send="true">rich.levinson@oracle.com</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 Filip,<br>
<br>
I think the difference is that rfc 7523:<br>
<a class="m_6472311438304103791moz-txt-link-freetext"
href="https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7523-23section-2D2.2&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=EPe9k-VIR0ohjxFngF-JqWOPVZHEV2ZCABLRtdxrP48&s=GR31ExtfzAJMxq9vy4EWgZZPmoeA93LwnqemSTTBOfE&e="
target="_blank" moz-do-not-send="true">https://tools.ietf.org/html/<wbr>rfc7523#section-2.2</a><br>
<br>
uses the token for client authentication.<br>
<br>
In the token exchange spec:<br>
<a class="m_6472311438304103791moz-txt-link-freetext"
href="https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Dtoken-2Dexchange-2D09-23section-2D2.1&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=EPe9k-VIR0ohjxFngF-JqWOPVZHEV2ZCABLRtdxrP48&s=JKeyfeoaBFgjN3HDxgyJXChtbotFH5SD2TiMxoE3G5g&e="
target="_blank" moz-do-not-send="true">https://tools.ietf.org/html/<wbr>draft-ietf-oauth-token-<wbr>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="m_6472311438304103791newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0);font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing: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
<div>
<div class="h5"><br>
<br>
<br>
<div class="m_6472311438304103791moz-cite-prefix">On
10/18/2017 12:50 PM, Filip Hanik wrote:<br>
</div>
<blockquote type="cite">
<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="
target="_blank" moz-do-not-send="true">https://tools.ietf.org/html/<wbr>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.<wbr>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_6472311438304103791m_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/dr<wbr>aft-ietf-oauth-token-exchange-<wbr>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="m_6472311438304103791h5"><br>
<br>
<br>
<div
class="m_6472311438304103791m_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-exchan<wbr>ge-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_6472311438304103791m_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/dra<wbr>ft-ietf-oauth-mtls-03.html</a>
<a
class="m_6472311438304103791m_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.proofpoint<wbr>.com/v2/url?u=https-3A__tools.<wbr>ietf.org_id_draft-2Dietf-<wbr>2Doauth-2Dmtls-2D03.html&d=<wbr>DwMFaQ&c=RoP1YumCXCgaWHvlZYR8P<wbr>QcxBKCX5YTpkKY057SbK10&r=nNxUK<wbr>neeZofWTyt9qclOUTeEg29NkEkknFy<wbr>DupoNiiA&m=tb9zOhjteWWIATXzVc3<wbr>HJCrh6hqsYhws1Yn11x8GiBg&s=<wbr>GTdDEw8rKcAS_akoL4N2C8PYXbN8wG<wbr>3H4JtBMenjwjA&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_6472311438304103791m_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_6472311438304103791m_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_6472311438304103791m_1564082914435183313moz-txt-link-abbreviated"
href="mailto:Openid-specs-ab@lists.openid.net" target="_blank"
moz-do-not-send="true">Openid-specs-ab@lists.openid.n<wbr>et</a>
<a
class="m_6472311438304103791m_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_6472311438304103791m_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/mailma<wbr>n/listinfo/openid-specs-ab</a>
<a
class="m_6472311438304103791m_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.proofpoint<wbr>.com/v2/url?u=http-3A__lists.<wbr>openid.net_mailman_listinfo_<wbr>openid-2Dspecs-2Dab&d=DwMFaQ&<wbr>c=RoP1YumCXCgaWHvlZYR8PQcxBKCX<wbr>5YTpkKY057SbK10&r=nNxUKneeZofW<wbr>Tyt9qclOUTeEg29NkEkknFyDupoNii<wbr>A&m=tb9zOhjteWWIATXzVc3HJCrh6h<wbr>qsYhws1Yn11x8GiBg&s=6xTtGMr1rt<wbr>CrSdJzSj_eq1FPnPRxDTIfb3jLJvIf<wbr>KwY&e=></a><br>
<br>
</blockquote>
<br>
<br>
<br>
<fieldset
class="m_6472311438304103791m_1564082914435183313mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
Openid-specs-ab mailing list
<a class="m_6472311438304103791m_1564082914435183313moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" moz-do-not-send="true">Openid-specs-ab@lists.openid.n<wbr>et</a>
<a class="m_6472311438304103791m_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/mailma<wbr>n/listinfo/openid-specs-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"
target="_blank" moz-do-not-send="true">Openid-specs-ab@lists.openid.n<wbr>et</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/mailma<wbr>n/listinfo/openid-specs-ab</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>