Re: VC Context and Security context are in conflict

I am also interested in Kyle's proposal to separate the credential
context from the security context.

For example, we found that RsaSignature2018 is not correctly defined in
the 2018-credential-v1 context:
https://www.w3.org/2018/credentials/v1

It uses the "sec" and "xsd" namespaces, but they are not defined in
RsaSignature2018, so if you use RsaSignature2018 outside of a
VerifiableCredential, it won't work.

We fixed this in the security-v3 context:
https://github.com/w3c-ccg/security-vocab/commit/9c027e20ac52b070ddd5e8475f9e414806ba6a03

But now the definitions of RsaSignature2018 in 2018-credential-v1 and
security-v3 are in conflict, and there may be errors when redefining
protected terms.

Therefore, would it make sense to start working on a new
2020-credential-v1 context (as Kyle suggested), which doesn't repeat the
same terms that are already in security-v3?

Markus

On 09.10.20 00:52, Tobias Looker wrote:
> > Before doing that, an effort should be made to clean up the security-v3
> context. It does not follow best practices now that JSON-LD 1.1 is out
> (security-v2 was written before JSON-LD 1.1 existed). Cleaning up the
> security-v3 context to follow best practices may result in eliminating
> any conflicts without needing any changes to the VC context.
>
> +1 to this, w.r.t best practises for context definitions, is here
> <https://w3c.github.io/json-ld-bp/#contexts> the best place to look
> and follow?
>
> Thanks,
> Mattr website <https://mattr.global>     
> *Tobias Looker*
> Mattr
> +64 (0) 27 378 0461
> tobias.looker@mattr.global <mailto:tobias.looker@mattr.global>
> Mattr website <https://mattr.global>  Mattr on LinkedIn
> <https://www.linkedin.com/company/mattrglobal>  Mattr on Twitter
> <https://twitter.com/mattrglobal>  Mattr on Github
> <https://github.com/mattrglobal>
>
>
> This communication, including any attachments, is confidential. If you
> are not the intended recipient, you should not read it - please
> contact me immediately, destroy it, and do not copy or use any part of
> this communication or disclose anything about it. Thank you. Please
> note that this communication does not designate an information system
> for the purposes of the Electronic Transactions Act 2002.
>
>
> On Fri, Oct 9, 2020 at 3:46 AM Dave Longley
> <dlongley@digitalbazaar.com <mailto:dlongley@digitalbazaar.com>> wrote:
>
>
>     On 10/8/20 1:00 AM, Kyle Den Hartog wrote:
>     > The 2018 context for verifiable credentials defined |the following 4
>     > terms which end up causing conflicts with the v1, v2, and now
>     > v3-unstable security contexts.
>     >
>     > EcdsaSecp256k1Signature2019|,
>     > |EcdsaSecp256r1Signature2019|, |
>     > Ed25519Signature2018|, |
>     > RsaSignature2018
>     >
>     > |
>     > |Would it make sense to publish a new context which removes
>     these terms
>     > under the URL:
>     >
>     > |
>     > |https://www.w3.org/2020/credentials/v1
>     >
>     > |
>     > |Which would then allow for the VC model to properly be extended
>     with
>     > new LD Proof signature suites using the security vocab.
>
>     Before doing that, an effort should be made to clean up the
>     security-v3
>     context. It does not follow best practices now that JSON-LD 1.1 is out
>     (security-v2 was written before JSON-LD 1.1 existed). Cleaning up the
>     security-v3 context to follow best practices may result in eliminating
>     any conflicts without needing any changes to the VC context.
>
>     >
>     > |
>     > |What would I need to do to make this work? From the looks of it the
>     > 2018 context is hosted directly by w3.org <http://w3.org>
>     <http://w3.org> rather than
>     > redirecting to a github pages site. Is this something that Ivan
>     has to
>     > do or is it something where I just need to get the new context
>     added to
>     > a github repo and have Ivan handle the redirects?
>     >
>     > |
>     > |- Kyle
>     > |
>     > |
>     >
>     >
>     > |
>     >
>     > This communication, including any attachments, is confidential.
>     If you are not the intended recipient, you should not read it -
>     please contact me immediately, destroy it, and do not copy or use
>     any part of this communication or disclose anything about it.
>     Thank you. Please note that this communication does not designate
>     an information system for the purposes of the Electronic
>     Transactions Act 2002.
>     >
>
>
>     -- 
>     Dave Longley
>     CTO
>     Digital Bazaar, Inc.
>
>
> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.