[WG-UMA] Draft minutes of UMA telecon 2021-07-29

[Alec Laws]

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-29

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

Deferred

Relationship Manager - user stories

1. As an ASO, I want to allow Alice to bring a resource management UX, in order to not provide this myself
   1. Today, the AS must provide some interface for Alice to see her registered resources (uri) and the policy for each resource→RqP. Core UMA has some implication that Alice can 'bring her own AS'
   2. As discussed last time, Alice may need to work with many AS's, and sometimes that is out of her control
   3. A challenge may be that Alice needs to authenticate uniquely to each AS? Alice will authenticate at an IDP, and there can be federation
   4. IN RM draft
      1. Instead of Alice managing resources in several AS UXs, she can use her single RM to manage her resources. In some cases, the existence of multiple ASs can be hidden from her
      2. The concept of the PAT is changed, such that a PAT represents the entire RS (all ROs) and the resource negotiate between the RS and AS are the types, not specific resources
         1. There's not necessarily a RO specific PAT, as the RS's API may not support user context in the path, even if it does there is a challenge around getting RO specific uris to the RqP
         2. ex an RS api `/me/profile` the RS get's a ticket that represents that type of resource, and during claims gathering the AS is able to determine the specific profile to return to the client. The RS learns the specific profile either by inspecting the RPT or through introspection
      3. Some initial goals of RM were to make a 'zero knowledge' AS. An AS that doesn't need to see end-user identity claims. Identity federation happens to the RM, the RM then registers RqP policy against RS→RM resource ids. The AS is only learning resource ids, and conveying to the RS during specific transaction. The RS is responsible to resolve the resource id to the right RO information 
      4. As there are more RS specified AS's, there are also new needs for federation or mutual trust between those ASs to get back to widest possible ecosystems. This is OOS of RM but could be achieved through other governance registries or discovery services
2. As Alice, I want a way to grant Bob access to my resources without knowing the URLs, in order to a) not deal with URLs b) share more complex resources (ex not a PDF, a health record)
   1. Today, all of Alices resources are registered with the AS independently, however this doesn't include any specific URI. Therefore she needs to get URIs for the RS, and somehow know which registered resource id corresponds to what URI(s). How does Alice know what at the AS means what URI to the RS?
   2. In some reference impls, the RS creates a new URI that is directly linked to the registered resource. 
   3. rsurl.com/alice/A.pdf, rsurl.com/alice/B.pdf, rsurl.com/alice/C.pdf → registered at the AS → (type:pdf, scope) x3 → (randomid1, randomid2, randomid3). 
      1. the RS keeps track of relationship from public uri and internal AS registered id. The RS writes RqP policy to the AS against the randomidN. 
      2. This RS performs on RM behaviour instead of making Alice interact with the AS at all
   4. there are also challenges exposing URIs AT ALL to Alice and Bob, if the URI includes any PI all parties can see it, even if they're not authorized. Best Practice: NO URIs are human readable
   5. Today this is somewhat addressed as URIs don't leave 'digital space' we share them through copy/paste, not through analogue means
   6. There are more challenge with URI sharing when the number of resource is very large or are dynamically create (such as FHIR observations created by a device)
   7. Another FHIR complication is querying by time frame... 
      1. some ways to address through 'shortcut' scopes like 'last_three_month', 'not_before=<timestamp>' 
      2. This is better addressed by Rich Authorization Request. There are still challenges with UMA async, Alice can't consider all possible authorization requests ahead of time. Alice is smart but she can't see the future. 
3. As Bob(RqP), I want to be able to discover resources available/shared with me, in order to not need URLs sent by Alice
4. As a Client, I want to be able to declare types I understand, in order to successfully use complex APIs 
5. 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)
6. As an ASO, I want to pre-register Clients, in order to assess their appropriateness, capability and complete non-technical activities
7. As a Client, I want to pre-register with ASs, in order to a) test my UX and technical integrations b) declare my capabilities

AOB

Attendees

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

Voting:

1. Alec
2. Eve

Non-voting participants:

1. Scott
2. Zhen

Regrets:

1. Steve