Trust does not Scale
One of the key user stories for the EU digital wallet toolbox is the diploma cross-border use case. This post identifies an underlying assumption of the use case which does not hold once you move beyond the very narrow limitations of this particular use case.
TL;DR
Trust seldom follow hierarchical paths and when it does it almost always scales poorly. The diploma use case which has been considered in many of the EUs activities in the self-sovereign space including ESSIF, EBSI and the EU Digital Wallet Toolbox work, over-simplifies the challenge of establishing trust in Verifiable Credentials[1] (VC) by hiding complexity which becomes apparent when considering other similar use-cases.
The desire to model trust only on existing legal structures ignores the fact that many highly trusted relationships depend on multiple inputs which may be both informal and situational.
Call to action
The EU digital wallet trust ecosystem should be amended to include more forms of trust structures than the hierarchies based on trusted status lists that are currently being discussed. There are situations where hierarchies are a natural part of how trust is managed — the diploma use case in higher education may even be one of those situations.
Introduction
This memo will demonstrate a problem with the EU digital wallet ecosystem trust architecture. We will also suggest possible avenues for identifying solutions. The title of the paper “Trust does not scale” is a colloquialism[2] sometimes used in the research and education trust and identity community where it is used to express that trust, as an emergent property of relationships, is inversely proportional to the size of the population.
This is a fact well known to anyone who has tried to build trust infrastructures (eg PKIs or identity federations) that the larger the group of connected entities, the lower the trust. This empirical property of trust may remind the reader of Dunbar’s number[3]. This is probably no accident since trust at least in part is related to maintaining relationships.
Below we will look more deeply into some cases where trust failed to scale and also where it was possible to overcome or avoid these limitations.
About the examples
This text attempts to illustrate some of the challenges associated with building large scale and open trust infrastructures such as the EU digital wallet ecosystem. Mostly this is done through the lens of a few examples. These examples are inspired by the real-world but do not contain all complexity. The author has made a conscious choice to simplify (some might even say over-simplify) certain aspects of the chosen examples to make the point crystal clear. In the words of Mark Twain: “never let the truth get in the way of a good story”.
A note on the term “trust”
This text uses the word trust a lot. By trust we mean the degree to which one party is willing to engage in transactions or exchange of information with a second party. Trust can be supported by technology but is not dependent on technology. Rather, trust is an emergent property of relationships. Trust is often tied to identity but not necessarily in the sense that trust requires full identification of the parties in a transaction.
Sometimes trust is represented using technology. When we need to distinguish trust as represented by technology we will use the term technical trust. Examples of technical trust include PKIX, SAML, OpenID Connect, Trust Status Lists etc. In this text we talk about technical trust and its limitations but the issue is always inter-personal and inter-organizational trust.
Failing to scale trust: the web PKI
The title of the section may seem like a non-sequitur: Arguably the Web has excellent scaling properties and equally true is the fact that web certificates (aka the Web PKI) has been very successful in enabling ubiquitous encryption of all web traffic. These are facts that speak for themselves.
In this section we will look at the scalability of trust using the Web PKI. Trust is not the same thing as “enabling encryption”. Trust is an emergent property of relationships and can be both strong and weak even if the underlying transport of data is secured against eavesdropping using encryption. There are several examples of systems where parties communicate using protocols where encryption is always turned on but trust in the identity of the endpoint can be quite low.
Historically the “trust does not scale”-effect has been manifested as the failure to grow trust infrastructures while maintaining quality — the issues facing global web PKI is a case in point: As deployment of PKI grew with the advent of the web and e-commerce, there was an increased demand for web certificates. A web certificate was meant as a “sign of trustworthiness” for a website, a sealed statement from an issuer to the effect that the holder of the certificate is the real organization behind a website.
Web certificates therefore contains signed information about the organization to which the certificate was issued. If a certificate contains the name of a bank (say) there is a natural expectation from the user that the issuer of the certificate has checked that the bank is indeed responsible for the keys associated with the certificate. Initially checking this so called name to key binding was easy for the certificate issuer because there were very few customers.
However as the popularity of e-commerce grew, a plethora of new PKI vendors appeared who pretty soon started to compete on price. As competition pushed price down — an apparent benefit for customers — PKI vendors faced decreased margins which in turn meant they could not spend as much resources on establishing the authenticity of each certificate. The user has no way of telling a certificate where the issuer has spent a lot of resources on due diligence from one that has been issued “on the cheap”. Price is not covariant with quality. This led to a devaluation of trust in web certificates.
In response to this, PKI vendors, introduced more “trusted” products such as Extended Validation (EV) certificates where the routines for validating the organization etc were more strictly enforced. The number of PKI vendors offering EV certificates grew because of increased customer demand resulting from the devaluation of trust in “basic” certificates. This in turn leads to a devaluation of trust in EV.
Yesterday’s “standard certificates” became today’s “cheap certificates” and became “almost worthless” the next day. The only recourse was to switch to EV certs which then also began to depreciate in value because PKI vendors could not keep up with the demands of trusted issuance at competitive prices. A corrupting cycle that makes scale contravariant with trust…. (sometimes).
This is not a problem associated with the technology of Web PKI but a problem that stems from the fact that web PKI was designed as a hierarchical structure where there was no way to buy a web certificate with a higher quality and have that reflected in a meaningful way to the user. In other words — a bank really doesn’t get any measurable benefits from buying a more expensive certificate.
Something very similar has happened with the market for “eIDAS compliant” products. Given the fact that there is currently no real compliance mechanism, vendors are filling the gap by aggressive marketing which in turns lowers trust in the eIDAS brand.
One result of this cycle is that all browser vendors have agreed to stop presenting the user with visual cues tied to the “trust level” of a web certificate. Historically, a web site using an EV certificate was presented with a green navigation bar in most browsers. This was clearly an attempt to inform the user that the EV cert was meant to carry more weight.
Browser vendors have since 2019 stopped showing EV browser indication[4] and there is today no difference — from the point of view of the user — between EV and “basic” certificates. The certificate trust landscape has been “flattened” — every certificate is at the same trust level. This in turn erodes the margins for PKI vendors and since PKI vendors now compete mostly on price, the race to the bottom quickly ends… at the bottom.
Successfully scaling trust: The Internet
There are basically two approaches to scaling trust: Hierarchies and Rings of Trust. An example of a hierarchy is the classical PKI where trust flows from the root CA, through intermediary CAs down to the leaf certificate.
PKIs are still common in closed environments, IoT systems, automotive industry etc. The modern web PKI is arguably coming closer and closer to being a simple hierarchy again with the letsencrypt CA as one of the few remaining root CAs (if you discount several national/regional CAs that still manage to survive).
Arguably the largest single root technical trust hierarchy in active use is the public DNSSEC hierarchy. The DNSSEC clearly is highly trustworthy at, and near the root where the ICANN root key ceremony is the gold standard for transparent key management.
However, below the TLD or gTLD level, there are seldom any published key management policies or transparent processes. When a zone is signed, the DNS hosting provider generates a key pair the public key of which (in the form of a so called DS record) is submitted to the registry by the zone owner.
The exact way this is done varies but what is in fact happening is that the owner of the domain provides a cryptographic binding between the domain at the registry and the domain at the DNS hosting provider. This cryptographic binding is analogous to what happens when a certification request is submitted to a PKI CA for issuing a certificate. The CA issuing process typically depends on determining the identity of the subject submitting the certification request.
In the case of the Web PKI (and many other PKIs) the process of identifying the subject is both transparently described and independently audited. In the case of DNSSEC the binding between domain registry and DNS hosting provider depends on the process by which registrys and DNS hosting providers know their customers — a process which is typically neither described nor audited.
Does this mean that the quality of DNSSEC is inferior or that trust in DNSSEC is misplaced? Most certainly not!
Would the DNSSEC hierarchy still scale if domain owners had to fulfil mandatory requirements on key management, policy publication, audit, legal delegation of authority etc? Probably not.
What is happening here is that DNSSEC is a technical representation of the business relationships between the registry, the domain holder and the DNS hosting operator and as such it does an excellent job.
Examples of rings of trust include several large-scale identity federations in the research and education sector[5][6][7] that also represent the business relationships built into the academic sector. However there is another example of an (arguably) high-trust ecosystem based on rings-of-trust: the Internet itself.
The network layer of the Internet is a mesh of interconnected networks, each controlling the exchange of traffic using a protocol called the Border Gateway Protocol (BGP). The protocol is used to control how Internet traffic is routed — i.e. sent between Internet Service Providers (ISPs).
The Internet runs on BGP. Each ISP maintains a set of peers — partners with which the ISP chooses to exchange traffic. The choice of which ISPs to peer with is based on business decisions made by each ISP. The Internet is an emergent property of the business decisions represented as routing policy implemented in BGP configuration at each ISP all across the world.
The operative concept here is “choice”. The Internet is not — and could not — be created as a hierarchical chain of delegations of authority. The Internet works because it is driven by the interconnected trust-relationships (represented by BGP) between ISP who choose to exchange traffic with each other. In other words: the Internet is an emergent property of properly managed business relationships represented using BGP. Another important aspect is flexibility: BGP is based on local policy expression which is the reason the Internet can adapt quickly to stress.
Arguably the Internet has good scaling properties.
An analysis of the EU digital wallet ecosystem
In this paper the authors seek to contrast and reflect on the choices made in the proposed EU digital wallet ecosystem to base the establishment of trust on an interconnected network of hierarchies relying on legal delegation of authority.
Hierarchical trust almost always tends to establish a cycle of devalued trust whereas systems based on circles of trust has the capacity to handle differentiated demands as well as situational and transitory trust.
The diploma use case
The EU digital wallet diploma use case goes something like this:
- Users authenticate to their University and obtain a verifiable credential representing a diploma — a statement by the university to the effect that the user has fulfilled the requirements of a certain degree.
- The user presents the VC to a prospective employer (the validator) in another member state.
- The validator checks the VC by following a trust-chain from the VC to the university and up through the hierarchy of issuing entities until the validation terminates in a common root of trust.
The act of issuing a university degree has legal implications. Historically, the term University is sometimes defined as an organization accredited for issuing doctoral degrees. The role of the accrediting body is well established in most parts of the world.
The trust model mirrors a classical PKI hierarchy and the validator has a simple task: follow the chain of trust backwards to a common root of trust.
This model is simple but should work pretty well for university diplomas: Degrees are (by definition) only issued by universities and universities are (by definition) only allowed to issue degrees if they are accredited by the appropriate body in each country. So far so good.
A researcher’s journey
University degrees and diplomas are not the only candidates for verifiable credentials in the research and education domain. It is common for universities and other institutions to form collaborative associations for the purpose of conducting research. Such research infrastructures come in many shapes and sizes, including such legal constructions as foundations, EU joint undertakings, ESFRIs, but also — very often — more loosely organized groups.
Consider the Ligo Scientific Collaboration (LSC) as an example. The LSC is composed of the researchers and organizations working on the Laser Interferometer Gravitational-Wave Observatory and has been conducting research since 1997. The LSC was awarded the 2017 Nobel Prize for Physics for its detection of gravitational waves.
The text-box below is a summary of the LSC as it stands in May 2021, clipped from ligo.org[8]. The LSC encompasses 127 institutions and counts over 1400 people as members. Not all employees of one of the LSC member institutions are automatically members of LSC however which leads to the need to bring new members (researchers) into the collaboration. This is known as onboarding new users.
Onboarding new users as members of the LSC is an important task and is predicated on knowing two pieces of information about a user: firstly that the user is associated with one of the LSC member institutions, and secondly that the user is working on LIGO data and observations — i.e. that the user is an active researcher. Let us consider onboarding a new user in the LSC from the point of view of the EU digital wallet ecosystem.
On first inspection, both these steps can be represented as a case of presenting two separate VCs issued by two different issuers: one VC attesting that the user is an active researcher employed by (say) the department of physics at the University of Vienna, AT. Another VC issued by LIGO attests to the fact that said department of physics is a member of the LSC. The combination of these two VCs can be used to onboard the user as a member of the LSC — and perhaps result in a new VC issued to the users digital walled to that effect.
As in many fields of science, data from neighboring domains is needed to enhance observations made in the LSC experiment. As such, LSC research involves accessing data from multiple sources and the European Southern Observatory, not part of LSC, has data our example user needs for her research.
Our user therefore proceeds to present her VC attesting to her status as an LSC member to the European Southern Observatory (ESO). Her VC trust chain looks like this:
Access to ESO data is controlled by a process — let’s call it the ESO data access manager. The ESO data access manager in our example could be implemented as a VC verifier, part of the EU digital wallet ecosystem. The verifier can easily verify the fact that the researcher is working for a physics department at the university of Vienna which is an academic institution of good standing in the higher education accreditation structure of Austria.
However the ESO data access manager has no way of validating the trustworthiness of the assertions from the LSC because the LSC, regardless of the fact that its founders and architects have been awarded a Nobel Prize, does not have any legal standing in any jurisdiction whatsoever. Not only is the LSC not an accredited institution in the sense of the diploma use case but it is also not part of one, nor is the LSC a legal entity but rather a semi-formalized collaboration between several institutions. The fact that the spokesperson is affiliated with a major university in the US does not mean that the LSC is part of that institution.
This is by no means an extreme example. Research collaborations are often informal in nature and any attribute issued by such a collaboration — for instance the attestation of active membership in a collaborative association — will often not be part of a trust-chain that is anchored in any national accreditation body or any other formal structure. This is just one example.
A cursory study of the research and education landscape will reveal that informal associations are the norm, not the exception. Nor is the LSC particularly “big” as research organizations go.
Of course the research community of today has already solved the problem of establishing trusted associations between researchers. Most research infrastructures deploy identity platforms[9][10][11][12] that mimic the behaviour of the proposed EU identity wallet ecosystem but where the root of trust is established based on peer review and academic standing rather than formal delegation of authority. To put it in simple terms: in the real world, the LSC is trusted by their international peers because these organizations have established academic relationships based on mutual trust and need to exchange data. Within the EU funded EOSC project[13], the member states, in collaboration with the research communities, are harmonizing the way such processes are done.
The astute reader will immediately see a relationship between this case and the BGP example in the introduction: Academic institutions exchange trust because there are solid “business” reasons to do so: research projects and academic institutions need to share data in order to conduct their research. In a similar fashion, ISPs exchange traffic because there are good business reasons to do so in the sense that in order to be successful as an ISP you have to deliver good quality Internet service to your customers.
The “good business reason” driver for establishing trust cannot be modeled on top of any hierarchical registry of relationships. It could be argued that establishing a registry of research projects might be a way to address the arguments presented above. Even if such an approach would be practical (it is not), it would not create trust. Research projects (as well as business ventures) trust each other because there is reciprocal benefit to collaboration, not because of, or incumbent upon, any delegated authority.
Similar to the above example in research collaborations, many relations in the real world are not hierarchical but local. Hence no hierarchical registry will ever be able to encompass these. To make an EU digital wallet ecosystem able to provide the core infrastructure for such use cases, it must also make room for more “mesh-like” and trust based on dynamic relationships which avoids introducing an element of fragility which typically is a problem for hierarchical trust infrastructure as seen above. This will greatly enhance usability of the EU digital wallet and will ease adoption in many fields including research & education, truly providing a generic trust infrastructure for our digital future.
Generalizing the diploma use-case (and all the problems)
Trust management in the diploma use case is based on the idea that approved organisations can be gathered in a trust status list. We’ve shown that this assumption does not hold in the research and education domain. Is the R&E domain unique somehow?
A lot of research and education involves what EU calls “cross border” aspects, ie requirements for international collaboration and transactions that require trust and identity. Both research and education is in part highly regulated (although perhaps not to the extent that say financial services, aviation or pharma is regulated).
Are there other organisations that share some key properties with the R&E domain: cross-border requirements combined with limited but not non-existent regulation? There are in fact several such examples but we will look at one in this section: the construction business in Sweden.
Quality control and environmental protection at or around building sites is regulated by the Swedish Work Environment Agency. This agency has published “Use of lifting devices and lifting accessories (AFS 2006:6)” — in other words crane operator requirements. This regulation is binding and includes requirements on crane operators having completed education. Exactly who can provide the education is only exemplified in the regulation. For all practical purposes the task of organizing education for crane operators is left to the construction industry.
Becoming a “licensed” operator of construction cranes typically involves taking a course and completing education. The word licensed is in quotes because there is in fact no government operated licensing scheme. The language in the regulation (AFS 2006:6) in Swedish calls out certain types of education as being sufficient but provides a lot of freedom for the industry to figure out how to fulfill the requirements. There is no official accreditation for course providers for crane operators. However there is a collaboration between industry and trade unions called BYN[14] which produces a collaborative accreditation and quality criteria. There is no official “blessing” of BYN from the regulatory agency (AF) but the construction business in the country have gravitated to a common platform. It is likely that a construction company that would choose to forego this voluntary certification process would be subject to extra scrutiny from the oversight agency but there is nothing that would make such an approach illegal in principle.
Let us consider this example in the context of the EU digital wallet ecosystem. The result of completing a crane operator course could be modeled as a verifiable credential issued by the education company. A verifier (eg a company that rents out building cranes) would need to be able to verify the VC trust chain which in most cases would look something like this:
Note that the industry accreditation group[14] has no special role in the sense of AFS 2006:6 other than being called out in the regulatory text as an example of a structure of approved education. Already in this case the EU Digital toolbox trust model has problems since the corresponding structure in each member state is going to look very different. There is nothing corresponding to the internationally recognized accreditation structure for higher education in this case. There are several international agreements regulating mutual trust in crane operator licenses in place and those agreements (eg Norway and Sweden has mutual recognition for crane operators but Sweden and Denmark do not) track business needs.
However it gets even worse when we consider the case of the company that decides (for some unknown business reason) to train all their crane operators internally and issue their own crane operator diploma. This is a hypothetical case but it is not uncommon for companies who wish to disrupt an industry to challenge the established structures of that industry in some way.
Consider a hypothetical construction company that does a lot of business with one of the major crane rental outlets. Such a major actor in the industry will ultimately have no problem convincing verifiers to accept this alternative trust chain:
Trust is always based on weighing business decisions with risk. In this case the crane provider (the verifier) has some responsibility for who they are renting their cranes out to and therefore carries some risk.
Our hypothetical (disruptive) construction company will most likely have to provide additional documentation demonstrating that the self-issued diplomas are just as trust-worthy as the ones issued by any of the recognized education companies. In the end business realities will most likely prevail and the self-issued VC would be accepted as long as the construction company is able to show that their crane operator education is as good as any provided by traditional course providers. Similar situations happens in the IT industry where major players (AWS, Microsoft, Google etc) all act as trust anchors in various ways precisely by virtue of the fact that customers are interested in buying their products.
The description of the regulation in this case is simplified and skips over several details but the important point is that it does exactly what it was meant to do: maintain regulatory quality control over the workplace environment at building sites, while providing the market enough room for companies to innovate. The example is meant to illustrate how expressions of technical trust must be able to accommodate a wide range of linked and overlapping hierarchies to be practical.
Permissioned and Permissionless trust… and stuff in between
Note for blockchain tech bros: the use of the term permissioned and permissionless in this section should not be confused with similar terms used about blockchains. These are similar, but not identical, concepts.
The EU digital wallet ecosystem as envisioned in the current use cases is a permissioned system in the sense that in order to issue (or validate) verifiable credentials you need to be registered. By contrast, a permissionless system allows anyone to issue VCs. In a permissioned system trust is established by the process by which entities are registered in the system. The EU digital wallet ecosystem as currently described is a permissioned system based on strictly enforced registration and trust status lists. For instance trust in the diploma use case depends on mirroring the accreditation system for higher education onto the EBSI. There are good reasons for wanting to build a permissioned system for the EBSI and the EU digital wallet ecosystem.
In a permissionless system anyone can issue credentials which means that a verifier must choose which issues to trust based on something other than external structures such as trust status lists. Of course trust and permissiveness are not binary, either-or properties but rather can be seen as a pair of axis where systems live.
In this memo I’ve been trying to show that currently the EU digital wallet ecosystem is design to support high trust use cases (which is good) but accomplishes this by a set of design choices which puts it in the upper corner of the trust/permissiveness square as shown above.
In a permissioned system trust is easy to evaluate since the verifier can just defer to the various trust anchors. On the other hand the applicable use cases are limited by the trust mode In a permissionless system, trust is much more difficult to evaluate and policies must be established by each verifier. On the other hand more use cases “fit” in a permissionless system because anyone can register an issuer for any purpose.
The takeaway here should be that if we want to achieve high trust but in order to permit more use cases to co-exist within the ecosystem we need a way to broaden the trust model in the EU digital wallet ecosystem to include trust models beyond top-down/hierarchical ones.
[1] https://www.w3.org/TR/vc-data-model/
[2] The author first heard this expression used by Lucy Lynch during the ISOC Trust and Identity workshop in Utrect 2014.
[3] https://en.wikipedia.org/wiki/Dunbar%27s_number
[4] https://www.bleepingcomputer.com/news/software/chrome-and-firefox-changes-spark-the-end-of-ev-certificates/
[5] https://wiki.sunet.se/display/SWAMID
[8] https://www.ligo.org/about.php
[11] https://elixir-europe.org/services/compute/aai
[12] https://www.eugridpma.org/
[13] https://eosc-portal.eu/about/eosc-projects
[14] Byggnadsindustrins yrkesnämnd in Swedish