VC-JOSE-COSE Candidate Recommendation #570
Conversation
Is this notion of a digital integrity (linked data) proof inside a JWT something that we've invented here, or is this coming over from VC-JOSE-COSE in some fashion? |
It was primarily a way to emphasize that |
|
@xaviaracil the terms used in the specification with respect to proofs are confusing. They are using terminology from the VCDM1.1 spec not the latest and greatest 2.0. This PR is a good first start but more is needed: The section on Proofs, should instead be referring to "Securing Open Badges" "linked data proofs", should instead 'Securing Open Badges using Data Integrity Proofs" Instead of references to "JSON Web Token Proof Format", ,it should be aligned with the VC-JOSE-COSE spec "Securing Open Badges using JOSE". References to VC-JWT should be removed or extracted into non-normative text One of the significant and backwards incompatible changes in 2.0 was the removal of the nesting of the VC under a |
| @@ -83,7 +79,7 @@ The JWT Payload is the JSON object of the [OpenBadgeCredential](#achievementcred | |||
|
|
|||
| | Property / Claim Name | Type | Description | Required? | | |||
| | ---------------------- | ---- | ----------- | --------- | | |||
| | \`exp\` | [NumericDate](#numericdate) | The \`validUntil\` property of the OpenBadgeCredential. Required if the OpenBadgeCredential has an \`validUntil\`. | Optional | | |||
| | \`exp\` | [NumericDate](#numericdate) | The expiration time of the signature. | Optional | | |||
| | \`iss\` | [URI](#uri) | The \`issuer.id\` property of the OpenBadgeCredential. | Required | | |||
There was a problem hiding this comment.
One of the important motivations of the VC-JOSE-COSE spec was to stop having two ways of encoding the same information - meaning the canonical examples no longer include iss, sub, jti, iat, nbf, exp.
Therefore, I suggest removing all of this table to keep it simpler on implementors. In fact, I would consider going the other way and require that the implementor not use the conflicting IANA claims, which makes verification a lot simpler.
| @@ -142,10 +138,11 @@ Verifiers that receive a OpenBadgeCredential in Compact JWS format MUST perform | |||
| - The JSON object MUST have the \`sub\` claim, and the value MUST match the \`credentialSubject.id\` of the [OpenBadgeCredential](#achievementcredential) object. If they do not match, the credential is not valid. | |||
| - The JSON object MUST have the \`nbf\` claim, and the [NumericDate](#numericdate) value MUST be converted to a [DateTime](#datetime), and MUST equal the \`validFrom\` of the [OpenBadgeCredential](#achievementcredential) object. If they do not match or if the \`validFrom\` has not yet occurred, the credential is not valid. | |||
| - The JSON object MUST have the \`jti\` claim, and the value MUST match the \`id\` of the [OpenBadgeCredential](#achievementcredential) object. If they do not match, the credential is not valid. | |||
| - If the JSON object has the \`exp\` claim, the [NumericDate](#numericdate) MUST be converted to a [DateTime](#datetime), and MUST be used to set the value of the \`validUntil\` of the [OpenBadgeCredential](#achievementcredential) object. If the credential has expired, the credential is not valid. | |||
| - If the JSON object has the \`exp\` claim, the [NumericDate](#numericdate) MUST be converted to a [DateTime](#datetime). If the resulting DateTime is before the current time, the signature has expired and the verification MUST be made using linked data proofs of the credential. If the credential doesn't have linked data proofs, the credential is not valid. | |||
There was a problem hiding this comment.
- Why insist on conversion to datetime?
- Consider removing the encoding requirements in JWT Payload Format making verification simpler by removing these requirements
Changes in the spec to adapt to the Candidate Recomendation version of the Securing Verifiable Credentials using JOSE and COSE specificaiton. Specifically:
typheader parameter has a new value (https://www.w3.org/TR/vc-jose-cose/#securing-json-ld-verifiable-credentials-with-jose).ctyoptional header parameterexpclaim is now related to the signature, not the credential itself (https://www.w3.org/TR/vc-jose-cose/#jose-header-parameters-and-jwt-claims)