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?