Tag Archive for: Privacy

What if the AHV number became an email address?

Digital identity is particularly important in official communication with authorities. Our guest author and President of the Conference of Cantonal Compensation Offices (KKAK) Andreas Dummermuth writes about his everyday life at the compensation office in the canton of Schwyz and future security solutions in authorities Social security is the most expensive infrastructure in Switzerland. Not the most important, but the most expensive. In 2015, 163 billion Swiss francs went into a health insurance fund, a pension fund, a family compensation fund, an accident fund or another fund. Trend: rising! 163 billion francs, that is 25 percent of Switzerland’s gross domestic product. So every fourth franc earned in Switzerland flows into social security. This enormous economic importance is necessarily reflected in the current financial and social policy discussions. Every franc that is spent must be spent in accordance with tight regulation. Every franc that is received also requires a clear factual and legal basis. Social security is so highly regulated because it involves 163 billion francs for over eight million people. Good, reliable and tangible organisation and implementation of social security is therefore a locational advantage for Switzerland.

Security in mass business

The procedure for handling this mass business is regulated in the Federal Act on the General Part of Social Insurance Law (ATSG). The procedure can be described in telegram style: No benefit without notification – no benefit without decree. Notification and decision are therefore the two cornerstones – in between there is a highly regulated clarification and decision-making process. As the manager of a cantonal social insurance office, the Schwyz Compensation Fund / IV Office, I have to ensure that all our legally defined social insurance products are produced correctly, economically, expeditiously and in a citizen-friendly manner. Our products have abbreviations: AHV, IV, EO, MSE, FZ, EL, IPV, PF, etc. In a small canton with about 157,000 inhabitants, we pay out annual benefits of about 750 million francs and collect social security contributions of half a billion francs. To do this, we scan almost a million pages of paper that are delivered to our offices every year. For twenty years, we have had a ‘paperless’ office in Schwyz with a digital archive and a workflow system, which has proven excellent for the internal control system and the quality management system, allowing for audit-proof processes. However, very fast and very accurate customer information is the most important thing about it. We know in every case and at every stage who has done what. By the way: everything that is scanned is disposed of in a physically secure way. What remains is only digital information. With annual IT security audits, we have this system constantly checked for security and functionality. Because we are of the opinion that the federal structure of implementation is also the best of all ways for social insurances, we do not cultivate cantonalism for a long time. Twenty cantons and the Principality of Liechtenstein have pooled their IT in the Swiss Informatics Society for Social Insurance.

App versus paper

Interim conclusion: We have a completely paperless procedure within the company. But before and after? In-bound’ and ‘out-bound’ are not yet completely digital. So digital registration and digital disposition are the next necessary steps. Personally, I think that this is technically the much smaller challenge than the paperless workflow system with the enormous data stocks. However, while we can act relatively independently internally, we are logically dependent on interfaces for ‘in-bound’ and ‘out-bound’. But now step by step according to the ATSG. Let’s start with the registration. In Schwyz, we can offer employers a free application for digital secure communication. The entire handling of social security contributions, family allowances, maternity compensation and income replacement regulations are handled by the companies and the compensation office without paper or signatures. AHVeasy is of course compatible with www.swissdec.ch. Unfortunately, however, many SMEs still prefer the traditional paper route, even though we in Schwyz give companies a twenty percent discount on their administrative cost contributions every year. So digital communication is working more and more with the companies. But it’s different with individual customers, the insured who want to receive a benefit. The associations ‘eAHV/IV ‘ and ‘Informationsstelle AHV/IV ‘ are working on a joint project to offer such new digital registration options. In the process, a problem is getting in our way that is not a problem at all. What do I mean? Legally, a registration does not have to have the signature of the insured person. But this principle is not lived. However, the tradition of a handwritten signature on a paper form has persisted for 200 years. This is called custom.

From the digital to the real

