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

[Takahiko Kawasaki]

"there seems to be a good consensus that servers must not require the
duplicates."

from FAPI Issue 315: PAR certification question - must servers allow
requests where scope/response_type only passed to PAR endpoint
https://bitbucket.org/openid/fapi/issues/315/par-certification-question-must-servers

A consensus has been reached which is enough at least for the conformance
suite. It is the same as my suggestion. Thank you for discussion.

Taka


On Wed, Sep 30, 2020 at 2:21 PM Takahiko Kawasaki  wrote:

> 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 
> 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
>> 
>> 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 <
>> vladi...@connect2id.com> 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 "Shoul

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

[Takahiko Kawasaki]

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 
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
> 
> 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 <
> vladi...@connect2id.com> 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 <
>> vladi...@connect2id.com> 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 Sectio

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

[Takahiko Kawasaki]

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

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 
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 <
> vladi...@connect2id.com> 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=...&re

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

[Vladimir Dzhuvinov]

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
> mailto:vladi...@connect2id.com>> 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 t

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

[Justin Richer]

In my opinion, all parameters should be able to be passed inside the request 
object, including `scope`. 

We couldn’t do that kind of thing in OIDC because that would be a breaking 
change to existing requirements in OAuth 2. JAR is taking the step of 
overriding those requirements, and so it should do so with all parameters.

There are a lot of things in OIDC that are a little wonky like this, where the 
general solution turned out to be slightly different than the tightly fit 
solution that OIDC pioneered. Discovery and issuer URLs are another notable 
example beyond this one.

In my view, OIDC should be updated to redefine its behavior in light of the 
family of new general purpose protocol extensions, including JAR. This could 
probably be done in a way that an IdP could support both the “classic” way of 
doing request objects as well as the “new” way, but likely for different 
clients. In which case, I think the behavior switch would be similar to what 
Vladimir describes.

 — Justin

> On Sep 23, 2020, at 7:58 AM, 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  > 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 t

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

[Takahiko Kawasaki]

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 
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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
ht

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

[Vladimir Dzhuvinov]

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



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth