Skip to content

Commit

Permalink
Merge branch 'main' into enhance-base-proof
Browse files Browse the repository at this point in the history
  • Loading branch information
Wind4Greg authored Feb 5, 2024
2 parents 5491407 + 70c312e commit 6dcad09
Showing 1 changed file with 63 additions and 38 deletions.
101 changes: 63 additions & 38 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -80,13 +80,6 @@
alternateFormats: [ {uri: "diff-20111214.html", label: "diff to previous version"} ],
*/
localBiblio: {
"RDF-DATASET-NORMALIZATION": {
title: "RDF Dataset Normalization 1.0",
href: "http://json-ld.github.io/normalization/spec/",
authors: ["David Longley", "Manu Sporny"],
status: "CGDRAFT",
publisher: "JSON-LD Community Group"
},
"RDF-CONCEPTS": {
title: "RDF 1.1 Concepts and Abstract Syntax",
href: "https://www.w3.org/TR/rdf11-concepts/",
Expand Down Expand Up @@ -209,7 +202,8 @@
}
},
lint: {"no-unused-dfns": false},
postProcess: [restrictRefs]
postProcess: [restrictRefs],
xref: [ "i18n-glossary" ]
};
</script>
<style>
Expand Down Expand Up @@ -284,8 +278,8 @@ <h2>Introduction</h2>
<p>
Applying the BBS signature scheme to verifiable credentials involves the
processing specified in this document.
In general the suite uses the RDF Dataset Normalization Algorithm
[[RDF-DATASET-NORMALIZATION]] to transform an input document into its canonical
In general the suite uses the RDF Dataset Canonicalization Algorithm
[[RDF-CANON]] to transform an input document into its canonical
form. An issuer then uses selective disclosure primitives to separate the
canonical form into mandatory and non-mandatory statements. These are processed
separately with other information to serve as the inputs to the BBS `Sign`
Expand All @@ -296,7 +290,7 @@ <h2>Introduction</h2>
</p>
<p>
Similarly, on receipt of a BBS signed credential, a holder uses the RDF Dataset
Normalization Algorithm [[RDF-DATASET-NORMALIZATION]] to transform an input
Canonicalization Algorithm [[RDF-CANON]] to transform an input
document into its canonical form, and then applies selective disclosure
primitives to separate the canonical form into mandatory and selectively
disclosed statements, which are appropriately processed and serve as inputs to
Expand Down Expand Up @@ -426,6 +420,11 @@ <h2>Proof Representations</h2>
<section>
<h3>DataIntegrityProof</h3>

<p>
A proof contains the attributes specified in the
<a href="https://www.w3.org/TR/vc-data-integrity/#proofs">Proofs section</a>
of [[VC-DATA-INTEGRITY]] with the following restrictions.
</p>
<p>
The `verificationMethod` property of the proof MUST be a URL.
Dereferencing the `verificationMethod` MUST result in an object
Expand All @@ -440,17 +439,8 @@ <h3>DataIntegrityProof</h3>
The `cryptosuite` property of the proof MUST be `bbs-2023`.
</p>
<p>
The `created` property of the proof MUST be an [[XMLSCHEMA11-2]]
formatted date string.
</p>
<p>
The `proofPurpose` property of the proof MUST be a string, and MUST
match the verification relationship expressed by the verification method
`controller`.
</p>
<p>
The value of the `proofValue` property of the proof MUST be an BBS signature or
BBS proof produced according to [[CFRG-BBS-SIGNATURE]] then serialized and encoded
The value of the `proofValue` property of the proof MUST be a BBS signature or
BBS proof produced according to [[CFRG-BBS-SIGNATURE]] that is serialized and encoded
according to procedures in section <a href="#algorithms"></a>.
</p>
</section>
Expand Down Expand Up @@ -546,6 +536,13 @@ <h4>createShuffledIdLabelMapFunction</h4>
</li>
</ol>

<p class="note informative">
It should be noted that step 1.2 in the above algorithm is identical to step 1.2
in <a href="https://www.w3.org/TR/vc-di-ecdsa/#createhmacidlabelmapfunction">
Section 3.3.4 `createHmacIdLabelMapFunction`</a> of [[DI-ECDSA]],
so developers might be able to reuse the code or call the function if implementing
both.
</p>
</section>


Expand Down Expand Up @@ -600,8 +597,13 @@ <h4>parseBaseProofValue</h4>

<ol class="algorithm">
<li>
Ensure the `proofValue` string starts with `u`, indicating that it is a
multibase-base64url-no-pad-encoded value, and throw an error if it does not.
Ensure the `proofValue` string starts with
<span class="codepoint" translate="no">
<bdi lang="en"><code title="LATIN SMALL LETTER U">u</code></bdi>
(<code class="codepoint">U+0075</code>
<code class="uname">LATIN SMALL LETTER U</code>)</span>,
indicating that it is a `multibase-base64url-no-pad-encoded` value, and throw
an error if it does not.
</li>
<li>
Initialize `decodedProofValue` to the result of base64url-no-pad-decoding the
Expand All @@ -613,8 +615,8 @@ <h4>parseBaseProofValue</h4>
</li>
<li>
Initialize `components` to an array that is the result of CBOR-decoding the
bytes that follow the three-byte ECDSA-SD base proof header. Ensure the result
is an array of five elements.
bytes that follow the three-byte BBS base proof header. Ensure the result
is an array of three elements.
</li>
<li>
Return an object with properties set to the five elements, using the names
Expand Down Expand Up @@ -711,10 +713,9 @@ <h4>createDisclosureData</h4>
</li>
</ol>
</li>

