UMA telecon 2021-08-26
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
- 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 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: