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

Tue Jul 5 15:57:02 UTC 2022

Thanks so much!

Yes, we should be able to go over them tomorrow.

2022年7月6日(水) 0:43 Brian Campbell <bcampbell at pingidentity.com>:

> I've tried to reiterate some of the comments in the tickets where
> appropriate. It's a bit chaotic to try and follow it all, to be honest. I'm
> hopeful we can go through the new issues on the call tomorrow and sort
> things out.
>
> On Tue, Jul 5, 2022 at 4:48 AM Nat Sakimura <nat at nat.consulting> wrote:
>
>> 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
>>
>
> *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/20220706/1477a9c6/attachment-0001.html>