diff --git a/index.html b/index.html index e914dcb..6bf6e75 100644 --- a/index.html +++ b/index.html @@ -298,7 +298,7 @@

Driver's License Example

"issuer": "did:web:dmv.utopia.example", "credentialStatus": { "type": "TerseBitstringStatusListEntry", - "terseStatusListBaseUrl": "dmv.utopia.gov/statuses/12345/status-lists" + "terseStatusListBaseUrl": "https://dmv.utopia.gov/statuses/12345/status-lists" "terseStatusListIndex": 123567890 }, "credentialSubject": { @@ -451,13 +451,14 @@

Terminology

Terms defined by cited specifications

Unicode code point order
-
This refers to determining the order of two Unicode strings (`A` and `B`), - using Unicode Codepoint Collation, - as defined in [[XPATH-FUNCTIONS]], - which defines a - total ordering - of strings comparing code points. - Note that for UTF-8 encoded strings, comparing the byte sequences gives the same result as code point order. +
+This refers to determining the order of two Unicode strings (`A` and `B`), +using Unicode Codepoint Collation, +as defined in [[XPATH-FUNCTIONS]], +which defines a +total ordering +of strings comparing code points. +Note that for UTF-8 encoded strings, comparing the byte sequences gives the same result as code point order.
@@ -533,9 +534,9 @@

OpticalBarcodeCredential

and the first 22 bits of the `signatureBitfield` value correspond to these fields. Each AAMVA mandatory field begins with a three character element ID (e.g. `DBA` for document expiration date). To construct a mapping between bits in the `signatureBitfield` value and these fields, sort these element IDs -according to Unicode code point order. Then, if a bit in position `i` of `signatureBitfield` is `1`, -the AAMVA mandatory field in position `i` of the sorted element IDs is digitally signed. The last two -bits in `signatureBitfield`MUST be `0`. For more information, see Section 3.5.4. +according to Unicode code point order. Then, if a bit in position `i` of `signatureBitfield` is `1`, the +AAMVA mandatory field in position `i` of the sorted element IDs is protected by the digital signature. The last two +bits in `signatureBitfield` MUST be `0`. For more information, see Section [[[#create-opticaldatahash]]].

@@ -590,6 +591,7 @@

TerseBitstringStatusListEntry

-To process a `TerseBitstringStatusListEntry`, apply the algorithm in -Section 3.4 to convert it to a `BitstringStatusListEntry`, +To process a `TerseBitstringStatusListEntry`, apply the algorithm in Section +[[[#convert-status-list-entries]]] to convert it to a `BitstringStatusListEntry`, then process it as in [[[VC-BITSTRING-STATUS-LIST]]].

-Implementers MUST set a value |listLength| for the length of an individual status list. This then yields +Implementers need to set a value |listLength| for the length of an individual status list. This then yields a number of status lists |listCount| = 2^32 / |listLength| for a 32-bit `terseStatusListIndex`. |listLength| is needed to convert from a `TerseBitstringStatusListEntry` to a `BitstringStatusListEntry`. -Noting that some values of |listLength| will harm the privacy-preserving properties of these status lists, it is -RECOMMENDED that implementations use |listLength| = 2^17 and |listCount| = 2^15. +Noting that some values of |listLength| will harm the privacy-preserving properties of these status lists, +implementations MUST use |listLength| = 2^17 and |listCount| = 2^15.

Encoding to and from barcodes

-While the credentials in this specification use CBOR-LD to efficiently encode Verifiable Credentials +While the credentials in this specification use CBOR-LD to efficiently encode [=verifiable credentials=] in a binary format, binary data is often inefficient or incompatible to turn into standard barcode -image formats directly. To that end, we provide recommendations here for +image formats directly. To that end, we provide requirements here for implementations.

-It is RECOMMENDED that implementers re-encode CBOR-LD encoded `UsDriversLicenseWithMandatoryFieldsPdf417Barcode` +It is REQUIRED that implementers character-encode CBOR-LD encoded `UsDriversLicenseWithMandatoryFieldsPdf417Barcode` credentials as base64url before encoding them in a PDF417.

-It is RECOMMENDED that implementers re-encode CBOR-LD encoded `CompleteMrzBarcode` credentials +It is REQUIRED that implementers re-encode CBOR-LD encoded `CompleteMrzBarcode` credentials as base32 with the string 'VC1-' prepended before encoding them in a QR code.

@@ -706,15 +708,15 @@

Credential Validation

Set |securedDocument| to the data in the PDF417 or MRZ.
  • -Set |verificationResult| to the result of applying the algorithm in -Section 3.2.2 to |securedDocument|. +Set |verificationResult| to the result of applying the algorithm in Section +[[[#verify-proof-ecdsa-xi-2023]]]to |securedDocument|.
  • Set |credential| to the `OpticalBarcodeCredential` in |securedDocument|.
  • -Set |statusListEntry| to the result of applying the algorithm in -Section 3.4 to |credential|. +Set |statusListEntry| to the result of applying the algorithm in Section +[[[#convert-status-list-entries]]] to |credential|.
  • Set |statusResult| to the result of applying the algorithm in @@ -750,14 +752,15 @@

    Convert Status List Entries

    Set |result| to be an empty [=map=].
  • -Set |listIndex| to ⌊|vc|.|credentialStatus|.|terseStatusListIndex|/|listLength|⌋. +Set |listIndex| to |vc|.|credentialStatus|.|terseStatusListIndex|/|listLength| rounded down +to the next lowest integer (i.e. apply the `floor()` operation).
  • Set |statusListIndex| to |vc|.|credentialStatus|.|terseStatusListIndex| % |listLength|.
  • -Set |result|.|statusListCredential| to -'${|vc|.|credentialStatus|.|terseStatusListBaseUrl|}/${|statusPurpose|}/${|listIndex|}'. +Set |result|.|statusListCredential| to the concatenation of the following values: +|vc|.|credentialStatus|.|terseStatusListBaseUrl|, '/', |statusPurpose|, '/', |listIndex|.
  • Set |result|.|type| to 'BitstringStatusListEntry'.