Presentation is loading. Please wait.

Presentation is loading. Please wait.

Dutch eID-Scheme Technical Specifications. Content High level introduction and background information Drivers and functional requirement Resulting landscape.

Similar presentations


Presentation on theme: "Dutch eID-Scheme Technical Specifications. Content High level introduction and background information Drivers and functional requirement Resulting landscape."— Presentation transcript:

1 Dutch eID-Scheme Technical Specifications

2 Content High level introduction and background information Drivers and functional requirement Resulting landscape Flow through landscape Questions/Discussion Design Decisions

3 Objectives for electronic services Objectives 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.

4 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 IDP K3 K1 K8 K5 K2 Broker AP Attribute Provider SIP Sector ID Provider AIP Authorization Information Provider Service Provider

5 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

6 Service Provider Authentication Provider Broker User Agent AuthnRequest serviceprovider - broker HTTP Artifact binding SOAP Binding User wants to access a protected service SP redirects user to Broker with an artifact Broker fetches the AuthnRequest through backchannel Attribute Provider

7 Service Provider Identity Provider Broker User Agent AuthnRequest broker- Identity provider HTTP Artifact binding SOAP Binding Identical flow for the Broker-IDP communication Attribute Provider

8 Service Provider Authentication Provider Broker User Agent 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 Attribute Provider

9 Service Provider Authentication Provider Broker User Agent Attribute Provider 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

10 Service Provider Authentication Provider Broker User Agent Attribute Provider 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

11 Authentication on behalf of other Service Provider Identity Provider Broker User Agent Authorisation Provider 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

12 Broker Summary Assertion SubjectConfirmationData.EncryptedID @ID, @Version, @IssueInstance Authnstatement Signature Conditions Statement.DeprecatedSubject Statement.ActingSubject Generic eID Statements Type, LoA, LinkedSignVal, etc. Issuer Declaration of Identity Subject @ID, @Version, @IssueInstance Advice Signature Conditions Statement.AttributeInformation2 Statement.AttributeInformation1 Generic eID Statements Type, LoA, LinkedSignVal, etc. Issuer Declaration of attribute Issuer @ID, @Version, @IssueInstance AdvicedeclarationOfIdentiy declarationOfAttribute Signature Conditions Authnstatement Broker Assertion Statement.AttributeInformation2 Statement.AttributeInformation1 Subject Statement.ActingSubject Statement.DeprecatedSubject

13 Subject @ID, @Version, @IssueInstance Authnstatement Signature Conditions Statement.DeprecatedSubject Statement.ActingSubject Generic eID Statements Type, LoA, LinkedSignVal, etc. Issuer Declaration of Identity @ID, @Version, @IssueInstance Advice Signature Conditions Statement.AttributeInformation2 Statement.AttributeInformation1 Generic eID Statements Type, LoA, LinkedSignVal, etc. Issuer Declaration of Authorisation Issuer @ID, @Version, @IssueInstance AdvicedeclarationOfIdentiy declarationOfAttribute Signature Conditions Authnstatement Broker Assertion Statement.AttributeInformation2 Statement.AttributeInformation1 Subject Statement.ActingSubject Statement.DeprecatedSubject Broker Summary Assertion With representation SubjectConfirmationData.EncryptedID

14 Questions Main concern; choices made in the Service Provider – eID Scheme interface Other points of interest

15 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

16 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

17 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

18 Other internal SAML issues Attributequery over asynchronous binding Linking of Assertions (adding context) Multiple subjects

19 Authorisation chain Information Chain Declaration of Identity ds:Signature SignatureValue= DecOfIDSignVal1 @ID= DoI111 Subject:TransAAA Declaration of Authorisation ds:Signature SignatureValue= DoAUsign2 @ID= DoA222 Subject:TransXYA Advice: @ID= DoI111 LinkedSign= DecOfIDSignVal1 Declaration of Attribute ds:Signature SignatureValue= DoAsign1 @ID= DoA333 Subject:TransAAA Advice: @ID= DoI111 LinkedSign= DecOfIDSignVal1 Declaration of Attribute ds:Signature SignatureValue= DoAsign1 @ID= DoA444 Subject:TransXYA Advice: @ID= DoA222 LinkedSign= DoAUsign2

20 Other questions Clarity: 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?


Download ppt "Dutch eID-Scheme Technical Specifications. Content High level introduction and background information Drivers and functional requirement Resulting landscape."

Similar presentations


Ads by Google