Revocation Semantics
revoked verification method, knowing whether a verification was made with a revoked [=verification method=] is trickier than it might seem. Some auditing systems provide the ability to look back at the state of an identifier at a -point in time, or at a particular version of the [=controllable identifier document=]. +point in time, or at a particular version of the [=controlled identifier document=]. When such a feature is combined with a reliable way to determine the time or identifier version that existed when a cryptographically verifiable statement was made, then revocation does not undo that statement. This can be the basis @@ -3307,7 +3307,7 @@Revocation Semantics
However, in order for such semantics to be safe, the second condition — an -ability to know what the state of the [=controllable identifier document=] was at the time +ability to know what the state of the [=controlled identifier document=] was at the time the assertion was made — is expected to apply. Without that guarantee, someone could discover a revoked key and use it to make cryptographically verifiable statements with a simulated date in the past. @@ -3361,17 +3361,17 @@
Encrypted Data in Controller Documents
Encryption algorithms have been known to fail due to advances in cryptography and computing power. Implementers are advised to assume that any encrypted data -placed in a [=controllable identifier document=] might eventually be made available in clear text +placed in a [=controlled identifier document=] might eventually be made available in clear text to the same audience to which the encrypted data is available. This is -particularly pertinent if the [=controllable identifier document=] is public. +particularly pertinent if the [=controlled identifier document=] is public.
-Encrypting all or parts of a [=controllable identifier document=] is not an appropriate +Encrypting all or parts of a [=controlled identifier document=] is not an appropriate means to protect data in the long term. Similarly, placing encrypted data in -a [=controllable identifier document=] is not an appropriate means to protect personal data. +a [=controlled identifier document=] is not an appropriate means to protect personal data.
-Given the caveats above, if encrypted data is included in a [=controllable identifier document=], +Given the caveats above, if encrypted data is included in a [=controlled identifier document=], implementers are advised to not associate any correlatable information that could be used to infer a relationship between the encrypted data and an associated party. Examples of correlatable information include @@ -3385,19 +3385,19 @@
Encrypted Data in Controller Documents
Content Integrity Protection
-[=Controllable identifier documents=] that include links to external machine-readable +[=Controlled identifier documents=] that include links to external machine-readable content such as images, web pages, or schemas are vulnerable to tampering. It is strongly advised that external links are integrity protected using mechanisms to secure related resources such as those described in the [[[?VC-DATA-MODEL-2.0]]] specification. External links are to be avoided if they cannot be integrity -protected and the [=controllable identifier document=]'s integrity is dependent on the +protected and the [=controlled identifier document=]'s integrity is dependent on the external link.
-One example of an external link where the integrity of the [=controllable identifier +One example of an external link where the integrity of the [=controlled identifier document=] itself could be affected is the JSON-LD Context [[JSON-LD11]], when present. To protect against compromise, -[=controllable identifier document=] consumers using JSON-LD are advised to cache +[=controlled identifier document=] consumers using JSON-LD are advised to cache local static copies of JSON-LD contexts and/or verify the integrity of external contexts against a cryptographic hash that is known to be associated with a safe version of the external JSON-LD Context. @@ -3409,8 +3409,8 @@
Integrity Protection of Controllers
As described in Section [[[#controllers]]], this specification includes a -mechanism by which to delegate change control of a [=controllable identifier document=] to -an entity that is described in an external [=controllable identifier document=] through the +mechanism by which to delegate change control of a [=controlled identifier document=] to +an entity that is described in an external [=controlled identifier document=] through the use of the `controller` property.
@@ -3421,7 +3421,7 @@Integrity Protection of Controllers
provide account recovery services, among other use cases. In such scenarios, it can be beneficial to allow the guardian to manage the rotation of their own key material. It can also be beneficial for the delegator to associate -a cryptographic hash of the remote [=controllable identifier document=] to "pin" the +a cryptographic hash of the remote [=controlled identifier document=] to "pin" the remote document to a known good value. @@ -3474,10 +3474,10 @@Level of Assurance
assertion and [=authentication=] might be used in some of these situations, information about the applied security context might need to be expressed and provided to a verifier. Whether and how -to encode this information in the [=controllable identifier document=] data model is out +to encode this information in the [=controlled identifier document=] data model is out of scope for this specification. Interested readers might note that 1) the information could be transmitted using Verifiable Credentials -[[?VC-DATA-MODEL-2.0]], and 2) the [=controllable identifier document=] data model can be +[[?VC-DATA-MODEL-2.0]], and 2) the [=controlled identifier document=] data model can be extended to incorporate this information.Level of Assurance
Service Endpoints for Authentication and Authorization
-If a [=controllable identifier document=] publishes a [=service=] intended for authentication +If a [=controlled identifier document=] publishes a [=service=] intended for authentication or authorization of the [=subject=] (see Section [[[#services]]]), it is the responsibility of the [=service=] provider, [=subject=], and/or requesting party to comply with the requirements of the authentication and/or authorization @@ -3500,16 +3500,16 @@
Service Endpoints for Authentication and Authorization
Privacy Considerations
-Since [=controllable identifier documents=] are designed to be administered directly by +Since [=controlled identifier documents=] are designed to be administered directly by the [=controller=], it is critically important to apply the principles of Privacy by Design [[PRIVACY-BY-DESIGN]] to all aspects of the -[=controllable identifier document=]. All seven of these principles have been applied +[=controlled identifier document=]. All seven of these principles have been applied throughout the development of this specification. The design used in this specification does not assume that there is a registrar, hosting company, nor other intermediate service provider to recommend or apply additional privacy safeguards. Privacy in this specification is preventive, not remedial, and is an embedded default. The following sections cover privacy considerations that -implementers might find useful when building systems that utilize [=controllable identifier +implementers might find useful when building systems that utilize [=controlled identifier documents=].
@@ -3517,13 +3517,13 @@Privacy Considerations
Keep Personal Data Private
-If a [=controllable identifier document=] is about a specific individual and is -public-facing, it is critical that [=controllable identifier documents=] contain +If a [=controlled identifier document=] is about a specific individual and is +public-facing, it is critical that [=controlled identifier documents=] contain no personal biometric or biographical data. While it is true that personal data might include pseudonymous information, such as a public cryptographic key or an IP address, publishing that sort of information does not create the same immediate privacy dangers as publishing an individual's full name, profile photo, or social media -account in a [=controllable identifier document=]. A better alternative is to transmit +account in a [=controlled identifier document=]. A better alternative is to transmit such personal data through other means such as verifiable credentials [[?VC-DATA-MODEL-2.0]] or other data formats sent over private and secure communication channels. @@ -3553,7 +3553,7 @@
Relationship to the Same-Origin Policy
(tracking). Those that use this specification are warned that there are trade-offs with each approach and to use the mechanism that maximizes security and privacy according to the needs of the individual or organization. Using a -[=controllable identifier document=] for all use cases is not always advantageous when a +[=controlled identifier document=] for all use cases is not always advantageous when a same-origin bound cryptographic key would suffice. @@ -3579,10 +3579,10 @@Controller Document Correlation Risks
The anti-correlation protections of [=pairwise identifiers=] are easily defeated -if the data in the corresponding [=controllable identifier documents=] can be correlated. For -example, using identical [=verification methods=] in multiple [=controllable identifier +if the data in the corresponding [=controlled identifier documents=] can be correlated. For +example, using identical [=verification methods=] in multiple [=controlled identifier documents=] can provide as much correlation information as using the same -identifier. Therefore, the [=controllable identifier document=] for a [=pairwise identifier=] +identifier. Therefore, the [=controlled identifier document=] for a [=pairwise identifier=] also needs to use pairwise unique information, such as ensuring that [=verification methods=] are unique to the pairwise relationship.
@@ -3592,7 +3592,7 @@Controller Document Correlation Risks
Subject Classification
-It is dangerous to add properties to the [=controllable identifier document=] that can be +It is dangerous to add properties to the [=controlled identifier document=] that can be used to indicate, explicitly or through inference, what type or nature of thing the [=subject=] is, particularly if the [=subject=] is a person.
@@ -3601,19 +3601,19 @@Subject Classification
[[[#keep-personal-data-private]]]) or correlatable data (see and [[[#controller-document-correlation-risks]]]) being present in -the [=controllable identifier document=], but they can be used for grouping particular +the [=controlled identifier document=], but they can be used for grouping particular identifiers in such a way that they are included in or excluded from certain operations or functionalities.-Including type information in a [=controllable identifier document=] can result +Including type information in a [=controlled identifier document=] can result in personal privacy harms even for [=subjects=] that are non-person entities, such as IoT devices. The aggregation of such information around a [=controller=] could serve as a form of digital fingerprint and this is best avoided.
-To minimize these risks, all properties in a [=controllable identifier document=] ought to +To minimize these risks, all properties in a [=controlled identifier document=] ought to be for expressing [=verification methods=] and verification relationships related to using the identifier.
@@ -3623,22 +3623,22 @@Subject Classification
Service Privacy
-The ability for a [=controller=] to optionally express at least one [=service=] in the [=controllable identifier document=] increases their control and agency. -Each additional endpoint in the [=controllable identifier document=] adds privacy risk either +The ability for a [=controller=] to optionally express at least one [=service=] in the [=controlled identifier document=] increases their control and agency. +Each additional endpoint in the [=controlled identifier document=] adds privacy risk either due to correlation, such as across endpoint descriptions, or because the [=services=] are not protected by an authorization mechanism, or both.
-[=Controllable identifier documents=] are often public and, since they are standardized, will +[=Controlled identifier documents=] are often public and, since they are standardized, will be stored and indexed efficiently. This -risk is increased if [=controllable identifier documents=] are published to immutable -[=verifiable data registries=]. Access to a history of the [=controllable identifier +risk is increased if [=controlled identifier documents=] are published to immutable +[=verifiable data registries=]. Access to a history of the [=controlled identifier documents=] referenced by a URL enables a form of traffic analysis made more efficient through the use of standards.
The degree of additional privacy risk caused by including multiple [=services=] in -one [=controllable identifier document=] can be difficult to estimate. Privacy harms are +one [=controlled identifier document=] can be difficult to estimate. Privacy harms are typically unintended consequences. URLs can refer to documents, [=services=], schemas, and other things that might be associated with individual people, households, clubs, and employers — and correlation of their [=services=] @@ -3706,7 +3706,7 @@
IANA Considerations
application/cid
This specification registers the `application/cid` media type specifically for -identifying documents conforming to the [=controllable identifier document=] +identifying documents conforming to the [=controlled identifier document=] format.