W3C home > Mailing lists > Public > public-credentials@w3.org > March 2018

Re: Please review simple signed VC

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Sat, 10 Mar 2018 13:15:03 -0500
To: public-credentials@w3.org
Message-ID: <27957b08-cafc-18f7-e4cd-ec1b99275e71@digitalbazaar.com>
On 03/10/2018 02:34 AM, Christopher Allen wrote:
> I ran this very simple, signed. web-of-trust, verifiable credential by a
> few folk at this week’s #RebootingWebOfTrust to confirm that it conforms
> to our latest thoughts, for possibly adding to a new CCG Valid Samples repo.
> 
> Some notes:
> 
> * Basically this verifiable credential says that DID “…tyke” (my testnet
> DID) names locally the DID “…xnhn” as “KimH” (this DID is a testnet DID
> created by Kim Hamilton).
> 
> * It uses a bitcoin-based DIDs, and both of these are real and functional.
> 
> * The public key can be confirmed in the Bitcoin blockchain, the
> signature is correct, and key has not been revoked by the DID.
> 
> * It uses valid schema.org <http://schema.org> and security schemas. At
> some point we should have our own schema, as alternateName should
> instead be edgeName as per new pet names paper.
> 
> * This credential does specify the issuer inside the claim itself,
> rather than relying on defaulting the issuer to be the creator of the
> signature.  This is important for future counter claims and witnesses.
> 
> * The signature is now called proof, not signature.
> 
> * The creator in the proof points to the public key in the DID, but
> doesn’t include the actual public key.
> 
> {
>   "@context": [
>     "https://schema.org/",
>     "https://w3id.org/security/v1"
>   ],
>   "issuer": "did:btcr:xyv2-xzyq-qqm5-tyke",
>   "claim": {
>     "id": "did:btcr:xkyt-fzgq-qq87-xnhn",
>     "alternateName": "KimD"
>   },
>   "proof": {
>     "type": "EcdsaKoblitzSignature2016",
>     "created": "2018-03-08T21:09:36Z",
>     "creator": "did:btcr:xyv2-xzyq-qqm5-tyke:#keys-1",
>     "signatureValue":
> "H3yEiysgAZ9KjCL5pd4PHKZRQ8UAN9PlkjSEb7xplXP+BLQ7yWZuplIGPCAh7943upqa7KgXfUqBDxW4oyXcbAo="
>   }
> }
> 
> Any other comments before I put it in the Valid Sample repo?

A few comments:

1. It should use "https://w3id.org/security/v2" (not "v1") for the
"proof" term.

2. We've introduced a new term "proofPurpose" in the new signature
suites we've created this year (RsaSignature2018 and
Ed25519Signature2018). This is a field in the signature that allows the
signature author to indicate the reason for the signature -- and that
reason doubles as a term itself that appears in the DID owner's document.

With LD Object Capabilities, we use this with granting or invoking
capabilities, where the "proofPurpose" value is either "grantCapability"
or "invokeCapability" (respectively). These terms then appear in the DID
Document and reference the key used in the signature -- demonstrating
that it was valid *for that purpose*. A signature can also use
"proofPurpose" with the "authentication" value to indicate the purpose
is for DID-based authentication (where, again, the key used must be
referenced in the "authentication" field in the DID Document).

The EcdsaKoblitzSignature2016 signature suite doesn't support this, but
a new one could be minted that would. The "proofPurpose" could be
"issueCredential" -- another term we could mint and use to help enforce
the purpose of the signature/proof and isolate/manage the keys permitted
to sign for that purpose in the DID Document.

3. Markus mentioned using "jws" instead of "signatureValue" -- but this
depends on the signature suite. EcdsaKoblitzSignature2016 uses
"signatureValue" -- so I think that's correct (it doesn't actually use
JWS). Alternatively, a new 2018 version of the koblitz signature suite
that's compatible with JWS could be released. The only changes would
likely be using a JWS detached signature and building on top of the new
Linked Data Signature/Proofs changes that allow "proofPurpose" to be used.

4. The "claim" and "issuer" terms are defined in the
"https://w3id.org/credentials/v1" context, which does not appear in the
above verifiable credential -- and it is sadly out of date at this
point. That context has not been kept inline with the changes made to
the VC data model. I would not expect it to work quite right with the
changes we've been pushing forward quickly in the VCWG and elsewhere. We
should mint a new context or update it. There are some legacy
credentials using the credentials-v1 context, so I think it would be
better to just do something new (new name entirely or do a
"credentials/v2").

We should really get some agreement on this point and make the changes
soon. But we need to keep in mind that as soon as we do, people
*will* implement, which is both a blessing and curse (if things change
in significant ways).

So -- in order for the example to be valid, I think, at a minimum, #1
and #4 need to be addressed. To address #1, we also currently need
an early version announcement in the JSON-LD 1.1 context -- something I
believe the JSON-LD CG is presently working to eliminate the need for:

{
  "@context": [
    {"@version": 1.1},
    "https://schema.org",
    "https://w3id.org/security/v2"
  ],
  ...
}


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
Received on Saturday, 10 March 2018 18:15:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:25 UTC