Accessibility Self-Review for VC DI BBS

[Wind4Greg]

The following is an Accessibility Self-Review for BBS Cryptosuite v2023: Securing Verifiable Credentials with Selective Disclosure using BBS Signatures. This specification is for a cryptographic message securing mechanism and thus do not contain text, visuals, audio, or haptic data that will be experienced directly by a human being. The one exception for this is possibly software developers, who might encounter error messages when using software libraries that implement the specification above. The errors have specific codes, which are internationalizable, but whose internationalization characteristics are up to each implementer.

We believe that these specifications, in general, do not create accessibility concerns, but are curious to know if we have overlooked some aspect of how these technologies will be used that will create accessibility issues.

The following self-review question categories were analyzed and resulted in the following answers:

• The technology DO NOT allow for visual rendering of content
• The technology DO NOT provide author control over color
• The technologies DO NOT provide features to accept user input
• The technologies DO NOT provide user interaction features
• The technologies DO NOT define document semantics
• The technologies DO NOT provide time-based visual media
• The technologies DO NOT provide audio
• The technologies DO NOT allow time limits
• The technologies DO NOT allow text content
• The technologies DO NOT create objects that don't have an inherent text representation
• The technologies DO NOT provide content fallback mechanisms, whether text or other formats
• The technologies DO NOT provide visual graphics
• The technologies DO provide internationalization support
  • Accessibility features can be internationalized to the same degree as other features
    • Specifically, the created date for a proof is expressed using XML Schema 1.1 where the date can be localized and made accessible given the nature of XML Schema 1.1 date time values.
• The technologies DO NOT define accessible alternative features
• The technologies DO NOT provide content directly for end-users
• The technologies DO NOT define an API
• The technologies DO NOT define a transmission protocol

Note that this self review is for a specification very similar to that of the recent accessibility reviewed verifiable credential data integrity specifications listed below:

• Verifiable Credential Data Integrity
• Data Integrity EdDSA Cryptosuites v1.0
• Data Integrity ECDSA Cryptosuites v1.0

[matatk]

Hi @Wind4Greg. We (the APA WG) are reviewing the spec. Thank you for providing the self-review info. We have a question regarding the created date. As you mention, the spec requires this to be an XML-SCHEMA formatted date string. Here are a couple of questions...

1. What's the rationale for using date-time strings, rather than a numerical timestamp that represents a date-time in UTC?
2. Is it required that the date-time strings always represent a time in UTC? (The examples all seem to be UTC, but the standard allows for other time zones to be used.)
3. Assuming that date-time strings are being used in order to be human readable, where do you see these being exposed to people to read?

I found a nit regarding the dates: sec 2.2.1 DataIntegrityProof states:

The created property of the proof MUST be an [XMLSCHEMA11-2] formatted date string.

...but the examples given in the spec all seem to be dateTime strings, not date strings. Other parts of the spec refer to dateTime rather than just date.

[Wind4Greg]

Hi @matatk thanks for starting the review. Concerning the created property. You found an error, this should be an [XMLSCHEMA11-2] dateTimeStamp string as defined in the VC Data Integrity Specification. I'll be putting in a PR to reference back to that specification rather than redefining it here.

In a discussion on issue https://github.com/w3c/vc-di-bbs/issues/114 @aphillips recommended language for adding time zones. Once again would want to roll this into the VC-Data-Integrity specification where created is originally defined.

On your item 3: a verifiable credential generally is processed in software with an end user holding it in a wallet, while one can directly inspect the JSON the wallet would generally render the credential into a human readable form. Note that VC-DI-BBS is one of a number of specific signature schemes that fall under the VC Data Integrity framework.

Yes, all the examples in the specification use dateTime and not date.

[matatk]

Thanks for the info @Wind4Greg - this, and the changes you've made, make sense to me.

There is one thing I'm still not 100% clear on, though it seems like it is probably outside the scope of accessibility: if the created field is indeed meant for machine-to-machine communication only (except for debugging) I would imagine it's simpler to specify that they must (rather than should) be in UTC - am I correct that they're not going to be presented to end users directly? (From your reply, that appears to be the case.)

[aphillips]

I would imagine it's simpler to specify that they must (rather than should) be in UTC

Some systems generate values that use a given UTC offset and some libraries might generate offset-based time serializations. All ISO8601 format strings, when parsed, result in time values that are in the UNIX epoch (millis or seconds or whatever since January 1, 1970 in UTC) and libraries that parse such strings are set up to consume the offset seamlessly. You're correct that the resulting value will almost certainly be formatted before it is displayed to a user, possibly using their local time zone. What we want to avoid are strings with no offset (which includes Z to indicate UTC) and which are also not in UTC. Requiring UTC would mean an additional check step or possible point of failure in cases where the implementer is using a library they didn't write.

[Wind4Greg]

Thanks @matatk and @aphillips for the illuminating discussion! The PR for the VC data integrity draft on this is https://github.com/w3c/vc-data-integrity/pull/240.

[msporny]

The a11y review was completed a while ago, the document is in CR, there don't seem to be any further actions required by the WG. Closing. Re-open if anyone in this thread disagrees.