Add placeholder algorithms

[OR13]

This PR attempts to address #187

---

Preview | Diff

[jyasskin]

This is exactly what I'm hoping for. Do you think you can make it that verifiers MUST NOT attempt to discover or retrieve keys during the process of verifying signatures or issuers?

[OR13]

We can state something like that... although I am not sure how normative we can make it....

All verification keys are assumed to have been previously dereferenced, keys SHOULD not be resolved at verification time, resolving verification keys at verification time leaks metadata.

The challenge is that for the 3 party model, verifiers do not know up front every issuer or holder they will encounter.

As a practical matter, you may need to do key discovery, if you had not previously done it... but how you do that and when you do that, can be separated from the verify algorithm to a certain degree.

[jyasskin]

Can you format this and the validation algorithm according to the conventions in https://infra.spec.whatwg.org/#algorithms (whether or not you actually cite Infra)? I'd like to see something like

To <dfn>verify a JOSE/COSE verifiable credential or presentation</dfn>, given a [=MIME type=] |mediaType| and a [=byte sequence=] |input|, the verifier MUST:
1. If |mediaType|'s [=MIME type/essence=] is "application/vc...+sd-jwt":
    1. Run the algorithm in <a data-cite="draft-ietf-oauth-selective-disclosure-jwt-06#name-verification-of-the-sd-jwt">Verification of the SD-JWT</a> with the following modifications:
       * The verifier MUST NOT dereference the issuer or key during this process.
       * Any particular claims to look for in the "Check that the SD-JWT is valid using claims such as nbf, iat, and exp" step.
       * Anything else from SD-JWT that asks for the application to customize it, and which can be determined at this level.
1. If |mediaType|'s [=MIME type/essence=] is "application/vc...+cose": ...

With any mistakes I've made in that sketch fixed up, of course.

[OR13]

Yes, although we probably don't want to repeat algorithm definitions if we can instead cite them directly in the IETF text.

I am hopeful we can do a bit of both here, use the infra style algorithm definitions and cause the reader to follow the steps as defined in the normative references without repeating normative algorithm definitions.

[jyasskin]

Is there a specification somewhere that maps from typ codes to the expected set of claims?

[OR13]

Thats typically done in the specification that registers the media type, for example:

• https://www.iana.org/assignments/media-types/media-types.xhtml
• application/secevent+jwt
• https://www.rfc-editor.org/rfc/rfc8417.html

Given the uncertainty of the multiple suffixes draft, and the possibility that specific credential token formats might be registered in the future, I am trying not to pin this down in the W3C spec.

I would expect any registered media type to define required parameters, in this specification we only require header parameters, since the entire payload is dedicated to application/vc+ld+json which can have redundant claims, see:

https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L18

[jyasskin]

Where do the interdependencies between iss and the issuer and holder properties need to be checked? They seem like verification to me, since they establish that there's an unambiguous issuer or presenter.

[OR13]

I would call any checking of specific deserialized members "validation" not "verification".

As a verifier, I might have a policy that allows me to verify credentials from acme, with a known public key regardless of what the string values for "iss" or "issuer" are.

validating the "verified payload" conforms to the core data model, is shared logic between all securing formats... and I prefer to cite it from this document, not duplicate it.

[iherman]

The issue was discussed in a meeting on 2023-12-20

• no resolutions were taken

View the transcript

3.1. Add placeholder algorithms (pr vc-jose-cose#190)

See github pull request vc-jose-cose#190.

Michael Jones: PR190, verification algorithm effort, has been reviewed. TallTed made suggestions.
… Jeff A. "said this is what it was hoping for".

Brent Zundel: Just want Ivan's script to run first...

Michael Jones: Can the minutes show we want to merge 190.

David Chadwick: details on PR... Question: on key revocation, key status...

Michael Jones: Short answer no. You might want to file an issue on that. Seems orthogonal.

David Chadwick: PR refers to the key and trust. Important to say something...

Michael Jones: important to making progress. Do you want to propose text?

David Chadwick: will raise an issue.

Brent Zundel: no one opposed to merge.