Service Endpoint Media Types/Behavior/Security

[SchulzeStTSI]

Hello:)

According to the https://w3c.github.io/did-core/#services description the service endpoints are just seperated by id/type. This leads in some high automation scenarios to problems, because you have actually no idea abot the follwing points:

a) what is behind the service endpoint? xml, json, grpc protocol, wss? Which parameters are required?
b) is the endpoint trustworthy?
c) owns the user the endpoint or is it a endpoint from someone else?

Each of them is actually a complex problem:

a) For point a it would be great to have an kind of accept/protocol/rfc parameter next to the service endpoint to indicate "http" and "application/json" as basics before establishing the communication. Selecting that over service endpoint types is mostly a guess like search for endpoints which follow HTTP-XML to find a service which is speaking http with xml response. For http protocol, options could be used normally, but in case of other protocols behind that endpoint, the options call could be not available. Additionally it would be very helpful to have an indication what kind of protocols could be expect from the endpoint to avoid implicit naming conventions of endpoint types. E.g. search for endpoint type "******OAuth2". According to this it could like this:

{
  "service": [{
    "id":"did:example:123#myFancyEndpoint",
    "protocol": "http", //(grpc, mqtt, mysql...)
    "accept": ["application/json", "application/jose"]
    "type": "SuperService", 
    "serviceEndpoint": "https://bar.example.com/api/v1/123355",
    "rfc":"https://datatracker.ietf.org/doc/html/rfc6749"   
  }]
}

b) For point b, the trustworthiness of the endpoint is quite tricky. Belongs www.example.com really to the did? It could be solved by using did-configurations, but this is an additional step, which is a bit anoyiny. Therefore it could be sensefull to insert in the endpoint definition an field for tls pinning with an jwk in it:

{
  "service": [{
    "id":"did:example:123#myFancyEndpoint",
    "type": "SuperService", 
    "serviceEndpoint": "https://bar.example.com/api/v1/123355",
    "tlsPinning": {
            "x5c": ...., 
            "x5u":...
    }
  }]
}

c) This point is actually more tricky than point b, but could be solved by registering an oid for the did checkup, which can be used then as custom extension of an X509 used by the endpoint e.g. 1.2.4.2304.233333333 which must contain the signature of an verification method reserved for this purpose. Is the connection established in the direction of the service endpoint, the server will respond with it's certificate, and the attribute can be checked against the verification methods. It would be better to use the private key of the verification method directly to create the CSR, but this is sometimes not possible, for example when automated certificate issuance systems are used (like let's encrypt) which are randomly choosing the X509 key pairs and write them in any cluster secret. Doesnt matter which variant is used, the specification should enforce a standard behavior for security checkups, to avoid phishings, fake urls, redirects etc. pp.

I hope this is maybe helpfull to improve the spec and i'm looking forward to your answer:)

kind regards

[peacekeeper]

Regarding a), some other specifications in the past (before DIDs) did include this. For example, Web Linking and XRD distinguished between link types (aka "rel") and media types (aka "type"). The DID document data model doesn't have this distinction.

Note however that the DID document data model is extensible! So you could define such additional properties in your own specifications, and then propose to add them to the DID Spec Registries.

[SchulzeStTSI]

@peacekeeper Thanks for your answer!:) The checked the specs that you provided in your answer and have a couple of questions:

1. The first link provides an format which is implicit, means the endpoint itself describes it's own setup, but in an implicit way, which must be parsed/extracted. This could lead to implementation gaps, which make the link unusable in the right way? Practically needs everyone then a library with 100% feature coverage and exactly the same behavior. This seems not really be feasible in the next years?
2. The XRD sounds better from the intention, but one question about this: as I understood it, XRD requires that each and everyone is implementing for it's service XRD Discovery services right? This makes for my understanding sense in Restful Services, but in low level scenarios, IOT etc. could this be an overkill.

Of course a new web method would be an option in general, but I see it more from the point of the overall did core architecture. The did core spec contains "services" which describe endpoints to communicate to the did subject. In theory this could be electronic, physical handover or a carrier pigeon, but practically it's on protocol/transport basis right? So from this cohesion point of view, there should be a protocol declaration, transport declaration (TCP, UDP, MQTT etc.) together with an identifier of that protocol (e.g. rfc)? This would increase the interoperability between did methods a lot without implementing xxxxx method specifications or assuming that someone is using the right link format and/or service discovery.