UMA telecon 2020-09-10

Owned by Alec Laws
Last updated: Sep 10, 2020
2 min read

UMA telecon 2020-09-10

Date and Time

Agenda

  • Relationship Manager profile
  • AOB

Minutes

Roll call

Quorum was not reached.

Relationship Manager profile

See the policy manager API in this email thread. Also see Policy Manager Extension #363. Continue discussion, Eve has proposed some questions to explore

- One API (AS only) or two (also RS)?
- (Each) API protection model?
- Topological and trust assumptions or lack thereof? What can be co-located? How many of each thing can there be?
- Any rules needed for policy (“policy condition”) priority between RM and AS (the “cascading” scenario)
- A clean way to model or illustrate the scenario when the RS is hosting claims (the “turtles” scenario)
- Customer requests for functionality that Eve discussed last time – this was the discussion of consent management servers (CMS's)


Reviewed the diagram of the different proposed extensions/profile from https://groups.google.com/g/kantara-initiative-uma-wg/c/iOfz_kYZ8f8

Adrian comments, that the policy management should not be uni-directional. Proposes we look into the cascaded AS spec before the other ones. 1. there has been interest, going back to the VA work, pauldron implementation. 2. object to requesting party not directly contacting an agent of the RO

In the diagram the dotted lines represent a single RO 'Agent' wherein Alice can ask the 'central AS' to federated claims gathering of the RqP to her 'cascaded AS'. In this way, the Resource request is mediated by the central AS, but the claims gathering happens directly between the RqP and an agent/service controlled by Alice.

Adrian, From data minimization, want RqP to come first to Alice's agent. Alice's AS would issue a capability to the the RqP, and the RqP would take that capability to the central AS. It's not problem with the central AS protecting the RS, but instead to maintain the primacy of Alice's AS before Policy decision happens. The purpose of the second AS is the maintain the privacy of the RqP. 

Doesn't Alice's AS set the policy conditions? Including presentation of personal information?

Are we separating two use-cases? First where a party known to Alice wants to access her resources, to protect that RqPs PI, those claims should be collected by Alice's agent. Second, a party unknown to Alice (eg defined by the community AS), Alice's AS can't evaluate those claims? No to second, Alice's AS should always get the chance to reject the request. What if Alice's AS can't evaluate the claims, this is where the "Adrian clause" kicks in and the central/secondary AS can override Alice's AS? 

It depends on nature of RS. eg break the glass use-case or a federal request for access. Who is responsibly to audit the transaction and claims? 

Which AS comes first, Alice's AS or the community AS? 

Attendees

As of September 3, 2020 (pre-meeting), quorum is 5 of 9. (Michael, Domenico, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve)

  • Peter
  • Michael

Non-voting participants:

  • Alec
  • Adrian
  • Scott

Regrets:

  • George
  • Eve