Ensure that status messages are committed to at issuance time.

[msporny]

This PR is an attempt to address issue #151 by requiring that status messages are committed to by issuers at issuance time. The PR does this by:

• Moving the statusSize, statusMessage, and statusReference fields to the BitstringStatusListEntry object.
• Explaining why the commitment is done at issuance time on the original VC itself.

NOTE TO REVIEWERS: Most of the changes in this PR are just moving text around in the spec. The only normative change is the first bullet item above. Everything else should be editorial. It looks like way more changed than it did.

I believe, if this PR is accepted, that it should address @jandrieu and PINGs concerns regarding the issuer changing the types of status messages that are possible without the holder or subjects knowledge.

---

Preview | Diff

[dlongley]

Suggested change

	array of URLs. Implementers using a `statusPurpose` of `status` are strongly
	array of URLs. Implementers using a `statusPurpose` of `message` are strongly

[dlongley]

How can these messages be committed to for users if they are not to be displayed or understood by them?

[msporny]

There is a presumption here that the user software will convert the value into something internationalized for the individual based on its programmatic value.

I do think that's excessively hand-wavy, given that the issuer could just do that work here, but given that the Traceability group wants it to work this way, and that there are no other strong opinions on how it should work, the text that's in the spec is the best we have at present.

[dlongley]

Does statusReference pose a privacy problem in the same way that uncommitted messages might? Perhaps a hash is also required (e.g., statusReference: {id: "https://example.com/foo", digestMultibase: "<hash>"}?

If statusReference were committed to via a hash, the statusMessage array could potentially be omitted entirely. This might be more attractive than always including all possible messages, now that they must be present in the VC itself. This may also help address the i18n + commitment issue (that I think might exist now as mentioned above) because a more rich response can be returned in the status reference document.

[mprorock]

could we just treat this identical to an external reference as in the core data model?

[dlongley]

I think that's the basic idea, it was just being given a more specific relationship name since it's well known how it relates.

[msporny]

I thought the statusReference was human-readable documentation, and so committing to it using a hash would prevent it being updated in ways that would harm readability?

Again, the design here is strange in that we have a unique value for each message (statusMessage.status), but then we have another "developer value" (statusMessage.message), that could just as easily live in statusReference (if it were a machine-readable file).

It's up to Traceability folks if they want to change the design to something simpler. I'm not going to let that hold up this PR.

[TallTed]

There's some difficulty of alignment between "status types" which are here blurred with "statusPurposes". "Revocation" and "suspension" are fine "status purposes", but they're terrible "status types". "Revoked" and "suspended" are OK "status types" (or "status statuses"), but terrible "status purposes". Maybe these "purposes" are associated with BitStringStatusLists, rather than with Statuses, per se? Partial text patch below; conversation may lead to modifications/additions.

Suggested change

	Status list entries can be used to associate a single status type,
	such as `revocation` or `suspension`, with a [=verifiable credential=] by using
	the `statusPurpose` property. The example below demonstrates the association
	of simple status list entries:
	Status list entries can be used to associate a single status type,
	such as `revocation` or `suspension`, with each [=verifiable credential=]
	by using the `statusPurpose` property. The example below demonstrates the
	association of simple status list entries:

[dlongley]

"a status type" => "a status purpose"?

[dlongley]

My review below includes a suggestion that incorporates Ted's suggestion with some edits.

[TallTed]

Suggested change

	Status list entries can be used to associate many status types with a
	[=verifiable credential=] by using the `message` status purpose. The set of
	messages associated with a particular entry is committed to by the [=issuer=]
	by using the `statusSize`, `statusMessage`, and optional `statusReference`
	properties. This commitment is done at the time of issuance to ensure that
	the [=holder=] knows what sort of information might be associated with a
	particular [=verifiable credential=] that is in their possession, and would
	then be discoverable by a [=verifier=] that receives that credential.
	Status list entries can be used to associate multiple status types with a
	[=verifiable credential=] through the single `message` status purpose. The
	[=issuer=] commits to the set of messages that may be associated with a
	particular entry (i.e., with a particular [=verifiable credential=]) through
	the `statusSize`, `statusMessage`, and optional `statusReference` properties,
	at the time of [=verifiable credential=] issuance. This is to ensure that
	the [=holder=] knows what sort of information might be associated with a
	particular [=verifiable credential=] they keep in their possession, that
	could then be discoverable by a [=verifier=] that later receives that
	credential.

[dlongley]

So "message" is just another "status purpose", it doesn't enable "multiple status types" (I don't think). It is just the case that just about any "message" about the status of a credential can be expressed. The purpose of a "message" status list expands to: "to express a specific message (one from a list of precommitted messages) describing the status of a credential". We should probably just avoid saying "status type" and stick to "status purpose".

So we have:

1. A status purpose of "revocation", which means that a status list is used to express the revocation status of a particular credential.
2. A status purpose of "suspension", which means that a status list is used to express the suspension status of a particular credential.
3. A status purpose of "message", which means that a status list is used to express a specific message, from a predefined list of messages, describing the status of a particular credential.

[dlongley]

Maybe some text like this can be incorporated into the suggestions above:

Status list entries can be used to express the purpose of a
status associated with a [=verifiable credential=] by using the
`statusPurpose` property.

The use of `revocation` or `suspension` as the status purpose
includes the semantics of the status, with `revocation`
indicating that a status bit expresses whether a
[=verifiable credential=] has been revoked and `suspension`
indicating that a status bit expresses whether a
[=verifiable credential=] has been suspended:

/* revocation and suspension examples */

The use of `message` as the status purpose enables an issuer to
define an arbitrary number of custom, descriptive messages about
the status of the [=verifiable credential=]. The [=issuer=] commits...
...

[dlongley]

I added a suggestion below (in my review) that attempts to combine Ted's suggestion with my own.

[brentzundel]

approved with Ted's suggested changes

[msporny]

Normative, multiple reviews, changes requested and made, no objections (but non-blocking design concerns raised), merging.