From 139c76a6e168b29d3c64fa2dde7b723652b4f2b2 Mon Sep 17 00:00:00 2001 From: 2byrds <2byrds@gmail.com> Date: Wed, 4 Oct 2023 11:41:23 -0400 Subject: [PATCH 1/3] included refererence to did:web privacy considerations and content from Phils did:keri privacy considerations Signed-off-by: 2byrds <2byrds@gmail.com> --- spec/privacy_considerations.md | 57 ++++++++++++++++++++++++++++++++-- 1 file changed, 54 insertions(+), 3 deletions(-) diff --git a/spec/privacy_considerations.md b/spec/privacy_considerations.md index 5652c31..3158ba3 100644 --- a/spec/privacy_considerations.md +++ b/spec/privacy_considerations.md @@ -1,5 +1,56 @@ ## Privacy Considerations +This section addresses the privacy considerations from [RFC6973](https://datatracker.ietf.org/doc/html/rfc6973) section 5. +For privacy considerations related to web infrastructure, see [`did:web` privacy considerations](https://w3c-ccg.github.io/did-method-web/#security-and-privacy-considerations). +Below we discuss privacy considerations related the KERI infrastructure. -::: todo -TODO: talk about ephemeral vs. long-lived identifiers, and about using witnesses. -::: +### Surveillance +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 + +For resolvers that simply discover the Key State endorsed by another party in a discovery network, caching policies +of that network would guide stored data security considerations. In the event that a resolver is also the endorsing party, +meaning they have their own KERI identifier and are verifying the KEL and signing the Key State themselves, leveraging the +facilities provided by the KERI protocol (key rotation, witness maintenance, multi-sig) should be used to protect the identities +used to sign the Key State. + +### Unsolicited Traffic + +DID Documents are not required to provide endpoints and thus not subject to unsolicited traffic. + +### Misattribution + +This DID Method relies on KERI's duplicity detection to determine when the non-repudiable controller of a DID +has been inconsistent and can no longer be trusted. This establishment of non-repudiation enables consistent attribution. + +### Correlation + +The root of trust for KERI identifiers is entropy and therefore offers no direct means of correlation. In addition, KERI provides +two modes of communication, direct mode and indirect mode. Direct mode allows for pairwise (n-wise as well) relationships that +can be used to establish private relationships. + +TODO: link to KERI docs for additional information about direct and indirect modes. + +### Identification + +The root of trust for KERI identifiers is entropy and therefore offers no direct means of identification. In addition, KERI provides +two modes of communication, direct mode and indirect mode. Direct mode allows for pairwise (n-wise as well) relationships that +can be used to establish private relationships. + +TODO: link to KERI docs for additional information regarding prefix generation and for a comparison between Direct and Indirect modes. + +### Secondary Use + +The Key State made available in the metadata of this DID method is generally available and can be used by any party +to retrieve and verify the state of the KERL for the given identifier. + +### Disclosure + +No data beyond the Key State for the identifier is provided by this DID method. + +### Exclusion + +This DID method provides no opportunity for [correlation](#correlation), [identification](#identification) or +[disclosure](#disclosure) and therefore there is no opportunity to exclude the controller from knowing about data that others have +about them. \ No newline at end of file From 0f7ab255166e167ae35a30e526c28611fc1edeea Mon Sep 17 00:00:00 2001 From: 2byrds <2byrds@gmail.com> Date: Wed, 4 Oct 2023 16:34:07 -0400 Subject: [PATCH 2/3] key agreement guidance Signed-off-by: 2byrds <2byrds@gmail.com> --- spec/diddocuments.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/spec/diddocuments.md b/spec/diddocuments.md index 4d08ca1..7b9cf8d 100644 --- a/spec/diddocuments.md +++ b/spec/diddocuments.md @@ -422,6 +422,12 @@ If the value of `kt` > 1 or if the value of `kt` is an array containing fraction References to verification methods in the DID document MUST use the relative form of the identifier, e.g., `"authentication": ["#"]`. +##### Key Agreement +There are multiple ways to establish key agreement in KERI. We detail common considerations and techniques: +* *BADA-RUN for key agreement:* Normally in KERI we would use [[ref: BADA-RUN]], similar to how we are specify endpoints, domain migration info, etc. This would allow the controller to specify any Key Agreement key, without unnecessarily adding KERI events to their [[ref: KEL]]. +* *Key agreement from `k` field keys:* It is important to note that KERI is cryptographically agile and can support a variety of keys and signatures. If the 'k' field references a Ed25519 key, then key agreement could be established using the corresponding x25519 key for Diffie-Helman key exchange. Alternatively if the key is an ECDSA or other NIST algorithms key then it will be the same key for signatures and encryption and can be used for key agreement. +* *Key agreement anchored in KEL:* It is always possible to anchor arbitrary data, like a key agreement key, to the KEL. Likely the best mechanism is to anchor an ACDC credential to a [[ref: TEL]] which is anchored to the KEL. + #### Service Endpoints `did:webs` supports service endpoints, including types declared in the DID Specification Registries, such as [DIDCommMessaging](https://www.w3.org/TR/did-spec-registries/#didcommmessaging). For additional details about the mapping between KERI events and the Service Endpoints in the DID Document, see [Service Endpoint KERI events](#service-endpoint-event-details). It is important to note that DID document service endpoints are different than the KERI service endpoints detailed in [KERI Service Endpoints as DID Document Metadata](#keri-service-endpoints-as-did-document-metadata). From fda06ce7f13131cf488d8be78e8f6d5bde166580 Mon Sep 17 00:00:00 2001 From: 2byrds <2byrds@gmail.com> Date: Wed, 4 Oct 2023 16:37:17 -0400 Subject: [PATCH 3/3] fix typo Signed-off-by: 2byrds <2byrds@gmail.com> --- spec/diddocuments.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec/diddocuments.md b/spec/diddocuments.md index 7b9cf8d..eaf3d55 100644 --- a/spec/diddocuments.md +++ b/spec/diddocuments.md @@ -426,7 +426,7 @@ References to verification methods in the DID document MUST use the relative for There are multiple ways to establish key agreement in KERI. We detail common considerations and techniques: * *BADA-RUN for key agreement:* Normally in KERI we would use [[ref: BADA-RUN]], similar to how we are specify endpoints, domain migration info, etc. This would allow the controller to specify any Key Agreement key, without unnecessarily adding KERI events to their [[ref: KEL]]. * *Key agreement from `k` field keys:* It is important to note that KERI is cryptographically agile and can support a variety of keys and signatures. If the 'k' field references a Ed25519 key, then key agreement could be established using the corresponding x25519 key for Diffie-Helman key exchange. Alternatively if the key is an ECDSA or other NIST algorithms key then it will be the same key for signatures and encryption and can be used for key agreement. -* *Key agreement anchored in KEL:* It is always possible to anchor arbitrary data, like a key agreement key, to the KEL. Likely the best mechanism is to anchor an ACDC credential to a [[ref: TEL]] which is anchored to the KEL. +* *Key agreement anchored in KEL:* It is always possible to anchor arbitrary data, like a key agreement key, to the KEL. Likely the best mechanism is to anchor an ACDC to a [[ref: TEL]] which is anchored to the KEL. #### Service Endpoints `did:webs` supports service endpoints, including types declared in the DID Specification Registries, such as [DIDCommMessaging](https://www.w3.org/TR/did-spec-registries/#didcommmessaging). For additional details about the mapping between KERI events and the Service Endpoints in the DID Document, see [Service Endpoint KERI events](#service-endpoint-event-details). It is important to note that DID document service endpoints are different than the KERI service endpoints detailed in [KERI Service Endpoints as DID Document Metadata](#keri-service-endpoints-as-did-document-metadata).