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)

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

1. As a Client, I want to be able to declare types I understand, in order to successfully use complex APIs 

2. 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)

3. As an ASO, I want to pre-register Clients, in order to assess their appropriateness, capability and complete non-technical activities

4. 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:

1. Eve

2. Alec

3. Steve

Non-voting participants:

1. Scott

2. Anik

Regrets: