# Intital Trust

How can we bootstrap trust relationships in a new DID ecosystem?
How can Alice be sure that after scanning a QR Code, she will give her personal data to the right verifier?

## Trust relationships

left to right direction

(Verifier) .[norank].> (Issuer) : trust (a)

(Issuer) ---> (Holder) : Verifiable Credential
(Holder) ---> (Verifier) : Proof

(Issuer) .[norank].> (Holder) : trust(c)
(Holder) .[norank].> (Verifier) : trust (b)

( a ) verifier needs to know: Is the issuer trustworthy? (which value do the credentials have?)

**( b ) holder needs to know: Is the verifier trustworthy? (will the verifier respect my privacy?)**

( c ) issuer may need to know: Is the holder's wallet trustworthy? How can I prevent misuse of the offered credentials?

## Related Questions:
How can inital trust (technically) be established between the certain parties (Issuer, Holder, Verifier) in a DID-based identity network (i.e IDunion)?

How can Alice be sure that after scanning a QR Code, she will give her personal data to the right verifier?

How can the wallet support Alice with this decision? Will we end up with a green checkbox or a more sophisticated, customizable, self-learning trust framework?

What (technical) methods are already described to establish initial trust? Are there new ones? What are their pros and cons?

Do we need a standard, Aries RFC for consistent gathering of trust information an UX across different wallet implementations?


## Methods

### web repudation-based trust

#### did:web method
- [did:web Decentralized Identifier Method Specification](https://w3c-ccg.github.io/did-method-web/)
- allows unidirectonal link from a domain to any DID over a did:web Document stored in a specific path of the domain.

##### Example:

**Domain:** example.com
**intermediate-did:** did:web:example.com
**intermediate-did-document-location:** https://example.com/.well-known/did.json
**controller-did:** did:indy:idu:1545654asdasdasdsdf

**intermediate-did-document:**

{
  "@context": "https://w3id.org/did/v1",
  "id": "did:web:example.com",
  "controller": "did:indy:idu:1545654asdasdasdsdf"
}

#### well-known DID configuration

- [DIF Working Group Approved Draft](https://identity.foundation/.well-known/resources/did-configuration/)
- method of establishing bi-directional relationship between DID controller and controller of a origin ("web resource")
- uses well-known location defined by IETF8615 and proposes did-configuration type for registration at IANA

**Verification Steps origin -> DID:**
- get https://example.com/.well-known/did-configuration.json
- parse JSON document to get *DID Configration Resource*
- contains array `linked_dids` with one or more *Domain Linkage Credentials*
- *Domain Linkage Credentials* represents VC as JSON Web Token or JSON-LD Proof
- verify mandatory data like `credentialSubject.id` `credentialSubject.origin`, check that origin matches the requested address
- resolve DID to DID document and validate signature

{
  "@context": "https://identity.foundation/.well-known/contexts/did-configuration-v0.0.jsonld",
  "linked_dids": [
    {
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://identity.foundation/.well-known/contexts/did-configuration-v0.0.jsonld"
      ],
      "issuer": "did:indy:idu:0124abcd",
      "issuanceDate": "2020-04-13T16:44:52-05:00",
      "expirationDate": "2020-05-13T16:44:52-05:00",
      "type": ["VerifiableCredential", "DomainLinkageCredential"],
      "credentialSubject": {
        "id": "did:indy:idu:0124abcd",
        "origin": "https://example.com"
      },
      "proof": {
        "type": "JsonWebSignature2020",
        "created": "2020-04-13T21:49:40Z",
        "verificationMethod": "did:indy:idu:0124abcd#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
        "proofPurpose": "assertionMethod",
        "jws": "eyJiNjQiOmZhbHNlLCJjcml0IjpbImI2NCJdLCJhbGciOiJFZERTQSJ9..KyuVW9YdrShA3kDMufSWKtKHXtIKTzRpbxPgx1n50S2pl3GwrqtJWtZAexUD6beaTqu4W4njCoAv3_qaCQmuBA"
      }
    }
  ]
}

**Verification Steps DID -> origin:**

- *Linked Domain Service Endpoint* describes method for reverse direction
- service endpoint in the DID document points to the origin
- enables closed loop of trust relationship between DID and origin

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    
    "id": "did:indy:idu:0124abcd#keys-1",
    "type": "RsaVerificationKey2018",
    "controller": "did:indy:idu:0124abcd",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
  }],
  "service": [
    {
      "id":"did:indy:idu:0124abcd#vcs",
      "type": "LinkedDomains",
      "serviceEndpoint": {
        "origins": ["https://example.com"]
      }
    }
  ]
}

#### DID in DNS
- [IETF Internet-Draft v4](https://tools.ietf.org/html/draft-mayrhofer-did-dns-04)
- allows to refer to DIDs from the Domain Name System (DNS)

##### Example

_did.example.com.  IN URI 100 10 "did:indy:idu:1234abcd"

#### Implicit domain binding
Connection Invitation URL, Link shortener (https://example.com/invite?asdfsdf123)
Service endpoint (https://example.com/didcomm)

### credential-based trust

#### Authoritative issuer of organizational credentials
- defined by Trust-over-IP

#### credential registry
- [Aries Verifiable Credential Registry](https://github.com/bcgov/aries-vcr), e.g. BCGov Orgbook
- "bootstrapping" process
- high quality public data repository

### eIDAS based
- cross-border and legally enforceable mutual recognition between Member States
- Electronic seal (eSeal): used by legal persons, it is similar in its function to the traditional business stamp. It can be applied to an electronic document to guarantee the origin and integrity of a document.

#### eIDAS bridge
[Technical Specification (15) - eIDAS bridge for VC-eSealing](https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITALEBSI/Technical+Specification+%2815%29+-+eIDAS+bridge+for+VC-eSealing)

- Adding legal value to Verifiable Credentials using traditional eSealing (no anoncreds)

#### certificate linkage
- Use public key of eSealing certificate for DID auth.

### new thoughts on organisation validation
- 2step approach:
- endorse DID (untrusted)
- validate DID controller (trusted)
- comparable to advanced TLS certificates(EV/OV)
- reusing existing eIDAS trust service provider ecosystem

#### DID document-based (with credentials)
- organisation requesting validation from a trust provider
- trust provider validates real offline organisation
- send credential with eSeal to organsiation
- organisation saves eIDAS Seal to the DID document

{
  "@context": ["https://www.w3.org/ns/did/v1", "https://w3id.org/security/v1"],
  "id": "did:example:123456789abcdefghi",
  "verificationMethod": [{
    "id": "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
    "type": "JwsVerificationKey2020",
    "controller": "did:example:123",
    "publicKeyJwk": {
      "crv": "Ed25519",
      "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ",
      "kty": "OKP",
      "kid": "_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A"
    }
  }, {
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2018",
    "controller": "did:example:pqrstuvwxyz0987654321",
    "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }],
  "eIDAS-proof" : { #eIDAS-Siegel
     "id": "did:example:378178320863", #Trust provider DID
     "proof": "ba33b235d7116a3263d29f68ee293053b7...1145093602b97c30de767f084ce30801"
  }
}

#### Indy integrated on-ledger
- Trust provider has a special role in indy network
- gives permissions for a special transaction similar to NYM/ATTRIB to write organsiation validation information to the ledger
- more decentralization/availability

### Other approaches
[diro io](www.diro.io)

### Integration in universal wallet

This is certainly a ux challenge...