search

spruceid / ssi

Core library for decentralized identity.
https://spruceid.dev
Apache License 2.0
193 stars 61 forks source link

Implement a DID Document builder and convenience functions #7

Closed wyc closed 3 years ago

wyc commented 4 years ago

@clehner this could be a good next step along towards the ultimate goal of satisfying the test suite. Recommend reviewing some prior art: https://github.com/digitalbazaar/vc-js

clehner commented 4 years ago

@wyc Should there be another constructor that takes all the options to add to the new struct? Getter/setter functions? Creating a document from deserializing a JSON string? What would be convenience functions?

wyc commented 4 years ago

@clehner I think we should have an "easy to get going" workflow but more advanced options at the user's choice. Would like to avoid having to set 50 different options to get a DID Document to work with, a simple did:key DID Document should be simple to spawn and work with.

Some interesting code patterns and discussions thereof to consider: https://github.com/colin-kiegel/rust-derive-builder https://github.com/rust-unofficial/patterns/issues/64 https://github.com/rust-unofficial/patterns/blob/master/patterns/builder.md https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis

Especially curious about the functional options pattern and if it would fit.

Perhaps we can further consider the resources linked here, which describe DID URL Referencing, one of the most common things we expect to do with DIDs:

https://github.com/w3c/did-core/issues/364 https://github.com/w3c/did-core/pull/253 (closed due to inactivity, but still relevant) https://w3c-ccg.github.io/did-resolution/

Imagine someone building a Universal Resolver (https://github.com/decentralized-identity/universal-resolver) with our library (we may do this, actually). Imagine someone taking the output of the Universal Resolver as per the DID Resolution spec using our library to feed into their application software which must inspect the DID Document.

As per serialization, we should consider a JSON-LD + CBOR-LD representations, keeping our core data models abstract and agnostic to wire formats as much as is reasonable.