[Bug] Service definition does not match DID spec for type and serviceEndpoint

[obany]

Bug description

The definition of the service type currently defines the type field as a string, and the serviceEndpoint as a Url https://github.com/iotaledger/identity.rs/blob/8a97e95ae549c5e78d32336739eb349f49e977f8/identity-did/src/service/service.rs#L25-L27

The spec defines these properties to also allow set of elements https://www.w3.org/TR/did-core/#service-properties

Expected behaviour

The service type should match the spec.

Actual behaviour

The service type only supports single strings.

[cycraig]

Hi, thank you for opening an issue.

Would you mind detailing the exact functionality you require from a serviceEndpoint? Do you just need a set for your use-case or also a map and nested set of maps?

A string that conforms to the rules of [RFC3986] for URIs, a map, or a set composed of a one or more strings that conform to the rules of [RFC3986] for URIs and/or maps.

The main problem is that It's unclear how options other than a single url interact with the service dereferencing API: https://w3c-ccg.github.io/did-resolution/#service-endpoint-construction

[obany]

In our case we store a set, with alternative endpoints to query if one is down.

[cycraig]

A Service now allows ordered sets and maps for the serviceEndpoint field but not nested maps. This change is currently only on the dev branch until the next version release.

Sample code using the Wasm bindings to add a new Service with a set of endpoints:

let serviceJSON = {
  id: doc.id + "#linked-domain",
  type: "LinkedDomains",
  serviceEndpoint: ["https://iota.org/", "https://example.com/"],
};
doc.insertService(Service.fromJSON(serviceJSON));

or with a map:

let serviceJSON = {
  id: doc.id + "#linked-domain",
  type: "LinkedDomains",
  serviceEndpoint: {
    "origins": ["https://iota.org/", "https://example.com/"]
  },
};
doc.insertService(Service.fromJSON(serviceJSON));

Please comment here or open a new issue if there are any problems. Thank you.

[7opf]

@cycraig are there plans to support sets of strings for the type? We have no need for it at the moment, but I came across a comment in our code regarding this issue from @obany.

[cycraig]

are there plans to support sets of strings for the type?

I forgot this was even a problem! Thanks for the report, will open a PR for it SoonTM.

[cycraig]

Should be addressed by #944.