- WG-UMA - mailman.kantarainitiative.org

Agenda for UMA telecon 2018-05-24
by Eve Maler 23 May '18

23 May '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-05-24 Date and Time - *Thursdays 9am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/857787301 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes - Approve minutes of UMA telecon 2018-03-01 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-03-01>, UMA telecon 2018-03-29 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-03-29>, UMA telecon 2018-04-12 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-04-12>, UMA telecon 2018-05-10 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-05-10> - Business model and use cases - RUFADAA <http://www.uniformlaws.org/shared/docs/Fiduciary%20Access%20to%20Digital%20…>++ scenarios – Eve will have some visual representations – how to "spec" all this? - UMA and Open Banking - Analyze relevance of UMA for "decoupled" use cases - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Additional news I forgot to mention on today's call: OpenMedReady
by Eve Maler 10 May '18

10 May '18

Some news (in which my company is involved) came out last Thursday regarding a new effort called OpenMedReady. The headline on its website, openmedready.org, is: "Data provenance, security, privacy and consent in remote patient monitoring", and UMA is mentioned as one of the key specs underlying it. One way to think of it is as a healthcare IoT initiative layered on top of existing standards and profiles. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2018-05-10
by Eve Maler 10 May '18

10 May '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-05-10 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2018-03-01 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-03-01>, UMA telecon 2018-03-29 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-03-29>, UMA telecon 2018-04-12 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-04-12>: Deferred. Business model and use cases - RUFADAA <http://www.uniformlaws.org/shared/docs/Fiduciary%20Access%20to%20Digital%20…> scenarios from Tim R ("life stage 4") Looking at the new (very collapsed) breakout explanation of how a Data Subject can delegate two kinds of authority to a separate RRA, does using the word "delegation" make sense if a child is delegating to a parent? We do have the child-to-party use case right afterwards. In that case, it's typically by law (guardianship). If delegation happens by law, in essence automatically, it has a sort of passive effect in the case of newborn Johnny – he doesn't literally "delegate-perm-authority-to" mother Alice, it just...happens. So maybe in modeling the graph, we need to think about wording the edge label a little more carefully. Just like "Data Subject Agent" was a little odd as terminology, currently "Requesting Party Agent" maps oddly next to "requesting party" (the lowercase technical entity terminology). Let's think on a better substitute. The "RUFADAA use case" feels like "life stage *n*"/scenario *n*: 1. The Data Subject is too young to use digital assets at all. 2. The DS is old enough to use assets but too young to consent to their use, so they have a legal guardian. 3. The DS is old enough to consent to their use. They manage their digital assets themselves. 4. The DS jointly manages digital assets with one or more others (e.g. online bank accounts). 5. (RUFADAA) The DS becomes mentally incapacitated or dies. (Obviously this can happen at earlier life stages as well.) See the design patterns below. RUFADAA is now enacted in 39 states of the union, and 6 more states are considering it, so we can expect it to be truly uniform/blanketing the US soon. Probate used to deal only with tangible assets. Not it's starting to deal with digital assets. It's key that our definitions in the draft business model report have incorporate "digital asset" terminology. The challenges of fiduciary (US term)/personal representative/executor handling of someone's estate in a world where we have social media and even online bank accounts have become clearer. There have been concerns about terms of service language and differential powers reserved by the services in question. The "Revised" UFADAA has accounted for more of these challenges. One key revision is to use the word "User" to allow our "resource owner" to designate who can manage digital assets after we're dead. It also clarifies what to do in the case of a conflict in instructions: the user's express instructions take precedence of the terms of service. The issue of the RRA is very relevant to all this. The law uses the term Online Tool for a solution that implements the law. We discovered that Google makes available an Online Tool for its own accounts, and Facebook has a more limited one. The idea is that, once we figure out the mappings to UMA legal roles and technical entities, we can help UMA-enabled services offer The possible scenario "design patterns" are as follows: - Alice doesn't designate anyone to manage her digital assets (in this case the Custodian's terms of service are in force) - The terms of service she agreed to with the Resource Server Operator *make the Custodian* the Designated Recipient - She makes a disclosure permission plan that designates her fiduciary/personal representative/executor to manage her digital assets - She designates her fiduciary/personal representative/executor to manage her digital assets - Inter vivos, she designates a Trustee who is the Designated Recipient *who is not* her fiduciary/personal representative/executor to manage her digital assets - The Trustee *grants access* to her fiduciary/personal representative/executor - The Trustee *does not grant access* to her fiduciary/personal representative/executor - She makes a disclosure permission plan that designates a Designated Recipient *who is not* her fiduciary/personal representative/executor to manage her digital assets – this could be the Authorization Server Operator, making her a special offer of an agreement that would count as express instructions - The Designated Recipient *grants access* to her fiduciary/personal representative/executor - The Designated Recipient *does not grant access* to her fiduciary/personal representative/executor Other laws in other jurisdictions may have different patterns. For this set of patterns, the theory is that if the fiduciary/personal representative/executor is the Designated Recipient, they become the RRA. If someone else is, then they *may or may not* grant access to the fiduciary/personal representative/executor, where the latter would be a RqP/RqPA. In email, John mentioned: More grist for the mill, or possibly water already under the bridge. See page 21 of the attached document on the ‘capacity to consent and assent’. This is about consent for research at SickKids hospital. What the scenarios elide, perhaps because its out of scope [likely true], is who gets to make the decision about the capacity of the data subject to give consent. It may not simply be a matter of age, and if there is someone acting for the data subject for a limited time, should they have the authority to grant a license that will last longer than their authority? BTW, references to TCPS are to this: http://pre.ethics.gc.ca/eng/policy-politique/initiatives/tcps2-eptc2/Defaul… UMA and Open Banking - Analyze relevance of UMA for "decoupled" use cases Deferred. Other news and updates - Implementation news RedHat Keycloak's 4.0 beta release documentation shows that it has UMA2 support. This is now on our Implementations <https://kantarainitiative.org/confluence/display/uma/UMA+Implementations> page. Who is going to EIC? Eve, Mike, George, Domenico. Eve has a keynote (that she's stressing about). Who is going to Identiverse? Eve, Mike, George, Sal, Justin. Mike and Eve have an UMA2 masterclass. We can probably work in a couple of demos. Sal, Mark, and Eve have a Privacy 2.0 masterclass. Justin has two talks. Sal is thinking about having an open house on Cape Cod (Buzzard's Bay – pretty close, "75 minutes on a bus") anytime starting Thursday prior. ZZ Auth is playing on the Wednesday night. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Sal 3. Eve 4. Mike Non-voting participants: - Scott - Tim - George - Justin - Bjorn - Colin Regrets: - Maciej - Cigdem - Andi - John *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

The Revised Uniform Fiduciary Access to Digital Assets Act
by Eve Maler 09 May '18

09 May '18

http://www.uniformlaws.org/shared/docs/Fiduciary%20Access%20to%20Digital%20… In our last call (now a month past), we discussed this use case a bit, and Tim has sent me some scenarios so that we dig into it a bit more deeply in this week's call; see below. The "parent-child resource management use case has three life stages (little Johnny is too young to use digital resources; old enough to use them but too young to consent; and finally old enough to consent and thus kick his legal guardian out of being in the resource owner/Resource Rights Administrator role). The RUFADAA use case is "life stage 4", if you will... It would be cool if we could get enough understanding/consensus on the call to be able to construct clean slide diagrams for all this (like we have for little Johnny and Alice now). Oh, and if anyone knows of any similar laws in other jurisdictions, that would be great too. ==== 3 Scenarios: 1) User (Alice) creates a disclosure permission plan (for future event of death or mental incapacity) 2) User (Alice) creates a Trust and makes an inter vivos (i.e. during Alice's lifetime) transfer of digital assets to the Trust for administration by Trustee (as, in effect, a successor User); Alice may or may not create a disclosure permission plan 3) User (Alice) does not create a disclosure permission plan for digital assets; fiduciaries create the disclosure permission plan after their appointment Scenario 1 User = Data Subject Custodian = Resource Server Operator Designated Recipient = AS Fiduciary = Resource Owner (or administrator) Scenario 2 User = Data Subject or Successor User (Trustee) = Resource Owner (or administrator) Designated Recipient = AS Custodian = Resource Server Operator Scenario 3 User (Fiduciary) = Resource Owner Designated Recipient = AS Custodian = Resource Server Operator Keep in mind that RUFADAA desines "User" as the person that creates the account with the Custodian *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Agenda for UMA telecon 2018-05-10
by Eve Maler 09 May '18

09 May '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-05-10 Date and Time - *Thursdays 9am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/857787301 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes - Approve minutes of UMA telecon 2018-03-01 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-03-01>, UMA telecon 2018-03-29 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-03-29>, UMA telecon 2018-04-12 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-04-12> - Business model and use cases - RUFADAA <http://www.uniformlaws.org/shared/docs/Fiduciary%20Access%20to%20Digital%20…> scenarios from Tim R ("life stage 4") - UMA and Open Banking - Analyze relevance of UMA for "decoupled" use cases - Other news and updates - Implementation news - AOB - *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Apologies, but cancelling one more UMA WG call this week
by Eve Maler 02 May '18

02 May '18

With my travel, it's just been too crazy to press ahead on the new business model use cases. However, next week is a lock for our next meeting. At RSA, I had many conversations with people about the "child-to-parent" and "disability/death" use cases, which enabled me to see these as a single big arc of several related life stages. Together they make a great basis for a POC -- and second report? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

Upcoming WG meeting schedule
by Eve Maler 13 Apr '18

13 Apr '18

Because of conferences and vacation, I've deleted some WG meetings from the April/May calendar. So our schedule currently looks like this (here's the calendar <https://kantarainitiative.org/confluence/display/uma/Calendar>): - Thu Apr 19: no meeting - Thu Apr 26: no meeting - Thu May 3: *meeting <-- note, we have a break coming up* - Thu May 10: *meeting* - Thu May 17: no meeting - Thu May 24: no meeting - Thu May 31: *meeting* Our current main focus is sanding off the edges of the business model and collecting use cases using it; I also expect some extension proposals to come in. I'd like to assemble a catalogue of use cases and figure out the right way to publish it by the end of May. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2018-04-12
by Eve Maler 12 Apr '18

12 Apr '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-04-12 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2018-03-01, UMA telecon <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-03-01> 2018-03-29 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-03-29>: Deferred. IIW report It had a big turnout, ~260 registered and ~240 at the peak of attendance. A blockchain 101 was offered and not needed, so that was different from a couple of years ago. There was somewhat more focus from that perspective. Lots and lots of blockchain identity people attended. Mike's blog post after the fact on "SSO vs. SSI" <https://www.gluu.org/blog/sso-v-ssi/> (on a subject on which he also convened a session) reflected on some of the hot topics that got discussed on Twitter afterwards. (The diagrams in this tweet are also good.) Mike is plumbing (and Adrian has done in HIE of One) some use cases around pushed claim tokens that are in the form of decentralized IDs (DIDs). The moment that anyone is using cloud Agents, we have privacy problems back again that SSI is supposed to solve. Shame that conversations these deep didn't happen there. Justin held a session called "What do you hate about OAuth?" A similar session perhaps could usefully could have been held! [image: (smile)] A lot of the work in security is preventing a MITM, which is where TLS comes in. In any case, this WG can be complementary in many ways with such technology, and doesn't have to have any kind of official stance on SSI's architecture or marketing. Legal formal model Eve did a session at IIW on the draft model <https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS…>, which is now being revised. The formal business model is designed to enable: - The auditing of technical artifacts (such as tokens) in a privacy-sensitive way during a run of the protocol to be able to prove the claimed consent/permission/delegation/licensing happened - How the artifacts can link out to the relevant legal devices (contracts and licenses) - Determining patterns of which artifacts need to be dissolved (e.g., tokens to revoke) and then remade (issued) to serve various complex business use cases Cigdem has a use case where you have a flood network of devices. A household has these devices deployed. Data generated by the devices may involve personal data. Predictions made from this data might also involve personal data, but where it's derived or inferred, it's not "owned" by the data subject but rather an enterprise admin due to the way GDPR works (so this would be a Legal Person as Resource Rights Administrator – our new candidate name – and thus the resource owner). Does derived data include algorithms performed over data? Mark believes so. In the case of OPAL (Thomas's Open Algorithms work) and where the ro uses UMA to ask specifically for an algorithm to be performed over data she does own (so the rs has the algorithm and the c has the original data and retains rights in the data as it is transformed), we'd want the relevant legal devices to ensure that the RSO retains rights in the algorithm IP (OPAL talks about making these algorithms open source/openly inspectable), and the DS retains rights in their data and the resulting transformed data (even though GDPR seems not to require this). There's work going on to see if cancer patients could be paid every time their data is used for research. The Revised Uniform Fiduciary Access to Digital Assets (RUFADA <http://www.uniformlaws.org/shared/docs/Fiduciary%20Access%20to%20Digital%20…>) Act defines requirements for what we think of as "digital death"; it mandates an "online tool" (Authorization Server/Operator?) that enables the ability for a "user" (Data Subject?) to choose a "designated recipient" (Resource Rights Administrator?) for administering access to their digital assets held by a "custodian" (Resource Server Operator?) when they die; that recipient might (RRA again?) or might not (Requesting Party?) be the same as their "personal representative" (or executor or whatever). Tim is writing up the use case and Eve will put it into visual terms. All are invited to submit business use cases that we can publish as a catalogue. Mark mentioned that he's spoken to the FB privacy team about the digital death challenge; he'll make intros with Eve. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Eve 3. Mike 4. Cigdem Non-voting participants: - Justin - Colin - Scott - Mark - George - Bjorn - Thomas Regrets: - Tim - Andi *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Agenda for UMA telecon 2018-04-12
by Eve Maler 11 Apr '18

11 Apr '18

Lots happened at IIW 26, so we'll be reviewing that and deepening the formal model work. Let me know if you want to bring up extensions or other items as well. https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-04-12 Date and Time - *Thursdays 9am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/857787301 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes - Approve minutes of UMA telecon 2018-03-01 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-03-01>, UMA telecon 2018-03-29 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-03-29> - IIW report - Legal formal model - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2018-03-29
by Eve Maler 29 Mar '18

29 Mar '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-03-29 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2018-03-01 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-03-01>: Deferred. Legal formal model The "UMA Legal role definitions" slide deck is here <https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS…>. Eve will give access to any UMA WG participant. Discussion about the parties, especially the agents: Are we factoring in the question of the sources of identity? UMA at the technical layer is agnostic as to the source: local, federated, whatever. It could be self-sovereign, as HIE of One does. But what about the quality of the identity? Shouldn't that be a matter for the business layer? Yes; each deployment should be able to build on our "meta-layer" to specify its requirements in order to manage liability. The Origo implementation uses identity assurance in exactly this manner. So could an organization be the Data Subject Agent for an individual Data Subject? In the NZ case, that's how the "headless user" worked. In fact, if a human administrator for the government agency creates the account and policy for elderly citizen Aroha, then they could be an Agent for the Data Subject Agent, but presumably at some point that's out of the view of the original Data Subject. Can the government be an RSO? In the Origo case, they are one of them. Additional scenarios: 1. ASO acts as an RSO and runs all rs == OAuth-ish 2. ASO acts as a CO and runs all c == no 3rd party client ecosystem 3. DS/DSA is an I, AAA ASO, and as dedicated to that single ro (“personal as”) 4. (Could add many others here to account for federated identity) In the chat: - in the real world today, at which point does Mom/Dad become a Data Subject Agent to child? Is it at the point where they exit the hospital or registers the baby? - Is EquiFax my Data-Subject-Agent? - So the NZ Gov becomes the RO, ASO, Data-Subject0-Agent - This almost means that there will never be Data-Subject-Agent because all the current holders of my data will say they are the RO. - @Tim: would it be useful to try map the UMA Legal entities with the Uniform Fiduciary Access entities? They call RO as "Person". Person" means an individual, estate, business or nonprofit entity, public corporation, government or governmental subdivision, agency, instrumentality, or other legal entity... - @Adrian: you can always extract potions of the UMA legal whitepaper for your use-case. - What law have some states passed? States as in EU, UK or as in U.S. States? - The RUFADA law IIW session ideas Thomas plans to convene a session on his decentralized OAuth I-D. This also relates to the topic above, which perhaps deserves a dedicated session. Upcoming schedule The Friday legal meeting schedule is on hold for now. We won't meet on Thu Apr 5 because of IIW, nor Thu Apr 19 because of RSA. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Sal 3. Eve 4. Mike Non-voting participants: - Thomas - Justin - Tim - Adrian Regrets: - Maciej Guests: - Brad Arlen (CEO of OneMe, privacy-as-a-service startup) - James Willett (of OneMe) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0