Peer DIDs: a secure and scalable method for DIDs that’s entirely off-ledger – Daniel Hardman

Peer DIDs
a secure and scalable method for DIDs that's entirely off-ledger
Daniel Hardman, November 2019
ssimeetup.org · CC BY-SA 4.0 International

1. Empower global SSI communities
2. Open to everyone interested in SSI
3. All content is shared with CC BY SA
SSIMeetup.org
Alex Preukschat @SSIMeetup @AlexPreukschat
Coordinating Node SSIMeetup.org
https://creativecommons.org/licenses/by-sa/4.0/
SSIMeetup objectives

Most DID methods
Acme
public DID: A.did@Any
pairwise DID: A.did@A:B
Bob
pairwise DID: B.did@B:A
shared source of truth (e.g., blockchain)
register, update
register, update
resolve A.did@Any, A.did@A:B
resolve B.did@B:A
resolve *.did@*
Everybody in the world
can resolve the pairwise
DIDs that only Acme and
Bob care about
(A.did@A:B and B.did@B:A).
Scale, cost, security,
privacy, performance,
regulation issues.
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International

Peer DIDs
Acme
pairwise DID: A.did@A:B
Bob
pairwise DID: B.did@A:B
B.diddoc@A:B
(from Bob)
A.diddoc@A:B
(from Acme)
resolve A.did@A:B
register, update
resolve B.did@B:A
register, update

Why?
Scale 99% of DIDs off ledger
Cost No transaction fees, no operating expense, no electrical bill
Security No ledger or node to hack, no common pipes to monitor
Privacy Only Acme and Bob know what only Acme and Bob care about
Performance Throughput automatically, perfectly matches number of parties
Regulation No ledger or node operator as GDPR data controller

How to create a peer DID
Make a DID Doc with whatever keys you like, but omit the actual DID value from
the doc. This is called the stored variant of the doc.
Compute sha256 hash of stored variant. This is called the numeric basis.
Encode the numeric basis and append the encoded data to the prefix,
did:peer:

Minimal doc
{
"publicKeys": [
{
"crv": "P-256",
"kty": "EC",
"x": "Gv6c_u05ogFn4HpZHxBS94CdGL8gIv0W307OHjpTSqM ",
"y": "Qjg7xEIAAfKvSaV2bZ8LP14fcD33YTkDTIwZ7KKXLMg ",
"kid": "1"
}
]
"authorization": {
"profiles": [ {"key": "#1", "roles": ["solo"]} ],
"rules": [
{
"grant": ["register", "authcrypt", "se_admin", "plaintext",
"oblige"],
"when": { "roles": "solo" }
}
]
}
}
Define a key (JWK format)
Map key to a privilege profile, “solo”
Tell what the “solo” profile can do.
This key lacks the privilege to administer keys or rules, so most evolution is
impossible. Suitable for very simple, ephemeral interaction.

How to share a peer DID
Option 1 (recommended): implement Aries RFC 0023 (DID Exchange Protocol)
● Defined conventions with multiple impls.
● Works with any transport: http(s), Bluetooth, NFC, email, message queue, QR codes, IPC, paper, files,
sockets, third party introduction, sneakernet…
● Strong mutual auth done the same way for both parties.
● Security and privacy guarantees are excellent.
● Allows one side to use peer DID and other side to use something else.
Option 2 (suboptimal): transmit DID + signed DID Doc over TLS session
● Easy as can be. But…
● No protocol defined (which API calls? which HTTP headers? who does what in which order?) -- proprietary.
● Not transport-agnostic.
● Security and privacy are suspect (SSL visibility appliances).

Layers of Support
Coding Time to Implement
DIDComm + 1 week (sync
docs, validate changes)
2-6 hours (generate and
store DID docs)
10 min (regex)

Status
Spec now on revision 6 or 7; about 9 months old
A few open issues
Likely to change in one important way (key formats) soon, but not much else
One ref impl of layers 1 and 2 in python (no dependencies); Aries Go Framework;
pending impls in Rust in Aries/Indy

How to update a peer DID’s DID Doc (simplified)
Generate a delta. This is a JSON fragment that tells what changed.
Compute the sha256 hash of the delta.
Attach the base64-ed deltas to sync_state DIDComm messages. Gossip these
messages with other parties to spread knowledge of state in all directions.
Apply new deltas.

Alice
A.1
A.2
A.3
A.4
Bob
B.3
B.4B.2
B.1
arrows point to an agent/key that might be reached and updated by the proactive agent/key on the other side
decentralized, ad hoc
(Messy but flexible. Handles edge-to-edge
and semi-connected. Relaxed management.)

Alice
A.1
A.2
A.3
A.4
Bob
B.3
B.4B.2
B.1
each side centralized
(Clean, but requires cloud connectivity and can’t
handle edge-to-edge.)

Alice
A.1
Bob
B.3
B.4B.2
B.1
domain of 1
(Clean, but requires cloud connectivity and can’t
handle edge-to-edge.)

