Extended status assertion errors table added

[SaraConsoliACN]

This commit aims to resolve issue #46.

[OR13]

In this case, the holder can never prove the credential is revoked, they can only prove if its not.

I wonder if treating revocation as an error is a good idea. I can see pro's and con's.

An alternative would be to issue an assertion that the credential was revoked, and return a different structure for errors with the request or on the server (4xx, 5xx).

[peppelinux]

please do a proposal, I would like to have draft 03 before the next interim meeting

I used status code set to 200 for two reasons:

1. the result is an array with multiple embedded responses, be these assertions or errors
2. adversaries won't take any behavioral information from the endpoint without inspecting the JWT/CWT contained in the response array

I want to know from you if you want a different approach or if you only want remove this error type about the already revoked credential

[peppelinux]

I have improved the alg parameter description and also proposed a section explaining the rationale behind the unsigned status assertion errors, specifying that it's an implementation choice and the requirement to validate the signature when it is present

@OR13 @fmarino-ipzs ^