search

Indicio-tech / pydid

Python library for validating, constructing, and representing DIDs and DID Documents
Apache License 2.0
11 stars 12 forks source link

Context should allow non string elements #47

Closed rodolfomiranda closed 2 years ago

rodolfomiranda commented 3 years ago

A valid context can be (generated by sidetree by the way): '@context': [ 'https://www.w3.org/ns/did/v1', { '@base': 'did:ada:EiCsykwe_DHYxv6TgtuCZp7_9gLHrBOs7VmuXi2H9vWXYw' } ] But now it only accepts a List of strings and throws error. Can the parsing of contexts be generalized?

dbluhm commented 3 years ago

According to my understanding of the DID specification at least, accepting objects isn't strictly conforming. Is this particular validation piece something that can be adequately solved by sub-classing and modifying validation? If this is a misunderstanding on my part of what the DID spec accepts -- or even if it's not -- I'm happy to accept a PR with some test cases and a fix :slightly_smiling_face:

rodolfomiranda commented 3 years ago

Seems you are right. This is strictly JSON-LD specifics: "The JSON-LD Context is either a string or a list containing any combination of strings and/or ordered maps." I'll start extending the validator class. If I find something elegant I would submit a PR.

Just for reference, this is what sidetree guys said about the @base: "If the implementation is outputting DID state data as a DID Document, and the DID Document is being rendered in the JSON-LD representation variant, the implementer SHOULD add an @base entry to the document's @context, and set the @base value to the id of the resolved DID. This ensures relative path values in the output DID Document are correctly projected into id-related strings by JSON-LD parsers."

dbluhm commented 3 years ago

Good to know, thanks for the info! The biggest challenge I've experienced with this library is striking the balance between strictness of validation and usability with the various DID methods. One of my goals is to accommodate trivial extension to cover as many DID methods as possible, even if the caller has to do a bit of informing the validator of what is expected. I'm open to including common variations directly in the library though.