<div dir="ltr">Thanks and Hi and nice to meet you etc., and see inline below for conversational replies inline.  <br><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 16, 2018 at 6:45 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>
Thanks for your feedback. <br>
<br>
> Am 15.08.2018 um 21:35 schrieb Brian Campbell <<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>>:<br>
> <br>
> As I said (or tried to say) on the call and reiterating some of the prior email, using response mode "jwt" here is a completely viable approach but it should probably be defined as a generally applicable response mode in that case. Perhaps saying that all authorization response parameters are put as claims in the JWT as the baseline. And then note exceptions like state/s_hash (and maybe id_token) and define how they specifically are handled.  I think also that some more clarity should be provided on how the response=[jwt] and state (and any other special params) are encoded for the redirection - i.e. as query string parameters, or application/x-www-form-urlencoded in a fragment component, or as form post parameters. The draft currently implies query string but there's definitely some potential ambiguity for response type(s) like the hybrid ones that do different things by default. <br>
> <br>
> In FAPI part 2 s_hash is defined as, <br>
> State hash value. Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the state value, where the hash algorithm used is the hash algorithm used in the alg header parameter of the ID Token's JOSE header. For instance, if the alg is HS512, hash the state value with SHA-512, then take the left-most 256 bits and base64url encode them. The s_hash value is a case sensitive string.<br>
> <br>
> So I think that this draft needs to clarify that the alg header parameter of the response JWT is used to determine the hash algorithm rather than from the ID Token (and there won't be an ID token many times). I imagine that's what most implementations would do anyway but there's definitely room for different interpretations as it's written now. And that should be tightened up. <br>
<br>
Is it reasonable to assume the hash alg of the JWT and the s_hash could differ?<br>
<br>
If so, would it make sense to add another claim to JWT indicating the hash alg used to calculate the s_hash? <br></blockquote><div><br></div><div>The rational for determining the hash alg used to compute the s_hash based on the alg of the JWS header was to allow for some algorithm agility in the hash without having to carry an additional indicator for it in the JWT (which could be another claim or something in the claim name like s_hash#s256 or something in the claim value like s256:<encoded hash> or even a JSON object as the value with an alg and value). <br></div><div><br></div><div>As best I can remember that was the rational in OIDC core for doing it that way with c_hash and at_hash. And FAPI just kept with the same approach for s_hash. <br></div><div><br></div><div>My comment was only meant to say that the s_hash definition in FAPI talks specifically about the ID Token so the reference to it in this document should qualify/clarify that in this context it's the header of the response JWT. <br></div><div><br></div><div>Of course you could also make up a new claim (perhaps s_digest or torstens_s_hash) and do it however you want.</div><div><br></div><div>Or just include state as a claim in the JWT like all the other authorization response parameters and not have to deal with any hashing or truncation or algorithm selection.  The downside of that is that it potentially bloats the token a lot. But that'd be less of an issue if the response is posted. It would also imply a little different processing on the client's end (have to look inside the JWT for the state) but I don't see that as problematic. <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>
> The s_hash in the example is misleading as "s_hash":"44D41668D199FF3D525FA357A25525D738AADF2A7B1E2C819A39E38500ABAED9", is almost certainly not a base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the state value. It looks like hex. <br>
<br>
You are right. Fixed it (hopefully). <br>
<br>
BTW: why is only the left-most half of the hash used? Doesn’t this reduce the collision resistance? <br></blockquote><div> </div><div>As best I can recall, OIDC core used the left-most half of the hash for  c_hash and at_hash to save space in the resulting JWT. And, while it does reduce the collision resistance, it was considered good enough for the context of use (which I think is really about second preimage resistance in the relatively short validity window of the JWT) . <br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> Also should a client metadata parameter be defined to say what alg(s) to use on this response JWT? Something akin to id_token_signed_response_alg and id_token_encrypted_response_alg and id_token_encrypted_response_enc but for this response JWT. <br>
<br>
I would suggest the same logic as in the JWT Introspection Response spec. There is a default and the client can setup algorithms using the pattern you mentioned.<br>
<br>
What do you think?<br></blockquote><div><br></div><div>That sounds good, yes. Probably also adding Authorization Server Metadata side of things as well? <br></div><div><br></div><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>