Verifiable Credential request/commit authorization

[zonotope]

Authorize client requests with signed queries and commits against a ledger to a ledger server using claims in a verifiable credential included in the request.

[mpoffald]

@bplatz does your work in #231 include this?

[bplatz]

This is independent, by design, of #231. #231 today expect just two things and will eventually be 3 things

1. The verified did/identity of the request
2. The role(s) the user is to be placed in, if any. This could happen via an intermediary step where a query happened, or might automatically get set based on the credential
3. (not yet in there) a map/flakes of authorized claims on the credential if the credential wasn't self-signed - e.g. if an identity provider signed the credential it could make claims about the user that in turn could get utilized inside smartfunctions.

[dpetran]

Here's my understanding of the issue:

Queries and transactions can come wrapped in a verifiable credential. We would use the signature on the credential as an auth input to the constraint enforcer, where one constraint could be: "transactions must be signed by the holder of the private key for this public key", or perhaps nested verifiable credentials.

We need to add logic to the query and stage functions to support checking those constraints.

[dpetran]

My understanding is actually another issue: #292

This one is about receiving auth claims alongside of the request, verifying that they are authoritative, and then incorporating the claims into the query/transaction pipeline.