Standing agenda for 2019: Work on producing our second legal-business framework report by September, initially focusing the work on use cases that illustrate each of our mappings from business relationships (and changes in those relationships) to UMA technical artifacts.
...
"Legal" topics are currently being covered in a separate legal-business framework meeting series. See the UMA calendar for details.
2019-08-06
Attending: Eve, Adrian, Cigdem, Domenico, Lisa, Nancy, Sal, Thomas, Vlad, Tim
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.
2019-07-30
Attending: Eve, Andi, Cigdem, Nancy, Vladimir Prihodko (works at Lush Group, has implemented UMA1 there), Domenico, Colin, Tim; regrets from Lisa
...
- Agreement that turns a service provider into an RSO (wasn't included in business model report)
- Agreement that turns a service (or app) provider into a CO (wasn't included in business model report)
- Agreement that enables a Person to act on behalf of a Data Subject [which puts them into position to act as a Resource Owner -- otherwise RO=DS]
- Agreement(s) that delegates authorization for an ASO to grant access permissions on behalf of an RO (typically Ts & Cs, privacy notice, EULA...)
- Agreement(s) that delegates authorization for an RSO to manage resources on behalf of an RO (typically Ts & Cs, privacy notice, EULA...)
- Agreement that enables a Person to act on behalf of a Requesting Party [which puts them into position to act as a Requesting Party Agent -- otherwise RqPA=RqP]
- Agreement that delegates access seeking to a CO on behalf of a Requesting Party
- Agreement that delegates permission to know and persist personal data to an ASO on behalf of a Requesting Party
Jim H has started on a CmA version of the model.
...
Arrgh, so close! Tim and Eve will try and wrap up all the remaining comments in the doc by Monday and get the e-ballot out.
2018-01-12
Attending: Eve, Colin, Tim
...