Verification of contacts within the Lissi Wallet

DIDComm promotes the usage of encryption envelopes which create a confidential channel between two parties, but in a digital context the challenge of identifying the “other” party remains unsolved. Before we exchange informations with another person or institution we have to be able to answer the following question:

• Who am I speaking to?

In a digital context the other party is ultimately hidden behind an IP address, which makes it challenging for a human to verify the other parties identity. Adding DIDs to the mix does not solve this issue by itself, it is still hard to for a holder to discover the identity of a verifier and issuer before a credential or any other information is exchanged.

For more background on the issue of trust in digital space see our following article on Medium.

Display of verification status for Lissi Wallet users

The Lissi Wallet shows a visual indication of trust levels to the user to support the user when determining if one is talking to the right organisation. It also provides recommended actions and labels the primary and secondary button accordingly.

Contact validation based on X.509 Certificates

“An X.509 certificate binds an identity to a public key using a digital signature. A certificate contains an identity (a hostname, or an organization, or an individual) and a public key , and is either signed by a certificate authority or is self-signed.” (Source: https://en.wikipedia.org/wiki/X.509)

“An Extended Validation Certificate (EV) is a certificate conforming to X.509 that proves the legal entity of the owner and is signed by a certificate authority key that can issue EV certificates. Unlike domain-validated certificates and organization-validation certificates, EV certificates can be issued only by a subset of certificate authorities (CAs) and require verification of the requesting entity's legal identity before certificate issuance.” (Source: https://en.wikipedia.org/wiki/Extended_Validation_Certificate)

The Lissi Wallet currently detects EV and QWAC certificates and will check if a valid EV certificate is bound to the domain of a serviceEndpoint of an incoming connection invitation:

Example

{
    "@type": "https://didcomm.org/connections/1.0/invitation",
    "@id": "12345678900987654321",
    "label": "Alice",
    "recipientKeys": ["8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K"],
    "serviceEndpoint": "https://extended-validation.badssl.com/endpoint",
    "routingKeys": ["8HH5gYEeNc3z7PYXmd54d4x6qAfCNrqQqEB3nS7Zfu7K"]
}

A given label within an invitation must match the organisation name of the EV certificate!

Given the example above the Lissi Wallet will check the domain extended-validation.badssl.com for a valid EV certificate. Given a valid EV certificate is bound to the domain, the wallet will match the given label within the invitation against the organisationName "O" within the certificate subject's distinguished names.

For the domain extended-validation.badssl.com the subject’s distinguished names are as follows:

businessCategory=Private Organization; jurisdictionCountryName=US; jurisdictionStateOrProvinceName=California; serialNumber=C2543436; C=US; ST=California; L=Mountain View; O=Mozilla Foundation; CN=extended-validation.badssl.com

Given the invitation from above, the Wallet will check that the given organisation name O=Mozilla Foundation is equal to the "label" : "Alice" given in the invitation:

"Mozilla Foundation".toLowerCase() == "Alice".toLowerCase()

If the statement above evaluates to True the requesting contact will be marked as verified (“green checkmark”), if the statement above evaluates to False the requesting contact will me marked as unverified.

Where can I get a certificate for my Agent?

As an agent provider you can get an EV certificate from any certificate authority which follows the guidelines of the CAB Forum.

One example for such a certificate authority is D-Trust GmbH. Their offering includes an “Advanced EV SSL/TLS ID” and a “Qualified EV SSL/TLS ID” certificate which are both valid options.

https://www.psw-group.de/ssl-zertifikate/advanced-ev-ssl-a010001/

https://www.psw-group.de/ssl-zertifikate/qualified-ev-ssl-a001474/

Outlook

The current validation process based on extended validation certificates leverages well established standards which bind an organisation identity to a certain domain name. Within an SSI ecosystem the ultimate identifier of an organisation should be a did https://www.w3.org/TR/did-core/ therefore the binding between identity and did based on a X.509 certificate issued for the domain of the serviceEndpoint is only indirect. For the long-term it is recommended to follow procedures which bind the identity of an organisation directly to a did.