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

Tue Jul 5 15:43:20 UTC 2022

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._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20220705/c9d9c3ba/attachment.html>