Add README for context directory. #91
Conversation
|
@msporny which context file should I use to set up the redirection? There are two files in the |
This one (as a general live redirect pre-CR): ...did-core/contexts/did-v1.jsonld |
Co-Authored-By: Ted Thibodeau Jr <[email protected]>
|
|
||
| The current system for DID context versioning is: | ||
|
|
||
| 1. Use `https://www.w3.org/2019/did/v1` as an alias to the latest version of the |
There was a problem hiding this comment.
The specific file that this resolves to should be linked here. We should also make it clear that file is meant to be the only one that received PRs for new property definitions.
There was a problem hiding this comment.
We need to make it clear how to contribute to context definitions, by providing the location of the files that are acceptable to edit, and instructions for how to provide human readable documentation.
If you are defining a property on sec I think this is currently not possible to do... I'd like to see all the context files and definitions needs to support dids hosted in this repo.
If people have to go crawling github and redirects, the documentation will never be up to date.
Yes, that'd be great. There were a number of companies at W3C, Microsoft being one of them, that objected to this group working on anything "security related". There is a section in our charter called "Out of Scope" that says "Out of Scope: Defining specific authentication, signing, or cryptography mechanisms. Scope is limited to defining extension points for these mechanisms." -- now, it's arguable that we could specify a security context within this group, but it's really the wrong group to do that... that should be up to the upcoming Linked Data Security WG. I'd prefer to do that work in this group just so there is a normative reference, but there be political dragons here. |
|
Just to be clear, Microsoft objected to a common vocabulary around the expression of key material and signing algorithms (security related concepts)? If thats true, I'd like Microsoft's objection in writing and publicly visible for all to see... thats completely antithetical to what we are doing here... @csuwildcat @selfissued can you provide clarity on how you think a centralized registry is different from defining security related terms in a single location? I'm having trouble seeing how these are different. |
|
To my knowledge, Mike and others did suggest a common vocabulary/index for
key material and related things: the JWK registry. Anything else you'd need
to ask them about, as it hasn't been my on my plate.
…On Fri, Feb 7, 2020, 8:36 AM Orie Steele ***@***.***> wrote:
Just to be clear, Microsoft objected to a common vocabulary around the
expression of key material and signing algorithms (security related
concepts)?
If thats true, I'd like Microsoft's objection in writing and publicly
visible for all to see... thats completely antithetical to what we are
doing here...
@csuwildcat <https://github.com/csuwildcat> @selfissued
<https://github.com/selfissued> can you provide clarity on how you think
a centralized registry is different from defining security related terms in
a single location?
I'm having trouble seeing how these are different.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#91>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABAFSQQIOFG4MKCPTESTP3RBWEYDANCNFSM4JGITB2Q>
.
|
|
So its Microsoft's official position that the only acceptable registry is one thats not machine readable and looks like a text document, https://tools.ietf.org/html/rfc7517 ? You guys need to put your position in writing. |
|
I'm not aware of any objections on Microsoft's part to using registries to enable a common interpretation of security-related identifiers, such as algorithm names and meanings, etc. Quite to the contrary! We helped author such registries, including the numerous registries at https://www.iana.org/assignments/jose/jose.xhtml and https://www.iana.org/assignments/jwt/jwt.xhtml. To support the use of secp256k1 by this and other communities, I'm registering identifiers for using it in the specification https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms. Others can do the same for algorithm identifiers (and other identifiers) that they care about. |
|
I will certainly encourage the folks responsible for those particular specs
to do so.
…On Fri, Feb 7, 2020, 9:51 AM Orie Steele ***@***.***> wrote:
So its Microsoft's official position that the only acceptable registry is
one thats not machine readable and looks like a text document,
https://tools.ietf.org/html/rfc7517 ?
You guys need to put your position in writing.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#91>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABAFSV766U4EWCYISCUIUTRBWNTBANCNFSM4JGITB2Q>
.
|
|
I'd like us to agree to a machine readable format for the did core registry... we have JSON-Schema and JSON-LD, we can programmatically generate xhtml, text or pdf or whatever we want from them... Can we get a clear yes from Microsoft to supporting a machine readable format for the did core registry? |
|
It's not clear to me that a machine-readable registry is any more necessary than a machine-readable version of the DID Core spec. In both cases, it's programmers who are the audience of the specifications that they reference and it's programmers who write code to implement and conform to the specified behaviors, whether they're specified in the core spec or specs referenced from registries established in the core spec. Don't get me wrong, I'm not philosophically opposed to machine-readable data formats, but I'd want to understand why they're necessary before deciding to also have them. The human-readable registries at the IETF have worked very well in practice, as one useful data point. |
|
A machine readable version of the registry will facilitate interoperability via software tests. Spec compliance could be testable. You can't easily test conformance with xhtml or text... the process of verifying JOSE implementations is tedious and involves things like: https://tools.ietf.org/html/rfc7520 The first thing an implementer does is convert these examples to structured data that can be imported into a test suite. https://tools.ietf.org/html/rfc7520#section-3.3 In a world where we published JSON Schema & JSON-LD definitions for the core registry, you could pass a json object, and instantly know if it was core compliant, linked data, or extended... With all the property definitions also being human readable via an xhtml or text version derived from the machine readable one. interoperability compliance should be testable, we should make it as easy as possible by using a machine readable format for the did core registry, and generate the human readable documentation from it. |
I strongly support the position that @OR13 is making above. |
|
Moving this discussion to an issue: #187 IMO we should consider closing all PRs that would be impacted by the registry changes until we have a foundation to build on... including this one. |
|
We should be adding this to https://github.com/w3c/did-core-registry context folder. I think this is blocked by: w3c/did-extensions#13 |
|
@msporny I suggest closing this, I've already moved the content to w3c/did-extensions#11 |
If @dmitrizagidulin agrees (he opened the original PR), we can close this. |
|
Closing, PR overtaken by events. |
Migrated PR from w3c-ccg/did-spec#272