Verifiable Governance

Dmitri Zagidulin <dzagidulin@gmail.com>

Benedict Lau <benedict@eqtylab.io>��

The Goal: Verifiable Governance

1. What is "Governance"?
1. "Governance is the process of making and enforcing decisions within an organization or group."� (leaving enforcing out of scope for this discussion)�
2. What do we mean by "Verifiable"?
• We're interested in: Capturing the legitimacy of decisions - who made them, when, and how?��a.k.a. "Let's sign and authenticate everything - keep logs of decisions by authenticated actors"

Modeling Governance

We'll need:

1. Data Model for the process of making decisions�
1. Could be arbitrarily complex, but let's start with "a log of decisions performed by the group".�Would be useful to capture the sign off/approval of those decisions, especially.�
2. We need: �Topics/resources, Policies about topics, approval requests, approval results.�
2. Data Model for Actors (individuals / groups / organizations)
• We've mostly "solved" the problem of representing a single actor (a DID). What about a group?�
3. Data Model for a role an actor plays in the organization�
• Useful for the purposes of signing. �"The CEO has signed off on this decision." How do you represent the "the CEO" part?�
• Specifically, how does the CEO digitally sign as the role.�

Our Contribution (what's new)

1. A spec for modeling governance decisions�
1. Extensive use of self-authenticating identifiers (hash-based), internal and ex-.�
2. Decisions as a snapshot of the system in time (incl. group membership)�
2. A spec for using DIDs and VCs to model actor relationships�
• Use of in-progress Verifiable Conditions spec for threshold signatures (optional)�
• Additional VCs for Role Assignment and Group Membership

Definitions

• Individual: a DID document controlled by a single person
• Role: an organizational role assigned to one or more persons. (A set of capabilities).
• Group: a named or ephemeral collection of individuals and/or roles
• Organization: the ultimate controller of role assignments and group memberships

Describing Governance Decisions

• Subject
• Self-authenticating hash-based identifiers (CID or DID)�
• Review Request
• Review Plan applied to a particular Subject�
• Identified by a Review Request CID
• Review Plan with a set of criteria assigned to a DID for approval�
• Review Result
• A set of VCs signed by DIDs approving each Criterion of a Review Request

Assigning self-authenticating IDs to things/topics

We want to record decisions about topics.

How do we give stable identifiers to arbitrary topics and resources?

DIDs? � * Globally unique, stable(?).� * Overkill - most things/topics/resources don't need their own keys

URNs? � * Globally unique, opaque, stable. � * Would be great to have integrity protection, though.

CIDs� * 'Content-addressable IDentifier'. Popularized by IPFS, but we're using them here generically.� * Similar to: hashlinks (url + digest hash)� * Immutability / content integrity, deterministic

CIDs (Content-addressable IDentifiers)

General Pattern: URL with a text-encoded digest hash.

Examples

IPFS CIDv1:

urn:cid:bagb6qaq6ece3zdatzdcpnr3ztxtenr5aoo4xx5kf3imvhp3llysearrzxtxfe

VC DM 2.0 style (see section 5.4):

https://example.com?digestSRI=sha384-z53j8ryjVeX16Z/dby//ujydhdEP5KUcPMmSe7edMlGr7G9rmcA==

Multihash-based (draft-sporny-hashlink-07):

https://example.com?hl=bagb6qaq6ece3zdatzdcpnr3ztxtenr5aoo4xx5kf3imvhp3llysearrzxtxfe

RFC 6920 (Naming Things With Hashes):� ni:///sha-256-32;f4OxZQ

Describing Governance Decisions

• Subject
• Self-authenticating hash-based identifiers (CID or DID)�
• Review Request
• Review Plan applied to a particular Subject�
• Identified by a Review Request CID
• Review Plan with a set of criteria assigned to a DID for approval�
• Review Result
• A set of VCs signed by DIDs approving each Criterion of a Review Request

Governance Example: Github PR

• Subject: the code patch (proposed files)�
• Self-authenticating hash-based identifiers (CID or DID) (Git uses commit hashes)�
• Review Request: one or more criteria to accept a code patch�
• For actual PRs, this can be explicit (expressed by the Github UI) or implicit (cultural agreement, such as "all our PRs will be reviewed and signed by at least two engineers".)�In our usage, �
• We use the term Review Plan (as applied to the Subject) -- a set of criteria to be accepted�
• Assigned to reviewers (GH usernames / DIDs) for approval�
• Review Result
• A set of VCs, signed by assigned DIDs, approving each criterion of a Review Request

Capturing Governance Decisions

Review Result

​

​

Request Outcome�

Final outcome (signed by Org)

Review Request

Review Plan

​

A set of steps/criteria

​

Example criterion:�

"Proper attributions are included in the dataset"

Subject

​

​

Data (CID)�

or

�Person (DID)

Criterion Outcome

Criterion sign-off (signed by Individuals/Group)

Subject Example� (a collection of files identified by a root hash)

Review Plan Examples� (each plan can have a set of criteria)

Governance Result

Overall Verification� (every green link is a valid VC from a Trusted Issuer)

​

​

2. Data Model for Actors (individuals / groups / orgs)

Data Model: Group

What do we need to model a Group?

1. An identifier�
2. (optional) Keys the group controls�
3. A list of members�
4. (optional) Metadata (group name, address, etc etc)�
5. (optional) Signing policies (N of M, etc)

DIDs!

? VCs?

Data Model: Group

​

Prior Art:

• vCards (RFC 6350)
• Several ways of modeling a group (KIND='group' / MEMBER URNs)
• Groups not well supported by iOS/Android/Gmail/Outlook etc UI�
• Active Directory Groups (distribution or security)�
• AWS IAM Group and many other similar models

Data Model: Group Membership

For a given group DID, how to we model its list of members?��Options (either, or both):

1. Add the list of Members directly to the DID Doc�
1. Explicit: In a new 'members' field?�
2. Implicit: As keys in the assertionMethod list?�
2. Use a Service Endpoint to link to a VC representing Membership List

for our use case (signing as a group),�we'll focus on this

Example: DID Document with Member Keys

{� "@context": ["https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/ed25519-2020/v1"],�� "id": "did:web:coop.example",�� "assertionMethod": [� {

"id": "did:web:coop.example#z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",� "type": "Ed25519VerificationKey2020",� "controller": "did:web:coop.example",� "publicKeyMultibase": "z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"

},

"did:web:alice.example.com#z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpb",�� "did:key:z6MkpTHR8VNsBxY…#z6MkpTHR8VNsBxY…" � ]

}

The Group's own key (by value)

Alice's and Bob's keys �(by reference)

(Sidetrack) Typing a Group DID

History: DID Core v1 WG discussed at length whether DIDs should be typed by "person vs org". Intentionally left out any typing.

So how do we say "this DID is a group/org, with the following members?"�Several options, none of them perfect.

• Add a 'type' field to the various DID methods we're using�
• Use the @context list as type (if it has the group context, it's a group)�
• Do nothing (current state) - verifier determines DID's type Out Of Band

Optional: DID Doc with Membership Service Endpoint

{� "@context": ["https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/ed25519-2020/v1"],�� "id": "did:web:coop.example",�� "assertionMethod": [ … ],

"authentication": [ … ],�� "service": [{� "id": "did:web:coop.example#members",�� "type": "Group Membership Credential",�� "serviceEndpoint": "https://coop.example/members.vc.json?cid=..."� }]�}

VC containing List of Members

Summary: Story So Far

• Verifiable Governance: authenticated records of group decisions�
• Need: Data model for decisions
• Decisions about what? Need identifiers for topics/resources
• Can we model decision workflow?�
• Need: Group data model
• Identifiers: DIDs
• Membership (either, or both):
• List of member keys in "assertionMethod", "authentication", etc.
• Optional: Link to a VC containing membership, via service endpoint
• Optional: Out-of-band VC (signed by the group) indicating membership�
• Need: Signing as hierarchical actors
• Signing as Individual with a Role
• Signing as Group
• (Optional) Threshold Signature Method�
• Putting it all together

The Goal: Signing as Individual, Role, Group, Organization

Use Cases

1. Signing as an Organization�"The Org has signed off on this budget"�
2. Signing as an Individual with Role/Capabilities�"The CFO has signed this budget (using the personal DID)"�
3. Signing as an Individual on behalf of a Group�"A member has signed this resolution (using their personal DID) on behalf of the Student Council”

Signing as an Individual

Individual��did:example:123

​

DID Document

Authorizes�(for signing):���

key 1

Verifiable Credential��issuer: did:example:123

​

credentialSubject:

. . .

​

​

proof:

verificationMethod: key 1

�

Signing as an Organization

Organization��did:example:123

​

DID Document

Authorizes�(for signing):���

key 1

Verifiable Credential��issuer: did:example:123

​

credentialSubject:

. . .

​

​

proof:

verificationMethod: key 1

�

Who holds the Org signing key?

Signing by API (via custom app logic)

In practice, most corporate/org deployments use KMSs (hardware key mgmt systems).

Reasonable approach:

1. Hardware KMS generates and keeps the Org's private signing key(s).��(Corresponding public keys are put in the Org's DID doc)�(keys don't leave secure chip enclave)�
2. Write a backend app/service that has access to the KMS.�
3. When the app's custom logic is satisfied (boss logs in, etc), app tells KMS to sign as the Org.��(don't forget audit trail / governance layer, in the app)

Organization

(Org DID authorizes Group DID and issues Role VC)

Group

(Group DID with Individual DID authorized as member)

Role

(VC assigning a Role to an Individual DID)

Individual

(e.g. did:key)

Individual

(e.g. did:key)

​

member of

assigned to

authorized by

authorized by

Signing as an Individual with Role/Capabilities

Individual’s DID�did:key:456

​

DID Document

Authorizes�(for signing):���

key

Verifiable Credential��issuer: did:key:456

​

credentialSubject:

. . .

​

​

proof:

verificationMethod: key

�

Role's VC�Ties the Role to an Org��issuer: did:example:org�

credentialSubject:

id: did:key:456� role: "President"

​

validFrom: …

validUntil: …

Out-of-band VC

Signing as an Individual on behalf of a Group

Group DID�did:example:group1

​

DID Document

Authorizes�(for signing):���

member's key

Verifiable Credential��issuer: did:example:group1

​

credentialSubject:

. . .

​

​

proof:

verificationMethod: member's key

�

Member's DID�did:key:456

​

DID Document

Authorizes�(for signing):���

member of

key

Governance As Crypto Signatures

How far can we go using signature primitives?

To express consensus, a Group can sign using:�

• Multiple signatures (a proof set - an array of individual member sigs)�
• Threshold multi-sig (when N of M members sign)�
• Ring Signatures (anonymous multi-sig, bleeding edge)�
• Any of the above, composed via Boolean logic (see Verifiable Conditions)

Threshold Proof Basics (see Verifiable Conditions spec)

Org's DID: Sets the policy (e.g., 1 of 2 sigs from the following…)�{� id: "did:ex:1234",� assertionMethod: {� /* Verifier, if EITHER did:web:bob.example OR did:web:alice.example signs� a VC, that is acceptable to me as an Org issuer. */

}�}�VC proof: Executes the policy�{� issuer: "did:ex:1234",� credentialSubject: { … },� proof: { /* signed by did:web:bob.example */ }�}