So when it comes to registration, we have some leeway: the registration does not actually have to be signed, but verification of the person is always possible. This leeway could be used for digital and intelligent registration tools. These would support the insured, relieve them of unnecessary form work and give the insurance bodies the data basis for their production applications. This brings us to the second point: the order. The bigger problem is the delivery of the decision, the dispatch of the decree. This must be done precisely: Today, the name and postal address of the insured person as well as their representatives can be ascertained, verified and standardised. If necessary, Swiss Post also offers secure delivery methods (e.g. A-Post plus or registered mail). Unfortunately, insurance carriers do not have a secure digital route. With a state-regulated digital identity, this would then be possible. Or formulated differently: Social insurance is dependent on a basic digital infrastructure (e-ID, secured mail address, reliable bandwidth). If we had that, then a simple, cheap and technically unspectacular way would be conceivable for the social insurances. Specifically: AHV number = email address. Full stop. Every natural person in Switzerland already has a national insurance number. This becomes AHV-Nummer@ahv.ch for example, or AHV-Nummer@sss.ch. ‘sss’ stands for “Social Security Switzerland”, which would be meaningful in all national languages and English. A central office, e.g. the Central Compensation Office ZAS, which already assigns the AHV numbers, deals with this and provides the e-mail address. The crux of the matter is the same as all other economic operators have: The verification of person and address. But half the world already does that today and that’s why we can do it in Switzerland too. The advantage for the population and all social security organs is clear: every communication and every delivery of an order can be made to this email address. And here too: Secured emails exist in private and public business life. You don’t have to do that either, you just have to install it. If one wants to. Social security is the most expensive infrastructure in Switzerland. As I said, not the most important, but the most expensive. That is precisely why it is worthwhile for this national economic infrastructure task to also have an economically modern infrastructure for communication.

Creative Commons LicenceCreate PDF

Related Posts

None found

Self-Sovereign Identities – Will we control our identity ourselves in the future?

In the real world we can identify ourselves easily and securely, but in the virtual world we still cannot. For digital identification, there are now several variants, but not always satisfactory. Now, self-sovereign identity seems to be gaining acceptance. Our author, BFH researcher Gerhard Hassenstein, explains what it has over the other concepts. Decentralised identities have many advantages over isolated and centralised identities in terms of flexibility and privacy protection, as explained in the previously published article. With a self-sovereign ID (self-controlled identity), the user regains sole control over his or her data, as central storage of identity data is no longer necessary. On the other hand, this also reduces data security problems of central identity providers, which are increasingly exposed to attacks. This article introduces the basic building blocks of Self-Sovereign Identities and explains their concept and functionality. The approach of a self-sovereign and decentrally organised identity is not new. This concept has already been used in various forms (e.g. Idemix[1] and uProve[2]). What is new about Self-Sovereign Identity (SSI) is that it works with a decentralised public register. This is a paradigm shift.

The main components of SSI

The technology behind Self-Sovereign Identity enables people, organisations or even things to control their digital identity themselves by also being able to determine at any time which personal attributes are transmitted during an authentication process. Users are thus given more rights but also accountability regarding their personal information.

Actors

– Theholder can create one or more identities themselves, each of which can be referenced with a DID[3] (a type of identifier). A holder first claims something about himself, e.g. where he lives (place of residence). Only when an issuer (e.g. the post office) has certified this, does this assertion become a verifiable proof. The holder can then present this proof, together with their identity, to a service provider (verifier) who can validate information and identity. – Theissuer authenticates properties (attributes) of a holder in the form of verifiable credentials, which have a standardised format[4]. The issuer ideally files the credential in a public register so that anyone can check it. The credential, on the other hand, he hands over to the holder for further use. Issuers are authoritative bodies such as authorities, companies or educational institutions. – Averifier receives a certificate from a holder and can check it with the help of the public register. The verifier can then use the credential to make a specific decision (e.g. access control).

Fig. 1: SSI components

Electronic wallet (ID wallet)

The holder stores DIDs, keys and proofs in a kind of electronic wallet, just as he stores his ID, driving licence, credit cards, etc. in his physical wallet in the real world. Such an ID wallet can be installed on any device and allows SSI data to be transferred from one device to another.

Agents and Hubs

To assist the holder in the processes of creating a DID, requesting proof, establishing secure communication with issuers and verifiers, etc., the SSI infrastructure provides digital agents that “wrap” and protect the ID wallet.

Fig. 2: Agents take the work off the owner’s hands

Decentralised public data registers

The fundamental change in SSI is the move away from a central authority that controls and stores identities. However, this requires a decentralised storage of identities. In order to still be able to offer a reliable data source, a tamper-proof, distributed database must be used in the form of a publicly verifiable data register that cannot be controlled by a single party. Among other approaches, blockchain technology, which is also used in a different form for cryptocurrencies, is a suitable solution.

How it works

Simple trust in an identity

The critical point in verifying a proof is the trust that can be placed in it. In other words, does a verifier trust the information in the proof, the issuer and the identity of the bearer? The trust relationship between the issuer, the holder and the verifier is immensely important. In a simple trust relationship, an examiner trusts the statement made by an issuer in the form of a proof about the identity of a holder.

Fig. 3: Simple trust relationship

