A DID (Decentralized Identifier) for Everything: Unified DIDs for Anything Decentralized dDID (derived-DID)
DADI (Decentralized Autonomic Data item) alock:hainssir:kfcli’:\l:.:i!th Ph.zDa‘w/m/zgr;o
hpsginmcommisemoe Papes 0 HHub & ifuon @®ProSapien sovrin consensvs
Early 2015 wanted to build credible portable decentralized reputation systems with data and algorithm provenance.
Needed decentralized identity (2016+) https:jgithub.com/SmithsamuelM/Papers/blobjmaster/whitepapers/identity-System-Essentials.pdf
Which led to decentralized identifiers (DID) (W3C) (2016+)
Combined with zero-trust computing (2017+)
Which led to decentralized autonomic data (DAD) (2018) https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/DecentralizedAutonomicData.pdf (RWOT6) Which results in data flow chaining for data and algorithm provenance (2018)
https:/fgithub.com/SmithSamuelM/Papers/blobjmaster/whitepapers/A_DID_for_everything.pdf (RWOT7)
Decentralized Distributed Data Streaming Applications Decentralized = controlled by multiple entities
Distributed = spread across multiple compute nodes
Maintain provenance (chain-of-custody) for distributed data under decentralized control undergoing various processing stages that follows perimeter-less diffuse trust (zero-trust) security principles.
DID = UNIFIED IDENTIFIER: 1 UUID: Universally Unique Identifier RFC 4122: UUID type1-5 ‘9866eb78-1376-11€9-babs-58ef68134€82" 16 byte collision resistant decentralized identifier generated with random number generator and optional name spacing data. Enables distributed applications to create unique identifiers without central authority Prefixed name spacing allows for sorting and searching properties such as time order, lexical order, nesting etc.
DID = UNIFIED IDENTIFIER: 2 URI: Uniform Resource Identifier, URI: Uniform Resource Locator, URN: Uniform Resource Name RFC 3986 scheme: [//[user| :password)@]host([:port]][/path][?query][#fragment] Enables specifying derived resources from central root. Mini language for performing operations on resources (ReST).
DID = UNIFIED IDENTIFIER: 3 Decentralized Self-Certifying Identifier: Contains fingerprint of public member of cryptographic public/private key pair. Key pair is generated by user not central registry. Enables decentralized self-sovereignty over identifier namespace Truly portable identifiers
DID = UNIFIED IDENTIFIER: 4 Hierarchically Deterministic Derived Self-Certifying Identifier: selfcertroot:/path/to/related/data?derivation=parent/child/child/child Enables low friction creation of identifiers on demand without having to store private keys
DID = UNIFIED IDENTIFIER: 5 Public lookup services for identifier(s) to find meta-data associated with identifier. Resolvable identifier meta data. Enables dynamic modification of identifier behavior and control
DID = UNIFIED IDENTIFIER: 6 Tupleizable (routable) Identifiers: Jchannelfhost/process/data = (channel, host, process, data) Enables data flow routing overlay for distributed data processing systems.
DID = UNIFIED IDENTIFIER Scheme - did:example:123456789abcdefghijk L T DID Method DID Method Specific String did: method: idstring (https://w3c-ccq.github. io/did-spec/) did:dad:Xq5Yqal6L48pfefu7IUhLeIRaU2_RXFPOAL4A3wYN148= did:dad:Xq5YqalL6L48pf@fu7IUnL@IRaU2_RxFPOAL43wYn148=:blue did:dad:Xq5YqalL6L48pf@fu7IUnL@IRaU2_RxFPOAL43wYn148=>who=me did:dad:Xq5YqaL6L48pfefu7IUhL@IRaU2_RXFPBALA3WYN148=: blue/my/stuff2name=samt/foo/@ DDo = DID Document. Resolver lookup provides meta-data about DID.
Decentralized Identifiers Invert Compute Architectures Conventional (centralized): Unconventional (decentralized): Server creates identifiers (GUID, Database primary keys) Client creates identifiers (DIDs) Server timestamps Client timestamps Event ordering relative to server Event ordering relative to client or vectorized relative Server manages keys, to multiple clients AuthN/AuthZ is indirect via client to server proxy Client manages keys Perimeter security around servers AuthN/AuthZ is direct peer-to-peer Server is source of truth Perimeterless security Server controls changes/updates to resources Clientis source of truth Signed at rest problematic Client controls changes/updates to resources Encrypted at rest problematic Server cannot make changes Server’s role is 2nd party in two party transactions Client signs at rest between client to server to client. Client encrypts at rest. Server’s role is either: Trusted 3rd party in 3 (multi) party transactions between 2 (or more) clients and server Agent or proxy for a client in two party transaction with another client.
DAD: Decentralized Autonomic Data Decentralized: governance of the data may not reside with a single party, trust in the data provenance is diffuse, DID based.
Autonomic: self-managing or self-governing. Self-managing includes cryptographic techniques that make the data self-identifying, self-certifying, and self-securing. Autonomic implies the use of cryptographic signatures to provide a root of trust for data integrity and to maintain that trust over transformation of that data Key management is thus a first order property of DADi. Reproduction, Rotation, and Recovery:
Pre-rotation & Hybrid recovery methods Provenance for decentralized distributed data streaming including transformations DADi: DAD item
DID, DDO, DADi, and dDID
DID = Decentralized Identifier DDo = DID Document, provides meta-data about DID. DADi = Decentralized Autonomic Data Item dDID = derived DID = Unique DID format identifier derived from one root DID/DDo that provides meta-data for a large number of dDIDs did:dad:Xq5Yqal6L48pfefu7IUhL@IRaU2_RxFPOAL43wYn148=:blue?chain=06/1 did:dad:Qt27fThWoNZsa88VrTkep6H-4HA8tr54sHON1VW16FE= Issues:
Multiplicity of data items (DADis) and associated identifiers
DDo lookup and caching may be expensive
DID/DDo pair per DADi may not be practical so use dDIDs in DADis
dDID Management
dDID NameSpacing with HD-path: root + namespace + hd path did:dad:Xg5Yqal6L48pfefu7IUhL@IRAU2_RxFPOALA3wYN148=:blue?chain=0/1 did:dad:Xq5Yqal6L48pfefu7IUhL@IRaU2_RXFPOALA3WYN148=:red?chain=0/1 dDID Sequencing: dDID + sequence number did:dad:Qt27fThioNZsa88VrTkep6H-4HABLr54sSHON1VIW1E6FE=/10057 dDID Database: index key = anonymous dDID, value = derivation from root DID {
030827 THMONZSa58VE Tkepih- HABESASHONTIMLGFE=" "did:dad:Xq5YqaL6L48pfofu7IUNLRIRAU2_RxFPBAL43WYN148=2chain=0\112", ¥
Example Signed DADi { "id": "did:dad:XqSYqal6L48pf@fu7IUhL@IRaU2_RxFPBAL43wWYn148=", "data": { “name": "John Smith", “nation": “USA™ } 1 Ar\nirin u7239aKHgz99FeK8pSkMnyqwvEr_3rpS_z2034L99sTWrMIIIGQPbVUII1cupo6cfIf_KCB5ecVRYOFRZAPNAQ==
Change Detection Prevent replay attacks: either or both: sequence number in dDID changed field with monotonically increasing sequence number or date time « "id": "did:dad:Qt27fThWoNZsa88VrTkep6H-4HA8tr54sHON1VW16FE=/10057", "changed" : "2000-81-21T00:00:00+00:00", "data": « “temp": 50, "time": "12:15:35" ) } Ar\n\r\n u72j9aKHgz99FK8pSkMnyqwvEr_3rpS_z2034L99sTWrMIIIGQPbVUII1cuposcfIf_KCBSeCVRYOFRZAPNAQ==
Zero-Trust Computing? . Never trust always verify No such thing as zero trust Really its diffuse trust zero trust term used in 2013NIST report Diffuse trust perimeter-less security model Resources: NIST: Developing a Framework to Improve Critical Infrastructure Cybersecurity 04/08/2013 Zero Trust Model for Information Security, Forrester Research. http:/jcsr.nist.govicyberframework/rfi_comments/o40813_forrester_research.pdf ‘https:/fwww.nist.gov/cyberframework Zero Trust Networks 2017 Gilman & Barth https:/fwww.amazon.com/Zero-Trust-Networks-Building-Untrusted/dp/1491962194/ref=sr_1_1? s=books8ie=UTF8&id=14998713798sr=1-1&keywords=zerostrustsnetworks
: Security Models Locality Trust Yy Zero Trust Hard shells around Soft bodies Hard bodies everywhere Remore Remte Untnsted | Internet Tusted femole emole e Gient Untusted Tusted £ Tent [ Lol eI ouz Bl Internet Hopiction Ptz e Gateway Sner | Trusted Sener Hoplcaton Sever 3 Sever Tanert gy Server Privileged Fopment Server Sener
Diffuse trust perimeter-less security principles: 1 The network is always hostile both internally and externally. Locality is not trustworthy.
Diffuse trust perimeter-less security principles: 2 By default, inter-host communication must be end-to-end signed/ encrypted and data must be stored signed/encrypted using best practices cryptography. Data is signed/encrypted in motion & at rest.
Diffuse trust perimeter-less security principles: 3 By default, every network interaction or data flow must be authenticated and authorized using best practices cryptography. Verify every time for every thing.
Diffuse trust perimeter-less security principles: 4 Policies for authentication and authorization must be dynamically modified based on behavior (reputation).
Behavioral verification rules.
Diffuse trust perimeter-less security principles: 5 Policies must be governed by diffuse-trust distributed consensus. Decentralized control.
Diffuse trust perimeter-less security principles: 6 By default, each data flow including all transformations must be end-to-end provenanced using decentralized identifiers (DIDs) and hence decentralized autonomic data items (DADis). Dadify everything.
Diffuse trust perimeter-less security principles Locality is not trustworthy. Data is signed/encrypted/provenanced in motion & at rest. Verify every time for every thing. Behavioral verification rules. Decentralized control. Dadify everything.