IAM: Handle s2s token request

[reinkrul]

Fixes #2495

Noteworthy things:

• I chose to return an unencrypted JWT as access token for now; since we don't have persisted token storage and I can't remember what we decided (using a JWT or opaque value that maps to a server-side stored token) -> we now an opaque token
• I assumed we don't need to support path_nested in Presentation Exchanges (not sure, maybe only if we support VCs and VPs in JWT format?) -> support pending (generate presentation submission with path_nested #2563)
• Matching the presentation submission against the Verifiable Presentation (in JSON-LD format) is kinda fiddly, since our VP JSON-LD marshalling compacts arrays. This means path indexers won't work if there's just 1 credential in the VP. I fixed with some []interface{} checking in PresentationSubmission.Credentials(), but theoretically there could be presentation definitions that map to compacted arrays in other Verifiable Credential types. So we might need to convert JSON-LD VPs/VCs to plain JSON first (uncompacting arrays). But maybe leave that out of scope for now, and fix it when implementing JWT support?

Requires #2566

[woutslakhorst]

We need to do opaque tokens since we need access to the entire VC/VP, they are too big to put in a header. Introspection will need to get them from session storage.

[reinkrul]

Rebased, changes:

• Removed access token JWT implementation, replaced secure random code stored in session database
• Returned OAuth2Error instead of "normal" Go error

[reinkrul]

Further VC/VP verification optimizations are part of #2528 (since it's existing code).

[gerardsn]

The presentation submission is incomplete without path_nested, but I'm not sure if that is blocking now.

OpenID4VP §6.1 has the following example of a presentation submission for a VP with nested credentials that matches our use case

{
    "id": "Presentation example 1",
    "definition_id": "Example with selective disclosure",
    "descriptor_map": [
        {
            "id": "ID card with constraints",
            "format": "ldp_vp",
            "path": "$",
            "path_nested": {
                "format": "ldp_vc",
                "path": "$.verifiableCredential[0]"
            }
        }
    ]
}

but I think JSONPath/PEX also allows this to be expressed as

{
    "id": "Presentation example 1",
    "definition_id": "Example with selective disclosure",
    "descriptor_map": [
        {
            "id": "ID card with constraints",
            "format": "ldp_vc",
            "path": "$.verifiableCredential[0]"
        }
    ]
}

IMO the former is nicer since you get the format of the VP, but not strictly necessary. Maybe we can get away with skipping path_nested for now?

[reinkrul]

@woutslakhorst @gerardsn rewritten most of PR based on introduced PresentationSubmission.Validate() function and JWT support. Resolved earlier feedback.

[woutslakhorst]

Apart from Gerards comments, the handle looks quite good. The rest of the PR is a bit cloudy since there have been some changes in master that should be merged first.

[woutslakhorst]

should be challenge from options.proofOptions

[reinkrul]

challenge is not the same as nonce? I'd say nonce is a technical random value included in the signature to prevent replay attacks, while challenge is a functional value (like the IRMA contract message)? In JSON-LD Proofs they're 2 different fields anyways.

[woutslakhorst]

openid4vp requires it to be passed

[woutslakhorst]

Maybe a disclaimer for these methods that this is what we expect for now. This is not required by any international spec.

[reinkrul]

Not sure that will add anything, when you feed the Nuts node a Verifiable Credential that it was never meant to understand (e.g. issuer is not a DID), things will also horribly fail. They're util functions that exactly state what they do, so either call 'm or don't?
If it's important to have a clear disctinction between what is standardized and what not (could be useful), we could consider organization code in such way (e.g. defining things like "profile")