Acme
A.3
hybrid
(Some centralization, some decentralization)
Bot Swarm

Authorization
Need ability to setup protective policies to handle cases like “My phone was
stolen; how do I keep the thief from taking over my DID?”
“authorization”: {
"profiles": [
{"key": "#Mv6gmMNa", "roles", ["edge"]}, {"key": "#Np4fAwXs", "roles", ["edge"]},
{"key": "#H3C2AVvL", "roles", ["offline"]}
], “rules”: [
{“grant”: ["authcrypt"], "when": {"roles": "edge"}, "id": "98c2c9cc"},
{“grant”: ["key-admin”], "when": {
“any”: [
{“roles”: “edge”, “n”: 2},
{“all”: [{“roles”: “edge”}, {“role”: “offline”}]}
],
"id": "47b3a6af"},
]
}
the key for the stolen phone
the protective rule
let a key in this DID doc add or remove keys only if...
any (either) of these conditions holds:
two edge keys agree, OR
an edge key AND an offline key agree

Privilege Model
register: can use DID to create Alice:peer connection (only in genesis state)
route: can handle forward messages intended for Alice (internal mediator)
authcrypt: can speak on encrypted channels on Alice’s behalf
plaintext: can see data intended only for Alice
oblige: can incur contractual obligations for Alice (e.g., terms of service, consent)
key_admin: can remove keys or add them, plus assign them profiles
se_admin: can remove or add service endpoints
rule_admin: can remove or add rules (map profiles to privileges)
These privileges resemble but are not identical to the use field
in JWK. The use field is less granular (only sig and enc are
defined), and its scope is one key. The scope of a privilege in
peer DIDs may be multiple keys acting as a unit.

Registration (sharing DID with peer)
Exactly 1 key must have the register privilege in the genesis version of the peer
DID doc, and this key must be the one to share the DID with the peer.
Signing a DID doc is not enough to register it properly; what gets authcrypted or
signed by the key with the register privilege must include enough context to bind
the relationship (e.g., the other peer’s DID or a nonce from the other party’s
connection_request).
Peer DIDs can’t be registered after genesis state unless existing peers consent
(upgrade to n-wise). This means an evolved peer DID can’t be registered
elsewhere.

CRDTs
Most items in the DID doc have an id property.
All changes are modeled as a combination of adds and deletes--there are no
modifies. This guarantees idempotence and eliminates most ordering problems,
since a given id never has more than one version of itself.

Consensus (coordination), centralization, or forks: pick 1
Consensus
what algorithm tolerates participants with different duties, different connectivity,
different motivery different connectivity, participants with radically different
sophistication,
Are forks really that bad?

Consensus (coordination), centralization, or forks: pick 1
Consensus
What algorithm tolerates participants with different duties, different connectivity,
different motives?
Centralization
Great for any party that picks it, but Alice can’t require Bob to centralize for her own
convenience.
Forks
Yuck. But wait… are they really that bad?

Forked Reality
A-land B-topia
B.1
B.2
A.2
A.1
A.3

Mental Model
● Keys and authorization rules enforce privileges.
● The sync protocol makes data flow.
● These are NOT the same thing.

Pending Deltas
Suppose Agent 1 gossips a change to Agent 2, the change requires 2 signatures,
but only 1 is affixed.
Agent 2 can:
● Authorize it by attaching a signature and re-gossiping the doubly authorized delta (if it
deems the change desirable)
● Hold the delta in pending status, if it can’t authorize (hasn’t taken effect yet, but we
know it’s been proposed)
Pending status means the CRDT/replication/gossip logic never applies a change unless/until it is
legitimate. Once a change is legitimate, there no denying it happened, and all agents who see it must
accept it. Thus, no merge conflicts, and remaining ordering constraints vanish. Contradictory forks
can still happen, but they represent historic divergences in how knowledge propagated; once both are
seen, both are applied, even if they cancel.

The ~state decorator
Included with all DIDComm messages to check synchronization. Triggers gossip if
any discrepancy detected.

Why No Merge Conflicts
● Idempotent
● Every item has a unique id that never repeats
● All operations are adds and deletes, never modifies (1 version of each item)
● Pending status
● Forks accurately represent divergent knowledge; reconciling just means
accepting both

More Info
http://j.mp/peer-dids-group
https://openssi.github.io/peer-did-method-spec
github issues at https://github.com/openssi/peer-did-method-spec
https://github.com/evernym/pypeerdid (ref impl of layers 1 and 2)

Peer DIDs
http://j.mp/2pmxrDc
(see also http://j.mp/peer-did-layer2) Nov 2019

Peer DIDs: a secure and scalable method for DIDs that’s entirely off-ledger – Daniel Hardman

More Related Content

What's hot (20)

Similar to Peer DIDs: a secure and scalable method for DIDs that’s entirely off-ledger – Daniel Hardman (20)

More from SSIMeetup (20)

Recently uploaded (20)

Peer DIDs: a secure and scalable method for DIDs that’s entirely off-ledger – Daniel Hardman