Feedback - Swiss e-ID and trust infrastructure: Trust protocol based on VCs

[bj-ms]

This thread is for feedback, questions or general inputs on the new trust protocol based on VCs specification.

Link to the new specification: https://github.com/e-id-admin/open-source-community/blob/main/tech-roadmap/rfcs/trust-protocol/trust-protocol.md

[mdoujak]

I like the idea of creating a trust protocol with VCs. I am just wondering on whether the proposal meets the expectations. To clarify my concerns, I have to provide a (probably incomplete) list of requirements:

1. To identify an issuer, I would like to receive a set of claims that is useful in the real world:

• Name
• Address
• Contact Information (phone, email,...)
• Web Site
• Legal references (e.g. Data Privacy Policy, ...)

2. To identify the authority of the entity that issued the Trust VC for the Issuer, I would expect the authority VC to be embedded in trust VC. This could be done recursively to create intermediate authorities and longer chains.
3. The claims of the authority would be similar or identical to the claims of the issuer.
4. Authority VCs should also carry "authorization" information. E.g. it could define, what types of VCs the authority is allowed to issue (Issuer VC and/or Authority VCs and/or Verifier VCs)
5. Issuer VCs could optionally contain a list of Schema references for VC Schemas this Issuer is able/allowed to issue. This could be combined with policy information (e.g. the Issuer is only allowed to issue a VC Schema of a specific Version, all Version issued after version X, or only the newest version.
6. Verifier VCs would have similar claims to the issuer VCs.
7. Verifier VCs should contain references to the presentation schemas that this verifier is able/allowed to request from the Holder.
8. As a Holder, I could then just have a list of dids of the root authorities of the ecosystems that I want to trust in my wallet and everything else could be derived from these "trust anchors". Each trust anchor would correspond with an ecosystem.

Example:

1. Santesuisse could decide to create an ecosystem for healthcare insurance in Switzerland. They would control the "Trust Anchor VC of the healthcare insurance" ecosystem.
2. SASIS could be the authorized intermediary to manage the technical part of the VC Issuance for the healthcare insurances.
3. As a Holder it is sufficient to trust Santesuisse to trust all the healthcare insurances.

Example 2:

1. BAG decides to create a healthcare ecosystem and they control the trust anchor of this ecosystem.
2. Santesuisse decides that healthcare insurance should be part of healthcare and they ask for Trust VC as a intermediate that can issue VCs for authorities, issuers and verifiers.
3. SASIS can retain their role to manage the technical parts of VC issuance.
4. HIN decides that their organization is also part of the healthcare ecosystem and they will receive a similar VC like Santesuisse.
5. As a Holder it is now sufficient to trust BAG to have all the doctors and all the healthcare insurances as trustworthy in the wallet.

[mdoujak]

I think you did not get my point. I object to TSPs having the trust anchors. If we create an ecosystem then the trust anchor should be under the control of the governance body of the ecosystem and not some TSP. This would have the following advantages:

1. Many governance bodies already exist and they have leverage with their issuers (as opposed to a commercial TSP). This not only applies to issuing Issuer-VCs but also facilitates discussion about the semantic interoperability o the VCs that will be issued by the Issuers. E.g. FINMA has leverage with the banks and they can manage the process, how banks agree on the content of a VCs for "Bonität" or a VC for "Kontoverbindung" much more easily than a TSP.
2. The governance body will be liable for the issuers to some extent. This liability already exists today for existing governance bodies. I don't see how a TSP could take on this type of liability, which they must, if they want to be the trust anchor. E.g. if FINMA issued a banking license to a russian hacker, I am sure there would be some kind of liability for FINMA.

Secondly, the Swiss Federal Administration is already gearing up to issue VCs for the E-ID, driver's license, and so forth. Issuing a VC for an Issuer (or Verifier) is just another Schema, with some claims and a different approver. I don't see that this makes a huge difference on the technical side.
Note: the number of issuers (and verifiers) is key. The level of automation required to handle the issuance will depend on the ecosystem. In finance I don't see a need for a high degree of automation since the total number of banks and FinTechs in Switzerland can still be managed manually. If we are talking about health care the number of ambulatory practices is in the tenthousands and automation would be needed. On the other hand FMH has with HIN already an organization that is perfectly placed to handle the issuance of issuer-VCs for doctors practices, should the need arise.

Last thought: The first attempt to an E-ID was declined by the Swiss population because they did not want a commercial organization to manage all the E-IDs. I am not sure what the reaction would be, if we tried to tell them that now the same commercial organizations will manage the entire trust layer.

I repeat: If a governance body decides to outsource the issuance of Issuer VCs to a TSP, I don't see a problem with that. But, the trust anchor remains with the governance body and the TSP just receives an Issuer-VC that allows the TSP to issue VCs to others.

[bjafs]

Hey there,

Thanks for your feedback!
Let me get back to you regarding the initial post.

At the moment, the trust protocol proposes a technical solution without delving too deeply into the governance of who operates it. The current legal framework assumes that the Confederation will manage a trust registry. Regarding additional third-party trust registries, there is no regulation within the e-ID bill.
Our current line of thought is that duplicating large amounts of information about entities from other existing registries is not highly beneficial and, moreover, complicates update mechanisms.
At its core, the value of the identity trust statement lies in the fact that the trust statement issuer has verified that the specific entity is who they claim to be. In our view, this is achieved by verifying that the person requesting the entry in the trust registry is authorized to act on behalf of the entity. Additionally, the entity needs to prove ownership of the Identifiers/Keys (DID-Document) hosted on the Confederation’s base registry.
By referencing the associated national registries (e.g., UID), our hypothesis was that additional information about the entity could be fetched from those sources. Information such as websites and legal references would most likely remain self-declared; therefore, we refrained from including them in the trust statement.

Authority
The current proposal is closely aligned with our regulatory requirements. It is relatively “flat” and does not currently foresee delegation to other authorizing bodies. This could be added at a later stage, or various sectorial “ecosystems” could exist in parallel. We are open to proposals on how this might evolve in the future.
In the current proposal, the issuer of the trust statement (in our case, the Swiss Confederation) serves as the authority verifying the information and issuing the statements. Since the authority signs the trust statements, its role is implicitly embedded in the trust VC. However, I believe I understand your point regarding chaining.

Authorization
If I understand you correctly, you are not referring to the proposed trust statements for issuance and verification, but rather suggesting that if VCs for authorities are introduced, information could be published regarding what they are allowed to attest. If we extend the concept, I believe it’s worth taking this into consideration.

Schemas
Schemas are mentioned in the Issuer and Verifier Trust Statements. Feel free to make a pull request or open an issue regarding the versioning. Currently, the hypothesis is that Issuer and Verifier Trust Statements and their associated schemas will primarily be offered for areas under the authority of the Confederation.
Regarding proof requests and presentation schemas, this is not a regulatory requirement at present. Evolution in this area could occur over time. However, since in Switzerland an entry in the trust registry is not mandatory, the system needs to function in a way that also works without this. To inform users about sensitive information in their credentials, a specific layer in OCAs will be used.

Multiple Trust Registries in Wallets
Yes, we see this as a possible evolution over time, but it is unlikely to be included at the initial launch of the system.

FYI: Most of us will be off during the festive season, so please bear with us if responses take a little longer than usual.

Best regards

[jurajsarinay]

a specific layer in OCAs will be used

Please avoid OCA. If unsure about this, find any computer scientist and show them the "specification".
My favourite gems:

• Numeric: a data type that defines anything relating to or containing numbers. Examples of numeric data types include 8-byte integers, fixed precision and scale numeric data, floating precision number data, integer (whole number) data, and monetary data values.

• Boolean: a data type where the data only has two possible variables: true or false. In computer science, Boolean is an identification classifier for calculating logical truth values and algebraic variables.

• Binary: a data type that defines a binary code signal, a series of electrical pulses representing numbers, characters, and performed operations. Based on a binary number system, each digit position represents a power of two (e.g., 4, 8, 16, etc.). A set of four binary digits or bits in binary code represents each decimal number (0 to 9). Each digit has two possible states: off and on (usually symbolised by 0 and 1). Combining basic Boolean algebraic operations on binary numbers makes it possible to represent each of the four fundamental arithmetic operations of addition, subtraction, multiplication, and division.

There are many encoding standards including Base64 [RFC4648], UTF-8, and ASCII to name a few. Each standard has a purpose, and applications using those encoding standards expect to receive data compliant with that encoding standard. The most popular types of character encoding are ASCII and Unicode [UNICODE]. While ASCII is still supported by nearly all text editors, Unicode is more commonly used because it supports a larger character set. Unicode is often defined as UTF-8, UTF-16 [RFC2781], or UTF-32 [ISO10646], which refer to different Unicode standards.

Figure 1. In a balanced network, semantic overlays determine the meaning and use of what is put in, taken in, or operated on by any process or system.

Figure 2. In a balanced network, inputs overlays determine what is put in, taken in, or operated on by any process or system.

The FOITT should do better.

[bjafs]

Thank you for your message.

In my understanding, your input pertains to the handling of the visual representation rather than the trust protocol. This topic is already being discussed in thread #32, where you have also shared your concerns on OCA. It is requested that this thread remain specifically focused on the proposed trust protocol.

[jurajsarinay]

your input pertains to the handling of the visual representation

Not really. The real concern is a Swiss government agency happily implementing (or seriously considering) any random nonsense from the Internet. This would not be appropriate at BAG or BAZL (say). Yet for BIT, it seems to be business as usual. Anything goes.

[mdoujak]

A few thoughts...

Trust Registry
I understand that the Confederation will operate a trust registry, but

1. There is no statement about how many ecosystems == trust anchors can be added to this trust registry. I suggest building the base technology of the trust registry so that multiple trust anchors can be operated by different governance bodies. This would allow Fedpol to manage the E-ID ecosystem, and the cantonal MVDs could manage the driver's licenses.
2. The law allows the trust registry to be used for purposes other than the E-ID but does not make the federal trust registry mandatory. This implies that the law intends to permit the federal trust registry to coexist with other trust registries. If this was not supported by the law, ambition level 3 would not be achievable.

Schemas
Before we start the discussion on how to manage Schemas, I suggest that we agree on what we want to achieve with these Schemas. A few points would be:

1. Innovation - the solution must evolve to accommodate new or changed requirements.
2. Information—The solution must provide the holder with enough information to make an educated decision about the identity of issuers and verifiers.
3. quality - The solution must provide the holder with enough information to understand (1) how reliable data provided by an issuer is and (2) how reliable information about an issuer or a verifier is.
4. authorization - The solution must provide the holder with enough information to understand who registered/authorized this issuer.
5. over identification—The solution must inform the holder if a verifier requests more claims than agreed upon during registration.

I am sure that I missed quite a few requirements, but I wanted to add these thoughts to our discussion before I leave as well.

Enjoy the holiday season, and all the best for the new year!

mike

[bjafs]

Thanks Mike,
We will get back to you on both points in the new year and will discuss taking the topic up for one of our next participation meetings.
All the best and a happy festive season!

[bjafs]

Hey mike,

I hope you had a restful break!
As promised, I’m picking up on our discussion from last year.

Regarding Trust Registries:

• Yes, it is indeed possible for multiple trust registries to operate in parallel.
• The e-ID Act neither regulates nor explicitly excludes third-party trust registries; it merely establishes a regulatory foundation for the trust registry operated by the Confederation.

The current technical proposal is relatively "flat" from a hierarchical perspective.
However, it allows for various registries (e.g., sector- or domain-specific) to run in parallel.
Within the trust registry managed by the Confederation, it is conceivable that authorization could be delegated to multiple authorities, allowing them to oversee governance surrounding their Verifiable Credentials (VCs). For example, ASA or Astra could act as the "owner" of the mDL, defining legitimate issuers (e.g., cantonal traffic authorities) and verifiers.

Additionally, within the Confederation’s trust registry, the confirmation of identities (e.g., ensuring that fedpol is who they claim to be) should largely be open to both private and public actors—provided certain stipulations are in place to ensure quality. This aligns with what is outlined in the e-ID Act.

The aforementioned claims of "legitimacy" will likely only be available for entities acting on behalf of the Confederation. This point should be clarified in the ordinance.
Third-party registries could potentially address gaps in this area.

Regarding Schemas:
I believe we are broadly aligned on this point. It’s might be worth differentiating between information that describes the content of a credential and information that pertains to the use and governance of a credential.

The idea behind the proposed trust protocol is to use a specific VC issued by the trust registry to convey information about the legitimacy of issuers and verifiers, referencing a schema.

I find the concept of "quality" interesting.
So far, my focus has primarily been on the actor level (verified vs. unknown).
Do you have any ideas on how to address this at the content level?

Regarding point 5, Switzerland has so far taken a slightly different approach.
Currently, there is no universal registration foreseen for verifiers.
It is up to the "owner" of a VC to decide whether they want to issue verifier legitimacy credentials.
In future, these credentials could be extended to include claims if needed.

The system is designed to support the "flagging" of sensitive information in a VC, warning users before transmitting this data to a verifier.
It will be up to the "owner" to define which of the data-fields are considered sensitive.

I’d be happy to explore these points further in an in-person meeting, if that’s of interest to you.

Kind regards,
Andreas