In conventional systems, a service provider is only checked for identity (e.g. by a web server certificate). However, the verification of an “identity” is often not sufficient. In many cases, it would be desirable if a service provider could also provide proof of authorisation. This is difficult to implement in conventional models. SSI, however, supports this form of mutual trust with the help of verifiable evidence. An auditor becomes the “auditee”. For example, an owner could require that an auditor provide evidence that identifies him or her as an “insurer”. However, it should not only be possible to verify such trust relationships on a technical level (e.g. by validating digital signatures). Guidelines should also be created at the legal and business level that extend the trustworthiness into technical evidence.

Authentication (DID-Auth)

A holder of an SSI must be able to prove to an issuer or verifier that he controls or is in possession of it. The data formats and procedures for this are summarised under the term DID-Auth[5]. DID-Auth allows unilateral or mutual authentication and the transmission of “Verifiable Credentials” in a secure channel.

Loss of DID or Verifiable Credentials

In a decentralised identity architecture – such as SSI, what happens if a holder loses the DID or associated credentials on their device or it is destroyed? In a centrally administered and controlled identity, this is usually not a problem; you ask the administrator of the identity if they can restore it or issue a new one. After an appropriate verification procedure, the central administration of an identity should be able to do this without any problems. This is not the case with decentralised identities, where no central authority is involved in the creation. This shifts the responsibility to the identity holder. Procedures such as “distributed key management” help the owner to distribute his identity information (key material and other information) to trustworthy trustees and, in an emergency, to restore his identity with their help. Since the trustees only ever own parts of the identity, they cannot use or misuse it themselves.

Conclusion

Even though the technologies for self-sovereign identities are not yet fully developed and some parts are still under development[6], a trend towards self-sovereign identities is emerging. Today’s society has become more sensitive to the “protection of privacy” of each individual, and makes new demands in this regard. The legal situation (at least in Europe) has also changed with the Data Protection Regulation (DSGVO). A technically secure solution that takes into account the protection of the privacy of each participant and is still user-friendly has a future.


References

1] IBM Research: http://www.zurich.ibm.com/idemix [2] Microsoft (formerly Credentica): http://research.microsoft.com/en-us/projects/u-prove/ 3] Decentralised IDentity [4] The Verifiable Credentials Data Model was published in 2019: https://www.w3.org/TR/vc-data-model [5] https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/final-documents/did-auth.md [6] https://w3c-ccg.github.io/roadmap/diagram.html

Creative Commons LicenceCreate PDF

Related Posts

Secure identities are needed for the trust of customers

Isolated, centralised or decentralised – here, two researchers from BFH Technik und Informatik compare the advantages and disadvantages of the different solutions for identification Identity management refers to processes and services that deal with the collection, administration and use of electronic identities. An electronic identity management system must find the right balance between user-friendliness, security and data protection. Classical models follow the approaches of isolated or centralised identities, which can only partially fulfil these goals. In recent years, decentralised approaches have been strongly discussed and have already gained a lot of international attention with Self-Sovereign Identity (SSI). This article will compare these models and the architectures and concepts behind them in order to show the advantages and disadvantages of the individual solutions.

In a networked world, machines have an identity, but users do not

The internet was basically built without electronic identities. An end device could not know who (person, organisation, service or thing) it was connecting to except on a technical level. Machines communicate with each other via IP addresses. They can also, to a certain extent, verify the authenticity of a partner, as they can resolve the link between a name and the associated IP address in a decentralised name register (domain, name, system) when a connection is established. In order to be able to establish genuine trust in names, a certificate must be created for a specific end device. For users, the scope of such certificates is usually limited to companies. In global networks, certificates are therefore almost only issued for web servers by specialised services. These certificate providers are usually central entities that must be trusted completely, even though they are often unknown (e.g. DigiCert). The problem of electronic identities on the internet (especially for user identities) has not (yet) been solved, although theft and deception of identities are spreading rapidly. This development undermines the public’s trust in the internet.

Isolated identities

This is the most common solution. Many websites or portals in our daily environment use such isolated identities. Here, a user must first have his identity verified at each portal before an electronic identity is issued for him. The user agrees – depending on the requirements of the service provider – on one or more means of authentication (password, mobile TAN etc….) in order to access his account in the future. However, this is an isolated identity as it can usually only be used for this purpose (service provider). As shown in the picture below, the service provider here is the administrator and issuer of electronic identities, i.e. a so-called Identity Provider (IdP).

Figure 1: Isolated identity management

