WIP: Verifiable Credential (VC) -based Capabilities #1354
Conversation
| { | ||
| "prefix": "multikey", | ||
| "namespace": "https://w3id.org/security#", | ||
| "preserveContextUri": true, | ||
| "jsonldContext": "https://w3id.org/security/multikey/v1" | ||
| } |
There was a problem hiding this comment.
There is already a sec ontology with the same namespace.
It would probably be better to improve the jsonldContext property of this ontology.
There was a problem hiding this comment.
Okay, thanks :)
My main objective here was to have a place where the constant https://w3id.org/security/multikey/v1 is defined (and can be used in the get re-framing with that context).
But then, a different location is probably better for defining this constant?
There was a problem hiding this comment.
What do you mean by "constant" ? The URL https://w3id.org/security/multikey/v1 exist and is valid as a JSON-LD context.
| // Context MUST include multikey context. | ||
| '@context': multiKey.jsonldContext, | ||
| '@id': resource.id | ||
| } |
There was a problem hiding this comment.
If the multikey is integrated into the sec ontology, and the sec ontology is included by default (I think it is, because it is required for ActivityPub), then you probably don't need to do reframing ?
There was a problem hiding this comment.
My concern was that dc:updated or other properties might be part of that resource and just replacing the context would result in invalid jsonld. What do you think?
There was a problem hiding this comment.
If the JSON-LD context above is included in the default context (eg. https://mypod.store/.well-known/context.jsonld), then you will have no problem to display dc:updatedas well as the multikey predicate.
There was a problem hiding this comment.
Ah sorry! I had the comment wrong. It should say "Context MUST equal multikey context." -- the library requires the context to be exactly "https://w3id.org/security/multikey/v1"....
There was a problem hiding this comment.
Ah, that sucks... Why is that ? Contexts are only a way to format data, the URL should never be mandatory. We explicitly use the ActivityStreams context because most ActivityPub servers are too dumb in validation (they treat JSON-LD as JSON), but a library handling RDF data should be more flexible. Did you try to do without this context anyway ?
On our side, an ontology with the same namespace cannot have different prefixes, that doesn't make sense (and I'm not even sure it would work). Instead of definining our own "sec" context, we wanted at first to use the JSON-LD context https://w3id.org/security/v1 (which is what is used by Mastodon) ... but the problem is that this context redefine "dc:created" and "dc:creator" (but not "dc:updated") and so it breaks a lot of code.
Maybe an intermediary solution (if really the library cannot be more intelligent) would be to adapt the SemApps ontologies services so that it can have custom context (the one that is integrated into eg https://mypod.store/.well-known/context.jsonld) + external files. Right now preserveContextUri is either true or false, but maybe we need something more flexible... 🤔
There was a problem hiding this comment.
Did you try to do without this context anyway?
Yep, the library throws an error in that case. I think this is done due to security concerns (overriding property names?)
There was a problem hiding this comment.
Reading those notes, the implementation seems to be too strict here though. I filed an issue.
digitalbazaar/ed25519-multikey#15
https://www.w3.org/TR/controller-document/#json-ld-context
https://www.w3.org/TR/controller-document/#Multikey
There was a problem hiding this comment.
Maybe an intermediary solution (if really the library cannot be more intelligent) would be to adapt the SemApps ontologies services so that it can have custom context (the one that is integrated into eg https://mypod.store/.well-known/context.jsonld) + external files. Right now preserveContextUri is either true or false, but maybe we need something more flexible... 🤔
Right now, I'm very time constrained and don't have an overview over those services. I will add it on the agenda for our next meeting.
There was a problem hiding this comment.
Turns out, I had an out of date version that was even stricter with the context. Now I can add our context too, as long as the multikey context is present.
| | `dc` | http://purl.org/dc/terms/ | | ||
| | `foaf` | http://xmlns.com/foaf/0.1/ | | ||
| | `ldp` | http://www.w3.org/ns/ldp# | | ||
| | `multikey` | https://w3id.org/security/multikey/v1 | |
There was a problem hiding this comment.
This is not the namespace, this is the JSON-LD context
| if (this.settings.vc !== false) { | ||
| this.broker.createService({ | ||
| mixins: [VCService], | ||
| settings: { | ||
| ...this.settings.vc | ||
| } | ||
| }); | ||
| } |
There was a problem hiding this comment.
The CoreService only include the minimum services to run a LDP+ActivtiyPub server.
We shouldn't include VC unless it is required by other services (but that shouldn't be the case).
Refactor capabilities to use VC, and refactor event invite features.