Open kamescg opened 4 days ago
I'd recommend that as well. Personally, going down the JSON-LD route is only useful if you plan to use JSON-LD VCs and their tooling. I don't expect many of the consumers will do that and so then we're likely going to face tradeoffs in whether the security works as expected. E.g. json-ld document processors will drop that key so it could fail in signature validation of a VC.
I'd expect with the most recent WG formed this is a problem they plan to tackle so it's worth keeping an eye on that to see how they recommend handling DID documents that are expected to be used as JSON only. We can then follow their advice once they've decided the best way forward.
As pointed out by @kdenhartog on X the current DID draft doesn't include the right context to verify default signing keys.
The
type
key in theverificationMethod
object currently usesEthEip6492
which is not a adopted spec and thus we can't include a reference in the@context
field.This
EthEip6492
type is placeholder in the first draft, because the prototype uses a signature validation method not included in the W3C DID specification e.x. https://w3c.github.io/vc-data-integrity/vocab/security/vocabulary.html#blockchainAccountIdMy Opinion
I think we should avoid trying to adhere to W3C standards perfectly (for the moment) and move forward with a minimal viable spec for this verification method type that is used internally--expecting multiple iterations as the project progresses/matures.
And once it's finalized submit to https://w3id.org/