[Question] 0005-didcomm: How is trust with Issuer/Verifier established?

[mspatelibm]

Wanted to understand the mechanism/protocol for establishing a connection with "trusted" verifiers and issuers.

Use case/scenario: Alice is looking to open up a bank account with Big Blue Credit Union (BBCU) and does not have a previous relationship with BBCU. Upon navigating to BBCU she thinks she is on BBCU website and is making a connection with BBCU (she does not know that BBCU DID is tied to BBCU unless there is a DID-entity-resolution registry). How does Alice know that she is interacting with a trusted BBCU and not an untrusted "Big Red Credit Union"?

Similar to how we interact with websites, there is a secure connection lock in a browser that indicates if the website is trusted prior to connecting to the website. I am suggesting a similar experience needs to exist when end users are connecting with varying issuing/verifying entities in which they do not have a previous relationship with.

The problem we are addressing is ensuring that end users are not providing information to entities purporting to be something else but instead indicating to end users that this is a trusted entity. "Trusted entity" can be defined by an agency determining if an entity is on a ledger that is trusted or by a governing group that attests for an acceptable governance framework being adhered to (contractual business and legal).

Question: is there a protocol in DIDcom that can allow for this type of "trusted" connection response check or do we need to create a separate protocol standard that allows for a standardized approach to check and render a response that indicates "trusted" or "untrusted" based on community governance and/or agency implementation that determines if the entity is on a "trusted ledger" with the corresponding checks of adhering to the ledger governance framework. I suspect some agencies will be more strict than others given the industry and regulatory requirements.

CC: @vinomaster

[swcurran]

Agreed this is needed and the solution is a combination of technical - largely, verifiable credentials, and governance what and who is producing the verifiable credentials. A similar use case occurs when I receive a verifiable credential - I can run the crypto to verify the credential, and I now know the DID of the issuer, but should I trust the issuer?

We wrote a paper about this quite awhile ago that outlines the issue and the basis of a solution. At the core, you are asking, under what authority are you operating? In the "Issuer" role - under what authority are you issuing credentials? Mostly covered in that paper is a recursive chain of request for verifiable credentials showing the authorization, and then a strategy for caching the responses. Alluded to at the end of that paper (and now better understood) could be well known Credential Registries, that contain verifiable credentials about issuers from a trusted source. The Credential Registry model is the same, but instead of the recursive chain of calls goes to a trusted (assuming you trust it...) source like a government list of Corporations, or Educational institutions.

Another idea that is floating around is a link between a DID and a DNS entry, so that when you get the public DID of an entity - for example, the issuer of a credential you are verifying - you can find the CA issued certificate for that entity. That would be a stop-gap measure to use the infrastructure we have on the way to decentralized IDs and a verifiable credentials-centric online world.