Although this model has the character of a decentralised solution, since an identity can only be used for one application, it brings with it some decisive disadvantages:

  1. From the user’s point of view: – For each service provider, the user receives a different electronic identity and, in many cases, a different means of authentication. This is difficult for the user to manage, as he or she has to maintain several electronic identities and the associated means of authentication locally. Solutions for simplification can be provided by password managers or cloud services for storing the identities. – The user must fully trust the service provider and its handling of their identity information. This is not very transparent for the user, even though the latest data protection laws require it.
  2. From the service provider’s point of view: – In order for the service provider to be able to verify the identity of the user, he has to store a proof of identity of the user with him (usually together with other information). – He is responsible for the security of the identity information he collects. For this reason, he must increasingly protect himself technically against the threat of misuse, as otherwise his reputation could suffer. – In order to be able to offer a contemporary and more secure authentication option, the service provider has to implement cost-intensive 2-factor procedures (e.g. additionally sending an SMS to the user’s mobile number) himself.

Central identities

Today’s service providers have, of course, long recognised these problems and solved them by taking a step towards centralised identities. They moved to delegate account management to specific companies. They allowed users to log in with an electronic identity issued and maintained by another company. Especially in the area of ‘social login’, this makes it easier for the user as they can log in to multiple apps and websites with one login. But the world has also become simpler for the service provider, as ideally they no longer need to set up their own identities. In an operational context, a central authentication service is often used for this purpose to relieve the burden on the applications. With centralised identities, the login and/or validation function is outsourced by the service provider to a specialised operator (identity provider) (1). The service provider trusts the identity provider’s processes and thus its confirmations.

Figure 2: Centralised identity management

In order to access a service provider, the user must first authenticate himself with the identity provider. After authentication, the identity provider sends the result to the service provider in the form of a confirmation. This makes it possible for a user to use a single identity for different service providers.

Two versions are possible in this model:

  • Isolated identity providers: Each IdP has – independent of other IdPs – its own identity data of the user, which is valid in its context. (e.g. “social login” solutions, such as Facebook, Google, Twitter, Amazon, Instagram, LinkedIn, Microsoft)
  • Networked identity providers: Several IdPs trust each other and, depending on the trust level, have a common set of identity data (attributes such as surname, first name, e-mail, etc.) of a user. The user can easily register with different IdPs because they share a common identifier. This common identifier is usually assigned by a state authority, which certifies the IdPs and provides them with standard identity data of a user. Each IdP certified in this model is free to add further attributes from its context to an identity. (e.g. E-ID of CH)

“central identities” have clear advantages over “isolated identities”, but they still have certain disadvantages:

  1. From the user’s point of view: – For the user, the administration of his electronic identity becomes easier, because he only has one or a few identities that he has to maintain. They should be able to use them with as many service providers as possible. Conversely, however, the user’s privacy is severely restricted because the identity provider is involved in every authentication process (login function) and is therefore able to remember when and how often a user has visited a service provider. This information can be used for profiling and targeted advertising. This form of unnoticed surveillance can only be prevented if the IdP is no longer involved in authenticating the user. – The user must now fully trust the identity provider and their handling of their identity information. In the end, this is not much more transparent for the user, even if more trust can be placed in specialised or even state-certified IdPs. – The user – who is actually the identity holder – becomes dependent on this service. If this service can no longer fulfil its function, the user’s electronic identity is also no longer accessible.
  2. From the service provider’s point of view: – Service providers delegate authentication to a specialised system of identity providers, which they trust completely. – This frees them from a burden: o they no longer have to store a user’s proof of identity with them. o they can obtain authenticated and thus trusted attributes from an IdP specialised for this purpose. From the perspective of the identity provider: – As data of users accumulates from different areas (service providers), it is worthwhile to carry out a complex data collection, to collect the user data and, if legislation allows it, to make money with it. There is a temptation to create multi-dimensional profiles, which, with powerful targeting and profiling tools, allow for a very efficient form of monitoring. The rich information from the user’s behaviour can be used for public advertising, but increasingly also for propaganda and electoral politics. – Aggregated data sets are increasingly becoming worthwhile targets for hackers. More and more, available resources are being freed up for misuse. Serious security problems can arise and become almost unmanageable. Such an IdP must protect identity information particularly well.

Decentralised identities

Self-Sovereign Identities (SSI) (2) try to get a grip on the remaining disadvantages. In this model, central instances can be dispensed with, since the identity information is independent of a centralised registration or certification authority or an IdP. Here, the focus is on the user as the owner of an electronic identity, because only he is in possession of his personal data (and never a central service or a state issuer). He can use this identity as needed in any environment, be it private or business (e.g. online shopping or in a government context).

Figure 3: Self-Sovereign Identity

