treatment of returned scopes divergent from RFC 6749

[Brian Campbell]

Item 15 in Section 5.2.2 of FAPI part 1 currently says that the authorization server "shall return the list of granted scopes with the issued access token" and FAPI part 2 inherits this in its own section 5.2.2 saying the AS "shall support the provisions specified in clause 5.2.2 of Financial API - Part 1".

While §5.1 of RFC 6749 allows for the scope parameter to be omitted when the scope granted is the same as the scope requested by the client.

   scope
         OPTIONAL, if identical to the scope requested by the client;
         otherwise, REQUIRED.  The scope of the access token as
         described by Section 3.3.

Requiring specific behavior that differs from RFC6749 is probably something that FAPI should avoid unless there's some compelling reason for the difference. And in this case, I'm struggling to see the reason.

All that I can come up with is that the requested scope could be altered by a bad actor in the user agent before the request is delivered to the AS. Then if all those altered scopes are approved, the AS would consider that identical to the scope requested by the client and omit the scope parameter in the response. In that case the client wouldn't be aware that the scope associated with the token(s) were different than what was requested.

That seems kinda far fetched though. The user of the user-agent is the resource owner so has no real need or motivation to alter the scope. And CSRF protection (required by FAPI and strongly encouraged by OAuth) should prevent or catch other attempts to alter the scope.

Also JWT/JWS signed requests, which are required by FAPI part 2, prevent the scope in the request from being altered.

I guess where I'm going with this is suggesting the removal of Item 15 in Section 5.2.2 of FAPI part 1. Or, if there's really good reason to have it there, I'd like to better understand what that is.

[Nat Sakimura]

I need an input from the Open Banking implementers if they have implemented it.

From the point of view of a profile, it is perfectly fine to be more restrictive than the base spec. That's the whole point of it. So, in principle, I find it OK with requiring returning the granted scopes.

In the protocol analysis, we are treating the user-agent as an untrusted entity with a possibility of the attacker inserting itself as a network attacker, e.g., as a browser extension, etc. So, it is a risk that we should deal with. It is actually a popular attack though primarily for the read-write access.

For read-write access, this has been dealt with the request object, so it is probably ok to drop it, though it will make the formal analysis more complicated as a different set of parameters makes them different protocol form that point of view.

The is another reason behind requiring it even for the read-write case. The assumption was that the server would also support read-only clients as well even in such a case. Then, uniformly requiring the scope to be returned seems to make the life simpler. (For Open Banking, they only support read-write so it is a non-issue but FS-ISAC is only supporting read-only.)

[Brian Campbell]

I understand, of course, that a profile can be more restrictive than the base spec. My point was that the profile should have some compelling reason for the restriction. Also some restricted behaviors are more likely than others to be controllable through off the shelf configuration options in products (although which is which is somewhat subjective, of course). In this case the reasoning didn't seem particularly compelling to me and the behavior seemed like something that OAuth/OIDC products and implementations likely wouldn't have configuration options for.

in the spirit of full disclosure, this is an issue that we've run into. My understanding is that the Open Banking conformance suite has a test for returning all the scopes even when the scope granted is the same as the scope requested by the client. Our product dutifully follows what RFC 6749 allows and omits the scope parameter in the response when the scope granted is the same as the scope requested by the client. And there's not currently any configuration option to control that behavior. Banks that are using our AS/OP product aren't passing that test and needing an exception from the Open Banking folks or however that works.

And that led me here to push back on or at least try and better understand the requirement from FAPI.

[Joseph Heenan]

I need an input from the Open Banking implementers if they have implemented it.

As per https://openbanking.atlassian.net/wiki/spaces/DZ/pages/126321042/Open+Banking+Security+Profile+Conformance 4 of the CMA9 banks have implemented the standard as written and hence pass the relevant part of the conformance test, plus all 3 of the reference/mock/sandbox implementations.

I'm not 100% sure this should influence the situation - if we removed the clause in FAPI, those banks would still be compliant as RFC 6749 does allow this behaviour.

In my personal opinion, it seems a little finely balanced, but I would tend to think that the extra clarity/certainty provided by the authorisation server always returning the scope is a good thing. It relieves the client from having to assume that all scopes were granted, and (by making the scope parameter always be returned) encourages client developers to realise that they should be looking at the parameter as they will always see the authorisation server returning it.

[Ralph Bragg]

I need an input from the Open Banking implementers if they have implemented it.

Echoing Joseph's sentiments here but also a little bit of Nat's. I'm happy if the scopes are not returned if they could not be altered by the User Agent. i.e if the scopes were always contained in the request object. If they weren't contained in the request object and could be altered by a UA without the OP or RP realising that this occurred then it's a problem that needs to be addressed

Unfortunately for the requested scopes claim in particular, wouldn't the opposite nearly always be true? "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."

As scopes must always be on the URI string i'd expect implementors to not put scopes in the request object.

From OIDC Core When the request parameter is used, the OpenID Connect request parameter values contained in the JWT supersede those passed using the OAuth 2.0 request syntax. However, parameters MAY also be passed using the OAuth 2.0 request syntax even when a Request Object is used; this would typically be done to enable a cached, pre-signed (and possibly pre-encrypted) Request Object value to be used containing the fixed request parameters, while parameters that can vary with each request, such as state and nonce, are passed as OAuth 2.0 parameters.

[Joseph Heenan]

@RaidiamRalph FAPI part 2 contains the clause "[the authorisation server] shall require that all parameters are present inside the signed request object". That mitigates the situation you describe I believe, if the scope in the URL query is modified the one in the request object is still the only one that matters.

That doesn't help the situation in part 1, ie. in part 1 the UA can modify the scopes and this may not be detected unless the AS always returns the granted scopes.

[Ralph Bragg]

@joseph_heelan yep i agree - i was thinking more from a vendors point of view generically. FAPI2 is just one profile. The pinciple should be, if it can be altered in the user agent and the RP and OP may not know that it was then the information (scopes in this case) should be conveyed back to the RP so it can confirm that they weren't changed.

[Ralph Bragg]

@bwb100 We need to bring this one to a resolution as it's now causing several ASPSPs in the UK angst. Either this body accepts that the profile is correct or it is changed. As it stands i believe the profile is correct. Latest example; in slightly older versions of a vendors product it was not possible to add claims to a id_token unless the "profile" scope was requested. The work around is that an ASPSP is having to use a it's WAF to intercept the request and then "tac on" the profile scope in order for this functionality to work. The resultant access token also includes "profile" as a bound scope even though "profile" was not requested by the TPP. Unfortunately this "tampering" isn't visbile to the OP and and such the scopes are not returned to the TPP on the request for tokens so the TPP has no visbility either.

[Tom Jones]

Is the ASPSP a user client? if that is so it should never alter the scopes as that is what the user has consented to.

[Brian Campbell]

According to the call notes from May 9 about this issue, "Those on the call felt that the wording in FAPI was fine, even though it is more restrictive than the base standard." I wasn't on that call but that note and the mixed reaction/discussion in this ticket indicate that there's not consensus or appetite for the proposed change at this point.

[Brian Campbell]

Doesn't seem to be consensus from the FAPI WG for making a change.