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
