Are service endpoints transport layer or application layer specific?

[brentzundel]

@kdenhartog moved from CCG (w3c-ccg/did-spec#104)

[kdenhartog]

Thanks for cross referencing this.

For context, one of the reasons I brought this up originally was because the DID spec examples used many application level service endpoints. In Hyperledger Aries, we've been thinking about service endpoints as a pipe to pass any number of semantically diverse messages between entities which led to my question.

To highlight the problem there's a few different ways that I believe service endpoints can be used:

• As a RESTful service endpoint to describe one service
• As a generalized pipeline for semantically diverse messages (e.g. DIDComm or libp2p)
  • This could also be supported over a variety of transports for example libp2p supports the ability to receive messages directly over tcp port, over QUIC, or WebRTC which would allow the same message to be sent over multiple transport layers.
• As a generalized protocol endpoint (e.g. IP:XMPP port)

Some aspects of consideration:

I'm aware that it's out of scope to define a protocol for the identity layer, so I don't believe we can be overly prescriptive here. However, I think it would be useful to account for the variety of methods that a service endpoint can be used in non-normative examples. E.g. listing an IP address:port to describe a protocol port available to communicate with an entity.

Some security and privacy considerations:

One of the first things performed in a penetration test is a port scan to identify ports that are open which identifies potential attack vectors. Similarly, I suspect that in the future, attackers will leverage the DID Document service endpoints to identify the potential attack vectors of an entity. I think we should provide non-normative descriptions about the implications of being overly descriptive with service endpoints in DID Documents.

Additionally, there's a point of concern from a privacy standpoint as well that should be non-normatively described. For example, if a service endpoint is listed in the DID Document that is uncommon when compared to other DID Documents (extreme example: a REST endpoint used only for communicating military defense positions) then the DID Document can be evaluated to correlated the entity represented by the identifier. In this case, it could be used to identify that the identifier represents a military operative.

In total, I think it would be useful for this specification to go into greater detail highlighting the thinking behind how service endpoints should be used without going so far as to prescribe a protocol that must be used for DIDs.

[msporny]

@kdenhartog This seems like you're asking for explanatory text in the privacy and security considerations section as well as the section on service descriptions (elaborating on what they're used for, good uses for them, and potentially concerning uses for them). Is this correct? Are you asking for editorial changes, or something else?

[kdenhartog]

Yeah, I believe based on my current understanding of what is in scope for this spec we should only be making editorial statements for describing some of the privacy concerns related to service endpoints. I can commit to submitting a paragraph on the subject.

If we do go as far as making normative changes, I think it would be around constraining the strings used in the service endpoints to require it be something conformant to a URL(?). URL may not be the correct spec here, but the intended goal is to constrain this field enough, while still allowing for extensibility. What're your thoughts on adding some normative statements like this? @msporny @talltree @peacekeeper

[msporny]

@kdenhartog wrote:

If we do go as far as making normative changes, I think it would be around constraining the strings used in the service endpoints to require it be something conformant to a URL(?). URL may not be the correct spec here, but the intended goal is to constrain this field enough, while still allowing for extensibility. What're your thoughts on adding some normative statements like this? @msporny @talltree @peacekeeper

If the normative statements are something to the effect of "a service endpoint MUST be a URL", then yeah, that should be easy enough.

There are possibly other (non DID spec) parameters that go in a service description that could have privacy/security impacts, we could explore those in these issues and then summarize the lessons learned in the security/privacy considerations section.

[talltree]

As much as I'd love to have a magic wand to avoid privacy or GDPR issues with service endpoints in DID documents...I personally believe it can't be done. It doesn't matter if we constrain the value of a serviceEndpoint property to a URL. You can stuff almost any kind of relatively short personal data in a URL if you want to.

That's not to say we shouldn't strongly recommend that in the Privacy Considerations section of the spec—as we currently do in Section 10.2: Keep Personally-Identifiable Information (PII) Private. I think we should beef that up to warn of including personal data in a service endpoint URL as well.

[kdenhartog]

To clarify I don’t think the constraint of service endpoints to URLs is about privacy. I think it’s an orthogonal point to the privacy point. Instead, the URL constraint is there to be more specific about what can go in service endpoints, which will clarify the original question of if they’re transport layer or application layer. If it’s set to a URL it can be both. The purpose in the non-normative statements would be to describe how no matter what is contained in that field it has the potential to leak information (as you pointed out). Would that make sense? Also, does a URL feel like the right constraint in this case or are there use cases where a URL won’t work and it would be better to constrain it to a URI instead?

…

On 15/10/2019, at 8:03 PM, Drummond Reed ***@***.***> wrote:  As much as I'd love to have a magic wand to avoid privacy or GDPR issues with service endpoints in DID documents...I personally believe it can't be done. It doesn't matter if we constrain the value of a serviceEndpoint property to a URL. You can stuff almost any kind of relatively short personal data in a URL if you want to. That's not to say we shouldn't strongly recommend that in the Privacy Considerations section of the spec—as we currently do in Section 10.2: Keep Personally-Identifiable Information (PII) Private. I think we should beef that up to warn of including personal data in a service endpoint URL as well. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

-- This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

[msporny]

Would that makes sense? Also, does a URL feel like the right constraint in this case or are there use cases where a URL won’t work and it would be better to constrain it to a URI instead?

Let's constraint it to a URL, we can always relax the constraint later. In general, our design philosophy has been that identifiers used in the id property MUST be URIs. serviceEndpoint is a bit different in that there is an expectation there that a protocol will be used to communicate with the serviceEndpoint, so a URL restriction seems like the right thing to do here (until someone comes up with a very good use cases where that doesn't happen).

[msporny]

As much as I'd love to have a magic wand to avoid privacy or GDPR issues with service endpoints in DID documents...I personally believe it can't be done. It doesn't matter if we constrain the value of a serviceEndpoint property to a URL. You can stuff almost any kind of relatively short personal data in a URL if you want to.

Completely agree. We should put this particular warning in the spec. @talltree, started a new issue here to track it: #72

[peacekeeper]

It has been proposed that the value of serviceEndpoint can itself be a DID: w3c/did-resolution#7. Just mentioning that, I don't think it changes anything that has been said in this thread.

The spec currently says the following:

The value of the serviceEndpoint property MUST be a JSON-LD object or a valid URI

[talltree]

I agree that a the value of a serviceEndpoint should be able to be a DID, which is why I think we should stick with the current text that it must be a URI. Again, that doesn't prevent any GDPR-style personal data issues, but at least it provides a technical validation check.

The part I'd like to revisit is allowing a JSON-LD object. Who has a use case for that? Would it be easier to just extend the service property if you need additonal description of a service endpoint?

[peacekeeper]

The part I'd like to revisit is allowing a JSON-LD object. Who has a use case for that? Would it be easier to just extend the service property if you need additonal description of a service endpoint?

In this case, we could make serviceEndpoint optional? I.e. if you have a serviceEndpoint then it MUST be a URI, but if you want you can also describe a service in other ways that don't involve a serviceEndpoint?

[ChristopherA]

In BTCR, a BTCR DID can only have one URL due to limitations of OP_RETURN in the bitcoin blockchain (80 chars max, 40 preferred).

If the OP_RETURN is a URL (not a hash) we use it as an "BTCR-Endpoint" pointing a SIGNED mutable json-ld object, with the first entry being the extension DID, and the remaining optional entries are public Verifiable Claims shared by the controller of the DID. If we ultimately can't put revoked keys in the extension DID (as proposed elsewhere) we will also put the revoked keys in that object as well. This whole package is signed with the single key from the bitcoin transaction (which can only have one).

If the OP_RETURN is a hash (we don't use multihash here as we do NOT want DID transactions to be censorable and many other protocols use hashes), it points to a immutable content-addressable hash (IPFS for now) which consists of an UNSIGNED, DID object. It doesn't have to be signed as in effect the blockchain signs it. It may list other IPFS hashes that contain public VCs and key revocation lists, but these are not endpoints in the same way the mutable URL-based BTCR DIDs are, as they too are immutable.

-- Christopher Allen

[msporny]

@kdenhartog wrote:

Yeah, I believe based on my current understanding of what is in scope for this spec we should only be making editorial statements for describing some of the privacy concerns related to service endpoints. I can commit to submitting a paragraph on the subject.

Hey @kdenhartog, can you please provide a PR that resolves the issue you raised? Once you do that we can refine it.

[kdenhartog]

Note I'm heading on vacation for two weeks, but intend to write a PR for this (possibly during some downtime). In the event I don't get to this before then this is why.

[kdenhartog]

Got a PR in for us to work off @msporny finally

Of note, I opted to not constrain to URLs for two reasons. One, I wasn't really sure what the best way to reference them similar to how we say

normalized according to the rules in section 6 of [[RFC3986]]

Two, I felt like based on the discussion about URLs in #218 it was probably best to leave it at URIs due to the mismatch of expectations that URLs are only for HTTP(S) links. My intention for service endpoints is that I can use any scheme, not necessarily just HTTP(S).