[Openid-specs-fapi] JWT Secured Authorization Response Mode (#155)

Brian Campbell bcampbell at pingidentity.com
Fri Aug 17 13:16:37 UTC 2018


Thanks and Hi and nice to meet you etc., and see inline below for
conversational replies inline.

On Thu, Aug 16, 2018 at 6:45 AM Torsten Lodderstedt <torsten at lodderstedt.net>
wrote:

> Hi Brian,
>
> Thanks for your feedback.
>
> > Am 15.08.2018 um 21:35 schrieb Brian Campbell <
> bcampbell at pingidentity.com>:
> >
> > 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.
> >
> > In FAPI part 2 s_hash is defined as,
> > 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.
> >
> > 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.
>
> Is it reasonable to assume the hash alg of the JWT and the s_hash could
> differ?
>
> If so, would it make sense to add another claim to JWT indicating the hash
> alg used to calculate the s_hash?
>

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).

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.

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.

Of course you could also make up a new claim (perhaps s_digest or
torstens_s_hash) and do it however you want.

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.

>
> > 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.
>
> You are right. Fixed it (hopefully).
>
> BTW: why is only the left-most half of the hash used? Doesn’t this reduce
> the collision resistance?
>

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) .



> >
> > 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.
>
> 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.
>
> What do you think?
>

That sounds good, yes. Probably also adding Authorization Server Metadata
side of things as well?

-- 
_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._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180817/17a9dceb/attachment.html>


More information about the Openid-specs-fapi mailing list