Page Comparison

...

Solution information: RS role

Any API exposed by an RS participating in interop has to expose either multiple resource sets (as registered with the interop MUST be "pbryan" API-compatible to provide predictability to clients participating in the interop. If a participant claims hardship and is also prepared to expose a well-known, well-defined API such as SCIM or FHIR, and at least one other party participating in the interop also has an interest in that specific API, we can consider creating a results list subset for the testing among that sub-communityAS) or multiple scopes, or both. This enables testing UMA-specific interop around sufficient/insufficient authz data, permission tickets that match/don't match the requested type of access, etc., while not dictating the specifics of what the API looks like. Each RS participant needs to provide enough information directly in the table below to explain how to access these differential resource sets and scopes, e.g. the URLs, parameters, etc. This way, clients can tell whether the RS was at fault or not if something goes wrong with authorization.

...