As shown in Figure 3, the user is his own identity provider. He creates his own key material, identity and data from the beginning. All of a user’s data is initially “non-confirmed”. Only when an authoritative authority has authenticated a user’s attributes (asserted properties) do they acquire a certain value for consumers (service providers). However, this approach raises a number of other questions:

  • How can a service provider trust a user’s information? Misuse would be easy to realise. A user could impersonate someone else, or present false properties without the service provider being able to verify the correctness.
  • What if a user no longer has access to his decentralised information (key material, identity information, …)? No one can help him, as there is no central authority that could restore the key material or re-issue confirmed identity data.

For these and other questions, some solutions have already been worked out in the past.

  • The verifiability of a statement is transmitted by the user in the form of verifiable credentials to a service provider. In order to build trust (verifiability) in identity data, a public, verifiable, distributed data register is used in the network. With this, verifiability and immutability of transactions can be implemented by users and issuers storing information in it that allows a service provider to form a proof of the authenticity of the information received. Instead of a classic, centrally managed system with which electronic identities can be issued, distributed and verified, a decentrally organised system is used to publish and securely retrieve meta-information about an identity.
  • Solutions have also been developed on how the deposit and recovery of lost key material – without a central authority – can be implemented. Proposals for this are discussed under the term “Distributed Key Management System” (DKMS).

Conclusion

Isolated and centrally managed identities show major gaps, especially in terms of flexibility and privacy protection. New data protection laws in the EU, and hopefully soon also in Switzerland, demand that privacy and the right to self-determination be guaranteed. Regaining sovereignty over data will become a central concern in the near future. It is therefore not surprising that “Self-Sovereign Identity” (SSI) seems to be establishing itself as a future identity management solution. Self-Sovereign Identities” replace conventional identity solutions with a flexible and dynamic ecosystem that covers a wide range of application areas. For the first time, communication in the global network is provided with an identity by default with SSI. Without an identity, communication between two partners cannot take place at all. This still very young approach has already attracted a great deal of international attention (3) and further advantages that a decentralised, user-centred solution could offer are constantly being recognised. Especially in the environment of heterogeneous system landscapes, which can often be found in our everyday lives and in complex organisations, such an approach offers an undreamt-of simplification. This form of electronic identity is analogous to previous procedures with which we are familiar. Legitimisation behaves in exactly the same way as we prove our identity to each other every day in the real world. We take the required evidence out of our wallet and show it to a verifying authority. Based on its appearance and content, the verifier decides on the authenticity of the evidence we have received from other trustworthy parties in advance (e.g. identity card or driving licence). When and where we use this evidence is completely unknown to the issuer, but it is possible in this scenario that anyone (whether person, organisation or thing) can be the issuer and verifier.


References

  1. This also includes solutions in which the identity data is handed over to the user in the form of a smart card.
  2. Also known as “Bring Your Own Identity” (BYOI).
  3. Further information on Self-Sovereign Identity: https://ssimeetup.org
  4. Roadmap to Self-Sovereign Identity: https://w3c-ccg.github.io/roadmap/diagram.html
Creative Commons LicenceCreate PDF

Related Posts

Insurance companies rely on M2M communication

Suva has been using the Swiss wage standard (ELM) for many years to process wage declarations from companies. Now, in addition to the Swiss wage standard (ELM), the Swiss benefit standard (KLE) is to be introduced in order to be able to process claims digitally and without media discontinuity Digitalisation plays an essential role for the future development of the insurance business as well as for the companies insured with Suva. Suva is therefore increasingly relying on solutions that support M2M (machine-to-machine) communications. As a member of the Swissdec association, Suva has been relying on the successfully implemented Swiss wage standard (ELM) in the area of wage declarations for many years. This enables Suva-insured companies to transmit their annual wage declarations directly from Swissdec-certified payroll accounting systems to Suva and other institutions (AHV, tax offices, other insurers and FSO) without media discontinuity. For some years now, Swissdec has been working on a second standard together with Suva and other insurers. This is the Swiss benefit standard (KLE). In future, this will enable the complete processing of claims management and daily allowance processes from Swissdec-certified payroll accounting with Suva and other insurers who are ready to receive data. A major difference between the Swiss payroll and benefit standard is the bidirectional data communication and the binding nature of the process. For the settlement of accidents, the data exchange must take place via a secure and protected channel. In addition, it must be ensured that the recipient of the data is really the company it claims to be. For this reason, a solution such as Swissdec Enterprise Authentication (SUA) is mandatory when the Performance Standard-CH is used in practice. SUA not only fulfils the requirements for security and data protection, but also enables companies to obtain a so-called company certificate quickly and easily.

Creative Commons LicenceCreate PDF

Related Posts

None found