Open wyc opened 3 years ago
+1 this idea.
There are several places where we load/dereference documents or resources from URLs. I'm not sure if there are are uses that would require one kind loaded via this way but not another. It could be useful for testing/developing did:web
or even arbitrary DIDs, e.g.:
# passing a DID document for a DID, maybe that is the credential issuer
$ didkit -@ "did:example:foo":foo.json vc-verify-credential ...
# specifying a DID document for a did:web DID for use during credential verification
$ didkit -@ "https://example.org/.well-known/did.json":example-did.json vc-verify-credential ...
As a CLI option, this could be used in didkit-cli
and didkit-http
. Would we want an analogous option for the FFI/libraries? WASM in browser may need a different way.
The other project is https://github.com/decentralized-identity/jsonld-document-loader. I'm not sure if it has a CLI or filesystem-based options. But it does also allow loading from paths and prefixes such as for DID methods.
Is the idea here with -@ "URL":file.json
that the context at URL is loaded in from file.json? And/or potentially that if file.json doesn't exist, the URL is fetched and its contents saved to file.json? And potentially the :file.json
could be left off entirely if you just wanted to fetch the context from the URL each time?
I've made a branch on didkit which augments CLI with two particular contexts that I need for work in my industry. It works by adding to the contents of ssi::jsonld::CONTEXT_MAP, which is the built-in default contexts. This builds against the context-loader
branch (specified in the root Cargo.toml file patch.crates-io).
https://github.com/LedgerDomain/didkit/tree/with-oci-contexts https://github.com/LedgerDomain/ssi/tree/context-loader
This -@ "URL":file.json
feature could be implemented by adding the specified contexts to ssi::jsonld::CONTEXT_MAP, similar to the hardcoded addition done here.
We should support
@context
and possibly jsonschema as options fed into the CLI. @clehner and I encountered this request at this most recent IIW. Perhaps it looks like:These are just some ideas. There's a lot of room for improvement, so feel free to take any design liberties to improve developer ergonomics and reduce chances of errors. Thank you @bumblefudge for the
-@
flag suggestion. :)@clehner, did you say there was another project that used this approach?