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

Fri Aug 17 03:52:43 UTC 2018

How about having response_mode=jwt to indicate the standard redirect
encoding (query, fragment) for the requested response type, and

response_mode=form_post.jwt
response_mode=query.jwt
response_mode=fragment.jwt

to set a preferred encoding explicitly?

The `.` was chosen as a delimiter character that is unreserved in
percent encoding (RFC 3986).

Vladimir

On 15/08/18 22:35, Brian Campbell via Openid-specs-fapi wrote:
> 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.
>
> 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.
>
> 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.
>
>
>
>
> On Wed, Aug 15, 2018 at 12:36 PM Brian Campbell <bcampbell at pingidentity.com>
> wrote:
>
>> [re-sending to the list as I forgot to reply-all earlier before the call]
>>
>> Hi Torsten,
>>
>> Yes, more text would needed around other response types because code is
>> the only thing described currently with others being out of scope - it
>> says, 'Note: The response mode "jwt" can be combined with other response
>> types, the respective syntax and behavior is out of scope of this draft.'
>>
>> I'm not sure I agree that state needs special treatment. But regardless,
>> as a general response mode, there should be more clear definition of what
>> goes in the JWT and what is a normal authz response parameter and how it's
>> all encoded.
>>
>> Kinder regards,
>> Brian
>>
>> On Wed, Aug 15, 2018 at 7:29 AM Torsten Lodderstedt <
>> torsten at lodderstedt.net> wrote:
>>
>>> Hi Brian,
>>>
>>> the mode can easily be combined with the grant type „token" (and the text
>>> also sketches how). One would include the response parameter access_token,
>>> token_type, expires_in, and scope in the JWT. I can also add more text on
>>> that.
>>>
>>> I think it makes sense to treat the state value special because it binds
>>> the response object to the initial transaction and can be evaluated
>>> _before_ the JWT is being processed. This is a security precaution.
>>>
>>> Kind regards,
>>> Torsten.
>>>
>>>> Am 15.08.2018 um 14:41 schrieb Brian Campbell via Openid-specs-fapi <
>>> openid-specs-fapi at lists.openid.net>:
>>>> As a Response Mode, I had envisioned that all the authorization
>>> response parameters would be passed as claims of the JWT. And would be
>>> applicable to any response types. Something like that would more closely
>>> mirror OAuth JAR. And be a more generally applicable response mode.
>>>> What is in this draft is more of a specialized treatment of the code
>>> response parameter (also state). If that's the extent of the functionality,
>>> it's probably more appropriate to be defined as a new response type (I know
>>> I suggested response mode but that was with the thinking that it'd be a
>>> generalized mode for encoding all the response params). Or, if response
>>> mode is used to signal this functionality, the mode value (and spec title)
>>> should probably be more true to what it is actually doing. Like
>>> response_mode=code_in_jwt_with_state_as_s_hash_and_other_stuff_undefined or
>>> just response_mode=jwt_code.
>>>>
>>>>
>>>> On Thu, Aug 9, 2018 at 10:03 AM Torsten Lodderstedt via
>>> Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
>>>> Hi all,
>>>>
>>>> please find attached the first version of the draft on the new signed
>>> response mode (
>>> https://bitbucket.org/openid/fapi/issues/155/support-authorization-and-identity).
>>> As this draft mirrors OAuth JAR (as already pointed out by Nat), I choose
>>> the name accordingly.
>>>> Looking forward for your feedback.
>>>>
>>>> kind regards,
>>>> Torsten.
>>>>
>>>>    _______________________________________________
>>>> Openid-specs-fapi mailing list
>>>> Openid-specs-fapi at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>>>>
>>>> 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._______________________________________________
>>>> Openid-specs-fapi mailing list
>>>> Openid-specs-fapi at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>>>
>
>
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180817/0ef6acaa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4002 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180817/0ef6acaa/attachment.p7s>