Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Attending: Eve, Ann, Scott D, John W, Mary

Eve's slides that show four "BLT use cases" are here. In UC3 (Alice oversees 12-year-old Susie's online usage), there are different kinds of harm that we're trying to protect against. Some are about inbound data sharing, some are outbound data sharing, some have other natures. Also, the diagram doesn't show that Susie is expected to be able to use her UMA client in turn as a downstream UMA RS. In some contexts/jurisdictions, there are rights that Susie would have that need to be protected as well. The "age of majority" subtleties hinge on various ages, and it can be a combination of a legal and a contractual status. We've imagined that it would be a technical status (PAT revocation) that would reify the status change that would allow "timing in" of legal capacity.

Though the primer probably wouldn't go here, and our UC diagrams are static, we could theoretically write UMA profiles that specify "state changes" such as PAT revocations and such that are legal capacity-dependent, perhaps in some complex workflow relationship with the type of the digital resource being protected. This could even enable "smart regulation". The Past Is a Foreign Country – can we overcome our biases about how we've done things previously? We suspect that this challenge is actually operational, rather than heavily theoretical. Once an AS knows the age of a resource owner, and an RS can share well-known semantics about a resource set type with the AS, then policy conditions can connect the dots about jurisdictional constraints on sharing information about, say, pregnancy test results once the resource owner is "of age".

Thinking modestly once again (smile), we do have to prepare for the technical layer to fail gracefully in a privacy-protective fashion as the other layers vary.

The technical layer (modulo our question about a client turning around and becoming a downstream RS?) stays the same no matter what happens at the other layers around it. The legal capacity picture around it is really interesting:

  • When you're young, you time-in to legal capacity
  • When you're old, you time-out of it
  • At some times in life, you might intermittently go into and out of it
    • Drunk or otherwise impaired (meds/drugs, distracted, tired)
    • Coerced (gun to your head)
    • Dementia but functioning
    • In Ontario law, there is a notion of "assumed implied consent" that lets someone take over for you if you're bleeding out on the ER table – a kind of break-glass right

How can we model this? Is it all down to revocation of the PAT? UMA doesn't have a notion of multiple resource owners, which presents a bit of a challenge.

John shared this blog post about privacy and fitness devices.

We had been thinking in terms of Ts & Cs that are relatively static for the (mostly) pairwise relationships between parties. Where could "smart contracts" introduce dynamism/configurability? The obvious place this had come in was in trust elevation, which is a Grantor/Grantee relationship. Where else could it apply? See our "trust relationship" discussions in the April notes (start here and work back).

Counterintuitively, injecting more democracy into previous feudal systems has the effect of creating more dynamic stability. That's what we're talking about here. (Not to put too fine a point on it. (smile) )

AI: Scott D: Take Eve's slides containing four use cases and translate the technical stability into a persuadable view of stability and value in other regimes.

2016-09-09

Attending: Eve, Ann, Kathleen, John W, Adrian, Scott D

We discussed Eve's new slide describing "key benefits to users" at a high level as a potential way of fleshing out the next subsection of the primer.

  • Not just opt-in or opt-out when asked
    • Sharing, unsharing, and editing of sharing preferences allowed at any time, without external influence
  • Possible to offer a service that centralizes sharing preference management across data services for user convenience
    • The central service doesn’t see any of the data
    • It acts on the user’s policy instructions when others attempt access to data services
  • The user can choose to share whatever “grain” of access each data service offers
    • Such as read vs. write, or weight vs. fat mass

We've now added and wordsmithed this.

Instead of the spiral or the simplified spiral in the primer, John suggests a very friendly version of the "three phases" paradigm (as suggested by Adrian) that's already explained in the spec. He will sketch what's he's thinking of, and we'll ask Domenico to turn it into something beautiful!

...