<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 16, 2018 at 7:00 AM Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Brian, <br>
<br>
> Am 15.08.2018 um 23:58 schrieb Brian Campbell <<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>>:<br>
> <br>
> 4.3 Processing Rules has, "Check the signature of the JWT using the JWK set of the expected issuer. Note: the client MUST obtain the JWK set from local data and MUST NOT follow the iss claim of the JWT to obtain key material. This is done to prevent DoS (see Security Considerations)" <br>
> <br>
> That sounds to me like it rules out the way that signature verification keys are typically obtained for ID Token verification where the OP's metadata points to a jwks_uri where keys can be retrieved and more seamless key rotation is possible. See 10.1 and 10.1.1 of OIDC Core for example. The jwks_uri is defined for both OP metadata and AS metadata.<br>
> <br>
> That verification key retrieval pattern from OIDC works pretty well as far as I know. I don't think this JWT Secured Authorization Response Mode should depart from it. As written it sounds like a client would have to somehow separately store/maintain keys for an AS for sole purpose of verifying a JWT Secured Authorization Response. <br>
<br>
My assumption is the client obtains the key material from the OAuth or OpenID Configuration of the AS/OP in advance. The clients needs anyway to obtain the endpoint data and memorize the issuer it sent the user agent to (mix up prevention). Linked to this data, it stores the respective key/keys or JWKS_URL. <br></blockquote><div><br></div><div>Yes. That. But the content of the JWKS_URL may need to be retrieved again or for the first time if a cache has expired or the kid value of the token doesn't match a key in the cached JWKS. <br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> I think there are other ways to address the stated security concerns - response size restrictions, caching, timeouts, etc. - and these things are already presumably happening because the typical OIDC ID token flow does what this draft wants to prohibit. And there are a lot of OIDC deployments. <br>
<br>
Good point. OIDC Core (<a href="http://openid.net/specs/openid-connect-core-1_0.html#Security" rel="noreferrer" target="_blank">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? </blockquote><div><br></div><div> Checking the signature. But if the issuer isn't known or expected, don't go trying to find keys for it, just reject the token.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> Or maybe I"m misinterpreting the text? If that's the case, some clarification is needed I think. <br>
<br>
I tried :-)<br></blockquote><div><br></div><div>I'm trying also :) <br></div></div></div>

<br>
<i style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:rgb(255,255,255);font-family:proxima-nova-zendesk,system-ui,-apple-system,system-ui,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;color:rgb(85,85,85)"><span style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"><font size="2">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.</font></span></i>