From 40a9e0330e29c0e1690826e2ffc4f065e68e5ad4 Mon Sep 17 00:00:00 2001 From: Ed Eykholt Date: Fri, 8 Dec 2023 17:18:23 -0800 Subject: [PATCH] Mostly grammar fixes, some clarifications, and "TODO:" for existing TODOs Signed-off-by: Ed Eykholt --- spec/abstract.md | 2 +- spec/core.md | 10 +++++----- spec/diddocuments.md | 6 +++--- spec/keri.md | 2 +- spec/privacy_considerations.md | 2 +- spec/security_characteristics.md | 34 ++++++++++++++++---------------- spec/whois.md | 2 +- 7 files changed, 29 insertions(+), 29 deletions(-) diff --git a/spec/abstract.md b/spec/abstract.md index c1642eb..977b9aa 100644 --- a/spec/abstract.md +++ b/spec/abstract.md @@ -14,7 +14,7 @@ The `did:webs` method does not need blockchains for trust. However, its use of KERI allows for the referencing of arbitrary blockchains as an extra, optional publication mechanism. This offers an interoperability bridge from (or between) blockchain ecosystems. Also, without directly supporting environments where the -web is not practical (e.g., IOT, Lo-Ra, BlueTooth, NFC), the method builds on a +web is not practical (e.g., IOT, Lo-Ra, Bluetooth, NFC), the method builds on a foundation that fully supports those environments, making future interop of identifiers between web and non-web a manageable step. diff --git a/spec/core.md b/spec/core.md index c0704ca..20dc206 100644 --- a/spec/core.md +++ b/spec/core.md @@ -73,7 +73,7 @@ practices to preserve good hygiene. However, the authenticity of data is guaranteed by the DID value itself, in conjunction with a digitally signed -data structure called a [[ref: KERI event stream]], which includes the +data structure called a [[ref: KERI event stream]], which includes for a given AID its [[ref: key event log]] ([[ref: KEL]]) and [[ref: transaction event log]] ([[ref: TEL]]). These trust mechanisms — the integrity checks built into the DID value, and the workings of the [[ref: KERI event stream]] — are defined by [[ref: KERI]]. @@ -95,7 +95,7 @@ The location of the [[ref: KERI event stream]] is determined by transforming the A GET on that URL MUST return the [[ref: KERI event stream]] for the AID in the `did:webs` identifier. The [[ref: KERI event stream]] MUST be CESR-formatted (media type of application/cesr) and the KERI events must be verifiable using the KERI rules. -The following are some `did:webs` DIDs and their corresponding DID document and [[ref: KERI event stream]] +The following are some example `did:webs` DIDs and their corresponding DID document and [[ref: KERI event stream]] URLs, based on the examples from the [DID Web Specification](https://github.com/w3c-ccg/did-method-web/), but with the (faked) AID `12124313423525` added: @@ -119,7 +119,7 @@ specification. This specification assumes a working knowledge of the concepts there. The inclusion of KERI in `did:webs` enables a number of capabilities for securing a `did:webs` identifier, including multi-signature support and the creation of [[ref: pre-rotated]] keys to prevent loss of control of the identifier if the -current private key is compromised. +current private key were to be compromised. A target system cannot forge or tamper with data protected by KERI, and if it deliberately serves an outdated copy, the duplicity is often detectable. Thus, @@ -166,14 +166,14 @@ as KERI witnesses and watchers. ### Handling Web Redirection A `did:webs` is intended to be a "stable" (long-lasting) identifier that can be -put into documents, such as verifiable credentials, that are intended to be +put into documents such as verifiable credentials, and that are intended to be useful for a very long time -- generations. However, the web is not a very stable place, and documents are moved around and copied frequently. When two or more companies merge, often the web presence of some of the merged entities "disappears". It may not be possible to retain a permanent `did:webs` web location. -When a `did:webs` moves, its AID does not change. The same [[ref: KERI event stream]] is used to verify +When a `did:webs` is updated for another location, its AID does not change. The same [[ref: KERI event stream]] is used to verify the DID document. Were the AID to change, it would be an altogether new DID, unconnected to the first DID. So if a resolver can find a newly named DID that uses the same AID, and the [[ref: KERI event stream]] verifies the DID, then they have resolved the diff --git a/spec/diddocuments.md b/spec/diddocuments.md index 1abcc53..f933e3b 100644 --- a/spec/diddocuments.md +++ b/spec/diddocuments.md @@ -100,7 +100,7 @@ as a `did:webs` DID and as a `did:keri` DID as well. Finally, the same AID may multiple domains at the same time and they should be considered the same DID since the AID portion of the DIDs are the same. -For each synonymous DID defined above (we need a way in KERI to declare other domains it is being +For each synonymous DID defined above (TODO: we need a way in KERI to declare other domains it is being served under, unless this is an implementation specific detail) an entry in the `alsoKnownAs` array in the DID document should be created. For the DID `did:webs:example.com:Ew-o5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M` the following `alsoKnownAs` @@ -122,12 +122,12 @@ KERI identifiers express public signing keys as Composable Event Streaming Repre determine the cryptographic algorithm used to generate the key pair. For each key listed in the array value of the `k` field a corresponding verification method will be generated in the DID document. The 'type' property in the verification method for each public key will be determined by the algorithm used to generate the public key. At the time of this writing, KERI currently -supports public key generation for Ed25519, Secp256k1 and Secp256r1 keys, however the protocol allows for others to be added at any time. +supports public key generation for Ed25519, Secp256k1 and Secp256r1 keys, and the protocol allows for others to be added at any time. We must define the subset of public key algorithms for KERI AIDs that this specification will accept, so we can define mappings to existing verification method types as registered in the DID Specification Registries. As KERI evolves with more algorithms, new verification method types must be registered in the DID Specification Registries and added to this specification. The `id` property of the verification method must be a relative DID URL and use the KERI key CESR value as the value of the fragment component, e.g., `"id": "#"`. -The `controller` property of the verification method must be the value of the `id` property of DID document. (Does the method spec need to specify this?) +The `controller` property of the verification method must be the value of the `id` property of DID document. (TODO: Does the method spec need to specify this?) For example, the key `DFkI8OSUd9fnmdDM7wz9o6GT_pJIvw1K_S21AKZg4VwK` in the DID document for the AID `EDP1vHcw_wc4M__Fj53-cJaBnZZASd-aMTaSyWEQ-PC2` becomes: diff --git a/spec/keri.md b/spec/keri.md index d169b30..efe6b44 100644 --- a/spec/keri.md +++ b/spec/keri.md @@ -47,7 +47,7 @@ Unlike a blockchain with a distributed consensus mechanism, witnesses do not coo ### Web Independence -Although _this DID method_ depends on web technology, _KERI itself_ does not. It's as easy to create AIDs on IOT devices as it is on the web. AIDs offer the same features regardless of their origin, and besides HTTP, they are shareable over Lo-Ra, BlueTooth, NFC, Low Earth Orbit satellite protocols, service buses on medical devices, and so forth. Thus, KERI's AIDs offer a bridge between a web-centric DID method and lower-level IOT ecosystems. +Although _this DID method_ depends on web technology, _KERI itself_ does not. It's as easy to create AIDs on IOT devices as it is on the web. AIDs offer the same features regardless of their origin, and besides HTTP, they are shareable over Lo-Ra, Bluetooth, NFC, Low Earth Orbit satellite protocols, service buses on medical devices, and so forth. Thus, KERI's AIDs offer a bridge between a web-centric DID method and lower-level IOT ecosystems. ### Flexible Serialization diff --git a/spec/privacy_considerations.md b/spec/privacy_considerations.md index 3158ba3..39061e6 100644 --- a/spec/privacy_considerations.md +++ b/spec/privacy_considerations.md @@ -4,7 +4,7 @@ For privacy considerations related to web infrastructure, see [`did:web` privacy Below we discuss privacy considerations related the KERI infrastructure. ### Surveillance -In KERI, A robust witness network along with consistent witness rotation provides protection from monitoring and association of +In KERI, a robust witness network along with consistent witness rotation provides protection from monitoring and association of an individual's activity inside a KERI network. ### Stored Data Compromise diff --git a/spec/security_characteristics.md b/spec/security_characteristics.md index 82855df..a1da530 100644 --- a/spec/security_characteristics.md +++ b/spec/security_characteristics.md @@ -6,7 +6,7 @@ There are several security characteristics necessary for `did:webs` to sufficien `did:webs` strives to narrow the attack surface against these common threats: - Broken Object Level Authorization (BOLA) -- Denial of service (DDoS) attack +- Denial of service (DoS) attack - Deletion attack - Duplicity detection - Eclipse attack @@ -19,19 +19,19 @@ There are several security characteristics necessary for `did:webs` to sufficien ### Concepts for securing `did:webs` information The following security concepts are used to secure the data, files, signatures and other information in `did:webs`. We characterize each concept with high, medium and low security to orient readers to the situational relevance. -We use KEL backed security for the highest possible security of on-disk storage, but also the most costly because it uses space in KELs. BADA-RUN is medium security and makes sure events are ordered in a consistent way, using a combination of date-time and a key state. Without having to negotiate security in did:webs we use a lower level of security when appropriate. +We use _KEL backed data_ security for the highest possible security of on-disk storage, but also the most costly because it uses space in KELs. _Best Available Data - Read, Update, Nullify_ ([[ref: BADA-RUN]]) is medium security and makes sure events are ordered in a consistent way, using a combination of date-time and a key state. Without having to negotiate security in did:webs we use a lower level of security, _KERI Request Authentication Mechanism_ ([[ref: KRAM]]), when appropriate. #### KEL backed data: High Security -[[ref: KEL backed]] information in `did:webs` can either be found in the KEL or found anchored to the KEL. This means the signatures on the events in the KEL are strongly bound to the key state at the time the events are entered in the KEL. This provides the strongest guarantee of duplicity evidence so that any verifier is protected. The information is end-verifiable and any evidence of duplicity means do not trust. A key compromise of a stale key can not result in an exploit because that would require forging an alternate version of the KEL which would be exposed as duplicity. Key compromise of the current key state is recoverable with a rotation to the pre-rotated key(s) (single-sig or multi-sig). By design pre-rotated keys are post-quantum proof. A compromise of a current key state is guaranteed to be detectable by the AID’s controller because the compromise requires publication of a new KEL event in infrastructure (i.e. witnesses) controlled by the AID controller. This limits the exposure of a successful compromise of the current key state to the time it takes for the AID controller to observe the compromised publication and execute a recovery rotation. +[[ref: KEL backed]] information in `did:webs` can either be found in the KEL or found anchored to the KEL. This means the signatures on the events in the KEL are strongly bound to the key state at the time the events are entered in the KEL. This provides the strongest guarantee of duplicity evidence so that any verifier is protected. The information is end-verifiable and any evidence of duplicity means do-not-trust. A key compromise of a stale key can not result in an exploit because that would require forging an alternate version of the KEL which would be exposed as duplicity. Key compromise of the current key state is recoverable with a rotation to the pre-rotated key(s) (single-sig or multi-sig). By design, pre-rotated keys are post-quantum proof. A compromise of a current key state is guaranteed to be detectable by the AID’s controller because the compromise requires publication of a new KEL event in infrastructure (i.e. witnesses) controlled by the AID controller. This limits the exposure of a successful compromise of the current key state to the time it takes for the AID controller to observe the compromised publication and execute a recovery rotation. -The ordering of events in the KEL is strictly verifiable because the KEL is a hash chain (block chain). All events are end-verifiable. Any data anchored to these events is also end-verifiable. All of these properties are guaranteed when data is anchored to a KEL, i.e., [[ref: KEL backed]]. Any information that wants to be end-verifiably authentic over time should be at this highest level of security. [[ref: ACDCs]] when anchored to a KEL directly or indirectly through a [[ref: TEL]] that itself is anchored to a KEL have this level of security. +The ordering of events in the KEL is strictly verifiable because the KEL is a hash chain (block chain). All events are end-verifiable. Any data anchored to these events is also end-verifiable. All of these properties are guaranteed when data is anchored to a KEL, i.e., [[ref: KEL backed]]. Any information that wants to be end-verifiably authentic over time should be at this highest level of security. [[ref: ACDCs]], when anchored to a KEL directly or indirectly through a [[ref: TEL]] that itself is anchored to a KEL, have this level of security. -#### BADA-RUN Medium Security +#### BADA-RUN: Medium Security [[ref: BADA-RUN]] stands for Best available data acceptance - Read/Update/Nullify and is described in the ToIP KERI [[ref: OOBI specification]]. It makes sure events are ordered in a consistent way, using a combination of date-time and a key state. -The latest event is the one with the latest date-time for the latest key state. This level of security is sufficient for discovery information because the worst-case attack on discovery information is a DDoS attack where nothing gets discovered. This is because what gets discovered in KERI must be end-verifiable (anchored to a KEL). So a malicious discovery (mal-discovery) is no different than a mis-discovery or a non-discovery. The mitigation for such a DDoS attack is to have redundant discovery sources. We use [[ref: BADA-RUN]] for service end-points as discovery mechanisms. Of course we could anchor service endpoints to KELs and make them more secure. All things considered, due to the dynamics of discovery mechanisms we decided to not bloat the KEL with discovery anchors. Because the worst case can be mitigated with redundant discovery, BADA-RUN is a defensible choice. +The latest event is the one with the latest date-time for the latest key state. This level of security is sufficient for discovery information because the worst-case attack on discovery information is a DDoS attack where nothing gets discovered. This is because what gets discovered in KERI must be end-verifiable (anchored to a KEL). So a malicious discovery (mal-discovery) is no different than a mis-discovery or a non-discovery. The mitigation for such a DDoS attack is to have redundant discovery sources. We use [[ref: BADA-RUN]] for service end-points as discovery mechanisms. Of course we could anchor service endpoints to KELs and make them more secure. All things considered, due to the dynamics of discovery mechanisms, we decided to not bloat the KEL with discovery anchors. Because the worst case can be mitigated with redundant discovery, BADA-RUN is a defensible choice. Monotonicity (or consistent ordering) protects against replay attacks and stale key compromise impersonation attacks. It does not provide strict ordering because there may be missed events and stale events but the last seen event always wins. So the only event that is end-verifiable is the last seen event but that event may be stale. @@ -51,39 +51,39 @@ In [[ref: BADA-RUN]], the RUN stands for Read, Update, Nullify and is a replacem #### KRAM: Low Security -KERI Request Authentication Mechanism ([[ref: KRAM]]) is the lowest security requirement and can only be used for ephemeral query/reply mechanisms that protect against replay attacks and key-compromise attacks at the moment, not over time. This is done with [[ref: KRAM]] which is a non-interactive replay attack protection algorithm that uses a sliding window of date-time stamps and key state (similar to the the tuple as in [[ref: BADA-RUN]]) but the date-time is the replier’s not the querier’s. **[[ref: KRAM]] is meant to protect a host** when providing access to information to a client from replay attacks by a malicious client. It is not meant to protect the information provided by the host. For that we must use [[ref: BADA-RUN]] or KEL backing. Thus, by itself [[ref: KRAM]] is not suitable to protect on-disk storage (see [[ref: On-Disk Storage]] section below). +KERI Request Authentication Mechanism ([[ref: KRAM]]) is the lowest security requirement and can only be used for ephemeral query/reply mechanisms that protect against replay attacks and key-compromise attacks at the moment, not over time. This is done with [[ref: KRAM]], which is a non-interactive replay attack protection algorithm that uses a sliding window of date-time stamps and key state (similar to the the tuple as in [[ref: BADA-RUN]]) but the date-time is the replier’s not the querier’s. **[[ref: KRAM]] is meant to protect a host** when providing access to information to a client from replay attacks by a malicious client. It is not meant to protect the information provided by the host. For that we must use [[ref: BADA-RUN]] or KEL backing. Thus, by itself [[ref: KRAM]] is not suitable to protect on-disk storage (see [[ref: On-Disk Storage]] section below). -The `did:webs` resolver should be using KRAM to access the service endpoints providing KERI event streams for verification of the DID document. This is part of what makes the local resolver trusted, it must control who has access and KRAM provides the necessary “non-interactive” basis for non-replay attackable access. +The `did:webs` resolver should be using KRAM to access the service endpoints providing KERI event streams for verification of the DID document. This is part of what makes the local resolver trusted, and it must control who has access and KRAM provides the necessary “non-interactive” basis for non-replay attackable access. ### On-Disk Storage -Both KEL backed and [[ref: BADA-RUN]] are suitable for storing information on disk because both provide a link between the keystate and date-time on some data when a signature by the source of the data was created. [[ref: BADA-RUN]] is too weak for important information because an attacker who has access to the database on disk can overwrite data on disk without being detected by a verifier hosting the on-disk data either through a replay of stale data (data regression attack) or if in addition to disk access the attacker has compromised a given key state, then the attacker can forge new data with a new date-time stamp for a given compromised key and do a regression attack so that the last seen key state is the compromised key state. +Both KEL backed data and [[ref: BADA-RUN]] security approaches are suitable for storing information on disk because both provide a link between the keystate and date-time on some data when a signature by the source of the data was created. [[ref: BADA-RUN]] is too weak for important information because an attacker who has access to the database on disk can overwrite data on disk without being detected by a verifier hosting the on-disk data either through a replay of stale data (data regression attack) or if in addition to disk access the attacker has compromised a given key state, then the attacker can forge new data with a new date-time stamp for a given compromised key and do a regression attack so that the last seen key state is the compromised key state. With BADA, protection from a deletion (regression) attack requires redundant disk storage. At any point in time where there is a suspicion of loss of custody of the disk, a comparison to the redundant disks is made and if any disk has a later event given [[ref: BADA-RUN]] rules then recovery from the deletion attack is possible. -[[ref: KRAM]] on a query is not usable for on disk storage by itself. Because its just a bare signature (the datetime is not of the querier but of the host at the time of a query). But the reply to a query can be stored on disk if the querier applies BADA to the reply. To elaborate, Data obtained via a KRAMed query-reply may be protected on-disk by being using BADA on the reply. This is how KERI stores service endpoints. But KERI currently only uses BADA for discovery data not more important data. More important data should be wrapped (containerized) in an [[ref: ACDC]] that is [[ref: KEL backed]] and then stored on-disk +[[ref: KRAM]] on a query is not usable for on disk storage by itself. Because it's just a bare signature (the datetime is not of the querier but of the host at the time of a query). However, the reply to a query can be stored on disk if the querier applies BADA to the reply. To elaborate, Data obtained via a KRAMed query-reply may be protected on-disk by being using BADA on the reply. This is how KERI stores service endpoints. However, KERI currently only uses BADA for discovery data not more important data. More important data should be wrapped (containerized) in an [[ref: ACDC]] that is [[ref: KEL backed]] and then stored on-disk -In the hierarchy of attack surfaces. Exposure as on disk (unencrypted) is the weakest. Much stronger is exposure that is only in-memory. To attack in-memory usually means compromising the code supply chain which is harder than merely gaining disk access. Encrypting data on disk does not necessarily solve attacks that require a key compromise (because decryption keys can be compromised) and it does not prevent a deletion attack. Encryption does not provide authentication protection. But encryption does protect the confidentiality of data. +In the hierarchy of attack surfaces, exposure as on disk (unencrypted) is the weakest. Much stronger is exposure that is only in-memory. To attack in-memory usually means compromising the code supply chain which is harder than merely gaining disk access. Encrypting data on disk does not necessarily solve attacks that require a key compromise (because decryption keys can be compromised), and it does not prevent a deletion attack. Encryption does not provide authentication protection. However, encryption does protect the confidentiality of data. -The use of DH key exchange as a weak form of authentication is no more secure than an HMAC for authentication. Its sharing secrets and anyone with the secret can impersonate any other member of the group that has the shared secret. +The use of DH key exchange as a weak form of authentication is no more secure than an HMAC for authentication. It is sharing secrets, so anyone with the secret can impersonate any other member of the group that has the shared secret. -Often did methods have focused on features that erode security characteristics. The paper [Five DID Attacks](https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/final-documents/taking-out-the-crud-five-fabulous-did-attacks.pdf) highlights some attacks to which `did:webs` should NOT be vulnerable. So when a pull request exposes `did:webs` to a known attack, it should not be accepted. +Often, DID methods have focused on features that erode security characteristics. The paper [Five DID Attacks](https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/final-documents/taking-out-the-crud-five-fabulous-did-attacks.pdf) highlights some attacks to which `did:webs` should NOT be vulnerable. So when a pull request exposes `did:webs` to a known attack, it should not be accepted. ### Alignment of Information to Security Posture As a general security principle each block of information should have the same security posture for all the sub-blocks. One should not attempt to secure a block of information that mixes security postures across is constituent sub-blocks. The reason is that the security of the block can be no stronger than the weakest security posture of any sub-block in the block. Mixing security postures forces all to have the lowest common denominator security. The only exception to this rule is if the block of information is purely informational for discovery purposes and where it is expected that each constituent sub-block is meant to be verified independently. -This means that any recipient of such a block information with mixed security postures across its constituent sub-blocks must explode the block into sub-blocks and then independently verify the security of each sub-block. But this is only possible if the authentication factors for each sub-block are provided independently. Usually when information is provided in a block of sub-blocks, only one set of authentication factors are provided for the block as a whole and therefore there is no way to independently verify each sub-block of information. +This means that any recipient of such a block information with mixed security postures across its constituent sub-blocks must explode the block into sub-blocks and then independently verify the security of each sub-block. However, this is only possible if the authentication factors for each sub-block are provided independently. Usually when information is provided in a block of sub-blocks, only one set of authentication factors are provided for the block as a whole and therefore there is no way to independently verify each sub-block of information. -Unfortunately what happens in practice is that users are led into a false sense of security because they assume that they don’t have to explode and re-verify but merely may accept the lowest common denominator verification on the whole block of information. This creates a pernicious problem for down stream use of the data. A down stream use of a constituent sub-block doesn’t know that it was not independently verified to its higher level of security. This widens the attack surface to any point of down-stream usage. This is a root cause of the most prevalent type of attack called a BOLA. +Unfortunately, what happens in practice is that users are led into a false sense of security because they assume that they don’t have to explode and re-verify, but merely may accept the lowest common denominator verification on the whole block of information. This creates a pernicious problem for downstream use of the data. A downstream use of a constituent sub-block doesn’t know that it was not independently verified to its higher level of security. This widens the attack surface to any point of down-stream usage. This is a root cause of the most prevalent type of attack called a BOLA. #### Applying the concepts Lets explore the implications of applying these concepts to various `did:webs` elements. -[[ref: KEL backed]] elements in a DID doc simplifies the security concerns. But future discovery features related to endpoints might consider BADA-RUN. For instance, 'whois' data could be used with [[ref: BADA-RUN]] whereas did:web aliases should not because it could lead to an impersonation attack. We could have a DID document that uses [[ref: BADA-RUN]] if we modify the DID CRUD semantics to be RUN semantics without necessarily changing the verbs but by changing the semantics of the verbs. Then any data that fits the security policy of BADA (i.e. where BADA is secure enough) can be stored in a DID document as a database in the sky. For sure this includes service endpoints for discovery. One can sign with CESR or JWS signatures. The payloads are essentially KERI reply messages in terms of the fields (with modifications as needed to be more palatable) but semantically the same. The DID doc just relays those replies. Anyone reading from the DID document is essentially getting a KERI reply message and they then should apply the BADA rules to their local copy of the reply message. +Using [[ref: KEL backed]] elements in a DID doc simplifies the security concerns. However, future discovery features related to endpoints might consider BADA-RUN. For instance, 'whois' data could be used with [[ref: BADA-RUN]] whereas did:web aliases should not because it could lead to an impersonation attack. We could have a DID document that uses [[ref: BADA-RUN]] if we modify the DID CRUD semantics to be RUN semantics without necessarily changing the verbs but by changing the semantics of the verbs. Then any data that fits the security policy of BADA (i.e. where BADA is secure enough) can be stored in a DID document as a database in the sky. For sure this includes service endpoints for discovery. One can sign with CESR or JWS signatures. The payloads are essentially KERI reply messages in terms of the fields (with modifications as needed to be more palatable), but are semantically the same. The DID doc just relays those replies. Anyone reading from the DID document is essentially getting a KERI reply message, and they then should apply the BADA rules to their local copy of the reply message. -To elaborate, these security concepts point us to modify the DID CRUD semantics to replicate RUN semantics. Create becomes synonymous with Update where Update uses the RUN update. Delete is modified to use the Nullify semantics. Read data is modified so that any recipient of the Read response can apply BADA to its data (Read is a GET). So we map the CRUD of DID docs to RUN for the `did:webs` method. Now you have reasonable security for things like signed data. If its [[ref: KEL backed]] data you could even use an ACDC as a data attestation for that data and the did resolver would become a caching store for ACDCs issued by the AID controller. +To elaborate, these security concepts point us to modify the DID CRUD semantics to replicate RUN semantics. _Create_ becomes synonymous with _Update_ where Update uses the RUN update. _Delete_ is modified to use the Nullify semantics. _Read_ data is modified so that any recipient of the Read response can apply BADA to its data (Read is a GET). So we map the CRUD of DID docs to RUN for the `did:webs` method. Now you have reasonable security for things like signed data. If its [[ref: KEL backed]] data you could even use an ACDC as a data attestation for that data and the did resolver would become a caching store for ACDCs issued by the AID controller. Architecturally, a Read (GET) from the did resolver acts like how KERI reply messages are handled for resolving service endpoint discovery from an [[ref: OOBI]]. The query is the read in RUN and so uses KRAM. The reply is the response to the READ request. The controller of the AID updates the DID resolvers cache with updates(unsolicited reply messages). A trustworthy DID resolver applies the BADA rules to any updates it receives. Optionally the DID resolver may apply [[ref: KRAM]] rules to any READ requests to protect it from replay attacks. diff --git a/spec/whois.md b/spec/whois.md index c32b599..0c25de1 100644 --- a/spec/whois.md +++ b/spec/whois.md @@ -1,6 +1,6 @@ ## The `whois` DID URL -The `did:webs` method defines that a controller MAY publish a [W3C verifiable presentation](https://www.w3.org/TR/vc-data-model/#presentations-0) beside the DID +The `did:webs` method defines that a controller MAY publish a [W3C verifiable presentation](https://www.w3.org/TR/vc-data-model/#presentations-0) in addition to the DID Doc (`did.json`). The verifiable presentation is referenced using the [[ref: DID URL]] `/whois` and can be resolved using the HTTPS DID path `/whois.vp`. The verifiable presentation MUST ONLY contain Verifiable