*Attending:* Steve, Andrew H, Ann, Adrian, Jim, Eve, Mark, Dazza *Agenda:* - Interest in a bit longer session this and/or next week? - Review of the list of draft deliverables to be produced - Review of Jim's candidate text and structures - Status of our budget proposal - How to take our work forward? - AOB *Proposed shape of draft deliverables:* - Model clauses for the various UMA role functions, both at a granular level and in the context of some templated agreements (think up-front "terms of service" in many cases) - Supported by all the necessary term definitions - As a sub-use case of this, templated "consent receipts" for a variety of cases when the party expecting some other party to function in an UMA role is themselves in an UMA Authorizing Party or UMA Requesting Party role - For example, instances where the Authorizing Party has created a policy for delating a right of access to a Requesting Party (there are others...) *Some technical considerations:* - A round-trip CmA format<->JSON mapping - A lightweight mechanism for technical integrity, so that the web location where an entire agreement gets saved off to contains within its URL a hash of the agreement itself *Notes:* *Logistics:* 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. *Draft deliverables:* 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 <http://www.privacylens.org> 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. *Technical considerations:* 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 <http://www.commonaccord.org/index.php?action=edit&file=/GHx/KantaraInitiative/Deep/Test_v0.md>", 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 <http://www.commonaccord.org/index.php?action=doc&file=GHx/KantaraInitiative/UMA/2013/2.md> ". 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 <https://github.com/mitreid-connect/trust-framework/blob/master/TrustFramework.md#28-order-of-precedence> and CmA <http://www.commonaccord.org/index.php?action=doc&file=GH/FutureCommerce/StandardLaw/IDFederation/Form/Doc_v0.md>). 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. *Our budget proposal, the legal subgroup, and 2016* 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. *Actions for next week* *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. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl