[Openid-specs-fapi] JARM: Questions about authorization_signed_response_alg

[Brian Campbell]

The way I interpret things is that 'authorization_signed_response_alg'
indicates the JWS alg to use to sign the response only when the
response_mode of the request is 'query.jwt', 'fragment.jwt',
'form_post.jwt', or 'jwt'. Otherwise 'authorization_signed_response_alg'
has no effect. I suppose it'd be reasonable for an AS to reject a request
without one of those response_mode values when the client has a
'authorization_signed_response_alg' value, as I think Vladimir suggested.
But that's more of a policy choice for the respective AS. I do strongly
agree that JARM should be turned on via the respective response_mode
parameter values only and authorization_signed_response_alg should not have
any impact on the response mode that's used.


On Tue, Sep 25, 2018 at 11:37 AM Torsten Lodderstedt via Openid-specs-fapi <
openid-specs-fapi at lists.openid.net> wrote:

> Hi Takahiko,
>
> what you recommend was the default behavior before we introduced JARM and
> should stay the default behavior. JARM should be turned on via the
> respective response_mode parameter values only. I’m a bit reluctant to add
> an additional statement.
>
> kinds regard,
> Torsten.
>
> > Am 23.09.2018 um 05:45 schrieb Takahiko Kawasaki via Openid-specs-fapi <
> openid-specs-fapi at lists.openid.net>:
> >
> > Dear Vladimir,
> >
> > Thank you for your comment. Now I agree that query.jwt and fragment.jwt
> should not be chosen as the default value in the case of response_mode
> omission regardless of what value the 'authorization_signed_response_alg'
> metadata of the client holds.
> >
> > If the specification explicitly said something like below, we would be
> able to expect higher interoperability.
> >
> > When the 'response_mode' request parameter is omitted, 'query' is the
> default value in the cases of 'response_type=code' and
> 'response_type=none', and 'fragment' is the default value for other
> response types such as 'code id_token token' that include at least either
> 'token' or 'id_token'. 'query.jwt', 'fragment.jwt' and other values should
> not be chosen as the default value in the case of response_mode omission
> even if the 'authorization_signed_response_alg' metadata of the client is
> set.
> >
> > Best Regards,
> > Takahiko Kawasaki
> > Authlete, Inc.
> >
> >
> >
> >
> >
> > 2018年9月23日(日) 3:11 Vladimir Dzhuvinov via Openid-specs-fapi <
> openid-specs-fapi at lists.openid.net>:
> > On 22/09/18 06:42, Takahiko Kawasaki via Openid-specs-fapi wrote:
> >> If an authorization request is made with response_type=code and without
> >> response_mode by a client whose authorization_signed_response_alg is not
> >> null (for example if it is RS256), should query.jwt be used as the
> default
> >> value? What I want to know is whether the value of
> >> authorization_signed_response_alg should affect the default value in the
> >> case of response_mode omission.
> >>
> > IMO the AS should return an invalid_request error, to signal the client
> (developer) that the submitted request doesn't match the contract
> established by the registered metadata for the client.
> >
> > https://tools.ietf.org/html/rfc6749#section-4.1.2.1
> >
> > I see three issues with the AS trying to fill in the missing
> response_mode parameter using registered client metadata:
> >       • When we take the authZ request on its own, the default
> response_mode is actually determined by the response_type parameter.
> >
> >       • Implementing the logic to detect a mismatch with registered
> client metadata appears simpler to me than trying to get the request right.
> >
> >       • If developers start relying on the AS to fill in the
> response_mode for them this may lead to interop and security issues down
> the road.
> >
> >> If an authorization request is made for FAPI READ+WRITE APIs and if the
> >> value of authorization_signed_response_alg of the client is neither
> PS256
> >> or ES256, should the request be rejected as required by "8.6 JWS
> algorithm
> >> considerations" of "FAPI Part 2
> >>
> >> <https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md>
> >> "?
> >>
> > Yes, that's how I also read the spec. The JWS alg restriction should
> then also apply to client registration.
> >
> > Vladimir
> > _______________________________________________
> > 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
>
> _______________________________________________
> 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._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180925/a59c8d73/attachment-0001.html>