...
Attending: Eve, Scott, Adrian, Jeff S, Jeffrey R, John, Kathleen, Jim
The 50K-foot view: We are tardy on our original model definitions and clauses schedule, but our "primer" deliverable is intended (ultimately) to drive clarity and force around the model text deliverable.
Do we want to enlarge our scope to encompass "enterprise UMA"/federated authorization use cases? Maybe we give it a nod, but don't address it fully. We may want a separate, similar paper on the "Legal Person" opportunities.
Our history with BLT in the primer: It didn't survive our analysis of doc structure. Scott's history with the invention of BLT: It was meant to be extractive: breakdown and then buildup. It might be the case that the duties within our obligations in the model clauses have "BLT metadata" somehow, if it's determined that this is useful, but they seem not to be a useful organizing principle in the doc.
In the intro, we want to get from a sharp Problem to a Solution and then to an enticing How we're going to help them solve it. UMA can help soft, fuzzy circumstances become harder and more measurable.
What scenario should we pick? Should it have "health" in it? We always debate this. Should we go with "smart home" and non-health, perhaps? Or "pure Google Apps-like"? We could tweak it to have smart home for a disabled person to allow them to live at home vs. other circumstances. That introduces an additional layer of regulations, however. The appeal of health is that the data is so intimate and sensitive. A baby monitor, or some other smart home devices, might have the same characteristics, though. IoT seems definitely popular.
Homework for next time: Please send your own ideal 1-2 paragraph scenario to the list so we can nail this down next week and power through the next section.
2016-07-22
Attending: Eve, John, Sal, Ann, Kathleen, Colin, Adrian, Jon, Scott (Maciej regrets)
We reviewed the primer and made changes dynamically.
We discussed whether "Alice and Bob" are appropriate as standard RO and RqP names, given their history as equal peers in PKI, vs. their asymmetrical nature in UMA. UMA's historical goal is to empower the RO role in an ecosystem fashion a la Eve's 2008 diagram from the Digital Contracts MIT event, even if instances of a running UMA protocol are indeed asymmetrical, since the RO has an "agent" – the AS – working on her behalf whereas the RqP doesn't. Of course, there's an admittedly asymmetrical part of the UMA protocol called trust elevation where the RqP may have to supply or direct services to supply information about themselves, which could be UMA-protected, so the RqP could have an "agent" acting on their behalf too. In short, while they're not peers at an "individual instance of the protocol" technical level, it's possible that they're similarly protected at the technical, contractual, and regulatory layers.
Self-regulatory structures are the common theme coming out of the list of "Additional Discussion Topics", which we spent a lot of time on. Some of those structures will be shaped by supply chain necessities – see, for example, how UPS and FedEx end up with similar contractual outputs. We think that once we have our "Tech/Contract/Reg" framework, we could spin out white papers on each of the additional discussion topics, and likely liaise more effectively with the IDoT, IRM, and BSC efforts in Kantara. (Be sure to see the notes so far from the BSC group.)
We reviewed the scenario in the Tech section. Scott asked: Do we want to draw the equivalence between the federated identity progress and federated authorization? Eve thinks this depends on whether we're writing for an audience that understands federated identity trust frameworks. Adrian goes by the "There's only one Alice" mantra – the AS shouldn't be "domain" (sector) specific. This is the personal AS viewpoint.
...