Working Group for the Swedish eID Framework

Meeting minutes - 2019-09-25

Attendees

Agenda/presentation

Below we include the contents for each slide in English (prefixed with "From the presentation").

Minutes

Suggested changes
PrincipalSelection extension

From the presentation:

Everyone agreed that there is a need to standardize this.

There is a draft published at https://docs.swedenconnect.se/technical-framework/updates/ELN-0614_-_Principal_Selection_in_SAML_Authentication_Requests.html.

Gunnar had a request that if an identity is passed using the PrincipalSelection extension the eIDAS node from a signature service, the eIDAS node should assert that the user-id (eIDAS ID) corresponds to the passed in identity before displaying the signature message. This is a good idea, but can be implemented in the eIDAS node without any changes being made to the technical framework.

Upgrade to the latest version of SAML2Int

From the presentation:

It was decided that we refer only to new SAML2Int as being an "inspiration", but make our technical framework normatively detached from SAML2Int, meaning that every requirement should be expressed within our specification (with the exceptions of references to core specifications and profiles).

Distinct requirements concerning algorithm support

From the presentation:

During the last year it has been clear that we need to document what should (and must) be supported concerning algorithms.

Everyone agrees that there is a need to clearly document what should be supported.

Editors note: We will probably add a MUST requirements for Identity Providers to support AES-GCM.

Uncertified LoA 3

From the presentation:

This is really an informational issue, where Martin asked everybody to not misuse loa3.

Entity categories for contracts

From the presentation:

Informational item with no further discussion.

Updated BankID profile

From the presentation:

Questions were raised why we declared a specific QR-code entity category for BankID. Why not use a generic identifier that affects other IdP:s also?

Martin replied that for Freja, it is more or less their choice how they would like to offer authentication services, where for BankID we have a little bit of different scenario where there are several IdP:s, but most important, the number of users that have been accustomed of a specific way of logging on using BankID.

Anyway. We (Martin) could not really argue in favour of just specifying this for BankID. Therefore, we will make changes in the drafts so that we remove the specific entity category for BankID and introduce a corresponding URI that is generic.

See Issue 96 for more details.

When discussing BankID there were questions about why we publish a specific profile for BankID, but say nothing about how Telia eID should be implemented within the federation. The reason for this is that Telia isn't used much anymore, and we haven't had any requirements to specify anything for those IdP:s. However, if the need arises we will look into it.

Declared algorithm support

For the presentation:

Informational item with no further discussion.

Samordningsnummer/Coordination number

From the presentation:

Informational item with no further discussion.

Certificate profile for SignRequest

From the presentation:

We will prepare the protocol so that it is possible to request a specific certificate profile, but will not define any profile identifier at this point.

Transaction evidence in signing certificates

From the presentation:

Informational item with no further discussion.

Other changes

From the presentation:

Informational item with no further discussion.

Other specifications and standards

From the presentation:

About the signature service specifications:

We all agreed that there is a need to take control of the normative specifications for signature services. As it is today, it is very hard to find the specifications, and they are in Swedish.

The working group suggests that all signature service specifications are written in English, and that it is developed and published from a GitHub repository. Should DIGG want to publish it from their own domain, this can also be accomplished.

The working group also suggests that there is a special working group that discusses, and leads, future development of the normative specifications.

About federation specific rules:

The working group agrees that there need to be a Sweden Connect Federation Policy in place. This policy would cover things that are not explicitly mentioned in the technical framework.

Currently we have some federation rules that can be found on swedenconnect.se, but we need to be more explicit on the matter.

Us a CPS/certificate policy needed for signature service CA:s?

Currently, a CA should follow the ETSI certificate policy. Stefan claimed that this is sufficient.

Other federations

From the presentation:

The working group discussed the matter and saw that the Swedish federations all are built upon the SAML WebSSO profile and "follows" SAML2Int. The differences are mainly:

We decided to try to involve each other in our respective work in order to understand, and hopefully make sure that our federations do not grow apart more that necessary. The aim should be that vendors should be able to have solutions that work for several federations.

Also, after the meeting Martin and Stefan discussed how we could solve the problems with the so called sigmessage URI:s used to indicate that a sign message has been displayed. See issue 95 for our suggestion.

When discussing the challenge that integrators and vendors face we came up the the proposal that there should be some sort of "Quality mark" that stands for "Compliant with Sweden Connect". We will bring this to DIGG.

The Technical Framework - Now and in the future

From the presentation:

Gunnar raised one thing regarding taking part in the work of developing the specifications for the Technical Framework and the signature service. It is hard for integrators (that are often working as consultants) to convince their management that they should be allowed to spend time for this kind of work. He suggested that DIGG creates a "group" to which all participants pay a fee. Only members are this group are allowed to respond to tenders concerning signature services and eID-solutions. By taking part in the work for the Technical Framework the fee could be reduced.

The Technical Framework - Roadmap

From the presentation:

Regarding "Getting rid of sigmessage URI:s", se issue 95. We will most likely include this is the coming version of the Technical Framework.

The work has started on "specifications for validation assertions and services". It will be done openly, and the specs and implementations will be published to GitHub.

The group discussed OpenID Connect, and there are use cases for OpenID Connect and signature services.