W3C home > Mailing lists > Public > public-credentials@w3.org > July 2020

Re: A question on best practices for dependent claims

From: Roman Evstifeev <someuniquename@gmail.com>
Date: Thu, 30 Jul 2020 10:34:54 +0300
Message-ID: <CAMX-vmJDw6yx+AEESvL0iS+zv-0rbOK4VOWwGGXO27ypf-bRFQ@mail.gmail.com>
To: steve capell <steve.capell@gmail.com>
Cc: W3C Credentials CG <public-credentials@w3.org>
On Thu, 30 Jul 2020 at 01:37, steve capell <steve.capell@gmail.com> wrote:
> Hi all,
> I'm hoping some of you will have some sage advice for me on how best to handle a common pattern that we need to solve here in Australia.  The generalised case is that a certificate (ie credential) issued by X has little value to verifier Y unless backed up by an accreditation (ie credential) issued by recognised authority Z that says X is authorised to issue this type of claim.  Some real world examples
> Business identity ABN123 issues a claim that a consignment of wine is genuine penfolds.  But without another claim from IP Australia that ABN123 is the holder of trademark "Penfolds" then it's of little value.
> Veterinary surgeon John Smith issues an animal health certificate about snoopy the dog.  But without a supporting claim from https://www.anzcvs.org.au/ that john smith is an accredited vetinary surgeon, the certificate is useless.
> And there are hundreds of others....
> Some initial thinking

> If these are totally separate credentials then there is a problem with identity linking.  The subject of one claim (john smith is a vet) must be identical to the issuer of the other claim (snoopy is healthy).  even if the identifiers are the same, there are lots of john smiths in the world so how to be sure that the one issuing the cert about snoopy is the one that was accredited?  Does John smith first create a self-sovereign identity and get https://www.anzcvs.org.au/ to issue the claim to that identity?

The possible way it could be implemented with DIDs is:

#1 John Smith obtains a veterinarian license (credential) from government
1.1 John Smith with the help of a (wallet-like) app creates his own DID
 1.1.1 John Smith creates a key pair and places public key data in the
verificationMethods and assertionMethod section of his DID document.
He will use private key to issue(assert) health credentials which
verifiers will check with corresponding public key
1.2 He provides a proof of control to the government
1.3 Government agency issues a credential:
  issuer: {
     id: "healthcare.gov.au",
     signingKey: "890ABC"
  credentialSubject: {
    id: "did:example:johnid",
    accreditedAs: "Veterinarian"
  expirationDate: "2025.01.01",
  proof: {
    signatureValue: "123"
The signing key which is used by the government must be well-known and
trusted by the verifier. Government agency can use centralized trust
chain that is common today (https certs, dns, on-prems federated
infrastructure), or use DIDs, zCaps, but these will probably link to
the root of trust as well.
1.4 John stores the credential in his trusted storage. In the simple
case - local device. Another storage option may be secure data store:
https://github.com/decentralized-identity/secure-data-store - one may
be hosted with the government help, but John can pick any other which
he trusts.

#2 Pet owner obtains a passport and ID for Snoopy the dog from the
government or authorized party. Passport has a photo (maybe also
biometrics?) and says
id: "Snoopy-passport-112"
Passport may be physical or digital or even Snoopy could have his own
DID, but it is not important for the current scenario. Only having a
verifiable ID for Snoopy is needed.

#3 Pet owner obtains health credential from John Smith
3.1 John smith issues a credential:
  issuer: "did:example:johnid#key1",
  credentialSubject: {
    id: "Snoopy-passport-112",
    vaccinatedDate: "2020.07.30",
    bloodTest: "healthy",
  expirationDate: "2022.01.01",
  proof: {
    signatureValue: "456"
He uses a private key generated at step 1.1.1 to obtain a
signatureValue, and places the public key id into the issuer field:
"did:example:johnid#key1" - that is DID url pointing into DID
3.2 John sends this health credential *and* his vet license credential
to the pet owner
3.3 Pet owner stores both health credential and John's vet license
credential in a trusted storage.

#4 Border officer verifies pet health credential
4.1 Pet owner presents Snoopy, his passport and sends both health
credential with a John's vet license credential to the Border officer.
4.2 Border officer checks photo in the passport is really Snoopy
(maybe also checks biometrics)
4.3 He checks that Veterinarian license is really signed by a trusted
government signing key.
4.4 He checks that accredited DID from the license has the same value
as the DID of the health credential issuer. "did:example:johnid" ==
4.5 He resolves the DID did:example:johnid to obtain DID Document
4.6 He searches id: #key1 in the DID Document list under "verificationMethod"
4.7 He checks that "#key1" is also linked in the "assertionMethod" in
the DID Document
4.8 He uses the value in the "publicKeyHex" of the verificationMethod
with id "key1" to verify signature on the pet health credential.
4.9 He checks that credentialSubject id == "Snoopy-passport-112"

> Another approach is that the accreditation authority runs a service that counter-signs each certificate.  so john issues the health cert and then authenticates to https://www.anzcvs.org.au/ and gets it counter-signed.  the verifier can trace the authority through a single health certifiate.  This implies some real-time infrastructure capability on the part of all accreditation authorities that might be a bit impractical.
> Another is that the accreditation authorities maintain public lists of accredited identities via some public ledger protocol. verifiers can check the issuer id in the health claim and then check the public list. Maybe the lists need to be anonymised via some kind of zero knowledge proof.
> and so on...
> Looking for best practice advice that is both cryptographically secure and practical to implement for large number of accreditors and certifiers.
> Thanks in advance!
> --
> Steve Capell
> +61 410 437854
Received on Thursday, 30 July 2020 07:33:20 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:01 UTC