Attending: Steve, Andrew H, Ann, Adrian, Jim, Eve, Mark, Dazza

Andrew H can't stay long this week or next. Jim can stay 30min longer next week. Let's target that for next week. Mark and Adrian send regrets for next week.

Andrew asks: Would "terms of service" include human-role demands on service-role functions? This would be VRMish thinking. Yes. It's ultimately all-way. This is important in the work he's doing. 

Adrian points to the PrivacyLens work that displays what part of the service you would lose if you turn off consent as a good idea. Mark discusses the "notice requirement" as part of the workflow of notice-consent. Andrew (Jim?) notes that redlining standard model clause text through CmA could be one way of showing what wouldn't apply if the user doesn't agree. Eve would like to put this topic aside because it's orthogonal, even if a good idea.

We have a lot of choices (depending on budget futures) for what sorts of comfortable LX (lawyer experience) we want to give for editing model clauses and agreements. What CmA's interface is doing right now is just a simply coded Markdown+HTML editing environment. Does it want to be a Markdown environment? A Word-to-Markdown environment? An HTML form environment? We could also be creating official JSON and even XML mappings.

There's a question about whether we're supposed to also provide the actual UX for human ROs and RqPs. Eve is doubtful about our work being able to satisfy all the millions of needed presentations of the text for notice-consent workflows. Think web apps, mobile apps, IoT devices... But isn't this integrity problem -- that is, how to ensure that the text has been sourced from the approved place -- covered by the hash technique (used by Consent Receipts, we think)?

We seem to have consensus that providing an LX solution (or multiple ones, as we determine later) is sufficient, as long as its technical layer includes a textual integrity solution so that broader UX solutions can leverage it in their notice-consent workflows.

We started to look at "Test0", which has a few sample model clauses, and all the UMA definitions, embedded in an "access federation" agreement for all parties to which could be added all the larger (e.g. identity federation) agreement clauses and definitions. An older version that has all of the older binding obligations is "UMA/2013/2".

This direction is starting to look good; however, Andrew would like to see more of an if/then structure. Dazza suggests looking at MITRE's trust framework and its Order of Precedence (text and CmA). Andrew has a couple of government levels and then private-sector levels.

It wouldn't be a good idea to "force" anyone trying to use our legal stacks/templates use too much of our non-UMA elements, since only the UMA stuff is really de novo. There's a lot of history and cruft out there. But since the whole CmA approach doesn't have to disturb the model clauses when reusing them in multiple contexts, we can eventually show multiple exemplars for different use cases -- e.g., for an HIE of One use case, a corporate federated authorization use case, up-front terms of service use cases, and various consent receipt use cases. And pretty much every legal document defines terms, so having a terms section would be pretty normal in most circumstances.

We'll likely find out about our budget proposal in mid-January or so. The UMA WG would be responsible for oversight over spending that money, and this subgroup would be the specific natural place for it if we continue.

Eve will propose a 2016 subgroup mission statement and timeline for next week, and get everyone's sense on that call. Andrew and Mark are supportive so far.

AI: Jim and Eve: Revise the clause text, and create 2-3 exemplars leveraging the clauses, for consideration.

AI: Eve: Speak to additional legal eagles and ask for their especial participation next week.