Re: [OAUTH-WG] [JAR] scope parameter outside request object of OIDC request

[Takahiko Kawasaki <[e-mail]>]

So, my suggestion is "When JAR compatible behaviors are employed, AS
implementations should not require that an OIDC request come with `scope`
query/form parameter when the request uses a request object." (NOTE: "an
OIDC request" implies that the request object contains `scope` including
`openid`.)

Any thoughts?

Taka

On Thu, Sep 24, 2020 at 11:07 PM Takahiko Kawasaki <[e-mail]>
wrote:

> Hi Vladimir,
>
> Just FYI. To be exact, FAPI (version 1) Part 1 (Read-Only) does not
> require all request parameters be put duplicately in a request object. It
> is FAPI (version 1) Part 2 (Read-Write) (Section 5.2.2
> <https://openid.net/specs/openid-financial-api-part-2-ID2.html#authorization-server>
> Clause 10) that has the requirement. In the context of FAPI Part 1, a
> request object does not have to be used. One more note is that parameters
> inside a request object and parameters outside a request object are merged
> (as they are in OIDC Core 1.0) when the authorization request is being made
> for FAPI Read-Only APIs (not for FAPI Read-Write APIs).
>
> Taka
>
>
> On Thu, Sep 24, 2020 at 7:14 PM Vladimir Dzhuvinov <
> [e-mail]> wrote:
>
>> Hi Taka,
>>
>> Speaking of the OIDC Core 1.0 conformance tests, IMO those should not
>> change with the publication of JAR.
>>
>> Speaking of the FAPI 1.0 tests, those already require all request
>> parameters to be JWT-secured, which makes the requests also JAR compliant:
>> all parameters are found in the JWT, with scope (as complete scope or
>> minimally required scope=openid), response_type, client_id and redirect_uri
>> also having a copy outside the JWT, as query parameters. Thus the request
>> is OIDC as well as JAR compliant.
>>
>> If I had an RP I would always construct OIDC auth requests like that, to
>> make sure they comply with OIDC as well as the new JAR spec (and will not
>> have issues with servers which implement both specs but are not able to
>> "switch" behavior for some reason).
>>
>> Vladimir
>> On 23/09/2020 14:58, Takahiko Kawasaki wrote:
>>
>> Hi Vladimir,
>>
>> Thank you for your reply. It sounds that your opinion is "`scope` request
>> parameter must exist outside the request object even if JAR applies if the
>> authorization request is an OIDC request". I'm on the fence on this topic
>> and just wondered whether those who had wanted to remove `response_type`
>> outside the request object (although doing it was a breaking change) would
>> want to remove `scope` outside the request object too with the same
>> motivation (although I don't remember well what was the motivation). JAR
>> dares to drop `response_type`, so it would not be surprising to see that
>> JAR dares to drop `scope` (including `openid`) too.
>>
>> OIDC Core 1.0 requires `response_type`, but JAR allows omission of the
>> parameter if the parameter is included in the request object.
>>
>> If we applied the same logic, we would be able to state:
>>
>> OIDC Core 1.0 requires `scope` (including `openid`), but JAR allows
>> omission of the parameter if the parameter is included in the request
>> object.
>>
>> In terms of `response_type`, practically speaking, JAR has modified OIDC
>> Core 1.0. Because JAR has already been allowed to go so far as that point,
>> I would say it is difficult to find a convincing reason not to allow
>> omission of `scope`.
>>
>> AFAIK, in the context of OIDC Core 1.0, parameters that are required to
>> exist outside a request object even if they are included in the request
>> object are `client_id`, `response_type` and `scope`. Because `client_id` is
>> mandatory in JAR (it has become mandatory after long discussion),
>> discussion for the parameter is not needed. Because the community has
>> already reached consensus that `response_type` can be omitted, discussion
>> for the parameter is not needed, either. What I've brought here is
>> discussion for `scope`, hopefully the last parameter that is affected by
>> JAR.
>>
>> Again, I'm on the fence on this topic. However, because logical
>> conclusion (at least of mine) is that JAR should allow omission of `scope`
>> (it also should be noted that JAR's basic rule prohibits referring to
>> request parameters outside a request object), I want to see explicit
>> consensus if `scope` (including `openid`) outside a request object is still
>> required even after JAR is enabled.
>>
>> In short, my question is "Should `scope` be omitted?" I guess that the
>> conclusion will affect the official conformance suite.
>>
>> Best Regards,
>> Takahiko Kawasaki
>> Authlete, Inc.
>>
>>
>>
>> On Tue, Sep 22, 2020 at 5:59 AM Vladimir Dzhuvinov <
>> [e-mail]> wrote:
>>
>>> Hi Taka,
>>> On 21/09/2020 20:12, Takahiko Kawasaki wrote:
>>>
>>> If we allow JAR (JWT Secured Authorization Request) to relax the
>>> requirement of `response_type` request parameter (outside a request object)
>>> from mandatory to optional, should we relax the following requirement of
>>> `scope` request parameter stated in OIDC Core 1.0 Section 6.1, too?
>>>
>>> ----------
>>> Even if a scope parameter is present in the Request Object value, a
>>> scope parameter MUST always be passed using the OAuth 2.0 request syntax
>>> containing the openid scope value to indicate to the underlying OAuth 2.0
>>> logic that this is an OpenID Connect request.
>>> ----------
>>>
>>> Otherwise, an authorization request like
>>> "client_id=...&request(_uri)=..." fails if the request object represents an
>>> OIDC request. An authorization request has to look like
>>> "client_id=...&request(_uri)=...&scope=openid" (`scope` including `openid`
>>> has to be given) even if the authorization server conforms to JAR and
>>> allows omission of `response_type` request parameter.
>>>
>>> The bottom of section 5 has normative text which allows a JAR compliant
>>> server to also comply with the OIDC spec with its own style of request /
>>> request_uri parameter handling insofar as to not reject other query params
>>> (such as scope, etc). The difference is that according to JAR their values
>>> cannot be used or merged (as in OIDC). But what can be reasonably done is
>>> to detect scope=openid as you say and then switch to OIDC style request
>>> object behavior.
>>>
>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-30#section-5
>>>
>>>    The client MAY send the parameters included in the request object
>>>    duplicated in the query parameters as well for the backward
>>>    compatibility etc.  However, the authorization server supporting this
>>>    specification MUST only use the parameters included in the request
>>>    object.
>>>
>>> The confusion between the two specs clears when it's seen that the
>>> request objects in OIDC and JAR have different objectives.
>>>
>>> In OIDC the objective is to enable securing of selected parameters.
>>>
>>> In JAR the objective is to secure the entire authz request.
>>>
>>>
>>>
>>> I think that implementers want to know consensus on this because it
>>> affects implementations. Has this been discussed yet?
>>>
>>> Best Regards,
>>> Takahiko Kawasaki
>>> Authlete, Inc.
>>>
>>>
>>> Vladimir
>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>