Web Based Validity Check of Identification Documents

2018-12-29   John Allberg   web e-leg

Since the summer 2017 I’ve been the editor for a new technical specification for revocation check for identity documents. It was finally publiched in beginning of november with the name
“SIS-TS 45:2018 Web Based Validity Check of Identification Documents”

Please buy it from SIS, it sponsors the workgroup for standardization of cards, TK448 , which I’m a member of. It enables us to continue to standardize for example the ISO/IEC 7816 series.

It would be even more fun if you choose to join TK-448 and helped with standarization! Get in contact with Anders Lindberg. 😀

Executive summary

The aim of the specification is to complement and eventually replace the phone based revocation checks for identity documents we use in Sweden today.

In it’s core it’s a simple web request that contains

  • type of ID document
  • the document number
  • expiry date
  • personal reference (for example the swedish personal number)

In the response you get a signed response if the identification document is valid or not.

The specification core

The core of the specification is the request from the relying party to the issuer of the identification document. It’s done over https and the content is json.

  "version": "1.0",
  "type": "SE-SIS",
  "serial": "9752219812312345678",
  "notAfter": "2020-06-16",
  "person": "191234561234",
  "reference": "42"

Whats requested above is the status of a swedish ID-card of the type SIS with document number 9752 2198 123 1234 5678 which is valid until 2020-06-16, issued to a person with personal number 191234561234.

As the response you get a signed (JWS) response with the following payload:

  "iat": "2018-12-29T08:20:23+0200",
  "status": "valid",
  "type": "SE-SIS",
  "reference": "42"

The reference in the response must match the reference the client supplied.

Originally the working group wanted the response to contain all parameters from the request, such as document number and personal reference, but in the comment letter from the Tax Authority they wrote that they eventually could not use the specification with all information in the request since that eventually could be seen as the Tax Authority exposing the information.

Managing keys and URLs

One of the obvious difficulties in the specification is the verification of the issuer signatures, especially establishing trust in the keys.

Therefor the specification includes a proxy function which is intended to offload the clients from managing the keys. Instead the client only trusts the proxy key, which the proxy uses to re-sign all responses from the document issuers. The proxy of course needs to to a signature verification on the signature from the issuers before re-signing. 😀

One other obvious difficulty is to know what URL to use för the identification documents.

Therefor the specification includes a “referral service” to find the URL for the request. The request to the “referral service” is the same format as to the issuer and the “referral service” responds with HTTP 303 and the URL to use.

Whats next?

I hope the major issuers of public identification documents in Sweden such as
the Police, banks, Tax Authority och Transportstyrelsen implements the specification.

Meanwhile, we in SIS/TK-448 will adopt the specification when problems are discovered during implementation.

My intention is to build a “Referral service” and a proxy with a GUI.

When at least one major issuer has implemented the specifikation it’s time for the “relying parties” such as banks to implement the client part of the specifikation and that’s also when “Referral service” and the proxy starts to be useful.

The Internationell Perspective

In december I was in Utrecht and presented the specification at CEN 224, the working group within the european standardization which, among other things, manages standards for smartcards.

It was well received and to my surprise none of the other countries currently had anything similar and they saw great potential not just within a country but also inter-country. In particular, the proxy function would take on the “single-point-of-contact” for a country, abstracting the internal issuers away from other countries.

To start standardizing withing CEN you need five contries which vote for the work item and are supplying their experts. We were joined by Germany, France and Holland so we are currently missing one more country. Lobbying for another country to join will now be started and formally proposing a NWIP (new workitem proposal).

<< Tidigare inlägg ("Så kan du minska bedrägerier med BankID")

Share This:    
John Allberg

John har arbetat med elektronisk identifiering och e-legitimationer sedan 2000. Först på Posten eSäkerhet mellan 2000 och 2004, sedan på Telia mellan 2004 och 2008. Från 2009 är han konsult inom området och 2010 grundade han Ayoy tillsammans med Oscar Jacobsson.