Add section on Processing Errors.

[msporny]

This PR attempts to address issue #64 by adding a section about processing errors and including how one can respond over HTTP if the APIs are exposed over HTTP.

---

Preview | Diff

[dlongley]

Maybe this should be STATUS_VERIFICATION_ERROR instead? Same for each other use of this error; it seems they may just be about verifying the data is authentic and proper vs. business rules around accepting the status information.

[TallTed]

I think the status fails to validate.

What the verifier chooses to do about that failure is then a business rules question.

[dlongley]

Ok, I can support that mental model.

[David-Chadwick]

I would just like to check that we have the following alternative processes covered:

1. the verifier asks the issuer for a status list at some previous date.time (e.g. last week)
2. the issuer responds with a status retrieval error because such a list is not available
3. the verifier then either terminates or asks for the current status list
   Alternatively
   1a. the verifier asks the issuer for a status list at some previous date.time (e.g. last week)
   2a the issuer ignores the date.time on the query, and returns the current status list.

[TallTed]

I would just like to check that we have the following alternative processes covered:

1. the verifier asks the issuer for a status list at some previous date.time (e.g. last week)
2. the issuer responds with a status retrieval error because such a list is not available
3. the verifier then either terminates or asks for the current status list

Step 3 feels very much like business logic to me.

Alternatively
1a. the verifier asks the issuer for a status list at some previous date.time (e.g. last week)
2a. the issuer ignores the date.time on the query, and returns the current status list.

I do not think (2a) is viable unless the status list VC includes its validity datetime range, which must be included whether or not the issuer supports historical status lists ... and I think there ought to be an advisory message along those lines ("You asked for a historical status list. I don't provide those. Here's my current status list.") to ensure that the verifier knows they're not looking at the historical snapshot they requested.

[msporny]

@dlongley your concerns have been fixed in 6e6d6b9.

@David-Chadwick I've addressed your concern in 6a35fd2.

[msporny]

Normative, multiple reviews, changes requested and made, no objections, merging.