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

feat: realign service with DID Core spec #75

Closed dbluhm closed 1 year ago

dbluhm commented 1 year ago

This PR realigns the service endpoint definitions to what is outlined in the DID Core spec. Specifically, permitting the service endpoint to be a string, map, or set of strings and/or maps. DIDs, DID URLs, general URLs, and now any string is now permitted. This is to support specifying arbitrary URIs. The rules for parsing URIs would be overly complicated to fully validate; slightly greater flexibility is preferrable to maintaining large regexes.

Through this realignment, pydid will now support didcomm:transport/queue as a serviceEndpoint value.

dbluhm commented 1 year ago

My one concern about opening it up for more flexibility is that it would possibly allow values that would be considered invalid endpoints.

Yeah, indeed. You raise good points and counterpoints. I arrived at more or less the same conclusion. Even if we did have more comprehensive URI validation, the variety of URIs mean that you could end up with something that's valid according to the spec but still unusable to the application anyways. My mentality with these changes is that we'll parse it into useful objects like DID and DIDUrl if we can but otherwise we'll let the application determine the validity of the endpoint.

I'll also call out that while the base Service object is now more permissive, the DIDCommService objects are still narrower, in accordance with the DIDComm V2 specification and relevant Aries RFCs. This will again help us to parse useful values according to the DIDComm specs but leave the validity of the final endpoint/uri to the application.

Thanks for the review!