Open msporny opened 4 months ago
@msporny The current spec does not contain any @language
or @direction
statements or even a mention of those features. The VC Data Model spec does at least mention @language
and @direction
.
So adding this feature to D.I. is not that hard (existing tests already exist in VC Data Model for this), the question is should the il8n examples be done as a feature that a suite or implementer can turn on to ensure conformance or should il8n be on by default in all suites? I believe the former makes more sense as no normative statement in DI says an implementer MUST support il8n. Additionally, should the il8n properties be on a data integrity proof (the subject of this test suite) or do we need to demonstrate that VCs with il8n properties can be signed with data integrity proofs?
{
"type": "DataIntegrityProof",
"id": "urn:uuid:26329423-bec9-4b2e-88cb-a7c7d9dc4544",
"cryptosuite": "eddsa-rdfc-2022",
"created": "2023-02-26T22:06:38Z",
"verificationMethod": "did:key:z6MktgKTsu1QhX6QPbyqG6geXdw6FQCZBPq7uQpieWbiQiG7#z6MktgKTsu1QhX6QPbyqG6geXdw6FQCZBPq7uQpieWbiQiG7",
"proofPurpose": {
"@value":" assertionMethod",
"@language": "en",
"@direction": "ltr"
},
"proofValue": "z5gL4Hy8N4B6zr9mQAGqpsry1iTdxEAp4zjqPNQv7iTvgdkMcHKnMALvPwU3YAKZhYn3k3Jmut2TAMxSaHaggFtf4"
}
only proofPurpose
and maybe cryptosuite
make sense as il8n values unless we want to express dates in non-arabic numbers.
Transferring this issue from https://github.com/w3c/vc-data-integrity/issues/218:
The test vectors use human-readable strings and the i18n group requested that we express them using the appropriate @language/@direction values across vc-data-integrity, vc-di-eddsa, and vc-di-ecdsa. This is a tracking issue to make sure we update the test vectors to conform to i18n guidance.