You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This means that the actual crypt schema that is used is hidden, and thus the filter becomes a lot less useful.
Therefore I think it might be useful to register a new di_vc and di_vp claim format which define a new cryptosuite property:
{
"^di_vc$|^di_vp$": {
"type": "object",
"additionalProperties": false,
"properties": {
// used for proof.type values (either DataIntegrityProof or custom one)"proof_type": {
"type": "array",
"minItems": 1,
"items": { "type": "string" }
},
// used for cryptosuite property of `DataIntegrityProof`, if `DataIntegrityProof` is include in `proof_type`)"cryptosuite": {
"type": "array",
"minItems": 1,
"items": { "type": "string" }
}
}
}
}
An alternative would be to extend the ldp_vc and ldp_vp with an optional cryptosuite property that can be used if the DataIntegrityProof type is used:
With the move towards the new data integrity vc spec (https://www.w3.org/TR/vc-data-integrity), it is now recommend to use
DataIntegrityProof
proof type.This means that the actual crypt schema that is used is hidden, and thus the filter becomes a lot less useful.
Therefore I think it might be useful to register a new
di_vc
anddi_vp
claim format which define a newcryptosuite
property:An alternative would be to extend the ldp_vc and ldp_vp with an optional
cryptosuite
property that can be used if theDataIntegrityProof
type is used:as data integrity is also the new name of the spec, it might be good to register the new
di_vc
either way.The text was updated successfully, but these errors were encountered: