- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 6 Jan 2019 13:22:56 -0500
- To: Gregg Kellogg <gregg@greggkellogg.net>
- Cc: W3C Credentials CG <public-credentials@w3.org>
On 1/4/19 1:05 PM, Gregg Kellogg wrote: > it seems to me personally that this would be reflected in a > best-practices document, as it’s not clear what would actually need > to change normatively in the rec-track specs to take advantage of > this. Correct, and that is by design... no normative changes needed to JSON-LD. I think explaining the functionality in a best practices document is the right way to go. > (In any case, it can be implemented via a custom document loader > before HTTP-like libraries provide broad support). Correct, and this is where the expected changes need to happen in either Legacy Hashlink URL (e.g. <url>?hl=XYZ) or Hashlink URL mode (e.g. hl:<hash>:<metadata>). > Is there a test suite for these drafts so that I might try my own > implementation and verify that it’s working properly? There are two test vectors at the end of the document (which is not enough): https://w3c-dvcg.github.io/hashlink/#appendix-c I've got some thoughts on how we could build a test suite around this (basically an HTTP server with symbolic links that serves up valid/invalid content and a driver that invokes a resolver that returns good/bad for any given hashlink URL), but have a deep backlog on the Verifiable Credentials test suite/spec and Decentralized Identifier test suite/spec, so I won't be able to get to that any time soon. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Veres One Decentralized Identifier Blockchain Launches https://tinyurl.com/veres-one-launches
Received on Sunday, 6 January 2019 18:23:22 UTC