[Openid-specs-fapi] Working Group Last Call - JARM

[Brian Campbell]

On Sat, Jul 2, 2022 at 1:54 AM Nat Sakimura via Openid-specs-fapi <
openid-specs-fapi at lists.openid.net> wrote:

> Gee. Was that May?
>
> So, there are a few points that need to be fixed or at least I would like
> to discuss and verify.
>
> * JARM appears to only define behavior for response type code and token,
> but the treatment of ID Token comes up later saying it needs to be
> encrypted. Perhaps the reference can be removed.
>

JARM defines behavior for any response type as the last part of the
introduction
<https://openid.bitbucket.io/fapi/openid-fapi-jarm.html#section-1-1> says,
"The JWT authorization response mode can be used in conjunction with any
response type" while the middle section of The JWT Response Document
<https://openid.bitbucket.io/fapi/openid-fapi-jarm.html#section-2.1-3>reiterates
that it "is applicable to all response types including those defined in [
OIDM <https://openid.bitbucket.io/fapi/openid-fapi-jarm.html#OIDM>]."  That
paragraph goes on to say "The following subsections illustrate the pattern
with the response types `code` and `token`", which is not limiting to those
but just illustrative of a couple response types.

This is how Torsten structured the document originally, so it's always been
like that, and I believe that the actual text makes it pretty clear that it
applies to any response type. But I have heard this misconception from at
least one other reader of the draft. So maybe something more or different
is needed to prevent the misunderstanding?



> * alg=none does not seem to be prohibited. This nullify the value of JARM
> so it should introduce a requirement prohibiting it and the client side
> check as well.
>

It is prohibited in the authorization_signed_response_alg client metadata
<https://openid.bitbucket.io/fapi/openid-fapi-jarm.html#section-3-3.1.1>
but I agree that explicitly prohibiting it in the client side processing
rules would be good to add. Probably in
the authorization_signing_alg_values_supported AS metadata too.


> * The verification process by the client does not use normative language.
>

The processing rules for the client
<https://openid.bitbucket.io/fapi/openid-fapi-jarm.html#name-processing-rules>
does indeed have normative language, so I honestly do not understand this
comment.



> * Protocol run identifier such as nonce or PKCE should be required.
>
>
That is beyond the scope of JARM, which is intended to be only a small
simple extension spec that allows for signing and encryption of the
authorization response. Use of PKCE and/or state are discussed somewhat in
the security considerations and maybe could be covered better. But JARM
shouldn't be placing requirements on other unrelated protocol elements.
That's more appropriate from things like the security BCP, FAPI security
profiles, and OAuth 2.1.




> I will file those issues later when I get back to my computer.
>
> Best,
>
> Nat Sakamura
>
>
> 2022年6月1日(水) 23:53 Dave Tonge via Openid-specs-fapi <
> openid-specs-fapi at lists.openid.net>:
>
>> Bumping this email as discussed on the call
>>
>> On Wed, 25 May 2022 at 17:15, Dave Tonge <dave.tonge at momentumft.co.uk>
>> wrote:
>>
>>> Dear FAPI Working Group
>>>
>>> We would like to start the working group last call for JWT Secured
>>> Authorization Response Mode for OAuth 2.0 (JARM)
>>>
>>> The latest draft is available here:
>>> https://openid.bitbucket.io/fapi/openid-fapi-jarm.html
>>>
>>> Please provide your feedback by the 1st of June so that we can start the
>>> public review period.
>>>
>>> Thank you
>>>
>>>
>>> --
>>> Dave Tonge
>>> FAPI WG Co-Chair
>>>
>>>
>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
>> Limited which is authorised and regulated by the Financial Conduct
>> Authority ("FCA"). Moneyhub Financial Technology is entered on the
>> Financial Services Register (FRN 809360) at https://register.fca.org.uk/.
>> Moneyhub Financial Technology is registered in England & Wales, company
>> registration number 06909772. Registered address: C/O Roxburgh Milkins
>> Limited Merchants House North, Wapping Road, Bristol, United Kingdom, BS1
>> 4RW, United Kingdom. Moneyhub Financial Technology Limited 2022 © Moneyhub
>> Enterprise.
>>
>> DISCLAIMER: This email (including any attachments) is subject to
>> copyright, and the information in it is confidential. Use of this email or
>> of any information in it other than by the addressee is unauthorised and
>> unlawful. Whilst reasonable efforts are made to ensure that any attachments
>> are virus-free, it is the recipient's sole responsibility to scan all
>> attachments for viruses. All calls and emails to and from this company may
>> be monitored and recorded for legitimate purposes relating to this
>> company's business. Any opinions expressed in this email (or in any
>> attachments) are those of the author and do not necessarily represent the
>> opinions of Moneyhub Financial Technology Limited or of any other group
>> company.
>>
>> _______________________________________________
>> Openid-specs-fapi mailing list
>> Openid-specs-fapi at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-fapi
>>
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> https://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/20220703/b3471008/attachment.html>