search

w3c / vc-data-integrity

W3C Data Integrity Specification
https://w3c.github.io/vc-data-integrity/
Other
42 stars 19 forks source link

Inconsistencies in our URLs #177

Closed iherman closed 1 year ago

iherman commented 1 year ago

Inconsistencies in our URLs

At the moment, our spec has:

There is an inconsistency: is the security spec bound to w3id.org or to https://www.w3.org/ns/data-integrity? After all, the vocabulary and the @context file are the two sides of the same Linked Data coin; these URLs should be consistent.

For better or for worse, the security vocabulary has been bound to https://w3id.org/security. As far as I know, the reason is historical (https://www.w3.org/ns was not available at the time when w3id.org was created). Changing https://w3id.org/security# to something like https://www.w3.org/ns/data-integrity/vocab# is something we SHOULD NOT do in my view. As a general guideline in the Linked Data world, changing the URL of a deployed vocabulary is a no-no, because this would create mayhem for all the deployed Linked Data referring to those URLs. (The Linked Data world is full of vocabulary URLs that, though ugly and difficult to remember, are just kept for similar reasons, think of http://www.w3.org/1999/02/22-rdf-syntax-ns# or http://xmlns.com/foaf/0.1/).

As I said, we create an inconsistency if the vocabulary is referred to from one base URL-s and the context file from another one. This is certainly not the way https://www.w3.org/ns should be used. We should not add a new /ns space just for the purpose of a @context file if the vocabulary file is referred to elsewhere.

I would therefore propose to use the old URLs in the examples as THE URL for the @context files as well, and not use https://www.w3.org/ns/data-integrity/.

One argument of using /ns for the @context file might be that, eventually, we would store the final @context file there and thereby relying on W3C's safe environment. But, beyond the storage of the hash values, we can reinforce that by deciding to put, eventually, i.e., when we finalize our specification, the @context file to our date space, e.g., https://www.w3.org/2024/data-integrity/v1.jsonld. This would be invisible to developers anyway, because https://w3id.org/security/data-integrity/v1 is merely a redirection service, but would provide the security we need (we should do the same with all our vocabulary and context files, b.t.w.).

@msporny @pchampin @TallTed

msporny commented 1 year ago

https://www.w3.org/2024/data-integrity/v1.jsonld

Yes, I guess that would be fine now that we have hash values for all the context files and have normative text that says you should treat those documents as cached anyway.

So, just to be clear, we're saying these things:

All that makes sense... but what do we do with:

"@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],

... those JSON-LD Context files /could/ live at the URLs above, or the URLs above could provide a proxied file to the date-stamped JSON-LD Contexts on W3C's servers? Thoughts?

msporny commented 1 year ago

I guess we don't have to wait for an answer on https://www.w3.org/ns/credentials/v2 to make progress on the Data Integrity URLs... I can make a PR to update those accordingly.

iherman commented 1 year ago

https://www.w3.org/2024/data-integrity/v1.jsonld

Yes, I guess that would be fine now that we have hash values for all the context files and have normative text that says you should treat those documents as cached anyway.

So, just to be clear, we're saying these things:

  • Only vocabulary documents will live at https://www.w3.org/ns/

Whether the documents "live" in /ns, or whether they live in date space and /ns is a redirection, is a detail. There is no reason why @context files would not be physically at /ns as well. The point is that we should be consistent with the URLs, and that the corresponding .../ns/… URL would be the user facing URL of that content. Put it another way, /ns is not supposed to be simply a parking place for files for the sake of long term security at W3C. That is why we have date spaces.

  • Any document that we provide a hash value for will live at a static, date-stamped W3C URL once we go into Proposed Rec (this includes machine-readable vocabulary documents and JSON-LD Context files).

Yes.

  • The https://w3id.org/security/ paths will be redirected towards those static date-stamped W3C files (once we go into PR).

Yes.

All that makes sense... but what do we do with:

"@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],

... those JSON-LD Context files /could/ live at the URLs above, or the URLs above could provide a proxied file to the date-stamped JSON-LD Contexts on W3C's servers? Thoughts?

You slightly misunderstood what I said (see my reply above): I do not see any problems per se to store a context file at /ns, if that URL coincides with the user facing URL of that content. My issue is consistency. So we can store, at the end of the process, the credential context files at /ns without further ado if we want, or store them at date space.

However, before somebody tells me: there is an inconsistency, because the user facing URL for the credential vocabulary is https://w3.org/2018/credentials# and not https://www.w3.org/ns/credentials#. Well... If we started from scratch, I would say we should follow the same approach, and indeed use the user facing URL https://www.w3.org/ns/credentials# as the URLs for the credential vocabulary. But then we would break the aforementioned point of not changing vocabulary URLs for deployed URLs. So, I am holding my nose and saying that we should leave things as they are. We can express our penitence regularly for our past mistakes, but leave it as is…

With that penitence well expressed, I may prefer to store the context files alongside the vocabulary files under 2018/credentials/ when the time comes, just to simplify our own administration. But that decision can be postponed until we go to Proposed Rec.

msporny commented 1 year ago

The point is that we should be consistent with the URLs, and that the corresponding .../ns/… URL would be the user facing URL of that content. Put it another way, /ns is not supposed to be simply a parking place for files for the sake of long term security at W3C. That is why we have date spaces.

Ah! Ok, I did partially misunderstand. So, just to summarize, these are all of our developer-facing context file URLs (across all versions of all specifications that VCWG has/will publish):

... and our developer-facing vocabulary file URLs:

After we reach the Proposed Recommendation state, each one of those URLs, when dereferenced, will result in a static file served from W3C date-stamped space.

Is that correct, @iherman?

msporny commented 1 year ago

PR #186 has been raised to address this issue. This issue will be closed once PR #186 has been merged.

iherman commented 1 year ago

The point is that we should be consistent with the URLs, and that the corresponding .../ns/… URL would be the user facing URL of that content. Put it another way, /ns is not supposed to be simply a parking place for files for the sake of long term security at W3C. That is why we have date spaces.

Ah! Ok, I did partially misunderstand. So, just to summarize, these are all of our developer-facing context file URLs (across all versions of all specifications that VCWG has/will publish):

  • https://www.w3.org/2018/credentials/v1
  • https://www.w3.org/2018/credentials/examples/v1
  • https://www.w3.org/ns/credentials/v2
  • https://www.w3.org/ns/credentials/examples/v2
  • https://w3id.org/security/data-integrity/v2
  • https://w3id.org/security/multikey/v1
  • https://w3id.org/security/jwk/v1

... and our developer-facing vocabulary file URLs:

  • https://www.w3.org/2018/credentials#
  • https://www.w3.org/ns/credentials/examples#
  • https://w3id.org/security#

After we reach the Proposed Recommendation state, each one of those URLs, when dereferenced, will result in a static file served from W3C date-stamped space.

Is that correct, @iherman?

These are the context file URLs. Additionally, we have

for the two vocabularies.

msporny commented 1 year ago

PR #186 has been merged, closing.