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

Want to be able to still share a URL and have flow work. This is a discovery mechanism, has many privacy implications, eg user understanding what the policy means. How does the user really know what will happen, do we need a notification mechnism to allow review ahead of the disclosure? We don't nessicarily want it to be a revocation after the data is shared. In this case the consent needs to be just in time, eg Alice is notified about the specific request based on the more general policy. This is back to the CIBA/liberty alliance interaction service, where the the AS can reach out to the RO. One the client side this is handled by the request_submitted token response.

How would discovery be layed on top of the existing protocol (vs overload). Discovery creates AS-first (or discovery server-first) flows

exposing the UMA Fedz resource API to the client
- two step process, the client/RqP are first identified to the AS, to get access to an AS hosted resource API
A discovery endpoint, the client goes there first and then gets a ticket to use with a token endpoint
- who hosts discovery endpoint? can is cross AS's, it is discovery only for the UMA protected URL, where each URL can be independantly protected.
- pass in the resource id (eg resource indicators) to the token endpoint with a PCT

We are separating discovery from existing UMA flow/roles, it can be co-located with an AS or entire separate service, in future could be colocated with RM (Alice shares he RM url instead of specific URLS)

In UMA, I pick an AS, all of my/Bob's services go through my AS to get authZ to my resources. Reality has shown there are likely 3/4 different ASs → this is one purpose of the RM, to be a layer that serves Alice directly. Comes down to where agreegation happens, and who knows about it, how this makes Alice's life easier to manage her distributed information.

We are seperating the policy of discoverability from the authorization to access, they have different policy needs. If these are different, why allow discovery? Because Alice wants transparency and want to understand the different risks. Knowing that Alice takes landscape photos may be discovery, while access to specific photos may want to be controlled. This goes back to a general policy around discvoery (all photographers can discover) vs the specific RqP (only selected photographers can access specific photos, tiered access)

Discoverability works well where there are a small amount of URLs, however in complicated APIS, there could be 100+. There can be expansion to 'wildcard' urls or types of resources vs the specific URI.

RS first access lacks mechanisms for intent. The RS must extrapolate from a single request the scope of resources to includes in the permission ticket. Discovery allows client/RqP to speak to there intent, eg as a client I can understand only specific resource types, however the RS can't know this ahead of time. We want to match the granted resources to the intent/capability of the Client. Bob can show up and declare what privacy obligations he'll uphold, and leave the notarized receipt with the AS for Alice to follow up with eg Data Controller information. Rather than audit trail, the receipt is meant to be one-time signal that be compared over time and allows the identification of policy change. On all resource accesses the AS receives a new and comparable-to-previous receipt.

I'm a health care system or photo sharing systems, the site needs to standalone. The could be cases where an RS is trying to add authz capabilities, this can be delegated to the UMA environment without major changes to the core RS. UMA needs to work for both scenarios.

The interesting questions always comes back to liability, if the AS is the authority and the RS releases the wrong data, the AS still needs to take the liability. The RS is the data custodian, and they always have liabity/responsibility to the RO. If company A uses UMA as technology for RS/AS/RM/Discovery, then there is little liability question, it's all in the same place. Once the ecosystem is wider, where company A holds the data, and delegates authZ to an AS of company B, now the liability split is less clear.

When PDP did the dashboard, there is an idea of consent boundaries. Anything happening at the RP on behalf of the RO, has a separate consent boundary, between teh client software and the RqP.

The ANCR would allow Bob/Client to create the notice receipt to the discovery mechnism so that Alice is able to see what terms we're accepted. From RqP perspective, access is based on presented claims, to meet Alice's policy. Bob wants to set his terms for sharing those claims with an AS(?) The policy within the AS is not-specified, the ANCR could be a profiled claim type for Alice/Bob to both understand the legal requirements/expectations for the claim handling. Purpose is to reduce the cognitive load on Alice/Bob to understand the terms, having a common vocabulary vs ad-hoc TOSs.

As an RqP, I can define an ANCR receipt, in order to specific my requirements for claims handling. THis could be a claims presentation to the AS. There are two privacy rights that need to be balanced: Alice→arbitrary client vs Bob→arbitrary AS. In ANCR, there is a cyber rights notary, when Bob wants access he see's Alice's preestablished policy.

AOB

Attendees

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

Voting:

Thomas
Alec
Domenico
Sal

Non-voting participants:

George
Ian

Regrets:

Eve
Nancy

Mark Lizar

unread,

Jul 9, 2021, 7:46:09 AM7/9/21

to Alec Laws, wg-uma@kantarainitiative.org WG

Alec,

A lot of great notes. Inspired me to try and add to the f Discovery discussion.

The flow we have been discussing in ANCR is: Bob puts up a sign, or posting an Online notice to indicate the operation of a service. Alice see’s a sign or is interrupted with a pop-up notice, or form for info/make an account. Alice generates an ANCR record for the Notice, then generates a receipt, sends the receipt to a Cyber Notary, the controller validated and verified,

This Discovery method is human centric, this means a person has to see a sign or notice and understand it. Or interact with it. The notice or sign has to be legally compliant (e.g. have identity of notice controller, contact info, and ideally purpose or purpose category) This required for notice is universal for humans. For example, if people dont know who controls their data, then legal consent is not possible. (In 99% of cases) Consent is a human condition. A consent grant, has a scope, this scope is used to determine permissions.

Discovery: Alices interaction with the notice provides that first receipt for explicit awareness to the Controller. (The first Tier of Awareness).

This tier is also required in law, and a key to setting shared privacy expectation. In addition, this proof of notice, provides evidence that the data controller/RP is compliant. Adding a direct link to privacy rights based access controls, (if proportional) then the liability for using the service can be transferred to Alice. In terms of medical research, this could be the purpose of the engagement, in this regard, the next step after discovery would be an explicit permission to share for a specific purpose to a legal entity, who is accountable, and sets to the permission for the federation. Research are the agents of the federation, Alternatively, the person could specify the purpose, and also that explicit consent and the identity of research is required each time. (So federation not needed)

Either way, the Cyber Notary that signs the consent receipt turns it into a shareable token (buy applying rights conformance profiles. Note: I have been working on these and have just posted this today — illustrating Privacy Rights & Receipt Types and the GDPR Receipt Type Profile.

The aim is that this profile can be applied via api, (using a receipt token) to check if the legal justification is still valid, if a notice or disclosure is required, and this can be accomplished each time the researcher/org etc. process that personal data/ (access the resource). Each time the receipt token is used it is validated by the active status of the legal justification (the legal state of processing) which is presented to the Cyber Notary. (Notartized for rights) e.g. if its a rp it is most often a contract legal justification.. so a contract notice receipt is generated with the ANCR Record ID and this is discoverable by Alice the next time she uses the service. .

That is essentially the flow.. and scoping components. The objective of this flow is for Alice and Bob to maintain a shared state of privacy and security expectations.. And thus be able to maintain the relations with the use of rights as defined in law.

— Looking forward to making a diagram.

Mark

_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
https://kantarainitiative.org/mailman/listinfo/wg-uma

Reply all

Reply to author

Forward

0 new messages