-
Notifications
You must be signed in to change notification settings - Fork 195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix JSON-LD Context Links #3
Comments
Blocked by perma-id/w3id.org#1638 |
this begs the question: if we are so dependent on those specifications, shouldn't we try to get into some agreements with the relevant CG (i.e., the Web Payment CG) that defines and maintains those context files and have some sort of joint control over them? As far as I could see, all the CG documents have been edited by @msporny, so this should be possible... (I do not know how active the Web Payment CG is and how wide the adoption of those specs are…) |
The Web Payments CG is inactive, the vocabularies have production deployments (some of them by Digital Bazaar). It's all redirected via w3id.org, and all the redirects can be updated to a new location. |
@msporny, but who controls those vocabularies if it comes to new terms, errors, etc? To be more direct, is there any reason why this WG would not take over the management of those? After all, they seem to have a central role in the WG's work, ie, the same level of control as for the core DID context file may be reasonable... (That is, of course, a WG's decision, cc-ing @brentzundel and @burnburn here...) |
The W3C CCG.
The DID Core context and DID Core Registry context make sense for this group to take control of. The Security contexts were meant to be picked up by a potential future Linked Data Security WG. There may be objections from W3C Members wrt. the Charter and us working on "security standards and protocols"... yes, those contexts are important for the DID WG and many of us are using those contexts. If we can get this group to publish those contexts and support the vocabularies, that's great (as long as control can be handed off to a future Linked Data Security WG). So, I'm in favor of putting the question to the group. |
+1 to that. As for the charter issue: my understanding is that the group is not supposed to develop new standards and protocols. But that is not what we are talking about: the context files just record the existing protocols by assigning URLs to them for unambiguous references. That is all... |
Proposal 1: https://github.com/w3c/did-core-registry hosts versioned json-ld, json-schema and cbor definitions in machine readable format, with minimal human readable documentation, that mostly links to did core repo or other web sources for human readable vocabulary. w3id.org and w3.org URIs point to the did-core-registry repo. Proposal 2: https://github.com/w3c/did-core-registry hosts json schema, did core hosts json-ld, w3id.org and w3.org point to various separate locations. which may or may not have human readable documentation associated with the machine readable definitions. (sorta what we have today) I'm in favor of proposal 1. |
your proposal 1 sounds reasonable to me. |
Once, #11 is merged, the context directory of this repo will be the same as the context directory of did-core, and we can change the HTTP redirects to point here... we are almost there... |
I agree that this needs to be addressed. For one thing w3c/did-core#23 is blocked on this. |
@msporny says: We are making good progress on on this item, w3id.org was fixed up, making redirects now, we have access for all JSON-LD contexts and vocabularies now, not blocked anymore AFAICT. |
At which point is it appropriate to remove the context files from the did-core repo? |
so, who audits the security of these vocabularies? |
(The context files have been removed from the did-core repo.) The original issue raised has been resolved I think so this issue can be closed, unless we're leaving it open to discuss @jonnycrunch's question about security audit. |
I'm closing this, its been resolved. |
We have the following JSON-LD Contexts which are part of the did core context:
We have the following vocabulary URIs:
We have blocks of JSON schema, that need to point to vocabulary definitions, like
Note that https://w3c.github.io/did-core-registry/#Ed25519VerificationKey2018 is almost... https://w3id.org/security/v1#Ed25519Signature2018
(pulled from https://w3c-dvcg.github.io/ld-signatures/#signature-suites)...
This kind of broken linkage / confusing stuff is what I am trying to fix.
If a term like
Ed25519VerificationKey2018
is going to be registered in the did-core-registry, every link to external documentation needs to be fulfilled.We cannot accept PRs to define terms, that contain broken links.
I consider the current state of https://w3id.org/security to be a blocking dependency of registering properties correctly.
We need to fix that, and then have:
https://w3c.github.io/did-core-registry/#Ed25519VerificationKey2018 point to a block which in turn links to:
(JSON-Schema)
(JSON-LD)
Before we attempt to do anything else, I'd like to fix w3id.org defintions, so they work... because they currently dump people on a website from 2016: https://web-payments.org/vocabs/security#Ed25519Signature2018
We need to update w3id.org to point to https://w3c-ccg.github.io/security-vocab/ before we can proceed... then I can fix links there, and then add properties here, so we never add an undocumented property to the registry.
The text was updated successfully, but these errors were encountered: