Closed kdenhartog closed 5 years ago
@kdenhartog I know this issue here was raised a long time ago, but I still wanted to respond. A service endpoint's type
property describes an application layer protocol (microblogging, file storage, messaging, etc.), not a transport layer protocol. There would be well-known conventions and vocabularies to identify protocols (e.g. HubService
). The proposed service-type
matrix parameter (https://github.com/w3c-ccg/did-spec/pull/191) could be used to identify service endpoints by type, as part of a DID URL.
In an earlier brainstorming document (Use Case Examples for DID URL Parameter Formats), there was also a comment that an additional matrix parameter service-protocol
could be defined that allows identification of service endpoints by their transport layer protocol, but this hasn't yet been discussed much.
Do you have additional thoughts/questions on this? Or should we close the issue for now?
Closing as we have adopted this issue in the new DIDWG repo.
Thanks, I'll move the discussion over there.
Putting a place holder here to bring up a discussion to find out if standard conventional use of did doc service endpoints should describe application layer (e.g. microblogging service, filestorage service, homepage service, music playlist service, gift registry service) instead of a transport layer (e.g. HTTP/HTTPS, FTP, Bluetooth, SMTP, NFC). This would be useful to figure out and describe within the DID spec to set good expectation of service endpoints and their usage.