Skip to content
This repository has been archived by the owner on Oct 29, 2019. It is now read-only.

Are service endpoints transport layer or application layer specific? #104

Closed
kdenhartog opened this issue Sep 28, 2018 · 3 comments
Closed
Labels

Comments

@kdenhartog
Copy link

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.

@rhiaro rhiaro added the clarify There is consensus, but the spec needs clarifying label Jan 25, 2019
@peacekeeper
Copy link
Member

@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 (#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?

@rhiaro rhiaro added question and removed clarify There is consensus, but the spec needs clarifying labels Aug 16, 2019
@jandrieu
Copy link
Contributor

Closing as we have adopted this issue in the new DIDWG repo.

@kdenhartog
Copy link
Author

Thanks, I'll move the discussion over there.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants