Dutch eID-Scheme

Technical Specifications

ContentHigh level introduction and background information

• Drivers and functional requirement• Resulting landscape• Flow through landscape

• Questions/Discussion Design Decisions

Objectives for electronic servicesObjectives

• Enhance security level

• Enhance confidentiality to guard privacy

• User-friendliness

• Free market processes

• Improve continuity

• Future stability

• Reduce costs

Requirements• Users should be in control with easy access to high

assurence levels using multiple tokens (both existing and new) and provide support for digital illiterates

• Unburden Service Providers and support multiple channels (web, mobile and S2S), decrease risks of abuse (fraud detection and prevention of identity fraud)

• Use Security by Design (compartimentation, data minimalisation and less trust in procedures) to create a more robust and resilient network, even during incidents

• Create market opportunities by standardisation of future proof interfaces (not implementation) based on open international standards and by providing a viable business model for private parties.

eID-Scheme

eID-scheme Landscape - Summary

• Many SP• K3: SAML easy adoption• Multiple Trust Providers

– Multiple roles– User in control– Each creates its own Assertion;

Multiple Assertions

• Broker– Hides network complexity– Enables user interaction– Is “blind” to what is declared

(privacy)– Summarizes the assertions for SP

IDPIDP

K3

K1

K8

K5

K2

BrokerBroker APAttributeProvider

SIPSector ID Provider

AIPAuthorization Information

Provider

Service ProviderService

Provider

Example of user-flow:Showing User Interaction, starting at accessing a protected resource for which age has to be established up to the authorization moment by Service Provider

ServiceProvider

AuthenticationProvider

Broker

UserAgent

AuthnRequest serviceprovider - broker

HTTP Artifact binding

SOAP BindingUser wants to access a protected serviceSP redirects user to Broker with an artifactBroker fetches the AuthnRequest through

backchannel

AttributeProvider

ServiceProvider

IdentityProvider

Broker

UserAgent

AuthnRequest broker- Identity provider

HTTP Artifact binding

SOAP Binding

Identical flow for the Broker-IDP communication

AttributeProvider

ServiceProvider

AuthenticationProvider

Broker

UserAgent

Response Identity Provider - Broker

HTTP Artifact binding

Way back is also artifact; to conceal the Assertion from the User Agent

Only now the response gets retrieved, containing the assertion

AttributeProvider

ServiceProvider

AuthenticationProvider

Broker

UserAgent

AttributeProvider

SOAP Binding

HTTP Artifact binding (!)

In order to make an Authorization decision, the SP need to know age. Therefor User is first sent to AP to retrieve that information

ServiceProvider

AuthenticationProvider

Broker

UserAgent

AttributeProvider

After consent, AP makes a Assertion of its own. Binds it to the context of the Authentication (assertion) en send user back to the Broker

Authentication on behalf of other

ServiceProvider

IdentityProvider

Broker

UserAgent

AuthorisationProvider

While remaining blind, the broker aggregates both assertions in a easy to process summary assertion. Which gets transported to the SP again over Artifact Binding

SOAP Binding

HTTP Artifact binding

Questions

Main concern; choices made in the Service Provider – eID Scheme interfaceOther points of interest

K3 interface: SP – broker - Functionality• Service provider asks eID-scheme to authorize the user for a certain

service• Broker optionally gives back all original Assertions; But also gives a

Summary• Summary Assertion will indicate the user is authorized for the

requested service, and holds most important information• Most service providers can rely on the broker summary assertion,

and do not have to validate and interpret all individual Assertions• Service Provider can make a default Authn-Request, one per Service• Service Provider receives a (fully compliant?) SAML Assertion, which

should be able to get used in automated processing by appliances

K3 interface: SP – broker Design Decisions

• WebSSO profile• Default is artifact binding for both request & response• Request, Assertion and ArtifactResponse always signed,

optionally response signed as well• No unsollicited responses• EncryptedID & EncryptedAttribute

– Allow broker to be “blind”(enhanced privacy)– Broker can collate Assertion from multiple Assertions

• AuthnContextClassRef default unspecified– Optional eID defined value for LoA in request; then in response as

well, otherwise default in Metadata

K3 interface: SP – broker Design Decision II

• Attribute extension– originalIssuer– lastModified

• Metadata– NameIDFormat used to indicate supported

persistent types and if transient will be accepted– AttributeConsumingServiceIndex in request links

to Service details in Metadata– Holds key and endpoint information

Other internal SAML issues

• Attributequery over asynchronous binding• Linking of Assertions (adding context)• Multiple subjects

Other questionsClarity:

Are the specifications clear enough to prevent multiple interpretations and loss of interoperability? If not, what suggestions do you have?

Conformance/compliancy: Is the K3 specification fully compliant with the SAML2.0-standard? If not, what (potential) divergences have you detected?Do you think the detected divergences are necessary? If not, what are alternatives to fully comply with the SAML-standard?Would it be a good idea to submit some of the divergences as change requests for the next version (2.1) of SAML? If so, which and how could this be done?

Software-support: Do leading software solutions provide sufficient ‘out-of-the-box’ support to easily implement the SP-side specifications?If not, what could be changed in the specification to make implementation easier? If not, what could be done to adapt leading software?What (open source) software would you recommend for providing a reference implementation or an interoperability test facility?

Else: Are there any other remarks you have on the dutch eID-specification as a whole with regard to interoperability, performance, security and privacy?