Re: Please review simple signed VC

Dave.

Will you open a couple issues for these items so we can track them. Dan
will assign them to Simone. I want to focus on reconciling our entries in
schema.org but you may want to track the other items as well...

On Sat, Mar 10, 2018 at 23:47 Dave Longley <dlongley@digitalbazaar.com>
wrote:

> 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 <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__schema.org&d=DwIDaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=c4q9lgzRqBL5G5I6b1rBQkoITiMmTStNFwMIwCrGyJQ&s=sp9gAc6LG4PL5fx4PInnVINK87hXnku99VFONDd08a0&e=>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__schema.org_&d=DwIDaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=c4q9lgzRqBL5G5I6b1rBQkoITiMmTStNFwMIwCrGyJQ&s=zKTIRzXepwUEnuAgrQOWFGGkKD54Pvg8gJjEnZxUtPg&e=
> ",
> >     "
> https://urldefense.proofpoint.com/v2/url?u=https-3A__w3id.org_security_v1&d=DwIDaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=c4q9lgzRqBL5G5I6b1rBQkoITiMmTStNFwMIwCrGyJQ&s=JYr0RtWlWF1O-4Nwr4LDxAFVrVSKb0KkZ1lBiL5sjMI&e=
> "
> >   ],
> >   "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://urldefense.proofpoint.com/v2/url?u=https-3A__w3id.org_security_v2&d=DwIDaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=c4q9lgzRqBL5G5I6b1rBQkoITiMmTStNFwMIwCrGyJQ&s=Ujnf2qz418EBkXhVgiuz-lIpQAkcYdjTW_DhA2HsuUs&e="
> (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://urldefense.proofpoint.com/v2/url?u=https-3A__w3id.org_credentials_v1&d=DwIDaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=c4q9lgzRqBL5G5I6b1rBQkoITiMmTStNFwMIwCrGyJQ&s=BAetuuV2laz-eWhTSaPAB--kJhcB8a_6xis1tI5SraM&e="
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__schema.org&d=DwIDaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=c4q9lgzRqBL5G5I6b1rBQkoITiMmTStNFwMIwCrGyJQ&s=YeJ0kl3k-S261fSPGyrymLPxaX3l5f8QEb3S-EMw9bI&e=
> ",
>     "
> https://urldefense.proofpoint.com/v2/url?u=https-3A__w3id.org_security_v2&d=DwIDaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=c4q9lgzRqBL5G5I6b1rBQkoITiMmTStNFwMIwCrGyJQ&s=Ujnf2qz418EBkXhVgiuz-lIpQAkcYdjTW_DhA2HsuUs&e=
> "
>   ],
>   ...
> }
>
>
> --
> Dave Longley
> CTO
> Digital Bazaar, Inc.
>
> --

=====
Matt Stone
501-291-1599