<li>
Initialize `bbsMessages` to an array of byte arrays obtained from the
UTF-8 encoding of the the values in the `nonMandatory` array.
Initialize `bbsMessages` to an array of byte arrays containing the values in the
`nonMandatory` array of strings encoded using the <a>UTF-8</a> <a>character encoding</a>.
</li>

<li>
Expand Down Expand Up @@ -861,21 +862,26 @@ <h4>parseDerivedProofValue</h4>
The following algorithm parses the components of the derived proof value.
The required input is a derived proof value (<var>proofValue</var>). A
A single <em>derived proof value</em> value object is produced as output, which
contains a set of five elements, using the names "bbsProof", "labelMap",
"mandatoryIndexes", and "selectiveIndexes".
contains a set of four elements, using the names "`bbsProof`", "`labelMap`",
"`mandatoryIndexes`", and "`selectiveIndexes`".
</p>

<ol class="algorithm">
<li>
Ensure the `proofValue` string starts with `u`, indicating that it is a
multibase-base64url-no-pad-encoded value, and throw an error if it does not.
Ensure the `proofValue` string starts with
<span class="codepoint" translate="no">
<bdi lang="en"><code title="LATIN SMALL LETTER U">u</code></bdi>
(<code class="codepoint">U+0075</code>,
<code class="uname">LATIN SMALL LETTER U</code>)</span>, indicating that
it is a `multibase-base64url-no-pad-encoded` value, and throw an error if it does
not.
</li>
<li>
Initialize `decodedProofValue` to the result of base64url-no-pad-decoding the
substring that follows the leading `u` in `proofValue`.
</li>
<li>
Ensure that the `decodedProofValue` starts with the ECDSA-SD disclosure proof
Ensure that the `decodedProofValue` starts with the BBS disclosure proof
header bytes `0xd9`, `0x5d`, and `0x03`, and throw an error if it does not.
</li>
<!-- [bbsProof, labelMapCompressed, mandatoryIndexes, adjSelectedIndexes] -->
Expand All @@ -892,7 +898,7 @@ <h4>parseDerivedProofValue</h4>
second element of `components` as `compressedLabelMap`.
</li>
<li>
Return <em>derived proof value</em> as an object with properties set to the five
Return <em>derived proof value</em> as an object with properties set to the four
elements, using the names "`bbsProof`", "`labelMap`", "`mandatoryIndexes`", and
"`selectiveIndexes`" respectively.
</li>
Expand Down Expand Up @@ -1212,8 +1218,8 @@ <h4>Base Proof Serialization (bbs-2023)</h4>
that order.
</li>
<li>
Initialize `bbsMessages` to an array of byte arrays obtained from the
UTF-8 encoding of the the values in the `nonMandatory` array.
Initialize `bbsMessages` to an array of byte arrays containing the values in the
`nonMandatory` array of strings encoded using the <a>UTF-8</a> <a>character encoding</a>.
</li>
<li>
Compute the `bbsSignature` using the `Sign` procedure of [[CFRG-BBS-Signature]]
Expand Down Expand Up @@ -1669,7 +1675,7 @@ <h3>Selective Disclosure and Data Leakage</h3>
(nesting, map, or array position, etc.) by using JSON-LD processing to transform
inputs into RDF. RDF can then be expressed as a canonical, flat format of simple
subject, property, value statements (referred to as claims in the Verifiable
Credentials Data Model [[VC-DATA-MODEL-2]]). In the following, we examine RDF
Credentials Data Model [[VC-DATA-MODEL-2.0]]). In the following, we examine RDF
canonicalization, a general scheme for mapping a verifiable credential in
JSON-LD format into a set of <em>statements</em> (BBS <em>messages</em>), for
selective disclosure. We show that after this process is performed, there
Expand Down Expand Up @@ -2010,6 +2016,25 @@ <h4>Linkage via VC Processing</h4>
simple.
</p>
</section>
<section>
<h4>Linkage via JSON-LD Node Identifiers</h4>
<p>
JSON-LD is a JSON-based format for serialization of Linked Data. As such, it supports
assigning a globally unambiguous `@id` attribute (node identifier) to each object
("node", in JSON-LD terminology) within a document. This allows for <q>the linking
of linked data</q>, enabling information about the same entity to be correlated.
This correlation can be desirable or undesirable, depending on the use case.
</p>
<p>
When using BBS for its unlinkability feature, globally unambiguous node
identifiers cannot be used for individuals nor for their personally identifiable
information, since the strong linkage they provide is undesirable. Note that the
use of such identifiers is acceptable when expressing statements about non-personal
information (e.g., using a globally unambiguous identifier to identify a large
country or a concert event). Also note that JSON-LD's use of `@context`, which
maps terms to IRIs, does not generally affect unlinkability.
</p>
</section>
<section>
<h4>Linkage via Proof Options and Mandatory Reveal</h4>
<p>
Expand Down

0 comments on commit 6dcad09

Please sign in to comment.