Claim format independence

[David-Chadwick]

The introduction states "This specification is designed to be both Claim format and transport envelope agnostic"

This statement is not correct because the claims have to be formatted in JSON.

Do we want to keep claim format independence, or should we limit the specification to only apply to the W3C VC data model? This restriction will simplify the specification in a number of ways a) format is no longer needed, because regardless of the crypto format the credential and presentation are always the same format so the same input descriptor can be used for all different crypto formats. b) path can be simplified to be a single element rather than a set in most cases.

[nklomp]

How would that work with JWTs? Note the wording in the first sentence of the encoding section below. I guess it can be handled during decoding and apply the JSON path on the resulting VC.

From https://www.w3.org/TR/vc-data-model/#jwt-encoding

For backward compatibility with JWT processors, the following registered JWT claim names MUST be used instead of, or in addition to, their respective standard verifiable credential counterparts:

exp MUST represent the expirationDate property, encoded as a UNIX timestamp (NumericDate). iss MUST represent the issuer property of a verifiable credential or the holder property of a verifiable presentation. nbf MUST represent issuanceDate, encoded as a UNIX timestamp (NumericDate). jti MUST represent the id property of the verifiable credential or verifiable presentation. sub MUST represent the id property contained in the verifiable credential subject. aud MUST represent (i.e., identify) the intended audience of the verifiable presentation (i.e., the verifier intended by the presenting holder to receive and verify the verifiable presentation).

[csuwildcat]

On the last call I promised a magical sentence that would make all our single-JSONPath-selector dreams come true, so here goes - assume this is the very first line of text in the Input Evaluation section:

The inputs received MAY be encoded in a data model that requires processing or transformation steps to produce the bytes Presentation Exchange Input Evaluation intends to target and evaluate. You MUST process or transform the items received in accordance with their data model prior to evaluation, and proceed with the steps listed below using the output of whatever the data model's processing and transformation steps produce. For example: if an item is a JWT variant of a W3C Verifiable Credential, one would be required to execute the processing steps required by the W3C Verifiable Credential specification to yield the .vc subtree from the item, which the implementer would then use for processing in the steps below.

[bumblefudge]

instead of, or in addition to

the WG compromise that launched a thousand non-interoperable implementations...

Here's my attempt at making this more explicit, and hopefully not too opinionated:

The inputs received MAY be encoded in a proofed representation of the VC data model that requires processing or transformation steps to produce the bytes that the Presentation Exchange Input Evaluation ~intends~expects to to target and evaluate , namely, what the VC data model defines as a "credential", more colloquially a "payload" in JSON. You MUST process or transform the items received in accordance with their representation and proofing method as defined in the VC data model prior to evaluation, and proceed with the steps listed below using the output of whatever the data model's processing and transformation steps produce. For example: if an item is a JWT variant of a W3C Verifiable Credential, one would be required to execute the processing steps required by the W3C Verifiable Credential specification to yield the .vc subtree from the item, which the implementer would then use for processing in the steps below.

[David-Chadwick]

@bumblefudge Well done!