UMA telecon 2021-08-26

Date and Time

Alternate-week Thursdays 10:00am PT
- Screenshare and dial-in: https://global.gotomeeting.com/join/485071053
- United States: +1 (224) 501-3316, Access Code: 485-071-053
- See UMA calendar for additional details: http://kantara.atlassian.net/wiki/display/uma/Calendar

Agenda

Approve minutes of UMA telecon 2021-06-10, UMA telecon 2021-06-17, UMA telecon 2021-06-24, UMA telecon 2021-07-01, UMA telecon 2021-07-08, UMA telecon 2021-07-15, UMA telecon 2021-07-22, UMA telecon 2021-07-29, UMA telecon 2021-08-05, UMA telecon 2021-08-12, UMA telecon 2021-08-19
Minimal Interop Profile
Relationship Manager - user stories / Discovery
AOB

Minutes

Roll call

Quorum was NOT reached.

Approve minutes

Approve minutes of UMA telecon 2021-06-10, UMA telecon 2021-06-17, UMA telecon 2021-06-24, UMA telecon 2021-07-01, UMA telecon 2021-07-08, UMA telecon 2021-07-15, UMA telecon 2021-07-22, UMA telecon 2021-07-29, UMA telecon 2021-08-05, UMA telecon 2021-08-12, UMA telecon 2021-08-19

Deferred

Minimal Interop Profile

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
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
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
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 a Client, I want to be able to declare types I understand, in order to successfully use complex APIs
As an RS, I want to defer permission ticket creation, in order to a) not have to understand the Client b) not make authZ decisions (tell me don’t make me think)
As an ASO, I want to pre-register Clients, in order to assess their appropriateness, capability and complete non-technical activities
As a Client, I want to pre-register with ASs, in order to a) test my UX and technical integrations b) declare my capabilities

UMA in Wikipedia

Have started an open document with the current english content. Everyone is welcome to suggest and edit and we can review next week

https://docs.google.com/document/d/1TbD4ODQOdQkLwHjlpjTQ4lbEPMbky67O8Clrzxejfn8/edit?usp=sharing

Attendees

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:

Browser not supported