0

I am interested in verifiable credentials and how they work and doing some reading about it recently. While doing the reading I had a question that I can't seem to find an answer (or don't know whom should I ask, sorry for my lack of knowledge).

My question(s):

As a verifiable credential issuer is allowed to register one or more DID's in decentralized (distributed) ledger, how can a verifier be assured that the credential that it is verifying, is actually issued by a legitimate issuer?

Below is an example to clarify the question:

Let's say, a motor driving licence issuing agency (MDLA) registered themselves into a decentralized (distributed) ledger with DID value as "did:example:mdla1". They have also registered the driving licence schema along with that DID which looks like below (over simplified example):

"schema_json":{
  "id":"mdla:drivinglicence:schema:v:1.0",
  "name":"Driving Licence",
  "attrNames":["full_name", "credential_created_date", "start_date", "end_date"],
  ....
}

Now, let's say I (a person/org/hacker etc.) want to tamper with the verifiable driving licence credential. And to do that, I do register myself in a decentralized (distributed) ledger with DID as "did:example:mdla2" along with the same credential schema as above (only changed the ID to be my preferred ID). And later populate a fake verifiable driving licence using that.

Now, when I present the credential (that I have created by myself) to a person (say a police officer) to verify, how the verifier will know that the credential is issued by me (thus it is fake) and not issued by the actual authority (MDLA)?

As per my understanding so far, my DID (did:example:mdla2) will have my public key associated with it and I have digitally signed my verifiable driving licence credential using my private key, therefore the signature should be verified without any issue.

Please help me clarify this confusion or point me to some resource where I can get a better understanding. Thanks.

vpv
  • 920
  • 2
  • 20
  • 46

1 Answers1

1

There are three main ways to establish issuer trust.

The first is using static trust in a wallet or verifier. This is common in first party use cases where the wallet is maintained by the issuer (this is not ideal as we don't want a world where users have a different wallet for each issuer or credential type). A verifier could have a business relationship with an issuer where trust is established out of band.

The second is to bind a DID to a domain using a well-known URL (this pattern is used with many protocols, including certificate issuance): https://identity.foundation/.well-known/resources/did-configuration/. In combination with DNSSEC and multi-hop resolution, this can provide a level of trust based on the organization's public web domain.

Another method is using trust lists or trust frameworks. A wallet or consortium may provide a list of trusted issuer DIDs as part of a trust framework that a wallet can consume, either implicitly or with user choice. An example would be the American Association of Motor Vehicle Administrators maintaining a trust list of US driver's license issuers (states) as part of a trust framework. Verifying organizations, such as bars, banks, and government agencies would evaluate this trust framework and utilize the trust list during VC validation.

Tim
  • 827
  • 4
  • 6
  • thanks for the feedback @Tim. Much appreciated. Also putting the link to the answer for the same question from W3C verifiable credential GitHub repo. https://github.com/w3c/verifiable-credentials/issues/34 – vpv Nov 18 '21 at 23:52