This is mostly a policy change due to actual practice. If a client makes a request with a set of scopes then does a refresh or exchange without specifying scopes, the standard say to "use the original scopes". The problem with this is that many specifications (such as WLCG) send along general scopes in the initial request to be used as queries. E.g. an initial request might have
read: write:
and get back a full set of these with paths the user is allowed. The user consents to these on the consent screen. Subsequent calls should have a subset of these returned scopes (or downscopes), but in practice this is not required by the spec and is not done. At this point, OA4MP is returning no scopes (or for WLCG throwing an error that no scopes were found).
What should now happen is that the original returned access token scopes are used whenever the user does not explicitly request a different set. May revisit this thinking in the future.
This is mostly a policy change due to actual practice. If a client makes a request with a set of scopes then does a refresh or exchange without specifying scopes, the standard say to "use the original scopes". The problem with this is that many specifications (such as WLCG) send along general scopes in the initial request to be used as queries. E.g. an initial request might have
read: write:
and get back a full set of these with paths the user is allowed. The user consents to these on the consent screen. Subsequent calls should have a subset of these returned scopes (or downscopes), but in practice this is not required by the spec and is not done. At this point, OA4MP is returning no scopes (or for WLCG throwing an error that no scopes were found).
What should now happen is that the original returned access token scopes are used whenever the user does not explicitly request a different set. May revisit this thinking in the future.