diff --git a/index.html b/index.html index bf67e5877..06c003418 100644 --- a/index.html +++ b/index.html @@ -1990,90 +1990,13 @@

Securing Mechanisms

This specification recognizes two classes of securing mechanisms: those that use enveloping proofs and those that use embedded proofs. An enveloping proof is one that wraps a serialization of -this data model. One such enveloping proof mechanism is JSON Web Token, -which is elaborated on in the [[[VC-JOSE-COSE]]] [[VC-JOSE-COSE]] -specification. An embedded proof is a mechanism where -the proof is included in the data model, using the extension point -defined in Section . One such embedded proof mechanism +this data model. One such enveloping proof mechanism is elaborated on in the +[[[VC-JOSE-COSE]]] [[VC-JOSE-COSE]] specification. An +embedded proof is a mechanism where +the proof is included in the data model. One such embedded proof mechanism is [[[VC-DATA-INTEGRITY]]] [[VC-DATA-INTEGRITY]]. These two classes of securing -mechanisms are not mutually exclusive. -

- -

-Securing mechanism specifications other than those -referred to above might also be defined, as necessary. -

- -

-Securing mechanism specifications MUST document normative algorithms that -provide content integrity protection for [=conforming documents=]. The -algorithms MAY be general in nature and MAY be used to secure data other than -[=conforming documents=]. -

- -

-Securing mechanism specifications MUST provide a verification mechanism that -returns only the information in the [=conforming document=] that has been -secured, without any securing mechanism information included, such as `proof` or -JOSE/COSE metadata. Specifications MAY provide additional mechanisms to convey -other information that might be helpful (for example, during validation or for debugging -purposes), such as securing mechanism metadata. A securing mechanism's -verification algorithm MUST provide an interface that receives a sequence of -bytes ([=byte sequence=] |inputBytes|) or a document ([=map=] |inputDocument|) -and a media type ([=string=] |inputMediaType|) as inputs and returns a -verification result with at least the following [=struct/items=]: -

- -
-
[=boolean=] |status|
-
-A verification status whose value is `true` if the verification succeeded and -`false` if it did not. -
-
[=map=] |document|
-
-A document that only contains information that was successfully secured. -
-
[=string=] |mediaType|
-
-A media type as defined in [[RFC6838]]. -
-
[=string=] |controller|
-
-A verification method controller as defined in [[VC-CONTROLLER-DOCUMENT]]. -
-
[=map=] |controllerDocument|
-
-A controller document as defined in [[VC-CONTROLLER-DOCUMENT]]. -
-
- -

-Securing mechanism specifications SHOULD provide integrity protection for any -information referenced by a URL that is critical to validation. Mechanisms that -can achieve this protection are discussed in Section - and Section -. -

- -

-Securing mechanism specifications SHOULD register the securing mechanism in the -Securing Mechanisms section -of the [[[?VC-SPECS]]] [[?VC-SPECS]]. -

- -

-There are multiple acceptable securing mechanisms, and this specification does -not mandate any particular securing mechanism for use with -[=verifiable credentials=] or [=verifiable presentations=]. -The Working Group that produced this specification did standardize two -securing mechanism options, which are: -[[[VC-DATA-INTEGRITY]]] [[VC-DATA-INTEGRITY]] and [[[VC-JOSE-COSE]]] -[[VC-JOSE-COSE]]. Other securing mechanisms that are known to the community -can be found in the -Securing Mechanisms section -of the [[[?VC-SPECS]]] [[?VC-SPECS]]. +mechanisms are not mutually exclusive. Securing mechanism specifications other +than those referred to previously might also be defined, as necessary.

@@ -4046,6 +3969,91 @@

Verifiable Credential Graphs

+
+

Securing Mechanism Specifications

+ +

+As described in Section , there are +multiple strategies that an implementer can use when securing a +conforming document. In order to maximize utility and interoperability, +specification authors that desire to author new ways of securing +conforming documents are provided with the guidance in this section. +

+ +

+Securing mechanism specifications MUST document normative algorithms that +provide content integrity protection for [=conforming documents=]. The +algorithms MAY be general in nature and MAY be used to secure data other than +[=conforming documents=]. +

+ +

+Securing mechanism specifications MUST provide a verification mechanism that +returns only the information in the [=conforming document=] that has been +secured, without any securing mechanism information included, such as `proof` or +JOSE/COSE metadata. Specifications MAY provide additional mechanisms to convey +other information that might be helpful (for example, during validation or for +debugging purposes), such as securing mechanism metadata. A securing mechanism's +verification algorithm MUST provide an interface that receives a sequence of +bytes ([=byte sequence=] |inputBytes|) or a document ([=map=] |inputDocument|) +and a media type ([=string=] |inputMediaType|) as inputs and returns a +verification result with at least the following [=struct/items=]: +

+ +
+
[=boolean=] |status|
+
+A verification status whose value is `true` if the verification succeeded and +`false` if it did not. +
+
[=map=] |document|
+
+A document that only contains information that was successfully secured. +
+
[=string=] |mediaType|
+
+A media type as defined in [[RFC6838]]. +
+
[=string=] |controller|
+
+A verification method controller as defined in [[VC-CONTROLLER-DOCUMENT]]. +
+
[=map=] |controllerDocument|
+
+A controller document as defined in [[VC-CONTROLLER-DOCUMENT]]. +
+
+ +

+Securing mechanism specifications SHOULD provide integrity protection for any +information referenced by a URL that is critical to validation. Mechanisms that +can achieve this protection are discussed in Section + and Section +. +

+ +

+Securing mechanism specifications SHOULD register the securing mechanism in the +Securing Mechanisms section +of the [[[?VC-SPECS]]] [[?VC-SPECS]]. +

+ +

+There are multiple acceptable securing mechanisms, and this specification does +not mandate any particular securing mechanism for use with +[=verifiable credentials=] or [=verifiable presentations=]. +The Working Group that produced this specification did standardize two +securing mechanism options, which are: +[[[VC-DATA-INTEGRITY]]] [[VC-DATA-INTEGRITY]] and [[[VC-JOSE-COSE]]] +[[VC-JOSE-COSE]]. Other securing mechanisms that are known to the community +can be found in the +Securing Mechanisms section +of the [[[?VC-SPECS]]] [[?VC-SPECS]]. +

+ +
+