Verifier: ��1. Checks signature, Fetch issuer DID Doc�2. Look in issuer DID's assertionMethod to see what sort of proofs are authorized�3. Encounter the EITHER/OR rule, see if VC's proof fulfils it

the Org's DID

VC issued BY the Org!

even though Bob signed the VC

Next Steps

1. Note on using DIDs for hierarchical actors
1. Propose as a Work Item to the CCG�
2. Data Model specs for Role and Group Member VCs�
3. Continue work on Verifiable Conditions spec

Questions?

(Sidetrack) Modeling a List of Members as a VC

Data modeling exercise:

a VC with multiple subjects? Or a VC with a single subject (the group) that has a list of members?

A: the latter.

credentialSubject:

id: <the group's DID>

hasMembers: [ � { id: “did:key:1”, name: "Alice" }, "did:key:2", …� ]

(Sidetrack) Organizational DID Identity Proofing

An Organization has a DID. For example:

did:ex:12345 - A DID that belongs to "Example, Inc."

But how do verifiers know that?

1. did:web - leveraging investments in org "brand"/website. did:web:example-inc.com (understood shortcomings/phishing etc)�
2. From context and trusted out-of-band channels/connections�(e.g. sign on a government building saying "Our DID is did:web:example.gov")�
3. Look up the DID in a list (e.g. Verifiable Issuers/Verifiers lists)�
4. Present a VC (from a trusted authority) asserting the identity proofing

