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 <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 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 https://www.ietf.org/mailman/listinfo/oauth
