Bug: Taking "expirationDate" from wrong place in encode_jwt_vc_claims

[vdods]

The expiration date of a credential isn't making it into a JWT-formatted VC:

In

ssi/crates/claims/crates/vc/src/v1/jwt/encode.rs

Line 40 in 507bdb1

take_object_property(&mut credential, "credentialSubject", "expirationDate")

pub fn encode_jwt_vc_claims<T: Serialize>(
    credential: &T,
) -> Result<RegisteredClaims, JwtVcEncodeError> {
    let mut credential = json_syntax::to_value(credential)?
        .into_object()
        .ok_or(JwtVcEncodeError::ExpectedJsonObject)?;
    let mut claims = RegisteredClaims::default();

    if let Some(date_value) =
        take_object_property(&mut credential, "credentialSubject", "expirationDate")
    {
        <...>
    }

    <...>

    if let Some(issuance_date_entry) = credential.remove("issuanceDate").next() {
        <...>
    }

    <...>
}

The "expirationDate" field should be taken from the credential, not the credential subject. It should work just like the "issuanceDate" case.

[vdods]

Related: fn encode_jwt_vp_claims doesn't encode the "aud" field listed in the VC spec https://www.w3.org/TR/2022/REC-vc-data-model-20220303/#jwt-encoding -- this section of the spec is very confusing, as it interleaves how to JWT-claims-encode a VP in with how to JWT-claims-encode a VC. The ssi crate correctly encodes the "jti" and "iss" fields, but omits the "aud" field.

This fix would just involve adding one more field-handling clause in fn encode_jwt_vp_claims and fn decode_jwt_vp_specific_headers.

[vdods]

Upon closer examination of fn encode_jwt_vp_claims, it extracts an "issuanceDate" field from the VP (even though that isn't specified in the JSON-LD context https://www.w3.org/2018/credentials/v1 -- this makes sense to me, as I think it should be possible to time-bound a VP using "nbf" and "exp" JWT fields to limit the possibility of a replay attack. Similar with the "nonce" field.

Would it make sense to add handling for "expirationDate" and "nonce" in fn encode_jwt_vp_claims analogous to the existing one for "issuanceDate"? This would complete the handling for all JWT fields* for VPs -- all of this is pertaining to V1.

• There is a noted confusion in the VC 1.1 spec regarding issuanceDate vs "iat" and "nbf" -- see https://www.w3.org/TR/2022/REC-vc-data-model-20220303/#issuance-date

[vdods]

This PR fixes the original issue regarding the "exp" field processing. The "aud" field discussed in later comments is still outstanding.

#689