-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement a DID Document builder and convenience functions #7
Comments
@clehner this could be a good next step along towards the ultimate goal of satisfying the test suite. Recommend reviewing some prior art: |
@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? |
@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: 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: w3c/did-core#364 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. |
No description provided.
The text was updated successfully, but these errors were encountered: