https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-08-19

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

Deferred

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 

Relationship Manager - user stories

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

Minimal Interop Profile

Goal: 

What parts of the spec will be test? Should we separate Grant from Fedz?

What is takes around the UMA AS

1. Mock RS (well known resources/scopes)
2. Mock Client (well known requests)
3. Mock IDP (well known RO/RqP)

Fedz:

• Mock RS test client
• PAT creation 
  • RS client credentials
  • RO authorization → auth code flow 

• 1 resource registration
  • set of resources, scopes, 
• 2 permission ticket creation
• 3 introspection

Grant:

• Mock Client test client
• Client Credentials → static/ well defined
• RPT endpoint
  • claims pushing, multiple rounds of pushing?
  • error
    • claims pushing or gathering
    • request submitted
  • PCT
• claims gathering endpoint

Policy:

• RqP has the rights via identity
• Other requirements, agree to ad-hoc TOS
• specific acr/scopes in claims token from 

FR AS:

https://github.com/ForgeRock/frdp-uma-resource-server/wiki

• claims pushing (IDToken)
• no
  • PCT
• not quite
  • request_submitted is supported, creates a pending req for RO, not using ticket/interval though
  • redirect_user / interactive claims gathering, gets a claims token through an auth_code flow

IDENTOS AS:

• interactive claims gathering
• RSasRO, RO has client credentials with AS
• no
  • request_submitted
  • PCT
  • claims pushing

Discovery

Per RS-directed

• the RO can tell the RS that some resources are public/discoverable (their existence not their content...)
• RO is able to share that discovery URL to the RqP,
  • doesn't mean the RqP can access all → could UMA protect discovery/webfinger, and get back the specific "stuff" that RqP can access
  • this is instead of sharing many specific URLs
• RO has abstracted URLs for specific resources, this is separate from discovery?

File names... in medical case the resources don't have 'names', A LOT of info falls under simple types. Eg sleep records vs infectious disease, should the RqP be able to discover the existence of both types even if they can only access the sleep records. 

AS-directed (or discovery service-directed)

• An RqP goes to the AS and asks for all the resources granted to the RqP
• the AS has the resource and the policy about which RqPs can access
  • can the RqP learn about the resource URLs (across many RSs) it can access
• Similar to Pension Dashboard case, discover and register all pensions with a single AS. RqP (user or financial advisor) go to the AS to find the locations and authZ to access
• Identos use-case,
  • the Client understands specific types of resources (eg xrays)
  • send the RqP to the to the AS to
    • i) know who the RqP is and (eg the Primary Care Physician)
    • ii) which resources that RqP have that match the type (all their patients xrays)
    • iii) choose which of those to share with the client (a specific patients for a specific encounter) 

Two discovery endpoints

1. protected discovery → managed by AS
   1. (or indapendant discovery service?)
   2. OIDC distributed claims (endpoint, token) that the RP can get claims from there
   3. the AS doesn't know the endpoint in UMA today
2. public discovery → managed by RS
   1. in FR impl, the RS proxies Client requests to the AS, to reduce who the client needs to talk to and could provide the more wholesome discovery

Attendees

As of October 26, 2020, quorum is 5 of 9. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve, Steve)

Voting:

1. Thomas
2. Alec

Non-voting participants:

1. George
2. Scott

Regrets:

1. Steve