This page records the Discussion Group's meeting notes for September 2016. We meet Tuesdays for 30 minutes at 7:30am PT / 10:30am ET / 3:30pm UK / 4:30pm CET. We meet Thursdays for 30 minutes at 11am PT / 2pm ET / 7pm UK / 8pm CET. US times are normative during daylight saving time changes. We use Kantara Line A (US +1-805-309-2350, Skype +99051000000481, international options, web interface, more info, code 4022737) and http://join.me/findthomas for screen sharing. See the DG calendar for our full meeting schedule. Previous meeting minutes are here: July, August.
Tuesday, September 6
Agenda:
- Pick a time for an ad hoc report working session
- Work on use cases on the call (finally!)
Attending: ...
Thursday, September 1
Agenda:
- Working session on report text to capture sentiment around "central tension" (vs. cooperative "outlet") and action items for fleshing it out
- Could result in text in use case(s) and technology/technique description/analysis too
Attending: Eve, Thomas, Matisse, Jim, John W, Adrian, Scott D, Kathleen
We'd really like to delve into all the use cases being contributed. But it seems we need to deal with this elephant in the room; then we can make quicker progress on the use cases and the technologies/techniques!
How to address the tensions and mitigations in our deliverables? There's a kind of recursion we can see in how reliability of interactions is increased (Scott D's traffic lights example). Or is it commoditization? Race to the top? Standardization? All of the above? Almost any use case could do, he thinks, as long as they capture the same pattern. Merkel turtles!
Scott suggests that channel integrity be applied along with reliability here. Financial products are commoditized though intangible. A blockchain is a time machine. Jim adds: Each event is a record, linking to the prior state and to any code or prose needed to execute or understand.
John asks: Is model-view-controller an apt design pattern to apply here? Jim notes: parameters-prose-code seems awfully close.
Applying security and privacy, Kathleen adds the concept of dynamism. Capturing someone's consent requires capturing their parameters.
The forthcoming paper on computational sovereignty is about "Who do you put in the 'turtle' position?" (Turtles all the way down...)
Identity comes in because you need to test "halt, who goes there" and "state your business" (authentication and authorization) and your purpose of use. But then you're right back to the "poison of centralization"! PKI, DNS, third-party asserted identity, IdPs, cross-domain SSO, and all the rest. Unless you're doing "decentralization" in a single-domain sandbox, which is less interesting (discussed on Tuesday), or doing ZKP tricks that are (Eve's position) too technically tricky and expensive for users' desires, IAM today is a centralization play.
Can we call it the "drug of centralization" instead, to be more philosophically neutral? Yes. Or even the "siren song".
Who's interested to put together the awesome 1-2 page summary of this? Eve, Thomas, Kathleen, Scott D.
Scott D points to Cope's Rule in biology as gainsaying Eve's belief that decentralization as inherently unstable in most circumstances. Scott: Rule-making, operations, and enforcement can be separated so that not all need to be centralization. (Also see the network effect.) Eve's version says that "No committee ever recommends its own demise." 
This is why she hopes that we stick to our six-month plan!
Can we find a chair pro tem for next Thursday?