At the moment there are no protocols to support this, although it can largely be done with the "present-proof" protocol - or perhaps the ephemeral challenge (found here https://github.com/hyperledger/indy-hipe/pull/95 - not sure what is Aries RFC for this). I think the bigger and much harder question is the governance part of this - what standard credentials can we define to make this easy to implement?

[vinomaster]

Fraud Dimensions

@dhh1128 (DH) has done a fantastic job of establishing the basis for describing fraud concerns. With this foundational vernacular should be able to minimally clearly articulate the concerns of fraud against our tech and optimally be able to categorize a problem and then resolve it. Bravo!

See Dimensions of Fraud.

Problem Statement

So applying this fraud vernacular to @mspatelibm (Milan's) question we can state the following:

Concern: How does the HOLDER know that she is interacting with the REAL Verifier as opposed to a FAKE Verifier?

Challenge: Can we a prevent a holder at time of connection from being fooled by a fake verifier?

Fraud Dimensions:

1. Who is the perpetrator of the fraud? fake-verifier
2. Who is directly deceived? fool-holder
3. When is the deception committed? connection-time
4. Where (on which fact) is the deception focused? bad-verifier-identity

Fraud Multidimensional Context: If this hypothetical situation is possible, how do we prevent it? If it is not possible, we should be able to clearly articulate the measures taken to prevent it.

   fake-verifier + fool-holder + connection-time + bad-verifier-identity

Questions

1. Can we modify DIDComm Exchange and maybe more specific RFC 0030: Sync Connection Protocol to prevent this situation?
2. Is this problem in scope of our technology? Meaning is the tech responsible for knowing (governing) who you connect with?

[vinomaster]

Relative to Question #2 in my prior comment - allow me to play devils advocate.

Alice arrives at her destination for her appointment with a service provider. The destination is a building with two suites. Alice does not know which suite is the correct one. Suite B (BAD) is the address of an impersonator of the service provider in Suite G (GOOD). Alice will enter one of these suites and establish a relationship. How she proceeds with that relationship is totally up to her.

Things to Consider

1. Our DIDComm protocol will allow Alice to establish a trusted relationship (connection) rooted in a web of trust based on a DID on some DID Ledger. (a) If the DID Namespace being used for the DID associated with Suite B is a Public Write ledger, trust is somewhat less guaranteed. Lower trust factor. (b) If the DID Namespace being used is associated with a Permissioned Write ledger, then there exists a lesser degree of possibility that Suite B will be allowed to establish a DID on that ledger. Or stated differently, there is a higher possibility that only Suite G's DID will be on the ledger.

2. As long as DIDs are written to the ledger for a specific namespace they should be trusted. This trust is the basis for our connection protocol. As we get into the realm of a network of networks where some network governance models yield reduced trust factors, then it is up to the *Agent Software* being used by the HOLDER to allow that HOLDER to decide which DID Namespaces to trust or minimally suggest the trust factor associated with such names spaces. The final decision is a human one and the responsibility of the HOLDER. Be careful who you hang out with* .. so use trust factors associated with DID Namespaces.

[swcurran]

@vinomaster, I don't think that DIDs should be trusted at all, or at least until some additional knowledge about the entity controlling the DID is established. That might be because of how the connection was established (you are at the DMV and connecting, you connected in person, you are on a web site you trust, etc.) or because you verified the credentials that the other party provided to you.

I don't think that the namespace of the DID should generally be trusted, any more than a web site should be trusted because they have an SSL cert.

In DIDComm, the anticipated most common model is that a connection will start with an out-of-band invitation, and there is no public ledger involved in connecting. It may turn out that the public DID model may be more common than invitations, but we aren't currently anticipating that.

[swcurran]

Also, about the example - given that IBM has completed it's acquisition of Red Hat, shouldn't we trust both Big Blue Credit Union and Big Red Credit Union?

[mspatelibm]

@swcurran big blue and big red was not implying any relationship other than to describe two different entities :)

regarding the above, there seems to be a few approaches:

1. embedding something within the "proof-request" protocol
2. embedding something within the "synch-connection" protocol

I know there are higher priority items right now in the community so wanted to understand how we best capture / prioritize this. Is this worth an IIW topic in a few weeks?

[dhh1128]

+1 to a conversation at IIW

[mspatelibm]

@swcurran @vinomaster @dhh1128 - this has come up twice in the last day regarding the question of "how do I as a holder trust the verifying party I am presenting a credential to"

I unfortunately was unable to attend IIW but looking for guidance on how we can formalize a conversation around this topic give the background you've provided regarding the problem and adjacent problems/knows

[talltree]

Since the last post in this thread, a group of authors from the Aries community published an RFC that is very relevant to this issue. The Trust over IP Stack (Aries RFC 1028) describes an overall interoperability architecture for forming and maintaining trust relationships on the Internet. One of the most important features of the ToIP stack is that it is two parallel stacks: a technology stack and a governance stack. It is the combination of both that address the issue raised in this message.

To explain the relevance to this issue, which we might generically call "trust establishment", let me build on the analogy (used in the initial post of the issue) about the lock icon in today's browsers that signals the presence of an encrypted session based on a valid HTTPS cert at a website. That TLS infrastructure depends on a set of known CAs that are the "roots of trust" because their public keys are built into our browser software.

The whole point of decentralized identity and trust infrastructure is to: 1) eliminate single points of failure for trust roots (such as CAs), 2) enable many more authorities around the world to serve as trust roots (rather than just those blessed by WebTrust as it works under TLS), 3) make it much easier to register them, and 4) enable a "web of trust" model for discovering and verifying them.