(Sidetrack) Authorization: ACLs vs CAPs

Options for authorization/access control:

Access Control Lists (ACLs, RBAC, ABAC, …)�e.g. a bouncer with a clipboard, �or a "Will-Call" at a concert.��"If you're on the list, you can come in."�

Capabilities (OCaps, zCaps, UCANs, … )

e.g. movie tickets or plane tickets��"If you have a ticket (capability), you can come in."

ACLs

Capabilities

Authorization: ACLs && CAPs

In practice, you need both.

​

ACL -> Cap� "You're on the list (acl), so here's a ticket (cap)."

​

Cap -> ACL� "Oh, you have a ticket? Ok, I'll add you to the VIP list."

B.F.F.s

ACL

Cap

(Sidetrack) What about delegation via DID 'controller'?

DID Core v1 spec has an under-explored delegation method: � the 'controller' property.

From DID Core v1 section 5.1.2 - DID Controller:�

"Any [keys] contained in the [DID docs found in the 'controller' field] SHOULD be accepted as authoritative, such that proofs that satisfy those verification methods are to be considered equivalent to proofs provided by the [original] DID subject."

​

(Sidetrack) What about delegation via DID 'controller'?

​

For example, for did:ex:1234 with the following DID Doc:

{ � "@context": [ … ],� id: "did:ex:1234",� controller: "did:web:employer.example",� …�}

