Skip to content
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

Closed
OR13 opened this issue Feb 16, 2020 · 15 comments
Closed

Fix JSON-LD Context Links #3

OR13 opened this issue Feb 16, 2020 · 15 comments
Assignees
Labels
critical-blocker Something which is preventing PRs from merging, or being opened, and which needs consensus.

Comments

@OR13
Copy link
Contributor

OR13 commented Feb 16, 2020

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

{
    "$id": "/did-core.publicKey.Ed25519VerificationKey2018",
    "type": "object",
    "title": "Ed25519VerificationKey2018",
    "description": "https://w3c.github.io/did-core-registry/#Ed25519VerificationKey2018",
    "properties": {
      "id": {
        "title": "Public Key ID",
        "type": "string",
        "required": false,
        "example": ["did:example:123#primary"]
      },
      "type": {
        "title": "Public Key Type",
        "type": "string",
        "enum":["Ed25519VerificationKey2018"],
        "required": true,
        "example": ["Ed25519VerificationKey2018"]
      },
...

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.

@OR13
Copy link
Contributor Author

OR13 commented Feb 16, 2020

Blocked by perma-id/w3id.org#1638

@iherman
Copy link
Member

iherman commented Feb 17, 2020

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…)

@msporny
Copy link
Member

msporny commented Feb 17, 2020

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.

@iherman
Copy link
Member

iherman commented Feb 18, 2020

@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...)

@msporny
Copy link
Member

msporny commented Feb 18, 2020

@msporny, but who controls those vocabularies if it comes to new terms, errors, etc?

The W3C CCG.

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...

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.

@iherman
Copy link
Member

iherman commented Feb 18, 2020

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...

@OR13
Copy link
Contributor Author

OR13 commented Feb 27, 2020

@msporny

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.

@OR13 OR13 self-assigned this Feb 27, 2020
@iherman
Copy link
Member

iherman commented Feb 28, 2020

@OR13

your proposal 1 sounds reasonable to me.

@OR13
Copy link
Contributor Author

OR13 commented Mar 13, 2020

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...

@OR13 OR13 added the critical-blocker Something which is preventing PRs from merging, or being opened, and which needs consensus. label Mar 24, 2020
@selfissued
Copy link

I agree that this needs to be addressed. For one thing w3c/did-core#23 is blocked on this.

@msporny
Copy link
Member

msporny commented Mar 31, 2020

@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.

@rhiaro
Copy link
Member

rhiaro commented Mar 31, 2020

At which point is it appropriate to remove the context files from the did-core repo?

@jonnycrunch
Copy link
Contributor

so, who audits the security of these vocabularies?

@rhiaro
Copy link
Member

rhiaro commented Jun 1, 2020

(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.

@OR13
Copy link
Contributor Author

OR13 commented Jul 10, 2020

I'm closing this, its been resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
critical-blocker Something which is preventing PRs from merging, or being opened, and which needs consensus.
Projects
None yet
Development

No branches or pull requests

6 participants