vc-di-bbs
vc-di-bbs copied to clipboard
w3c
Internationalization Review for VC DI BBS
This review is for the BBS Cryptosuite v2023: Securing Verifiable Credentials with Selective Disclosure using BBS Signatures, a cryptosuite implementation for Verifiable Credential Data Integrity
- [x] If the spec (or its implementation) contains any natural language text that will be read by a human (this includes error messages or other UI text, JSON strings, etc, etc), ensure that there’s metadata about and support for basic things such as language and text direction. Also check the detailed guidance for Language and Text direction.
- [ ] Not applicable
The specification is a cryptographic message securing mechanism and thus does not contain text that will be read by a human being. The one exception for this is possibly software developers, who might see error messages, which have specific codes, which are internationalizable, but whose internationalization characteristics are up to each implementer.
- [ ] If the spec (or its implementation) allows content authors to produce typographically appealing text, either in its own right, or in association with graphics. take into account the different typographic styles used around the world (for things such as line-breaking, text justification, emphasis or other text decorations, text selection and units, etc.) Also check the detailed guidance for Typographic support.
- [x] Not applicable
The specification is cryptographic message securing mechanism and thus does not provide the features described in the paragraph above.
- [ ] If the spec (or its implementation) allows the user to point into text, creates text fragments, concatenates text, allows the user to select or step through text (using a cursor or other methods), etc. make allowances for the ways different scripts handle units of text. Also check the detailed guidance for Text-processing.
- [x] Not applicable
The specification is cryptographic message securing mechanism and thus does not provide the features described in the paragraph above.
- [ ] If the spec (or its implementation) allows searching or matching of text, including syntax and identifiers understand the implications of normalisation, case folding, etc. Also check the detailed guidance for Text-processing.
- [x] Not applicable
The specification is a cryptographic message securing mechanism and thus does not provide the features described in the paragraph above.
- [ ] If the spec (or its implementation) sorts text ensure that it does so in locally relevant ways. Also check the detailed guidance for Text-processing.
- [x] Not applicable
The specification is a cryptographic message securing mechanism and thus does not provide the features described in the paragraph above, i.e., (a) the spec doesn't define text ordering and (b) because the RDF Dataset Canonicalization specification work doesn't define a human-visible ordering (it uses code point order).
- [ ] If the spec (or its implementation) captures user input ensure that it also captures metadata about language and text direction, and that it accommodates locale-specific input methods.
- [x] Not applicable
The specification is a cryptographic message securing mechanisms and thus does not provide the features described in the paragraph above.
- [x] If the spec (or its implementation) deals with time in any way that will be read by humans and/or crosses time zone boundaries ensure that it will represent time as expected in locales around the world, and manage the relationship between local and global/absolute time. Also check the detailed guidance for Local dates, times and formats.
- [ ] Not applicable
Dates and times are used when expressing the creation and validity periods for Data Integrity proofs. For these fields, we use XML Schema 1.1 date-time format.
- [ ] If the spec (or its implementation) allows any character encoding other than UTF-8. make sure you have a convincing argument as to why, and then ensure that the character encoding model is correct. Also check the detailed guidance for Characters.
- [x] Not applicable
All character encoding for all cryptographic suites use UTF-8 for text encoding.
- [ ] If the spec (or its implementation) defines markup ensure support for internationalisation features and avoid putting human-readable text in attribute values or plain-text elements. Also check the detailed guidance for Markup & syntax.
- [x] Not applicable
The specification is a cryptographic message securing mechanisms and thus does not provide the features described in the paragraph above.
- [] If the spec (or its implementation) deals with names, addresses, time & date formats, etc ensure that the model is flexible enough to cope with wide variations in format, levels of data, etc. Also check the detailed guidance for Local dates, times and formats.
- [x] Not applicable
This specification does not introduce any new date/time formats beyond those in the Verifiable Credential Data Integrity.
- [ ] If the spec (or its implementation) describes a format or data that is likely to need localization. ensure that there’s an approach in place which allows effective storage and labelling of, and access to localised alternatives for strings, text, images, etc.
- [x] Not applicable
The specification is a cryptographic message securing mechanism and thus does not require localization (other than potential error messages and dates, which have been detailed above).
- [ ] If the spec (or its implementation) makes any reference to or relies on any cultural norms ensure that it can be adapted to suit different cultural norms around the world (ranging from depictions of people or gestures, to expectations about gender roles, to approaches to work and life, etc).
- [x] Not applicable
The specification is a cryptographic message securing mechanism and thus does not provide the features described in the paragraph above.
Note: This review is very similar to that of the following specifications that have recently undergone i18n review, the first being the base data integrity specification, and the latter two being specific cryptosuite implementations of the base specification:
- Verifiable Credential Data Integrity
- Data Integrity EdDSA Cryptosuites v1.0
- Data Integrity ECDSA Cryptosuites v1.0
Thank you for completing a self-review!
A few comments on the above:
One minor caveat to this is the RDF Dataset Canonicalization mechanism (which will undergo a separate i18n review), which is concerned with string ordering when canonicalizing data sets. That feature, however, isn't covered by these specifications, but rather, the RDF Dataset Canonicalization specification.
Your self-review should indicate that this is not-applicable to your specification, partly because (a) you don't define text ordering and (b) because the RDF-star work doesn't define a human-visible ordering (it uses code point order). This section is about features such as putting a list of credentials into "alphabetical" order.
Dates and times are used when expressing the creation and validity periods for Data Integrity proofs. For these fields, we use XML Schema 1.1 date-time format.
We've covered the time zone, offset, and other serialization issues in the VC data integrity spec. If your spec introduces any new datetime related fields, pointers to or replication of health warning and such found there might be useful. We look forward to a successful I18N review.
By the way... did you intend to request an I18N review? If so, please visit our I18N request repo to create a request. This self-review is not sufficient to trigger a review.
Thanks @aphillips! I'm getting ready for all the reviews. However, there are two PRs (security considerations, and privacy considerations) that I'm waiting to merge before formally asking for any reviews. I'll update the self review per your recommendations prior to putting in the request.
Hi @aphillips updated self review per your comments. Will be formally asking for the review soon. Thanks!
