spruceid / didkit

A cross-platform toolkit for decentralized identity.
https://www.spruceid.dev/didkit/didkit
Apache License 2.0
266 stars 76 forks source link

Support JSON-LD @context and (possibly) jsonschema in CLI #151

Open wyc opened 3 years ago

wyc commented 3 years ago

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:

# adding single JSON-LD schema for "http://w3id.org/mycontext"
$ didkit -@ "https://w3id.org/mycontext":mycontext.json vc-verify-credential ...

# adding multiple JSON-LD schemas for "http://w3id.org/context1" and "http://w3id.org/context2"
$ didkit -@ "https://w3id.org/context1":mycontext1.json -t "https://w3id.org/context2":mycontext2.json vc-verify-credential ...

# adding zero or more JSON-LD schemas for "http://w3id.org/places/country" and "http://w3id.org/places/state"
$ tree contexts
contexts
└── places
    ├── country
    └── state
$ didkit -@ "https://w3id.org/":./contexts vc-verify-credential ...

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?

clehner commented 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.

vdods commented 2 years ago

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?

vdods commented 2 years ago

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.