2019-08-06

Attending: Eve, Adrian, Cigdem, Domenico, Lisa, Nancy, Sal, Thomas, Vlad, Tim, Colin

Cigdem sent some thinking around the "multiple DS" cases:

Regarding multiple DS’es the table would look like this.
The Multiple DS case may not occur often, but is present in the case of a shared bank account between partners.
When a couple opens a bank account, they may start at State 5, when one of the couple goes under care, they transition to State 6,
When one of them dies, the end state is State 1 if the other partner is the sole beneficiary, or if there is another person, it may go back to State 5, or State 7 etc.

Not sure how to represent this technically – it seems to work for DS=2; not sure it extends to a larger number.
Do we have cases where DS is greater than 2. 

DS>1 | Rep>0 | Carer>0 | State
 F   |  F    |  F      | State 1: Self-management (Single DS)
 F   |  F    |  T      | State 2: Management under care (Single DS)
 F   |  T    |  F      | State 3: Co-management (Single DS)
 F   |  T    |  T      | State 4: Co-management under care (Single DS)
 T   |  F    |  F      | State 5: Self-management (Multiple DSes)
 T   |  F    |  T      | State 6: Some/All DSes under care (Multiple DSes)
 T   |  T    |  F      | State 7: Some/All DSes co-manage with Reps (Multiple DSes)
 T   |  T    |  T      | State 8: Some or all DSes under care and co-managed (Multiple DSes)

If we're in State 5, but I decide to co-manage my bank account with another party, what does my partner get to say about the situation given that they are a DS too? What if the two partners have different accountants; does the second partner get to/have to consent to the first partner's sharing with a chosen accountant? Divorced parents may have different custody rights and agendas – but this may fall under the single-DS case. Joint bank accounts and DNA data seem to fall under the "multiple-DS" case. What use cases are truly realistic around the RRA and sharing breakdowns beyond that? If there are whole state machine branches that are truly not realistic, let's not map them. Are trusts another example of potentially multi-DS and multi-RRA? It seems so. Trusts generally are for administering physical assets, but if they could be used for virtual assets as well, then what we're doing here could provide real added value.

The ASO/AS role provides value in terms of the actual permissions as they change. Right now we're focusing on the RRA/RO role changes, which are at the "head" of UMA-technical. Is there another service/party needed, something like a "relationship manager", to manage the state transition stuff? In identity management, there are some solutions that do things like this under the heading of identity lifecycle management, relationship management, and essentially "multi-identity lifecycle management".

Thinking out loud: Three siblings open a shared account, A, B, and C. They appoint an account manager, D, as an RRA. So each is in state 6. Brother B decides he wants to self-manage the account, so he may need to get permission from the others before transitioning to state 1. 

Sal and Mark at OpenConsent have been doing some work on policy states and state transitions; we will hope for a demonstration soon. We think it's complementary.

Some concrete scenarios: This PC Magazine article explains a) how to delete your Facebook account, and also b) how to request removal of accounts for someone who is medically incapacitated and c) how to get an account memorialized when someone dies. The latter two seem RUFADAA-like and have very close analogues in our Cradle to Grave use cases. For example, in use case (b), the party making the request has to prove they have the right to be the RRA (a Rep). In use case (c), the RRA role is self-asserted but they have to prove the DS has died.

Should we think of multiple state machines, one for every DS, and not maintain States 5-8 as formal constructs? Does the "relationship manager" center on resources first (e.g. the bank account) and then look up the relevant current DS(es) and RRA(s)? Relationships tend to be graph-like, without a single "head of the hierarchy" in reality, even if the RM isn't using graphDB technology to manage them.

There are two mechanisms of state transition (not reason, but mechanism) we might tend to see: either automatic or manual. Automatic means that you don't need consent or any other active participation by parties for the transition to occur. It times in (little Johnny grows up(, or a law now goes into effect, or a sensor reports a high enough temperature, or whatever. You might, however, need notification and other workflows. Manual is when parties do need to take action, such as consent or permission or setup (such as registration). Applications could need custom workflows in either case.

Next steps: Apply the three FB use cases and Nancy's healthcare use cases to UMA and our state machine and try to make them "work" visually and in writing.

We don't have a formal meeting next week. Cigdem will inform whether she can hold an ad hoc meeting at either our regular time or another time. We do have a meeting on Aug 20.