FAPI1Adv: Apparent inconsistency in RP requirements compared to OP requirements
There’s an apparent inconsistency in specs, which means the RP tests and the OP tests for FAPI1 Advanced are also inconsistent.
In the FAPI1Adv RP tests, we have a test for clause 5.2.3-10 in FAPI1-base:
shall verify that the scope received in the token response is either an exact match or contains a subset of the scope sent in the authorization reques
The test includes an extra random scope in the token endpoint response, and expects the client to fail.
In the FAPI1Adv OP tests, we don’t appear to do any checks on the scope returned by the token endpoint, i.e. we don’t seem to be failing OPs if they decide to return extra unrequested scopes.
The two obvious ways to resolve this inconsistency seem to be to either:
- Remove the RP test, or,
- Update the OP test to check scope if it is returned from the token endpoint <--- the FAPI WG decided this approach is correct, see below
Guidance from the FAPI WG on the way forward would be appreciated please. I believe this issue was raised in this conformance suite issue: https://gitlab.com/openid/conformance-suite/-/issues/966
Comments (11)
-
reporter -
reporter Minutes of meeting that decided to remove the test: https://bitbucket.org/openid/fapi/wiki/FAPI_Meeting_Notes_2022-04-20_Atlantic#rst-header-id33
-
- changed component to Part 2: Advanced
-
- changed component to FAPI 1 – Part 2: Advanced
-
- changed component to FAPI 1: Advanced
-
-
assigned issue to
Joseph to check if test was removed
-
assigned issue to
-
@Joseph Heenan any update on this? Thanks
-
reporter I’ve no idea - I’ve opened a ticket on our side to make sure we do check and remove: https://gitlab.com/openid/conformance-suite/-/issues/1205
Now we’re talking about errata, we should consider this one for an errata too - in particular clause 5.2.3-10 in FAPI1-base:
shall verify that the scope received in the token response is either an exact match or contains a subset of the scope sent in the authorization request
should have “if the request was passed in the front channel and was not integrity protected” added.
I’ll update the title of this ticket to make clearer it’s to be considered for a spec errata.
-
reporter - edited description
- changed title to FAPI1Adv: Apparent inconsistency in RP requirements compared to OP requirements
-
reporter I missed that we already had an issue In the conformance suite:
https://gitlab.com/openid/conformance-suite/-/issues/966
So I’ve closed the issue I opened about. This is already resolved on the conformance suite side, so it’s just the spec errata to be considered now.
-
- changed status to resolved
fixes
#494- FAPI1Adv: Apparent inconsistency in RP requirements compared to OP requirements→ <<cset 3840af391680>>
- Log in to comment
This was discussed on today’s WG call; there seemed to be a consensus for option '1', removing the RP test. We did discuss tweaking the spec but any change would likely be too close to a normative change to do it an errata.
There was some in-depth discussion about this previously, which I’ve since looked up and the “other” clause on this subject (a requirement on the AS) had “if the request was passed in the front channel and was not integrity protected” so it reads:
The RP clause I quote about probably should have had that same “if the request was passed in the front channel and was not integrity protected” added at the same time.