Page Comparison

...

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)

1.  resource registration
   1. Error cases
      1. PAT less requests
      2. get/put/delete, requests without known id
      3. leaking between PATs
   2. Create resource description: POST rreguri/
      • should always work, returns new id
      • performs 5+ times for each PAT
   3. Read resource description: GET rreguri/_id
      1. ready all created 
      2. should always work for returned ids
   4. Update resource description: PUT rreguri/_id
      • should always work, return same id
   5. Delete resource description: DELETE rreguri/_id
      1. should always work
      2. removed from list after deleted
      3. future: effect on RPTs/tickets
   6. List resource descriptions: GET rreguri/
      1. only returns created resources for this PAT
      2. likely interjected between other cases, ensure state is reported accurately
2. permission ticket creation
   1. all scopes for single resource
   2. multiple resources, all scopes
   3. single resource, subset of scopes
   4. multiple resource, subset of scopes
   5. error cases
      1. wrong resource for PAT
      2. wrong scopes for resource id
   6. future,
      1. AS overriding resource/scope sets
3. introspection (optional)
   1. keep in mind, introspection is an OAuth defined item, want to limit to UMA defined functionality to remain minimal viable 
   2. RPT issued with all resources from permission ticket
   3. RPT used with correct PAT 
   4. active:true, must have the 'permissions' array
   5. how to test active:false response?
      1. would require manual intervention at the AS?
   6. error cases
      1. wrong PAT for RPT
   7. (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:

1. Eve
2. Alec
3. Steve

Non-voting participants:

1. Scott
2. Anik

Regrets: