sec:authenticationMethod != sec:authentication
Closed this issue · 13 comments
IRIs for verification methods in did core context are not correct.... https://w3c-ccg.github.io/security-vocab/#authentication
Yeah, it should be "sec:authenticationMethod". The simple term "authentication" maps to "sec:authenticationMethod" (this is how it's been in software and contexts for years).
@dlongley for the current (RDF) vocabularies and constraint files (in #183) I only used sec:authenticationMethod. The only place where authentication term appears is in the context file. In other words, at least in those vocabulary files, sec:authentication does not exist (nor does did:authentication). That is then correct, isn't it?
@iherman, that's right. It looks like the only problem is with the draft security vocab document here:
https://w3c-ccg.github.io/security-vocab/#authentication
Which should be simple enough to fix and is unrelated to #183.
@OR13, open an issue on the security-vocab repo and link to this one. Then this one can be closed.
+1 to @dlongley. There are, I believe, serious issues with the security vocab document*, but that is not the responsibility of this WG and/or the registry document. I believe the DID vocabulary files and context files are all right and this issue should be closed.
* Formally, the security vocab document is a misnomer. It does not define a vocabulary, it specifies, essentially, the JSON-LD context file. For DID the context file and the vocabulary specification are separate, and the same should be done with the security vocabulary. The discrepancy between authentication and sec:authenticationMethod is just a visible tip of the iceberg.
Cross linked, but unclear how to resolve: w3c-ccg/security-vocab#91
Tell me what to do.
Cross linked, but unclear how to resolve: w3c-ccg/security-vocab#91
Tell me what to do.
From my point of view: the same work should be done as what we did for DID. Ie, conceptually:
- specify a vocabulary document with a proper RDF specification in RDF(S), with serializations in JSON-LD and in Turtle, and an HTML file that describes the vocabulary items. That vocabulary contains
sec:authenticationMethodand only that. - specify a separate JSON-LD context file and, possibly, a human-readable short description thereof, that defines a mapping from the JSON-LD terms to their equivalents in the formal vocabulary. That contains
sec:authenticationand only that.
Obviously, bits and pieces are already in the current document, so the human-readable part can be done by re-engineering the current document. The context file itself is also present, of course. The vocabulary files must be created.
Caveat: I speak with my (former) Semantic Web hat on...
I think I'm running into a problem related to this, but I'm really not that knowledgeable on JSON-LD and how it works under the hood so I'm not sure.
A controller object is created from a resolved did document, but the authentication keyword is resolved to sec:authenticationMethod by the linked data processor (while the others keep their simple term)
Due to this the controller proof purpose check I wrote (read: copied from vc.js authentication keys. Is it correct that this is related to this issue?
Commenting the line from the local DID context I use for testing solves the issue:
"authentication": "sec:authenticationMethod",
@TimoGlastra the problem you are reporting is likely due to the way frame uses the context to find the correct verification method. this example works for me:
https://did.key.transmute.industries/did:key:z6MktZ82N6qNh8ocwFpZvdSoM4X3871cg4v4PoDVAPnBXNvg
https://github.com/w3c/did-spec-registries/blob/master/vocabs/v1/context.jsonld#L34
I used the wrong context. Sigh...
Thanks!