Format address as property of Identity (#285)

* refactor: write consistently email instead of e-mail * feat: write address lowercase and format if possible * refactor: reformulate phrase "your address" * refactor: emphazise enmeshed Address as proper noun in some cases
nmshd · Dec 5, 2024 · 0e68374 · 0e68374
1 parent 2a437c4
commit 0e68374
Show file tree

Hide file tree

Showing 38 changed files with 89 additions and 91 deletions.
diff --git a/_docs_explore/23-privacy.md b/_docs_explore/23-privacy.md
@@ -30,7 +30,7 @@ Potential examples of personal data / PII:
 - Names
 - Addresses
 - Phone numbers
-- E-Mail addresses
+- Email addresses
 - Birth dates
 - Payment details
 - IP addresses
@@ -61,7 +61,7 @@ Due to the broad scope of scenarios encompassed within the public sector, an abs
 
 The developers at enmeshed interpret the data privacy regulations narrowly, which has earned the appreciation of lawyers and data privacy experts for the design of the solution. Notably, the ability to delete all of the following data categories within our solution is pivotal for **absolute data privacy**:
 
-1. (Non-technical) personal data which could directly identify a person (like names, e-mail addresses, birth dates, public/social ids, or phone numbers) is only processed in an end-to-end encrypted way between users and organizations. The central service does not have access to this data.
+1. (Non-technical) personal data which could directly identify a person (like names, email addresses, birth dates, public/social ids, or phone numbers) is only processed in an end-to-end encrypted way between users and organizations. The central service does not have access to this data.
 2. Pseudonyms or technical identifiers which are shared between multiple Identities (like enmeshed Addresses, enmeshed Public Keys, Device Ids, or Identity versions) are considered PII, as an entity could use this information to map this data to real world persons.
 3. Pseudonyms, technical identifiers or secrets which are shared between two Identities (like Backbone credentials, device versions, or Relationship public keys) are considered PII, as an entity could use this information to map this data to real world persons.
 4. One-way functions (hashes/digests) of PII are considered PII, as an entity theoretically has the possibility of mapping these hashes to real world persons or could potentially map the hashes to real world persons.
@@ -72,7 +72,7 @@ When considering a **relative data privacy** , one might contend that only data
 
 ## Least Knowledge
 
-'Least Knowledge' is the fundamental principle upon which enmeshed is built. As a result, the solution aims to minimize Personally Identifiable Information (PII) usage, thereby providing an optimal user experience and comprehensive features. In fact, the "usual personal data", like e-mail addresses, telephone numbers or names never reach the Backbone (and its operator) in cleartext.
+'Least Knowledge' is the fundamental principle upon which enmeshed is built. As a result, the solution aims to minimize Personally Identifiable Information (PII) usage, thereby providing an optimal user experience and comprehensive features. In fact, the "usual personal data", like email addresses, telephone numbers or names never reach the Backbone (and its operator) in cleartext.
 
 - The enmeshed App stores the data in a local database on the device it is operating on. Data usually can only be sent to or received from the Backbone, generic Internet access from the App is blocked.
 - The enmeshed Connector stores the data in a local database within an organization's network. Data can only be sent to or received from the Backbone, no other Internet access should be made possible.
@@ -94,7 +94,7 @@ enmeshed additionally follows the once-only principle for such data, thus enabli
 
 The Backbone is the most significant component in terms of privacy. As a centrally hosted component by a third party, it is understandable that privacy-related questions usually focus this component."
 
-The Backbone only stores technical information of Identities or devices. It never has access to cleartext data such as content of Messages, names, e-mail addresses, and so on, as all this information is end-to-end encrypted. Furthermore, even encrypted data of the Backbone is not publicly available - only the Identities which have reason to access the data get access.
+The Backbone only stores technical information of Identities or devices. It never has access to cleartext data such as content of Messages, names, email addresses, and so on, as all this information is end-to-end encrypted. Furthermore, even encrypted data of the Backbone is not publicly available - only the Identities which have reason to access the data get access.
 
 Without the actual keys from the respective Identities (which the Backbone hosting entity does not receive) the actual data cannot practically be decrypted or analyzed. The **relative data privacy** mindset should thus be reasonably fulfilled by using the enmeshed mechanisms.
 

diff --git a/_docs_explore/60-addresses.md b/_docs_explore/60-addresses.md
@@ -3,7 +3,7 @@ title: "enmeshed Addresses"
 permalink: /explore/addresses
 ---
 
-The Address is the primary identifier for an enmeshed Identity. It is public and created out of the Identity’s Signature Public Key. Thus, the Identity’s root signature key and its corresponding Address are interlinked with each other and cannot be changed. Nobody is able to change the public key for a corresponding Address and everybody has the possibility to check, if a given public key matches a given Address without having to trust someone. Both are important security features.
+The enmeshed Address is the primary identifier for an enmeshed Identity and stored within the `address` property of the data object of type [Identity]({% link _docs_integrate/data-model-overview.md %}#identity). It is public and created out of the Identity’s Signature Public Key. Thus, the Identity’s root signature key and its corresponding Address are interlinked with each other and cannot be changed. Nobody is able to change the public key for a corresponding Address and everybody has the possibility to check, if a given public key matches a given Address without having to trust someone. Both are important security features.
 
 - As Addresses do not contain special characters, copy and pasting via double-click is supported.
 - As they do have a checksum included, syntactically wrong Addresses can be checked by a computer program locally.

diff --git a/_docs_explore/63-blockchain.md b/_docs_explore/63-blockchain.md
@@ -10,7 +10,7 @@ permalink: /explore/blockchain
 Having full control over data, authorizations, or the hard- and software one can use for using the data is called self-sovereignty. A self-sovereign Identity is a digital Identity which anybody can set up, without the power of somebody else to deny access, spy on or change the data.
 
 **Example:**
-The common scenario in the Internet is, to create a user profile on a website, enter all the required information including username, password, e-mail address, and many more personal information. This data is stored on one central solution provider which has the complete authority over your account. This authority can be used for tracing or blocking users. A user would not be able to login or use all the features anymore - a common topic with social login providers.
+The common scenario in the Internet is, to create a user profile on a website, enter all the required information including username, password, email address, and many more personal information. This data is stored on one central solution provider which has the complete authority over your account. This authority can be used for tracing or blocking users. A user would not be able to login or use all the features anymore - a common topic with social login providers.
 
 A self-sovereign Identity wouldn't work it that way: The user will always have the full control over this Identity – only the usage for a specific service (e.g. a specific social network) could be blocked by the network. But the Identity itself could still be used for any other tasks.
 

diff --git a/_docs_integrate/attribute-values.md b/_docs_integrate/attribute-values.md
@@ -521,11 +521,11 @@ It is not recommended to send a DigitalIdentityDescriptor to another Identity by
 
 **Properties**
 
-| Name         | Type                          | Required | Validation                                           |
-| ------------ | ----------------------------- | :------: | ---------------------------------------------------- |
-| `@type`      | `"DigitalIdentityDescriptor"` |    ✓     |                                                      |
-| `address`    | `string`                      |    ✓     | The Address of the Identity that owns the statement. |
-| `attributes` | `string []`                   |    ✗     | see [`Identity Attributes`](#identity-attributes)    |
+| Name         | Type                          | Required | Validation                                                                                                           |
+| ------------ | ----------------------------- | :------: | -------------------------------------------------------------------------------------------------------------------- |
+| `@type`      | `"DigitalIdentityDescriptor"` |    ✓     |                                                                                                                      |
+| `address`    | `string`                      |    ✓     | The `address` of the [Identity]({% link _docs_integrate/data-model-overview.md %}#identity) that owns the statement. |
+| `attributes` | `string []`                   |    ✗     | see [`Identity Attributes`](#identity-attributes)                                                                    |
 
 ## StatementAuthorityType
 
@@ -582,11 +582,11 @@ It is not recommended to send a object to another Identity by its own. Instead,
 
 **Properties**
 
-| Name         | Type                | Required | Validation                                           |
-| ------------ | ------------------- | :------: | ---------------------------------------------------- |
-| `@type`      | `"StatementObject"` |    ✓     |                                                      |
-| `address`    | `string`            |    ✓     | The Address of the Identity that owns the statement. |
-| `attributes` | `string []`         |    ✗     | see [`Identity Attributes`](#identity-attributes)    |
+| Name         | Type                | Required | Validation                                                                                                           |
+| ------------ | ------------------- | :------: | -------------------------------------------------------------------------------------------------------------------- |
+| `@type`      | `"StatementObject"` |    ✓     |                                                                                                                      |
+| `address`    | `string`            |    ✓     | The `address` of the [Identity]({% link _docs_integrate/data-model-overview.md %}#identity) that owns the statement. |
+| `attributes` | `string []`         |    ✗     | see [`Identity Attributes`](#identity-attributes)                                                                    |
 
 ## StatementPredicate
 
@@ -611,11 +611,11 @@ It is not recommended to send a subject to another Identity by its own. Instead,
 
 **Properties**
 
-| Name         | Type                 | Required | Validation                                           |
-| ------------ | -------------------- | :------: | ---------------------------------------------------- |
-| `@type`      | `"StatementSubject"` |    ✓     |                                                      |
-| `address`    | `string`             |    ✓     | The Address of the Identity that owns the statement. |
-| `attributes` | `string []`          |    ✗     | see [`Identity Attributes`](#identity-attributes)    |
+| Name         | Type                 | Required | Validation                                                                                                           |
+| ------------ | -------------------- | :------: | -------------------------------------------------------------------------------------------------------------------- |
+| `@type`      | `"StatementSubject"` |    ✓     |                                                                                                                      |
+| `address`    | `string`             |    ✓     | The `address` of the [Identity]({% link _docs_integrate/data-model-overview.md %}#identity) that owns the statement. |
+| `attributes` | `string []`          |    ✗     | see [`Identity Attributes`](#identity-attributes)                                                                    |
 
 ## Street
 

diff --git a/_docs_integrate/create-attributes-for-peer.md b/_docs_integrate/create-attributes-for-peer.md
@@ -60,7 +60,7 @@ The following table provides an overview of the possible kinds of Attributes tha
 
 ### Example of creating an IdentityAttribute
 
-We assume that the Integrator of the Sender wants to create an IdentityAttribute of type [EMailAddress]({% link _docs_integrate/attribute-values.md %}#emailaddress) for the Recipient. To request the creation of this IdentityAttribute, the Sender needs to insert it into the `attribute` property of the [CreateAttributeRequestItem]({% link _docs_integrate/data-model-overview.md %}#createattributerequestitem) contained within the `items` property of the [Request]({% link _docs_integrate/data-model-overview.md %}#request) for creating Attributes. As the IdentityAttribute should be owned by the Recipient, an empty string is specified for its `owner` property. If the Sender sends the corresponding [Request via a Message]({% link _docs_integrate/create-attributes-for-peer.md %}#request-via-message), the Address of the Recipient could alternatively be specified explicitly. In our example, we have chosen to set the value of the `mustBeAccepted` property of the CreateAttributeRequestItem to `true`. Please note that the `<...>` notation is used as a placeholder for the actual data as usual.
+We assume that the Integrator of the Sender wants to create an IdentityAttribute of type [EMailAddress]({% link _docs_integrate/attribute-values.md %}#emailaddress) for the Recipient. To request the creation of this IdentityAttribute, the Sender needs to insert it into the `attribute` property of the [CreateAttributeRequestItem]({% link _docs_integrate/data-model-overview.md %}#createattributerequestitem) contained within the `items` property of the [Request]({% link _docs_integrate/data-model-overview.md %}#request) for creating Attributes. As the IdentityAttribute should be owned by the Recipient, an empty string is specified for its `owner` property. If the Sender sends the corresponding [Request via a Message]({% link _docs_integrate/create-attributes-for-peer.md %}#request-via-message), the address of the Recipient could alternatively be specified explicitly. In our example, we have chosen to set the value of the `mustBeAccepted` property of the CreateAttributeRequestItem to `true`. Please note that the `<...>` notation is used as a placeholder for the actual data as usual.
 
 ```jsonc
 {
@@ -95,7 +95,7 @@ We now consider the case in which the Sender has an active [Relationship]({% lin
       "mustBeAccepted": true,
       "attribute": {
         "@type": "RelationshipAttribute",
-        "owner": "<Address of Sender>",
+        "owner": "<address of Sender>",
         "key": "<key of RelationshipAttribute>",
         "confidentiality": "public",
         "value": {