Thread by @ChristopherA

The countdown to #RWOT9 in Prague continues, and my review of some more of our advance reading and topic papers that were submitted to help inform the community about our mutual interests and the "weak signals" of the edges of decentralized identity tech to collaborate on…

TITLE Gently introducing DIDs to the Mastodon/ActivityPub Fediverse KEY CONCEPT Many in this community are joining us at #RWOT9 & this paper discusses how to transition their existing DNS-based actorIDs to use DIDs to allow portability between servers github.com/WebOfTrustInfo…

…"long term stability of a federated service crucially depends on persistent trust relations across all participants (developers, admins, users) that are not distorted by the implicit hierarchical structure of a centralized reference system, such as DNS."

…The original proposal for how the Fediverse might use DIDs was proposed back at #RWOT5 github.com/WebOfTrustInfo…

…"it left us wondering how to turn this into reality - how to change the base reference system of a large federated network, e.g. within the current mastodon fediverse?"

…The Mastodon/ActivityPub/Fediverse community existed before #RWOT, but has aligned interests in decentralization. They are piggybacking their own event after #RWOT9 to collaborate and engage with us. I'm glad they will joining us to learn about DIDs & for us to learn from them.

TOPIC The Current Status of the DID Specification KEY CONCEPT "a summary of the current state of work on the specification. It includes a rough categorization…with the goal of identifying actions which can be taken quickly" github.com/WebOfTrustInfo…

…"Major areas of ongoing discussion & work…1) Cleaning up introduction(s), overview, and similar…2) Matrix parameters - which should be included in the DID URI and which belong elsewhere 3) 'clarify'…relationship with key management operations, definition of "proof purpose"…

…"…representing services, making sure normative statements are testable 4) 'discuss' definition of DID controller, id for service and publicKey, What do/can/should DIDs identify?, Method-specific DID params, Empty method-specific-id, Key revocation: #96"

…The DID specification was incubated at #RWOT, but is now moving along the W3C track toward international standard. I'm pleased that #RWOT can serve as a F2F coordination point for further discussions/clarifications.

TOPIC Rubrics for Decentralization of DID Methods Creative Brief KEY CONCEPT This paper is a "creative brief" for how we might create a rubric for evaluating and comparing the decentralization qualities of real or potential DID Methods. github.com/WebOfTrustInfo…

…"Objectives: Present a set of rubrics for evaluating the decentralized character of any given DID Method. Explain how these rubrics help evaluate DID methods. Be concise and accessible."

…"Goals: Help standards collaborators make better decisions about what DIDs should enable and how they might do so. Help DID Method creators evaluate the trade offs in decentralizing their DID method. Help DID Method users to evaluate potential DID Methods"

…Non-goals: This rubrics document explicitly is NOT about defining "a top-level metric for evaluating DID methods. No single metric can encapsulate all engineering trade offs. We reject singular metrics as oversimplified."

…NOT "a framework for certification, self- or otherwise. The intent is to enable a subjective, qualitative evaluation, not a rigorous, hard standard with specific measurable characteristics. Document readers will interpret the rubrics against their specific use cases."

…"It will not be exhaustive.…It will not directly provide guidance on DIDs or decentralization.…It will not provide direct guidance on what DID Methods should or should not be published in any particular registry."

…Call to action: we want people to "collaborate and communicate better about how DIDs and DID methods support decentralization." "Avoid rabbit holes of decentralization in collaborative conversations. Instead, focus on the rubrics that most affect your desired outcomes."

…The topic of "what is decentralized" or "decentralized enough" has become a divisive topic in our community, especially as (IMHO) there can be no perfect decentralization (some forms of decentralization break others). I look forward to seeing the final rubric document evolve.

TOPIC Zion Key Management APIs and Social Key Recovery
KEY CONCEPT The new Exodus cell phone from HTC offers an SDK/API for developers to leverage its TrustZone secure hardware for key management. This paper gives an overview of that architecture. github.com/WebOfTrustInfo…

…"The goal of HTC Exodus is to let you keep data—and blockchain currencies—private and secure on the device rather than in the cloud. And to maximize the capability of that, we believe open to the community is important. Therefore, we create the SDK sets for Zion Key Management"

…"ZKMA…is a service which provides a way for developers to manage seed security built into HTC Exodus devices, which integrates Zion protection. All secure operations (input pin, display seed, sign transaction…) will be performed by the trusted OS and no secure data exposed"

…"ZionVaultSDK…provides two major functions: Get crypto currency account address from Zion Vault. Request Zion Vault to sign a transaction…two approaches…Web base integration…Application base integration"

…"Zion Social Key Recovery SDK…is an Android library that provides Java APIs for developers to integrate HTC Zion Vault's Social Key Recovery (SKR) feature into their apps. 3rd party apps integrating Zion-SKR-SDK will be able to use SKR to backup or restore their…(HD Keys)"

…Almost all of the current POCs and pilots for DIDs implement key management in the user space of their device, rather than the best practice of using hardware. I'm pleased to see some discussion about good APIs for communicating with secure cell phone hardware.

TOPIC Mandates and Delegation KEY CONCEPT The Dutch government has a defined a concept of "mandate" and "delegation" that is potentially relevant to DIDs and Verifiable Credentials. This paper proposes the creation of specifications for mandates.
github.com/WebOfTrustInfo…

…Under Dutch law a "mandate means: the authority to take decisions in the name of an administrative body", and "A decision taken by the mandatee within the limits of his authority counts as a decision of the mandator"

…"Delegation is understood to mean: the transfer by a governmental body of its power to take decisions to another person who exercises this responsibility under his own responsibility"

…"There are very many different ways in which mandates can be created, used, updated, disputed end deleted/revoked." …

…"Guardianship is in order when someone is incapable of taking sufficient care for him/herself. Examples include small children, and people with certain mental and/or physical disabilities.…"

…"…Under such conditions, a judge may be asked to install guardianship, which, if awarded, results in a set of obligations and the appointment of a natural person or a legal person (called the 'guardian') that will be held accountable for their realization."

…There is a lot of subtlety in these distinctions around guardianship, stewardship, delegation & mandates that I don't quite understand. It is clear that as a community if we want to support this in a self-sovereign architecture that we need further dialogue—this is a beginning.

Another 5 advance reading topic papers reviews completed, about ~25 remaining to cover in the next 5 days. I hope that these summaries are useful to you, even if you are not coming to #RWOT9 in Prague next week.