https://ssimeetup.org/peer-dids-secure-scalable-method-dids-off-ledger-daniel-hardman-webinar-42/
Daniel Hardman, Chief Architect, Evernym / Secretary, Technical Governance Board – Sovrin Foundation will show how Peer DIDs will allow off-chain transactions for the self-sovereign identity (SSI) world.
Most documentation about decentralized identifiers (DIDs) describes them as identifiers that are rooted in a public source of truth like a blockchain, a database, a distributed filesystem, or similar. This publicness lets arbitrary parties resolve the DIDs to an endpoint and keys. It is an important feature for many use cases. However, the vast majority of relationships between people, organizations, and things have simpler requirements. When Alice(Corp|Device) and Bob want to interact, there are exactly and only 2 parties in the world who should care: Alice and Bob. Instead of arbitrary parties needing to resolve their DIDs, only Alice and Bob do. Peer DIDs are perfect in these cases. In many ways, peer DIDs are to public, blockchain-based DIDs what Ethereum Plasma or state channels are to on-chain smart contracts— or what Bitcoin’s Lightning Network is to on-chain cryptopayments. They move interactions off-chain, but offer options to connect back to a chain-based ecosystem as needed. Peer DIDs create the conditions for people, organizations, and things to have full control of their end of the digital relationships they sustain.
Low Sexy Call Girls In Mohali 9053900678 🥵Have Save And Good Place 🥵
Peer DIDs: a secure and scalable method for DIDs that’s entirely off-ledger – Daniel Hardman
1. 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
2. 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
3. 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
5. 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
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
6. 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:
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
8. 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.
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
9. 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).
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
10. 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)
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
11. 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
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
12. 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.
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
13. 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.)
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
14. 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
each side centralized
(Clean, but requires cloud connectivity and can’t
handle edge-to-edge.)
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
15. Alice
A.1
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
domain of 1
(Clean, but requires cloud connectivity and can’t
handle edge-to-edge.)
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
16. Acme
A.3
arrows point to an agent/key that might be reached and updated by the proactive agent/key on the other side
hybrid
(Some centralization, some decentralization)
Bot Swarm
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
17. 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
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
18. 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.
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
19. 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.
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
20. 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.
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
21. 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?
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
22. 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?
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
24. Mental Model
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
● Keys and authorization rules enforce privileges.
● The sync protocol makes data flow.
● These are NOT the same thing.
25. 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.
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
26. The ~state decorator
Included with all DIDComm messages to check synchronization. Triggers gossip if
any discrepancy detected.
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
27. 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
SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
29. 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