<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Do we also want to cover the hybrid OIDC flows? And if we do,
could there be implications with having the state in a encrypted
JWT?<br>
</p>
<p>Other than that I don't see why having the state in a encrypted
JWT wouldn't work.<br>
</p>
<p>One of my original concerns was that validation of the signed
JWTs becomes a bit more complicated and some libs may not readily
support this, i.e. use JWT claims as inputs to the validation. But
this is mostly an implementation issue.<br>
</p>
<p>Vladimir<br>
</p>
<br>
<div class="moz-cite-prefix">On 17/08/18 20:24, Brian Campbell via
Openid-specs-fapi wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+k3eCRaYrh1gJ3MWWSUxo+poDK+XXhohojGmk2-iie0bKDBrw@mail.gmail.com">
<pre wrap="">Yeah, I think that captures the general processing flow.
On Fri, Aug 17, 2018 at 8:50 AM Torsten Lodderstedt <a class="moz-txt-link-rfc2396E" href="mailto:torsten@lodderstedt.net"><torsten@lodderstedt.net></a>
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Brian,
</pre>
<blockquote type="cite">
<pre wrap="">Am 17.08.2018 um 15:39 schrieb Brian Campbell <
</pre>
</blockquote>
<pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com</a>>:
</pre>
<blockquote type="cite">
<pre wrap="">
Good point. OIDC Core (
</pre>
</blockquote>
<pre wrap=""><a class="moz-txt-link-freetext" href="http://openid.net/specs/openid-connect-core-1_0.html#Security">http://openid.net/specs/openid-connect-core-1_0.html#Security</a>) does not
discuss this attack angle. From your perspective, what is the typical way
to detect crafted/modified ID Tokens in the id_token flow?
</pre>
<blockquote type="cite">
<pre wrap="">
Checking the signature. But if the issuer isn't known or expected,
</pre>
</blockquote>
<pre wrap="">don't go trying to find keys for it, just reject the token.
I would like to summarize the discussion regarding handling of state value
and response processing.
From what I understand, the processing would work as follows (assuming the
„state" is carried in the JWT):
1) decrypt JWT using the client's private key - the key is determine by
the „kid“ header parameter
2) obtain „state“ from JWT
3) check binding of state value to user agent, if check fails - abort
processing
4) obtain „iss" from JWT
5) check whether „iss" is known and expected („aud“ could be checked in
this step as well), if not abort processing
6) obtain signing key based on „iss“ and „kid"
7) check signature, if signature validation fails - abort processing
8) use response parameters
Does this capture your thoughts correctly?
Kind regards,
Torsten.
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-fapi mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-fapi@lists.openid.net">Openid-specs-fapi@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a>
</pre>
</blockquote>
<br>
</body>
</html>