CAEP Interop Profile says if OAuth Protected Resource Metadata (OPRM) is present the scopes to access the Transmitter must be fetched from it, but what should we do if OPRM is present, but the scopes_supported are not listed there?
CAEPIOP 2.7.2 OAuth Scopes says
If the Resource Server, hosting SSF configuration APIs, supports OAuth Protected Resource Metadata [OPRM] then the client MUST obtain the required scopes by using it.https://openid.github.io/sharedsignals/openid-caep-interoperability-profile-1_0.html#section-2.7.2-2.1.1
assuming "client" refers to the SSF receiver.
OPRM 2. says
scopes_supported
RECOMMENDED. JSON array containing a list of scope values, as defined in OAuth 2.0 [RFC6749], that are used in authorization requests to request access to this protected resource. Protected resources MAY choose not to advertise some scope values supported even when this parameter is used.https://datatracker.ietf.org/doc/html/rfc9728#section-2
What is the expected behavior for an SSF Receiver if scopes_supported a) is not present, or only partially present (not or not all scopes for ssf endpoints) in the OPRM provided by a SSF Transmitter?
In case of a) Should we then fallback to use ssf.read and ssf.write?
What to do in case b) ?
CAEP Interop Profile says if OAuth Protected Resource Metadata (OPRM) is present the scopes to access the Transmitter must be fetched from it, but what should we do if OPRM is present, but the scopes_supported are not listed there?
CAEPIOP 2.7.2 OAuth Scopes says
OPRM 2. says
What is the expected behavior for an SSF Receiver if
scopes_supporteda) is not present, or only partially present (not or not all scopes for ssf endpoints) in the OPRM provided by a SSF Transmitter?In case of a) Should we then fallback to use
ssf.readandssf.write?What to do in case b) ?