UMA telecon 2018-05-10

Owned by Eve Maler
Last updated: May 10, 2018
4 min read

UMA telecon 2018-05-10

Date and Time

Agenda

  • Roll call
  • Approve minutes
  • Business model and use cases
    • RUFADAA 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

Minutes

Roll call

Quorum was reached.

Approve minutes

Approve minutes of UMA telecon 2018-03-01, UMA telecon 2018-03-29, UMA telecon 2018-04-12: Deferred.

Business model and use cases

  • RUFADAA 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/Default/

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 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