Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

222 views

Published on

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.

Published in: Internet
  • Be the first to comment

  • Be the first to like this

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

  1. 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. 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. 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
  4. 4. 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 SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
  5. 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. 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
  7. 7. SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
  8. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  23. 23. Forked Reality A-land B-topia B.1 B.2 A.2 A.1 A.3 SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
  24. 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. 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. 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. 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
  28. 28. 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) SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International
  29. 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
  30. 30. Peer DIDs http://j.mp/2pmxrDc (see also http://j.mp/peer-did-layer2) Nov 2019 SSIMeetup.orgssimeetup.org · CC BY-SA 4.0 International

×