A VC signed by did:web:employer.example (the controller)

is considered "equivalent to" a VC signed by did:ex:1234 (the subject).

Somewhat confusing, but:��1. The delegation is one-way. (the controller "speaks for" the subject, but not reverse)

2. The 'controller' property is intended only for DID Document updates (key rotations etc), not for VCs.

the Subject

2. Signing as an Individual with a Role/Capabilities

Org’s DID document (authorizes the Role):�{� @context: [ … ],� id: "did:web:group.coop.example",� assertionMethod: [� { /* the group's own key */ },� /* keys of other members */,� "did:web:president.coop.example#key2"� ]�}

VC signed by the President's DID (on behalf of group):��{� @context: [ … ],�� issuer: "did:web:group.coop.example",� � credentialSubject: { … },�� proof: [{� verificationMethod: "did:web:president.coop.example#key2",� cryptosuite: "ecdsa-jcs",� proofPurpose: "assertionMethod",� proofValue: "...."� }, …]�}

President's DID document:�{� @context: [ … ],� id: "did:web:president.coop.example",�� assertionMethod: [� "did:key:...#key1"� {� id: "did:web:president.coop.example#key2",� type: "Multikey",� controller: "did:web:president.coop.example",� publicKeyMultibase: "..."� }, …]�}

Governance As Crypto Signatures

Multiple signatures on a VC (e.g. ProofSet or ProofChain)

• Standard, built into VC securing specs
• Bring-your-own business logic �(This VC was signed by 2 DIDs. What does that mean?)

Threshold Multi-sig (Shamir Secret Sharing, N of M) (in-progress drafts)

• DID sets proof policy, VC proof section fulfils it. �See:
• CCG Verifiable Conditions work item
• KERI - https://identity.foundation/keri/kids/kid0004.html
• Gordian Envelopes https://github.com/BlockchainCommons/Gordian