1A/ DID Service Discovery
DID Discovery Service
Thursday 1A
Convener: Sam Curren
Notes-taker(s): Drummond Reed
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Sam began by explaining the "service" block in a DDO (DID Descriptor Object).
A slide deck describing DIDs and DDOs was given in session #1 yesterday—the link is https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2017/blob/master/topics-and- advance-readings/DIDs-solving-the-root-identity-problem-2017-03-14.pptx.
George Fletcher asked about whether the DID spec will standardized service name types. Sam explained that it will, but Sam feels that it will not matter. George thought it was important.
The x-dash convention was suggested, but Justin and others argued against it as x-dash specs often become permanent. They suggested to use a URI, and to have widely adopted URIs receive short names in the JSON-LD context description.
Sam suggested that the value for each service name should be a list (an array), and there should be a SHOULD to keep the number of URIs short.
George suggested that each service name spec should specify if there will be more than one (arity) and how to choose if there is more than one.
Sam suggested that service names do not include any other metadata, so that any additional discovery takes place on the discovered URI and not via the DDO.
Sam then proceeded to described his ideas for a protocol for DID Service Discovery. This specifically applies to "agents" that are associated with DIDs and DDOs.
The overall approach is to use the Well Known spec to publish a JSON object at the standard well-known location:
//.well-known/
At that location would be a well-known file that would define the extensions supported by that particular service.
There was discussion about whether it was a good idea to try to fix a path for services or whether you should discover the path via
RFC 7320 is the IETF spec on avoiding Web squatting.
Justin also pointed to the Webfinger spec as an example of how complex that URI construction can get. Mark Atwood agreed, saying that "path construction is pathological".
Sam pointed out that retrieving full URIs as the locations for extensions allows the service definitions to use other protocols than HTTP. That's an advantage.
Each of the services that would be described in the Well Known document will have a Swagger description that can be retreived. The general format is:
{ "extensions": {
"XYZ-API": "uri",
"ABC-API": "uri"
]
}
Sam proposed that the API names (XYZ and ABC above) are DIDs, so they are long-lived. The alternative is to use URIs as the names for the specs.
The URI is the URI of a Swagger specification that describes the implemention of the API/service.
The overall result is an Extensible API description spec.
Sam explained that the Swagger spec does not support evented APIs, so Sam wants to extend it to work on that.
There was a question about supporting services like OAuth that do not have Swagger specs.
George suggested that OAuth could be used to access all the service names in the Well Known document.
UMA was brought up as an example of a service that could be support in the Well-Known list. This could be a great way to expose UMA endpoints via a DID.
There was a discussion around the need to resolve human-readable names to DIDs, and how important that was for some use cases. Justin suggested that Webfinger could be used that points to a Well-Known/DID file.
We also discussed correlation. Sam talked about protecting the Well-Known endpoint using authentication. George took it to the logical conclusion that a DDO just supports a single service —a Personal Discovery Agent—that handles all further discovery.
We agreed that the DID service block can support any number of services, including a standard DID Discovery Service.
Drummond said that the plan is to turn this into a written spec quickly, and asked anyone interested in working on it to loop back with Sam.
Justin asked how to "round-trip the trust" between the DID and the Well-Known endpoint.
ADDITIONAL NOTES FROM GEORGE FLETCHER
Looking for an Agent that is connected to a DID
Service names rules are defined in the DID spec. Service names have semantic meaning. Need a way to added small specs for service names to describe the semantics. For example, “openid” means do OpenID Connect discovery on the URL.
Sam would like to see support for multiple URLs in regards to the service name. Order matters. Rather, allow the “service name spec” to define what to do with the list (order matters, or randomly pick one). The list SHOULD be as small as possible. Additionally have the “service name spec” describe whether the value is single or an array.
If there is no “service name spec”, use a collision resistant name (e.g. URN/URI)
Agents accessible via HTTPS using the TLS via DIDs certs instead of CA issued certs.
— make sure this is implementable in all the common SSL libraries
Agents
— use .well-known mechanism for discovery of agent features
— return JSON plus API exentions
— composeable set of APIs
— API extensions defined in swagger (OpenAPI v3?)
— add path of API location part of extension JSON block
— make the “extension name” be the swagger spec, URI is where that spec is implemented (it’s a base URI)
Sam would like to extend Swagger to support evented APIs
What about “private” services that shouldn’t be public?
— can only put one things in the user DID service spec and it points to an agent that does permission exposure of services
One last question: How do you do relationships on the blockchain?
