<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    How about having response_mode=jwt to indicate the standard redirect
    encoding (query, fragment) for the requested response type, and <br>
    <br>
    response_mode=form_post.jwt<br>
    response_mode=query.jwt<br>
    response_mode=fragment.jwt <br>
    <br>
    to set a preferred encoding explicitly?<br>
    <br>
    The `.` was chosen as a delimiter character that is unreserved in
    percent encoding (RFC 3986).<br>
    <br>
    Vladimir<br>
    <br>
    <div class="moz-cite-prefix">On 15/08/18 22:35, Brian Campbell via
      Openid-specs-fapi wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CA+k3eCQir3b8gJ9yLTS=6ELi_8HXojB+J9-vJb3uYfDYwxU1RQ@mail.gmail.com">
      <pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:bcampbell@pingidentity.com"><bcampbell@pingidentity.com></a>
wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="">[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 <
<a class="moz-txt-link-abbreviated" href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a>> wrote:

</pre>
        <blockquote type="cite">
          <pre wrap="">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.

</pre>
          <blockquote type="cite">
            <pre wrap="">Am 15.08.2018 um 14:41 schrieb Brian Campbell via Openid-specs-fapi <
</pre>
          </blockquote>
          <pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:openid-specs-fapi@lists.openid.net">openid-specs-fapi@lists.openid.net</a>>:
</pre>
          <blockquote type="cite">
            <pre wrap="">
As a Response Mode, I had envisioned that all the authorization
</pre>
          </blockquote>
          <pre wrap="">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.
</pre>
          <blockquote type="cite">
            <pre wrap="">
What is in this draft is more of a specialized treatment of the code
</pre>
          </blockquote>
          <pre wrap="">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.
</pre>
          <blockquote type="cite">
            <pre wrap="">


On Thu, Aug 9, 2018 at 10:03 AM Torsten Lodderstedt via
</pre>
          </blockquote>
          <pre wrap="">Openid-specs-fapi <a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-fapi@lists.openid.net"><openid-specs-fapi@lists.openid.net></a> wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">Hi all,

please find attached the first version of the draft on the new signed
</pre>
          </blockquote>
          <pre wrap="">response mode (
<a class="moz-txt-link-freetext" href="https://bitbucket.org/openid/fapi/issues/155/support-authorization-and-identity">https://bitbucket.org/openid/fapi/issues/155/support-authorization-and-identity</a>).
As this draft mirrors OAuth JAR (as already pointed out by Nat), I choose
the name accordingly.
</pre>
          <blockquote type="cite">
            <pre wrap="">
Looking forward for your feedback.

kind regards,
Torsten.

   _______________________________________________
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>

CONFIDENTIALITY NOTICE: This email may contain confidential and
</pre>
          </blockquote>
          <pre wrap="">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._______________________________________________
</pre>
          <blockquote type="cite">
            <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>
          <pre wrap="">

</pre>
        </blockquote>
      </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>