owned this note
owned this note
Published
Linked with GitHub
# 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
```plantuml
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?
![](https://i.imgur.com/6ztc8gN.jpg =400x)
## 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:**
```json
{
"@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
```json
{
"@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
```json
{
"@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
```json
{
"@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...