Pick an extension for .fhir-backed-vc

[jmandel]

• Do we need different extensions for encrypted vs just signed VCs?
• Do we need additional guidance about when to use (e.g., email attachments vs links to download), and how to protect these?
• Can we include example downloadable VCs in the spec?

[jdkizer9]

Somewhat related, one thing that I'm also not quite clear on is whether the VCs in the files will be encoded in JSON Web * format that we're currently using or something else. If so, could we provide examples on how the decryption / verification process would work? I think the note in this section is relevant, but still an unknown to me.

The example below shows a VC using the "vanilla" JSON representation. When packaging a VC into a JSON Web Token payload, there are a few differences, to retain compatibility with standard JWT claims. For example, compare this "vanilla" JSON representation with its corresponding JWT payload. Note that in the JWT payload, most properties have been pushed into a .vc claim.

[radamson]

Is the whole presentation expected to be encrypted, or just the included VCs? If only the VCs contained are encrypted as JWEs then I'd imagine no additional metadata would need to be provided in a file extension.

e.g. this notional presentation from the spec:

{
  "verifiableCredential": [
    "<<Verifiable Credential as JWE or JWS>>",
    "<<Verifiable Credential as JWE or JWS>>"
  ]
}

[jmandel]

One note on terminology: the .fhir-backed-vc file isn't strictly a "presentation"; it's just collection of VCs; the VCs themselves are of course signed, and may optionally be encrypted. (Note: the "signed but not encrypted" case is nice when there's little up-front workflow integration -- e.g., when the issuer doesn't know a DID for the user.)

Re: metadata, the VC JWTs in the verifiableCredential array can be dealt with like:

1. Check the header to know if it's a JWE or a JWS. If it's a JWS, proceed directly to step 2. If it's a JWE, check the kid in the header and decrypt with that key to obtain a JWS (if decryption fails, you're stuck; throw an error).
2. Now you have a JWS. Validate this per JWS rules; a few details to ensure...

• JWS payload's iss is on your whitelist. (We should make sure that user-facing issuer description, name, logo, etc are all part of the whitelist for now; eventually we can do a better job of decentralizing these details.)
• JWS header's kid belongs to the iss (i.e., resolve the issuer's DID doc and ensure this kid is present, and is a signing key)
• JWS iat time is in the past, and exp if present is in the future

[jmandel]

(If these details make sense, would love a PR adding them to the spec; if there are open questions, let's work through them.)

[jmandel]

@jdkizer9 are you still willing to add these clarifications in a PR?

[jmandel]

Re: extension -- for now, .fhir-backed-vc seems good enough; will close this issue.