- From: Roman Evstifeev <someuniquename@gmail.com>
- Date: Thu, 30 Jul 2020 10:34:54 +0300
- 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 did:example:johnid 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: ```json { 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: ```json { 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 document. 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" == urlparse("did:example:johnid#key1").netloc 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