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

Tue Jul 5 10:48:30 UTC 2022

Thanks, Brian for the comment. I will eventually record them to the issue
tickets I have created.
(Or, you could add them yourself, :-)

Regarding

> * 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.
>
> I did not write clearly enough from my mobile, but it is somewhat better
explained in issue #511.

The current sentence structure is such that

The client is obliged to process the JWT secured response as follows: (<<
non-normative language)
#. ==Some check description using non normative language==.  If the check
fails, ==action in Normative language==.

Thus, the relevant normative sections are all conditional. What I meant was
that each "check" has to be normatively required.

This can be achieved by replacing "is obliged to" in the second paragraph
of 2.4 with a "MUST".

Best,

Nat

2022年7月4日(月) 7:56 Brian Campbell <bcampbell at pingidentity.com>:

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

-- 
Nat Sakimura
NAT.Consulting LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20220705/ce3f9c8f/attachment-0001.html>