...
Let's get to some test cases/requirements?
PAT is fairly impl specific, could be given to the Mock RS test suite
- auth code flow
- can become first point of non-interop
Goal: make sure that AS's are interoperable , eg one AS can be 'swappable' with other ASs. Understanding of 'extras'/vendor specific values that degrade that interop. As an RS the more ASs I can support define the 'wide' ecosystem I can support
Scope of test
- 1 AS under test
- 1 Mock RS test suite
- 2+ ROs
- clear success cases (including error conditions)
- response testing for unexpected values returned → WARN
- Minimum Viable ONLY
Input to Mock RS Test Suites
- name of 'rreguri' endpoint at the AS
- multiple PATs to represent the RO context
- at least 2
- value for _id, ie what key will the AS return
- resource descriptions keys supports
- Only required content is resource_scopes
- Optional to push other keys (type, desc, name, icon_uri)
- create support for user_access_policy_uri
- use of introspection
- optional support for exp, iat, nbf (maybe too much since this is OAuth introspection scope)
- resource registration
- Error cases
- PAT less requests
- get/put/delete, requests without known id
- leaking between PATs
- Create resource description: POST rreguri/
- should always work, returns new id
- performs 5+ times for each PAT
- Read resource description: GET rreguri/_id
- ready all created
- should always work for returned ids
- Update resource description: PUT rreguri/_id
- should always work, return same id
- Delete resource description: DELETE rreguri/_id
- should always work
- removed from list after deleted
- future: effect on RPTs/tickets
- List resource descriptions: GET rreguri/
- only returns created resources for this PAT
- likely interjected between other cases, ensure state is reported accurately
- Error cases
- permission ticket creation
- all scopes for single resource
- multiple resources, all scopes
- single resource, subset of scopes
- multiple resource, subset of scopes
- error cases
- wrong resource for PAT
- wrong scopes for resource id
- future,
- AS overriding resource/scope sets
- introspection (optional)
- keep in mind, introspection is an OAuth defined item, want to limit to UMA defined functionality to remain minimal viable
- RPT issued with all resources from permission ticket
- RPT used with correct PAT
- active:true, must have the 'permissions' array
- how to test active:false response?
- would require manual intervention at the AS?
- error cases
- wrong PAT for RPT
- (future) AS imposed changes based on policy
The test suite could be 'random' ie for scope generation?
Real application, UMA protect userinfo (OIDC scopes)
Relationship Manager - user stories / Discovery
...
As of October 26, 2020, quorum is 5 of 9. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve, Steve)
Voting:
- Eve
- Alec
- Steve
Non-voting participants:
- Scott
- Anik
Regrets: