[Task] Create functionality for issuing presentations as JWTs

[olivereanderson]

Description

PR #1148 introduces functionality for issuing credentials in the JWT format according to the VC-JWT specification (version 1.1). Now we need to provide similar APIs for presentations.

Approach

I would suggest to take a similar approach as what was done in the (simpler) case of Credentials. Where we keep users as close to the standard VC Data Model as possible. In other words one essentially passes a Presentation to a (storage) document which in turn carries out the required transformations and yields a JWS.

In analogy with the case of Credentials the golden path for validating a presentation issued as a JWS would then be a (JWT-based) PresentationValidator that decodes and validates the JWS and returns a PresentationToken wrapping a Presentation.

The complication here is the question of what the value of the verifiableCredential property of a presentation should before and after signing it. The natural thing to do when signing is to place the JWT representations of each credential into this array, but when verifying we would want them in the standard Credential format. To solve this problem I would suggest using generics in Rust (and then manual monomorphization in the Bindings). More precisely we could make the verifiable_credential field in Presentation generic of type T and we introduce two type aliases:

/// A Presentation that has yet to be issued. 
/// This presentation type wraps JWT/JWS representations of the contained credentials. 
pub type PreSignedPresentation = Presentation<String, ..>;

/// A presentation that has been decoded from a JWS.
pub type DecodedPresentation = Presentation<Credential, ..>;

The high level APIs for working with these would then be:

/// Issue a presentation as a JWS in accordance with the VC-JWT specification. 
JwkStorageDocumentExt::sign_presentation(presentation: &PreSignedPresentation, ...) -> Result<String>`;

PresentationValidator::validate(presentation_jws: &str, ...) -> Result<PresentationToken>;

where PresentationToken is analogous to CredentialToken and defined as:

/// Decoded presentation from a cryptographically verified JWS. 
pub struct PresentationToken {
    /// The decoded presentation
   pub  presentation: DecodedPresentation,
   
   /// The parsed protected header
   pub header: Box<JwsHeader>, 
   
   /// The parsed protected headers of the credentials in the 
   /// order they appear in `presentation.verifiabe_credential`. 
   pub credential_headers: Vec<JwsHeader>,
}

This produces a decent separation between the world of JWTs and the VC Data Model and it also provides some flexibility. For instance the credentials and/or presentations can then optionally contain a data integrity proof in the proof property which could be verified in addition to the JWS (or potentially instead of if alg = none and the application accepts that).

Motivation

This would give a complete implementation of the VC-JWT specification.

Resources

Sub-task of #1103, follow up of #1148.

To-do list

Create a task-specific to-do list. Please link PRs that match the TODO list item behind the item after it has been submitted.

• Item one
• Item two
• Item three

Change checklist

Add an x to the boxes that are relevant to your changes, and delete any items that are not.

• The feature or fix is implemented in Rust and across all bindings whereas possible.
• The feature or fix has sufficient testing coverage
• All tests and examples build and run locally as expected
• Every piece of code has been document according to the documentation guidelines.
• If conceptual documentation (mdbook) and examples highlighting the feature exist, they are properly updated.
• If the feature is not currently documented, a documentation task Issue has been opened to address this.