[BUG] did:web resolution incorrect service type validation

[PatStLouis]

When resolving a did:web with the /resolver/resolve/ endpoint the validation checks if the service.type is a string. According to the did core spec, this value can be a string or an array.

The value of the type property MUST be a string or a set of strings. In order to maximize interoperability, the service type and its associated properties SHOULD be registered in the DID Specification Registries [DID-SPEC-REGISTRIES].

Having an array for the service.type raises this error:
500: Response was incorrectly formatted. Failed to deserialize DIDDocumentRoot:. 1 validation error for ParsingModel[DIDDocumentRoot]. __root__ -> service -> 0 -> type. str type expected (type=type_error.str). [ErrorWrapper(exc=ValidationError(model='DIDDocumentRoot', errors=[{'loc': ('service', 0, 'type'), 'msg': 'str type expected', 'type': 'type_error.str'}]), loc=('__root__',))].

Changing the service.type to a string instead of an array resolves this error however both should be valid.

[dbluhm]

Shoot. This is a PyDID issue. This has the potential to be a painful change though; several routines scan through services expecting to find a string.

Out of curiosity, do you have an example of this in use?

[PatStLouis]

The traceability interoperability spec uses a list for the service.type. Aca-py isn't able to process the document any further if the value is not a string, therefore can't fetch a verificationKey to verify a VC:
https://w3c-ccg.github.io/traceability-interop/draft/#service

One could just use a string instead however this prevents interoperability with the did core specification.

[PatStLouis]

Tagging this link to keep breadcrumbs of the work:
Indicio-tech/pydid#81

[PatStLouis]

@dbluhm we fixed this in the pydid library and a new version was released. Is there anything we need to do on aca-py side to pull this new version or is it auto-magical?

[dbluhm]

I believe we may need to do a poetry.lock update so the images will include the newer version. If pulled via PyPI or github as a dependency of another project, I think the current version constraint will correctly resolve to the new pydid version but the dependent projects would also need to do something like a poetry update themselves to get the new version.

[PatStLouis]

closing as #2737 was merged and addresses this issue