To bring this down to the brass tacks of what this means about how you would perform trust establishment over a new peer DID connection:

1. First the two peers form the secure connection.
2. The peer needing to establish initial trust (in this example, the end user) asks the other peer (in this case the website) for one or more proofs that the second peer is a member of one or more governance frameworks (GFs) that the first peer trusts.
3. The second peer provides the proofs.
4. The first peer verifies the proofs.
5. If the proofs verify and match one or more of the GFs that the user trusts, the first peer's agent displays the appropriate "trust signal"— the DIDComm equivalent of the lock symbol in the browser.

The other specifically relevant RFC is 0207—Credential Fraud Threat Model, which covers different ways to prevent fraud on new connections.

Net net: while we still have a lot of work to do to reach the point where DIDComm and ToIP infrastructure is as widely accepted at today's HTTPS and TLS infrastructure, we have a clear path to get there. We had a good discussion about this issue on the 2019-12-18 Hyperledger Aries community call (the afternoon call) and there was consensus on that call to close this issue with this post.

[TelegramSam]

Closed per our discussion in Aries WG Call 2019-12-18, and thanks to @talltree for delivering the excellent addition he volunteered for. :)

[mspatelibm]

@talltree thanks for explanation. what im struggling to understand right now is the following:

In your point 5 you mention "if the proofs verify and match one or more of the GFs that the user trusts...", I dont think the user will know who to trust and who not to as they will rely on their agency provider to give some sort of indication.

Is each and every single user going to make that decision at runtime and will the user know to send a proper proof request to the verifier before establishing a connection and how do they logically process that (I just want to create a bank account... how do I know what proof request to send and when I get a proof response, how do I know to trust it)? I suspect the users (citizens) will just look for an indicator (yes/no) on whether to trust it, which is propagated from the agency they choose to use, thus I think there is a standard protocol that all agencies must follow to indicate "trusted connection". Based on that, its up to the citizen to say I want to proceed or not proceed...

This means that ultimately there is an agency wide "trusted whitelist" of networks and upon establishing a connection any and all agencies need to standardize a way to indicate to users that this is a trusted verifier/issuer (of course each agency may have a different set). So yes, in spirit ToIP is the foundation to it but I also think there needs more thinking in terms of how this is then manifested in a way where multiple agencies (vendors) will have a trusted list of networks/issuers/verifiers that comply to a standardized approach for communicating to end users (citizens) that it is a trusted connection based on whatever GF is approved by each agency.

I understand the shift from CA to decentralization but at the end of the day citizens need an indicate of trusted issuer/verifier or not... interested in your perspective here as always... this has come up yet again in a client driven conversation

cc: @vinomaster

[dhh1128]

I am going to be raising a PR about machine-readable trust frameworks that will address this question in more detail. I will post a link back to it here, when the PR becomes available. Let's see how much clarity it brings. I predict it will be a partial coverage, not total -- but that it will clarify a lot.

[dhh1128]

See #431

[kdenhartog]

I'm curious where people stand on who evaluates trust frameworks? Is it Users determine them, Software Authors determine them, or a combination of both? Currently TLS allows for a combination of both where the majority are added by vendors (default root CAs) and Users can optionally add certificates. The conundrum I run into when approaching the problem from this lens is that if software authors are evaluating them mostly we end up with a model similar to browsers and if Users evaluating them mostly then it's a system ripe for fraud.

[dhh1128]

I think we'll end up with a hybrid approach. Allowing users to make their own decisions is what makes innovation possible; allowing institutions to recommend frameworks is what makes it possible for users not to have to worry about details. I agree that such a model doesn't eliminate fraud.

What gives me a little hope is that we can associate trust frameworks with reputations (think of how reviews work on Amazon). This would be a big improvement on how CAs work, and it would not be hard for users to make mostly correct decisions.