WP-Number: 24000...Aug 31, 2017 · Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Introduction 4/57 IDV_24001_Interface_Specification.docx 1 Introduction

State Secretariat for Economic Affairs SECO

IDV_24001_Interface_Specification.docx

Interface Specification

WP-Number: 24000

Project Sponsor State Secretariat for Economic Affairs SECO

Project Manager Marc Zweiacker

Author AdNovum Informatik AG

Number 24001

Classification Not classified, internal, confidential, CLASSIFIED

Status Pending, approved

List of Changes

Date Version Changes Author

07.06.2017 0.2 Initial version of interface specification AdNovum Informatik AG

11.08.2017 0.7 Added detailed message format AdNovum Informatik AG

30.08.2017 0.9 Document for review AdNovum Informatik AG

Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Introduction

2/57


Table of Contents

Introduction ...................................................................................................................... 4 1

Summary ........................................................................................................... 4 1.1

Target Audience ................................................................................................ 4 1.2

Status of this Document .................................................................................... 4 1.3

Notation ............................................................................................................. 4 1.4

Terminology ...................................................................................................... 5 1.5

References ........................................................................................................ 7 1.6

Overview and Structure of the System ............................................................................. 9 2

Overview ........................................................................................................... 9 2.1

Design Guidelines ........................................................................................... 10 2.2

Use of SAML Protocols ................................................................................... 10 2.3

External Interfaces Catalogue ......................................................................... 11 2.4

Requirements ................................................................................................................ 12 3

General Requirements .................................................................................... 12 3.1

IDV Broker Requirements ................................................................................ 12 3.2

RP Requirements ............................................................................................ 14 3.3

IdP/AA Requirements ...................................................................................... 15 3.4

Runtime Protocols .......................................................................................................... 17 4

Authentication (and Attribute) Relaying ........................................................... 17 4.1

Fetching of IDV Attributes by the IDV Broker ................................................... 21 4.2

IDV SAML Message Format ........................................................................................... 22 5

Metadata ......................................................................................................... 22 5.1

Name Identifiers .............................................................................................. 26 5.2

Attributes ......................................................................................................... 27 5.3

SAML Protocol Message Content (General) .................................................... 27 5.4

SAML Protocol Message Content (RP Participants) ........................................ 27 5.5

SAML Protocol Message Content (IdP Participants) ........................................ 32 5.6

Security .......................................................................................................................... 34 6

Baseline Requirements ................................................................................... 34 6.1

Digital Signatures in a SAML 2.0 Context ........................................................ 34 6.2

Assertion Conditions ....................................................................................... 35 6.3

Data Transfer Encryption ................................................................................. 35 6.4

SAML 2.0 Requests and Responses ............................................................... 35 6.5

Attribute Definitions ........................................................................................................ 37 7

IDV Name Identifiers ....................................................................................... 37 7.1

Level of Assurance (LoA) for Authentication .................................................... 37 7.2

IDV Attributes .................................................................................................. 38 7.3

Message Format Examples ........................................................................................... 39 8

RP Participant Related Message Format Examples ........................................ 39 8.1

IdP Participant Related Message Format Examples ........................................ 47 8.2

Extensions and Special Cases ....................................................................................... 54 9


3/57


Integration of Non-IDV-Conformant IdPs ......................................................... 54 9.1

IDV Attributes .................................................................................................. 55 Annex A:

Annex A 1: Overview ..................................................................................................... 55

Annex A 2: Common IDV Attributes .............................................................................. 55

Annex A 3: Attributes G2C Domain (Integration Pilot) ................................................... 56

Annex A 4: Attributes G2G Domain (Integration Pilot) ................................................... 57


4/57


Introduction 1

Summary 1.1

Today’s information systems must be protected; a simple fact also applicable to the public

administration. User management and access control are among the core tasks of IT opera-

tion departments. These tasks are rather costly, as users need to be identified and regis-

tered. The users, in turn, need to enroll with each service separately. Access data and ac-

cess tools they receive cannot be used anywhere else, so ordinary internet users accumulate

numerous accounts and passwords over time, raising chances for them to be handled care-

lessly. On the other side, users need to be identified, registered and administrated by each

organization separately.

There are ways to have a user authenticate for your local service with authentication means

they have received from somewhere else. Those methods can be used without lowering the

level of trust. Besides, they are based on international security standards.

IDV Schweiz allows interconnecting identity providers and attribute authorities on one side,

with service providers operating web applications in such a way on the other side. It allows a

user to access a multitude of web applications with his preferred account at a given identity

provider. The service providers can give up their own user management, solely relying on

authentication done outside their own perimeter.

Target Audience 1.2

The IDV platform interface specification is targeted for participants of the platform and covers

the platform requirements for relying parties (RP) and identity providers (IdP) which may also

act as attribute authority (IdP/AA).

Status of this Document 1.3

The present version of the interface specification is based on IDV system requirements 1.0

([IDV-REQ]), the IDV platform system architecture and the current prototypes. The technical

scope and protocols are frozen. The document has been released so that it can be reviewed

by interested parties.

At the end of September 2017 an updated version of this specification will be published incorpo-

rating the feedback obtained so far. Version 1.0 of this specification will be published at the end of

the IDV integration pilot phase, mainly addressing the remaining technical scope that is not yet

available during the integration phase of the IDV broker:

IdP/AA communication with use of an extended SAML AuthnRequest

IdP/AA communication with use of a SAML AttributeQuery via Side Call

Notation 1.4

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,

“SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be

interpreted as described in [RFC2119].

Conventional XML namespace prefixes are used throughout the listings in this specification

to stand for their respective namespaces as follows, whether or not a namespace declaration

is present in the example:

Prefix XML Namespace Comments Example

ds http://www.w3.org/2000/09/xmldsig# This namespace is defined in the XML

<ds:X509Certificate>


5/57


Signature Syntax and Processing specification [XML-DSIG].

ext urn:oasis:names:tc:SAML:attributes:ext SAML V2.0 attribute extensions [SAML-ATTR-EXT].

ext:OriginalIssuer

md urn:oasis:names:tc:SAML:2.0:metadata SAML V2.0 metada-ta namespace de-fined in the SAML V2.0 metadata specification [SAML-META].

<md:EntityDescriptor>

mdattr urn:oasis:names:tc:SAML:metadata:attribute SAML V2.0 metada-ta attribute namespace defined in the SAML V2.0 metadata extension for entity attributes [SAML-META-ATTR].

<mdattr:EntityAttributes>

mdui urn:oasis:names:tc:SAML:metadata:ui SAML V2.0 metada-ta extension namespace defined in the SAML V2.0 metadata exten-sions specification for login and discov-ery user interface [SAML-META-UI].

<mdui:Logo>

saml2 urn:oasis:names:tc:SAML:2.0:assertion SAML V2.0 asser-tion namespace defined in the SAML 2.0 core specifica-tion [SAML-CORE].

<saml2:NameID>

saml2p urn:oasis:names:tc:SAML:2.0:protocol SAML V2.0 protocol namespace defined in the SAML 2.0 core specification [SAML-CORE].

<saml2p:Response>

xenc http://www.w3.org/2001/04/xmlenc# XML Encryption Syntax and Pro-cessing [XML-

ENC].

<xenc:EncryptedData>

xsd http://www.w3.org/2001/XMLSchema This namespace is defined in the W3C XML Schema speci-fication [SCHEMA1]. In schema listings, this is the default namespace and no prefix is shown.

xs:string

Terminology 1.5

A complete glossary for IDV is maintained in a separate document. The definitions of some

important terms are copied here to simplify the look-up for the reader.

Term Definition

Attribute Au-

thority (AA) Attribute Authority (AA) is an entity, usually a directory, offering a service to manage and query

attributes regarding a subject. It is able to issue attribute assertions.

IDV Domain The services of an IDV platform are provided for domains. In this sense IDV Schweiz is divided

into domains, whereas a domain is a kind of circle of trust between an IDV domain manager,

IdPs and RPs which all agree on a common domain policy, attribute set, and quality models

which guide the authentication service provided by IDV for that domain.


6/57


Home Realm

Discovery

(HRD)

A user selects a suitable identity provider from a list of available identity providers. After selec-

tion, the user will be redirected to the IdP for authentication.

Identity Pro-

vider (IdP) A kind of service provider that creates, maintains, and manages identity information for princi-

pals and provides principal authentication to other service providers within a federation, such as

with web browser profiles [SAML-GLOSSARY].

IdP/AA Stands for an identity provider (IdP) which is also an attribute authority, which is the case for

most IdPs.

IDV The project IDV Schweiz develops the necessary technical infrastructure and organizational

measures for a Swiss-wide identity and authentication federation platform (IDV platform) based

on the STIAM architecture standards according to eCH.

IDV Admin The IDV admin application (short IDV admin) covers the functionality for management of the

participating entities (service providers, identity providers, and attribute authorities). This part

covers the so-called “definition-time” services.

IDV Broker The IDV broker provides the so-called “runtime” functionality, which covers the authentication

process of an end user for a service provider. The IDV broker implements an authentication

brokering service based on [ECH-0168].

IDV Platform Central platform (IDV platform) to link eGov services with matching identity providers and attrib-

ute authorities for the purpose of user authentication. The IDV platform should address govern-

ment to citizen (G2C), government to business (G2B), and government to government (G2G)

scenarios.

LoA A Level of Assurance, as defined by the by ISO/IEC 29115 Standard, describes the degree of

confidence in the processes leading up to and including an authentication. It provides assurance

that the entity claiming a particular identity is the entity to which that identity was assigned.

PET Privacy-Enhancing Technologies is a system of ICT measures protecting informational privacy

by eliminating or minimizing personal data, thereby preventing unnecessary or unwanted pro-

cessing of personal data without the loss of the functionality of the information system [PET-

HANDBOOK].

PII Personally identifiable information

Relying Party

(RP) A Relying Party (RP) is an entity which uses the IDV platform to authenticate users and obtain

attributes regarding them in order to control access to its resources.

Service Pro-

vider (SP) A Service Provider (SP) is used in the present document as a synonym of RP. Thus in the con-

text of IDV, SPs are mostly governmental organizations operating web applications (eGov ser-

vices).

SAML Re-

quester A system entity that utilizes the SAML protocol to request services from another system entity (a

SAML authority, a responder). The term “client” for this notion is not used because many system

entities simultaneously or serially act as both clients and servers. In cases where the SOAP

binding for SAML is being used, the SAML requester is architecturally distinct from the initial

SOAP sender [SAML-GLOSSARY].

SAML Re-

sponder A system entity (a SAML authority) that utilizes the SAML protocol to respond to a request for

services from another system entity (a requester). The term “server” for this notion is not used

because many system entities simultaneously or serially act as both clients and servers. In cas-

es where the SOAP binding for SAML is being used, the SAML responder is architecturally dis-

tinct from the ultimate SOAP receiver [SAML-GLOSSARY].

Single Page

Application

(SPA)

Web application that fits on a single web page with the goal of providing a user experience simi-

lar to that of a desktop application.

System Entity,

Entity An active element of a computer/network system. For example, an automated process or set of

processes, a subsystem, a person or group of persons that incorporates a distinct set of func-

tionality [RFC4949].

User Consent

(UC) To comply with data protection laws, the user has to give his consent when personal data is

transmitted from one party (notably from an IdP/AA or an AA) to another party (normally a RP).

https://aww.adnovum.ch/confluence/display/IDVCH/IDV+Platform+System+Architecture#IDVPlatformSystemArchitecture-SAML-GLOSSARY


7/57


References 1.6

Reference Description

[CAB-

FORUM] CA/Browser Forum

https://cabforum.org/

[ECH-0097] eCH (2015, Nov) eCH-0097: Datenstandard Unternehmensidentifikation [Online]

https://www.ech.ch/vechweb/page?p=dossier&documentNumber=eCH-

0097&documentVersion=3.0

[ECH-0107] eCH (2013, Dec) eCH-0107: Gestaltungsprinzipien für die Identitäts- und Zugriffsverwaltung

(IAM) [Online]

http://www.ech.ch/vechweb/page?p=dossier&documentNumber=eCH-


[ECH-0113] eCH (2012, Jun) eCH-0113: Spezifikation SuisseID [Online]



[ECH-0167] eCH (2014, Jun) eCH-0167: SuisseTrustIAM-Rahmenkonzept [Online]



[ECH-0168] eCH (2014, Nov) eCH-0168: SuisseTrustIAM technische Architektur und Prozesse [Online]

http://www.ech.ch/vechweb/page?p=dossier&documentNumber=eCH-0168

[ECH-0170] eCH (2014, Jun) eCH-0170: eID Qualitätsmodell, Version 1.0 [Online]



[ECH-0170V2] eCH (2017, Jan) eCH-0170: Qualitätsmodell zur Authentifizierung von Subjekten, Version 2.0

[Online]

Version 2.0, Status Entwurf, Publiziert am 09.01.2017

https://www.ech.ch/vechweb/page?p=dossier&documentNumber=eCH-


[ECH-0174] eCH (2015, Nov) eCH-0174: SuisseTrustIAM‐ Implementierung mit SAML 2.0. [Online]


0174&documentVersion=1.0[

[EIDAS] EU regulation on electronic identification and trust services for electronic transactions in the Eu-

ropean Single Market. The set of standards was established in EU regulation № 910/2014 of 23

July 2014 on electronic identification and repeals directive 1999/93/EC.http://eur-

lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32014R0910

[ID-META-

INTEROP] Identity Metasystem Interoperability Version 1.0, OASIS Standard, 1 July 2009. [Online]

http://docs.oasis-open.org/imi/identity/v1.0/identity.html

[IDV-

GLOSSARY] IDV Glossary, State Secretariat for Economic Affairs SECO.

[IDV-REQ] IDV System Requirements, Version 1.0, 26.04.2017, State Secretariat for Economic Affairs

SECO.

[RFC2119] RFC 2119, Key words for use in RFCs to Indicate Requirement Levels, BCP 14, March 1997.

[Online]

https://tools.ietf.org/html/rfc2119

[RFC2397] RFC 2397, The "data" URL scheme, L. Masinter, August 1998. [Online]


[RFC4949] RFC 4949, Internet Security Glossary, Version 2, Internet Engineering Task Force, August 2007.

[Online]


[RFC5280] RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List

(CRL) Profile, D. Cooper NIST, S. Santesson Microsoft, S. Farrell Trinity College Dublin, S. Bo-

eyen Entrust, R. Housley Vigil Security, W. Polk NIST, May 2008. [Online]

https://www.ietf.org/rfc/rfc5280.txt

[SAML- Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0, J. Hodges, R. Phil-



https://www.ech.ch/vechweb/page?p=dossier&documentNumber=eCH-0097&documentVersion=3.0


http://www.ech.ch/vechweb/page?p=dossier&documentNumber=eCH-0107&documentVersion=2.0




















http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32014R0910

http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32014R0910

http://docs.oasis-open.org/imi/identity/v1.0/identity.html




https://www.ietf.org/rfc/rfc5280.txt


8/57


GLOSSARY] pott and E. Maler, March 2005. [Online]

https://www.oasis-open.org/committees/download.php/21111/saml-glossary-2.0-os.htm

[SAML-ATTR-

EXT] OASIS Standard, SAML V2.0 Attribute Extensions, Version 1.0, Committee Specification 01, 4

August 2009. [Online]

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-attribute-ext-cs-01.pdf

[SAML-BIND] OASIS Standard, Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0 -

Errata Composite, Working Draft 06, 8 September 2015. [Online]

https://www.oasis-open.org/committees/download.php/56779/sstc-saml-bindings-errata-2.0-wd-

06.pdf

[SAML-

CORE] OASIS Standard, Assertions and Protocols for the OASIS Security Assertion Markup Language

(SAML) V2.0 – Errata Composite, Working Draft 07, 8 September 2015. [Online]

https://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata-2.0-wd-

07.pdf

[SAML-META] OASIS Standard, Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0 –


https://www.oasis-open.org/committees/download.php/56785/sstc-saml-metadata-errata-2.0-wd-

05.pdf

[SAML-META-

ATTR] OASIS Standard, Security Assertion Markup Language (SAML) V2.0 Metadata Extension for

Entity Attributes V1.0, 06 February 2009. [Online]

http://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-attr-cd-01.pdf

[SAML-META-

PREV] OASIS Standard, Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0 –

Errata Composite, Working Draft 04, 1 December 2009. [Online]

https://www.oasis-open.org/committees/download.php/35391/sstc-saml-metadata-errata-2.0-wd-

04-diff.pdfhttps://www.oasis-open.org/committees/download.php/56785/sstc-saml-metadata-

errata-2.0-wd-05.pdf

[SAML-META-

UI] OASIS Standard, SAML V2.0 Metadata Extensions for Login and Discovery User Interface, V1.0,

03 April 2012. [Online]

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-ui/v1.0/sstc-saml-metadata-

ui-v1.0.pdf

[SAML-PROF] OASIS Standard, Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 –


https://www.oasis-open.org/committees/download.php/56782/sstc-saml-profiles-errata-2.0-wd-

07.pdf

[SCHEMA1] H. S. Thompson et al. XML Schema Part 1: Structures. World Wide Web Consortium Recom-

mendation, May 2001.http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/

[STORK2] Secure idenTity acrOss boRders linKed 2.0 project aims to establish a European eID Interopera-

bility Platform allowing citizens to establish new e-relations across borders, just by presenting

their national eID. [Online]

https://www.eid-stork2.eu/

[WEBTRUST] AICPA/CICA WebTrust Program for Certification Authorities

http://www.webtrust.net

[XML-DSIG] XML Signature Syntax and Processing (Second Edition), W3C Recommendation, 10 June 2008.

http://www.w3.org/TR/xmldsig-core/

[XML-ENC] XML Encryption Syntax and Processing, W3C Recommendation, 10 December 2002.

http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/





http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-attribute-ext-cs-01.pdf

https://www.oasis-open.org/committees/download.php/56779/sstc-saml-bindings-errata-2.0-wd-06.pdf

https://www.oasis-open.org/committees/download.php/56779/sstc-saml-bindings-errata-2.0-wd-06.pdf

https://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata-2.0-wd-07.pdf

https://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata-2.0-wd-07.pdf

https://www.oasis-open.org/committees/download.php/56785/sstc-saml-metadata-errata-2.0-wd-05.pdf



http://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-attr-cd-01.pdf



https://www.oasis-open.org/committees/download.php/35391/sstc-saml-metadata-errata-2.0-wd-04-diff.pdf

https://www.oasis-open.org/committees/download.php/35391/sstc-saml-metadata-errata-2.0-wd-04-diff.pdf



http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-ui/v1.0/sstc-saml-metadata-ui-v1.0.pdf

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-ui/v1.0/sstc-saml-metadata-ui-v1.0.pdf

https://www.oasis-open.org/committees/download.php/56782/sstc-saml-profiles-errata-2.0-wd-07.pdf



http://www.w3.org/TR/2001/REC-

http://www.w3.org/TR/2001/REC-



http://www.webtrust.net/

http://www.webtrust.net/

http://www.w3.org/TR/xmldsig-core/

http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/

Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Overview and Structure of the System

9/57


Overview and Structure of the System 2

Overview 2.1

The project IDV Schweiz develops the necessary technical infrastructure and organizational

measures for a Swiss-wide identity and authentication federation platform (IDV platform).

The IDV broker is the core component of the IDV platform. It acts in a similar way as the

STIAM Hub specified in [ECH-0168].

The main customers of the IDV broker are the relying parties (RP), which provide services to

different groups of users through web applications. At some point the relying parties need to

authenticate the user and delegate this task to a trust domain on the IDV platform.

The platform maintains a list of identity providers (IdP) and attribute authorities (AA), which

are part of an IDV domain and together build the identity federation.

The registration of participants such as IdP, RP, AA can be done in a self-administration

mode. An IDV admin application providing workflow-based processes with approval steps will

ensure that no domain policy is violated by a registrant. The registration info is based on

SAML metadata of the participants.

IDV admin: The IDV admin application component covers most of the definition-time and

administrative requirements. The administration of the IDV platform and the initial setup of an

IDV domain are done by the IDV system administrators. The IDV domain management is

handed over to domain managers as well as to the system administrators of the participating

entities (RP, AA, IdP).

IDV broker: The IDV broker component covers the runtime requirements. During an authen-

tication relaying operation triggered by a RP (B), the broker interacts with the user through a

web browser to leave the user the freedom to choose a suitable IdP. The user is then redi-

rected to the IdP for authentication (D), which returns a SAML assertion to the broker upon

successful authentication. Depending on the requested attributes, the broker may query AAs

for additional attributes about the user (C), before returning the result to the RP.

Figure 1: IDV Platform External Interfaces


10/57


Currently, there are no generally available pure AAs, they might exist in custom IDV do-

mains. But most of the time, the IdP is also a source of attributes and covers the functionality

of an AA. Such a twin component will be called IdP/AA in this document.

Each IDV domain's own IdP metadata and each IDV domain's own RP metadata are pub-

lished and made available for download for RPs and IdP/AAs (H). The format of the metada-

ta follows [SAML-META].

Design Guidelines 2.2

A number of basic principles have guided the design of the IDV platform:

Use of open standards: The IDV platform defines a set of interfaces and protocols with

no prescription about the implementation. Protocols and interfaces are based on open

standards such as SAML 2.0.

Platform independence: The IDV platform is a platform-independent framework. There

is no demand for a specific computer system, architecture, processor, or operating sys-

tem.

Usability (user’s perspective): Users need to be able to use IDV Schweiz in the sim-

plest way possible and safely for electronic commerce (e-business, e-government). Users

should have to interact as little as possible, but at the same time always be in control of

their data.

Ergonomics: The use of an IDV solution must not generate any significant additional ef-

fort for the user, or impair the ergonomics of the dependent e-government applications,

e.g. by increased waiting times.

Usability (relying party’s perspective): Relying parties within the IDV ecosystem

should be able to integrate and use the relaying infrastructure quickly and easily. Thus,

for example, as much information as possible about an IDV participant should be stored

in the IDV platform infrastructure already at the define-time, i.e. at registration, in the form

of metadata, so the runtime requests can be kept simple. In particular, the integration

costs for a relying party are to be kept as low as possible.

Transparency: The IDV broker should not act as an additional platform, but work in the

background as far as possible. It should thus seamlessly integrate with already known

processes.

Enforcement of data protection: IDV should allow for scenarios with different data pro-

tection requirements.

Segregation: In terms of a needs-based segregation, the relaying infrastructure should

support different domains, which should be specifically distinguishable by their scope and

their policy. The IDV platform needs to support segregation also as a means of mitigating

operational risks.

Traceability: IDV Schweiz must establish clear rules for all participants in the network

and also enforce these rules. The relaying infrastructure must be controllable, traceable

and auditable.

Use of SAML Protocols 2.3

The protocol used has a direct impact on the achievable level of authentication according to

the quality model defined in [ECH-0170V2]. The IDV platform should also be usable for use

cases requiring a high level of authentication.

Best suited for the two core domains is the "SAML 2.0 Web Browser SSO-Profile with HTTP

POST Binding". It is used as base protocol for [ECH-0174]. This protocol is the one with the

least demanding connectivity requirements between the involved components. Only the user


11/57


agent needs to be able to connect to the IdP, IDV platform, and the SP. No direct connection

is required between IdP and IDV platform, or IDV platform and SP.

Drawback of the usage of the Web Browser SSO profile is that the exchanged messages are

exposed on the user agent. One way to address this issue is to use encrypted assertions. In

the revised version of [ECH-0170V2], encryption of assertions will be one way of achieving a

federation LoA of 2. The other way to achieve a federation LoA of 2 is to use the artifact bind-

ing to transfer the responses from the IdP to the IDV broker (“Back Channel” in [ECH-

0170V2]), and from the IDV broker to the relying party. The disadvantage of artifact binding is

that it requires a connection from the IDV broker to the IdP. For organizational IdP/AAs as

used in G2B or G2G scenarios, this might become an issue. Because a federation LoA of 2

is also possible with encryption, the initial version of the IDV platform does not support arti-

fact binding.

Holder-of-Key (HoK)

[ECH-0170V2] requires the usage of the “Holder-of-Key (HoK) Web Browser SSO Profile” to

achieve a federation LoA of 4 (highest federation LoA). This significantly limits the available IdPs,

because the holder-of-key pattern is only well-standardized for X509 certificates. Other ap-

proaches than X509 certificates exist to implement a holder-of-key pattern but they would require

some additional standardization effort between the involved parties (including some custom pro-

cessing for key verification). This is something that might be done for a custom domain. There-

fore, HoK will not be supported by the IDV platform in the first version due to the limitation of the

IdPs, the additional complexity required, and the fact that there is no pilot use case needing a

federation LoA of 4.

External Interfaces Catalogue 2.4

ID Name Description Application Profiles

A Relaying Inter-

face between

RP and IDV

Broker

Users are interacting with their browser and will be redirected to

the IDV broker SAML SSO endpoint by the relying party where

they requested a service.

The relying party has no direct connection with the IDV platform

during runtime. With the HTTP post binding, the user is redi-

rected to the relying party by the IDV platform after successful

authentication of the user by the IdP.

SAML 2.0 Web Brows-

er SSO with HTTP

POST Binding

B Relaying Inter-

face between

IDV Broker and

IdP/AA

Normally, the IDV platform has no direct connection with the IdP

during runtime. For some IdPs/AAs, interface C is used to fetch

attributes. In case of HTTP post binding, the user is redirected to

the IdP for authentication and the IdP uses the same approach to

transmit the answer back to the platform.

SAML 2.0 Web Brows-

er SSO and Attribute

Query with HTTP

POST Binding

C Attribute Query

Interface on

IdP/AA for IDV

Broker

The IDV broker may fetch the requested attributes by an attribute

query via a side call to an IdP/AA over this interface. With the

current technical scope the interface will only be used for

IdPs/AAs offering no other possibility to access the attributes.

SAML Attribute Query

with SOAP Binding

X Metadata Inter-

face of IDV Bro-

ker

RPs may periodically import the IDV domain metadata of the

IDV broker (SSO endpoint)

IdPs and AAs may periodically import the IDV domain

metadata of the IDV broker (ACS endpoint)

SAML 2.0 Metadata

Integration Pilot

During the integration pilot, interface C is not yet available.

Table 1: External interfaces catalogue

Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Requirements

12/57


Requirements 3

The following high-level overview of the participant requirements was extracted from the IDV

technical scope that was agreed with the IDV architecture board.

Custom IDV domains may have more restrictive policies resulting in additional requirements

for participants. See also chapter 6, Security, for additional details.

General Requirements 3.1

IDV participants have to implement the following general requirements:

Requirement Description

Time synchroniza-

tion Each participant of the IDV platform that issues SAML messages or consumes SAML mes-

sages MUST synchronize its time with an accepted time server.

Conformance All applied standards (SAML 2.0, HTTP, ...) MUST be applied in accordance with the cor-

responding specifications.

Security See chapter 6, Security

The initial IDV domains are intended to be used for web applications. Thus, the end users,

which should be authenticated by the IDV platform, access the application with a web brows-

er. Due to the broad usage scenarios of IDV, IDV isn’t able to impose a certain type of

browser. But all operating systems now have an integrated update mechanism to ensure that

the web browser and other system components are regularly updated with the latest security

patches. Thus, it’s legitimate to assume that the user has a recent version of its favorite

browser.

Many web applications using IDV will not only be accessed from classical desktop PCs, but

more often from tablets and smartphones. Thus, the runtime user interfaces of IDV should

follow a responsive design approach.

IDV Broker Requirements 3.2

The following functionality is supported by the IDV broker:

Function Comment

Identity Proxying Mode Similar to [ECH-0168], chapter 3.4.1

SAML 2.0 Web Browser SSO-Profile

with HTTP POST Binding and bearer

assertions

See [ECH-0174] and SAML specifications.

SAML 2.0 Web Browser SSO-Profile

with HTTP POST Binding and en-

crypted bearer assertions for feder-

ated LOA2+ according to [ECH-

0170V2].

This is similar to SAML 2.0 Web Browser SSO-Profile with HTTP POST

Binding in [ECH-0174] but using encrypted assertions according to the

SAML specifications.

Support for IDV domains to segre-

gate the IDV ecosystem An IDV domain is a kind of circle of trust between an IDV domain manag-

er, IdPs and RPs which all agree on a common domain policy, common

semantics (domain-specific identifier, attribute set and quality models)

which guide the authentication service provided by IDV for that domain.

Initially, there will be an IDV e-government domain for G2C (and later

G2B) use cases and an IDV e-government domain for G2G use cas-

es.

In future, there will be an IDV core domain representing the most

comprehensive domain (a kind of community), including the G2C,

G2B and also B2C use cases.

Table 2: General requirements


13/57


Additionally, further domains called "custom domains" with more spe-

cific requirements and features are supported.

Home realm discovery (HRD) Available set of IdPs is computed based on IDV domain membership

of a relying party, requested authentication LoA and requested attrib-

utes.

Supports grouping of IdPs and prioritization of IdPs

User consent (UC) Support of a user centric approach to comply with data protection laws.

IDV domain-specific Persistent ID ("distributed id"), RP Persistent ID, Persistent ID and Transient ID

Due to privacy requirements, the IDV platform must support four types of name identifiers for the authenticated subjects (see chapter 7.1, IDV Name Identifiers).

Several authentication LoA models Authentication LoA based on current version of [ECH-0170] with indi-

vidual authentication LoA per IdP

o Implementation of LoA attribute similar to [ECH-0174]

4 levels custom authentication LoA model for IDV domains other than

the core domain

Support of multiple authentication LoAs per IdP during authentication

Metadata support Provisioning of SAML broker IdP metadata (used by connected RPs) and SAML broker RP metadata (used by connected IdPs) per IDV domain.

Predefined attribute sets per IDV domain.

Enforcement of IDV domain mem-bership and enforcement of con-formance with metadata down to attribute level.

Support of legacy IdPs Transformation of attribute names ("renaming") obtained from the

IdPs before remitting them to the RP

Transformation rules on the IDV broker to reorganize attributes and

their related values obtained from the IdPs before remitting them to

the RP

Support of 'Partial Identity Relaying Mode' for RPs

Optional disclosure of "origin of attributes/authentication" (policy per

IDV domain)

Optional disclosure of original assertions in identity proxying mode

Disclosure can be prohibited by an IdP to support anonymous IdP/AA

Audit Audit trail, including all SAML messages during a relaying operation

In particular, the following functionality is not addressed by the IDV broker:

IdP linking

Retrieval of attributes from pure AA

Identity Relaying Mode: the IDV platform will not support identity relaying according to

[ECH-0168], chapter 3.4.2

SAML 2.0 Web Browser SSO-Profile with HTTP POST Binding and Artifact Binding for

the responses (alternative approach for FLoA2)

SAML 2.0 Holder-of-Key Web Browser SSO Profile (FLoA3)

Re-authentication ("refresh session")

Step-up authentication

Single logout for enterprise domains

Session-based attribute queries

Some of the functionality may be added in future versions of the IDV broker.

Table 3: IDV broker requirements


14/57


RP Requirements 3.3

3.3.1 Define-time Requirements

Function Comment

Each RP MUST be registered on the IDV

platform as RP.

Each RP MUST configure its services on

the IDV platform either by its metadata or

from scratch.

For the SP role the following descriptive information needs to be pro-

vided:

The public key(s) used by the SP for signing MUST be specified

The public key(s) used by the SP for encryption SHOULD be

specified

UIInfo (DisplayName, description and logo) as well as a support

URL and a privacy URL MUST be specified

Required minimal authentication LoA MUST be specified

At least one AssertionConsumerService MUST be specified

The expected NameIDFormat MAY be specified

One or more AttributeConsumingService MAY be specified

SP MAY be configured to receive the original assertions inside

the SAML assertion

SP MAY be configured to receive the origin of authentication or

attributes within the issued assertion

SP MAY assign a priority to some IdPs/AAs to make them appear

at the top of the HRD list

SP MAY mask some IdPs/AAs (i.e. exclude all commercial

IdPs/AAs which exceed a certain pay per usage level) by means

of IdP groups

3.3.2 Runtime Requirements

Function Comment

RP MUST support the SAML 2.0 Web Browser SSO-Profile with HTTP

POST Binding and bearer assertions.

RP MUST sign authentication requests to the IDV broker.

RP MUST (according to its configuration on the IDV platform) be able to

validate and interpret responses sent back from the IDV broker.

RP MAY use AttributeConsumingServiceIndex in authentication

requests to the IDV broker to request IDV attributes.

RP MAY specify one single IdP in IdPList to emulate IdP first.

RP MAY set the required minimal level in the authentication request. MUST be higher than or equal to the

required minimum authentication

LoA specified at define-time.

RP MAY request a less restrictive name id format.

RP MAY force the IDV broker to request that the presenter must be au-

thenticated directly on the IdP/AA rather than the IdP/AA relying on a pre-

vious security context.

Table 4: RP define-time requirements

Table 5: RP runtime requirements


15/57


In chapter 5, IDV SAML Message Format, the exact format of the exchanged messages is

defined.

Integration Pilot

During the integration pilot, the registration and configuration of RP are done manually.

Pilot Domains

G2C pilot domain and G2G pilot domain are inspired by [ECH-0170V2]. Therefore, RPs that want

to be registered in one of those pilot domains have to fulfill the following additional requirement:

RP MUST be able to process encrypted assertions if it requested it (e.g. in case of authentica-

tion LoA >= 2).

IdP/AA Requirements 3.4

3.4.1 Define-time Requirements

Function Comment

Each IdP/AA MUST be registered on the IDV

platform as IdP/AA.

Each IdP/AA MUST be configured on the IDV

platform either by its metadata or from scratch. For the IdP/AA role, the following descriptive information

needs to be provided:

The public key(s) used by the IdP/AA for signing MUST be

specified

UIInfo (DisplayName, description and logo) as well as a

support URL and a privacy URL MUST be specified

The IdP/AA MUST declare the maximum authentication

LoA it can provide

The IdP/AA MUST declare the supported NameIDFor-

mat(s)

The IdP/AA MUST declare the supported attributes

The IdP/AA MAY specify if consent is obtained directly at

IdP/AA

3.4.2 Runtime Requirements

Function Comment

IdP/AA MUST support the SAML 2.0 Web Browser SSO-Profile with HTTP POST Binding

and bearer assertions.

IdP/AA MUST sign the authentication response sent back to the IDV broker and the con-

tained SAML assertion.

IdP/AA MUST return the requested authentication LoA in its response. IdP/AA MAY return

also a higher-level authentication LoA if the user was authenticated accordingly.

IdP/AA SHOULD support persistent name identifiers, otherwise it can be used only for RP

requesting IDV transient name identifiers. See also chapter

7.1, IDV Name Iden-

tifiers

IdPs/AAs that provide attributes SHOULD support some of the predefined attribute sets

per domain. Furthermore, such IdPs/AAs SHOULD be able to process AttributeCon-

sumingServiceIndex in SAML AuthnRequests. Alternatively, they MAY support ex-

tended AuthnRequests or AttributeQuery.

See also chapter

4.2, Fetching of IDV

Attributes by the IDV

Broker

Table 6: Define-time requirements


16/57


In chapter 5, IDV SAML Message Format, the exact format of the exchanged messages is

defined.

Integration Pilot

During the integration pilot, the registration and configuration of IdP/AA are done manually.

In case of attribute requests the IDV broker will use AttributeConsumingServiceIndex in

AuthnRequest with IdP/AAs.

Outlook

Based on the the IDV broker will also support additional methods to request attributes:

Broker will also support extended AuthnRequest with IdP/AAs

Broker will also support AuthnRequest followed by AttributeQuery with IdP/AAs

Pilot Domains

The G2C pilot domain and G2G pilot domain are inspired by [ECH-0170V2]. Therefore, IdPs that

want to be registered in one of those pilot domains have to fulfill the following additional require-

ment:

IdP/AA MUST be able to issue encrypted assertions if it supports authentication LoA >= 2.

Table 7: IdP/AA runtime requirements

Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Runtime Protocols

17/57


Runtime Protocols 4

Authentication (and Attribute) Relaying 4.1

4.1.1 Overview

The following sequence diagram describes the protocol to authenticate a user to the subject

and to optionally return attributes.

Step Description

1 The user wants to access a resource on a RP.

2 The RP creates a <samlp:AuthnRequest> towards the IDV broker and sends it to the browser of

the user (subject) in a self-submitting HTML form.

If IDV attributes are required, the RP specifies a <samlp:AttributeConsumingServiceIndex> in

the <samlp:AuthnRequest> (see chapter 5.5.1, SAML AuthnRequest (RP → IDV Broker)). If only

authentication relaying is requested, the index is omitted.

3 The browser sends the <samlp:AuthnRequest> of the RP to the <md:SingleSignOnService> of the

IDV broker as HTTP POST message.

Figure 2: Authentication protocol


18/57


4 The IDV broker looks up the RP (by RP ID of the <saml:Issuer> element of the SAML request) in its

metadata store (<md:entityID> entry).

The IDV broker verifies the signature of the <samlp:AuthnRequest> with the X.509 certificate of the

RP based on its metadata.

If the RP specified an <samlp:AttributeConsumingServiceIndex> in the request, the IDV bro-

ker looks up the required IDV attributes based on the index.

5 The IDV broker creates a list of suitable IdPs/AAs based on the given request and its SAML metadata store. The following parameters are evaluated by the IDV broker to compute the list: Domain membership: Only IdPs/AAs that have the same domain membership as the RP are added to

the list.

Requested authentication LoA: Only IdPs/AAs that support the minimum LoA the RP requested are

added to the list.

Requested attributes: Only IdPs/AAs that support the requested attributes from the RP are added to

the list.

RP's configured IdP group selection: Domain managers can define groups of IdPs, based on attributes

and properties of the IdP. Based on the domain’s IdP groups, the relying party can form their own

groups to mask some IdPs/AAs (i.e. exclude all commercial IdPs/AAs which exceed a certain pay per

usage level).

Preliminary User Consent

In case that IDV attributes are requested by the RP and the UC needs to be requested by the IDV

broker, the IDV broker has to request the user's consent already at this point before releasing attrib-

utes fetched from an IdP/AA to a RP.

If the list of suitable IdPs/AAs contains more than one entry, an HRD dialog is displyed to the user.

6 The user selects based on the list of IdPs/AAs (computed in step 5) an IdP/AA and submits it as HTTP

POST request to the IDV broker.

7 The IDV broker creates a <samlp:AuthnRequest> towards the selected IdP/AA and sends it to the

browser of the user in a self-submitting HTML form.

8 The browser sends a HTTP POST message with the <samlp:AuthnRequest> to the SSO service of the

IdP/AA.

9 The IdP/AA shows a login dialog to the user and requests user credentials (username/password, PKI-

based, 2FA, etc.).

10 The user provides its user credentials to the IdP/AA to log in.

11 The IdP/AA authenticates the user. Depending on the SAML request, the IDV/AA fetches also attributes.

If the IDV broker on behalf of the RP asked for user attributes, the IdP/AA MAY ask for the user's con-

sent (note: per default, user consent is asked by the IDV broker).

Afterwards, the IdP/AA creates a <samlp:Response> with an <saml:Assertion> that contains a

<saml:AuthnStatement> and optionally (if attributes were fetched) a

<saml:AttributeStatement>.

The IdP/AA has to digitally sign the <samlp:Response> and the <saml:Assertion>.

Finally, the IdP/AA sends a <samlp:Response> to the browser of the user in a self-submitting HTML

form.

12 The browser sends an HTTP POST message with the <samlp:Response> of the IdP/AA to the ACS

service of the IDV broker.

13 The IDV broker verifies the digital signatures of the <samlp:Response> and the <saml:Assertion> of

the IdP/AA. In case IDV attributes were requested (and no IdP/AA native consent was already requested), the IDV broker sends an HTTP response to the browser of the user to display a UC dialog.

14 The user gives its UC.

15 The IDV broker creates a <samlp:Response> with a <saml:Assertion> that contains a

<saml:AuthnStatement> and optionally (if attributes were fetched) a <saml:AttributeStatement>.

The IDV broker has to digitally sign the <samlp:Response> and the <saml:Assertion>.


19/57


Finally, the IDV broker sends back the <samlp:Response> to the browser of the user in a self-

submitting HTML form.

16 The browser sends an HTTP POST message with the <samlp:Response> of the IDV broker to the ACS

service of the RP.

17 The RP verifies the signatures of the <samlp:Response> and the <saml:Assertion> of the IDV bro-

ker. The RP uses the response of the IDV broker to take a decision whether to deny or grant the user access to the resource according to its locally defined policy.

18 In case the RP grants access to the resource, it submits the resource data back to the browser of the user.

4.1.2 Identity Proxying

The IDV platform supports identity proxying as described in the eCH standard ([ECH-0168],

chapter 3.4.1) by means of authentication and attribute brokering from one source. This

mode is preferred because it simplifies the usage of IDV for relying parties, and allows many

other features, which support simplification. Additionally, this mode blinds IdPs from RPs and

vice versa.

To cover use cases where it may be important for an RP to get more detailed information

about the origin of the nameId and/or the received attributes, the IDV platform supports to

enrich each attribute and the authentication statement within the issued assertion with infor-

mation of the origin. If the RP needs to verify the originally issued assertion of an IdP/AA,

disclosure of original assertions in proxying mode is also supported. The last two features

reduce the trust needed in IDV and add more traceability and transparency for relying par-

ties. It is paid with loss of privacy, which might allow RPs to gain more information about the

end users (derived from the IdP/AA used for authentication). Furthermore, the RP configura-

tion gets more complex as RPs need to know the metadata of each IdP to be able to verify

the original assertions.

Domains should be careful with those features and establish clear rules about their usage in

the domain policies.

4.1.3 User Consent

Asking the user’s consent whenever information about him is transmitted to the relying party

is an important part of privacy, trustworthiness and data protection. Therefore, when an RP


20/57


requests attributes (i.e. user profile information) from an IdP/AA, the user must be informed

by default about the transfer of this information and, if required, the user's consent must ex-

plicitly be obtained before releasing attributes from an IdP/AA to an RP.

On the IDV platform there are two types of domains:

Domains where user consent MUST be obtained by the IDV broker or the IdP/AA such

as domains with "private" users (e.g. citizens)

Domains where there is no need for user consent requests at all as the user consent is

given by other means (e.g. in case of government employees acting as member of their

organizations on services of other government organizations)

Pilot Domains

In case of the G2C pilot domain, user consent MUST be obtained by the IDV broker or the

IdP/AA.

In case of the G2G pilot domain, user consent is not requested.

The IDV platform supports two ways of user consent for domains where user consent must

be obtained:

IDV broker user consent as a fill-in (default)

Native IdP/AA consent (user consent is already implemented in the IdP/AA and cannot

be omitted)

Display / Confirmation of the Requested Attributes

The confirmation page MUST show the name and value of each attribute that was requested

except for attributes that are marked as sensitive on a IDV domain (e.g. AVS/AHV number).

In case of sensitive attributes, only the name is displayed.

The following is a sample confirmation dialog provided by the IDV broker:

There are no optional attributes. The user can only approve or decline the consent for the

whole attribute set. If the user declines the consent, the SAML response attribute Consent is

set to urn:oasis:names:tc:SAML:2.0:consent:unavailable.

For users regularly working with the government, cantons or municipalities, it may be annoy-

ing in their daily business to be repeatedly asked for consent for the same attributes. This is

especially true when accessing RPs which would do an attribute-based access control. For

such cases, the IDV platform supports the possibility for the user to store his last given con-

sents per attribute set and RP in a manner that user consent can be omitted in the subse-

Figure 3: Sample confirmation dialog


21/57


quent requests. A later change in the attribute set or new values of the attributes will trigger

user consent again.

4.1.4 Relay State

The IDV broker and IdP/AA MUST support RelayState parameters as indicated in the SAML

binding specification ([SAML-BIND]). If the RP uses RelayState in its authentication request,

the IDV broker MUST return the same RelayState in its response. If the IDV broker uses Re-

layState in its authentication request the IdP/AA MUST return the same RelayState in its re-

sponse.

According to the SAML 2.0 binding specification, RelayState data MAY be included in a

SAML message submitted using the binding. The value MUST NOT exceed 80 bytes in

length. Relay state SHOULD be considered a handle from the point of view of the service

provider and SHOULD be integrity protected by the entity creating the message. Signing is

not realistic given the space limitation. But because the value is exposed to third-party tam-

pering, the entity SHOULD ensure that the value has not been tampered with by using a

checksum, a pseudo-random value, or similar means.

Fetching of IDV Attributes by the IDV Broker 4.2

The IDV broker is able to get the attributes from the IdPs/AAs in one of three different config-

uration modes.

4.2.1 IdP/AA Communication with Use of Attribute Sets (Default)

The metadata of the IdP/AA contains the definition of the provided attribute sets and the IDV

broker request contains the information from the domains' metadata provisioned.

4.2.2 IdP/AA Communication with Use of an Extended AuthnRequest

The IdP/AA sends the list of attributes by answering a specific (extended) AuthnRequest

which contains the list of the provided attributes. This mode is typically used for IdPs/AAs

that cannot handle attribute sets (AttributeConsumingServiceIndex) and don't support

AttributeQuery via side call.

4.2.3 IdP/AA Communication with Use of an Attribute Query via Side Call

The IdP/AA must support AttributeQuery service calls. After the AuthnRequest the IDV bro-

ker does a standard compliant AttributeQuery request according to chapter 5.6.3, SAML At-

tributeQuery (IDV Broker → IdP/AA) (over a different channel than the user browser) to re-

ceive the list of attributes the IdP/AA provides.

The channel that is used is a SOAP channel. Therefore, the basic flow contains the following

steps:

The broker sends a SOAP request containing the SAML AttributeQuery to the appropri-

ate service endpoint of the AA. The NameID from the previously received assertion con-

taining an authentication statement is used as query parameter.

The AA validates and authorizes the request, fetches the attributes based on the re-

quested NameID, which has to be known to the IdP/AA, and issues a SAML assertion,

which is returned to the IDV broker.

o The authorization can be based on an X509 certificate of the broker (domain):

Transport layer: 2-way SSL handshake, or

Message layer (WS-Security): signed SOAP message

Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification IDV SAML Message Format

22/57


IDV SAML Message Format 5

The following subchapters specify the message format of exchanged SAML metadata as well

as of SAML <AuthnRequest> messages, SAML <AttributeQuery> messages and SAML

<Response> messages to be exchanged between IDV participants.

The message format is described with tables containing a set of the following columns:

Column Description Comment

Element /

Attribute Name of element / attribute that is specified as well as path

to the element / attribute.

Description Description of the element / attribute that is specified.

Availability Describes whether an element / attribute MUST, SHOULD

or MUST NOT be included in a SAML request. Applicable only for request mes-

sages.

eCH-174 Describes whether the element / attribute is handled similar-

ly or differently than described in [ECH-0174].

Default Describes the default values for the element / attribute and

its precedence.

RP Metadata Describes whether the element / attribute can be specified

in the RP metadata. Applicable only for request mes-

sages issued by the RP.

Domain Describes whether domain-wide defaults can be specified

for the element / attribute.

Level Key word describing the level of a element /attribute. Key word is to be interpreted as

described in [RFC2119].

Comments Comments about the element / attribute.

Metadata 5.1

The IDV platform needs to know which entities are part of the system and it needs to know

the configuration parameters of the participating system entities. This configuration is called

metadata. The IDV platform provides a standard way to exchange this information with the

participants by means of SAML metadata.

IdPs/AAs and RPs publish their metadata during the registration of their entities on the

IDV platform, see chapters IdP/AA metadata and RP metadata.

In the same manner, the IDV platform publishes the domain's own IdP metadata and the

domain's RP metadata, see chapters 8.1.2, Broker (Domain IdP) Metadata and 8.2.2,

Broker (Domain RP) Metadata.

Each RP and each IdP/AA MUST configure its services on the IDV platform by its metadata. In the following sections, "MUST" is to be read as "MUST either be provided in the metadata or di-rectly on the platform".

5.1.1 RP Metadata

Standard RP Metadata

Structure: <md:EntityDescriptor>/<md:SPSSODescriptor>/...

Implicitly defined:

<md:SPSSODescriptor>[AuthnRequestsSigned]: true

<md:SPSSODescriptor>[WantAssertionsSigned]: true

<md:SPSSODescriptor>[protocolSupportEnumeration]:

urn:oasis:names:tc:SAML:2.0:protocol


23/57


Explicitly defined: Element / Attribute Description Level Comments <md:EntityDescriptor>

[entityID] Unique identifier for an IDV participant.

MUST

<md:KeyDescriptor>

[use="signing"]/<ds:KeyInfo> Complete chain

(<ds:X509Certific

ate> elements) of the

certificate used to sign

SAML <AuthnRe-

quest> message.

MUST The IDV broker will use this key material to validate the signature

of the SAML <AuthnRe-

quest>.

<md:KeyDescriptor>

[use="encryption"]/

<ds:KeyInfo>

Certificate to use for encrypting SAML asser-tions.

MAY The IDV broker will use that key material to encrypt SAML asser-tions.

<md:AssertionConsumerService> Elements Assertion-

ConsumerService

describe indexed end-points that support the profiles of the Authenti-cation Request protocol defined in [SAML-PROF].

Attribute index MUST

be set. Attribute isDe-

fault MUST NOT be

set.

MUST AssertionConsumerServ-

iceURL provided in the SAML

<AuthnRequest> MUST con-

form to the Attribute Location.

<md:AttributeConsumingService> Describes an application or service provided by the service provider that requires or desires the use of SAML attributes.

MAY Zero or more AttributeCon-

sumingService elements

provided by the domain policy. The corresponding indexes are freely definable and MAY be used by the RP in the SAML

<AuthnRequest>.

According to [SAML-META], at most one At-tributeConsumingS-

ervice element can have

the attribute isDefault

set to true. The default ele-ment is the first element with the isDefault attrib-

ute set to true. If no such elements exist, the default element is the first element without the isDefault at-

tribute set to false. If no such elements exist, the de-fault element is the first el-ement in the sequence.In IDV this behavior is kept simpler as in [SAML-META-PREV]: If no such elements exists, a plain authentica-tion request is sent.

Therefore, the attribute isDe-

fault must only be used if no

plain authentication request is required.

<md:NameIDFormat> Specifies the expected NameIDFormat in the

SAML assertion.

MAY MAY be overridden by the RP during run-time in the SAML

<AuthnRequest> with the

NameIDPolicy element. If both

are not present, the NameIDFor-

mat of the domain policy is ap-


24/57


plied.

Metadata Extensions for Login and Discovery User Interface

The <mdui:UIInfo> container element, defined below, MUST appear within the <md:Extensions>

element of <md:SPSSODescriptor>, see [SAML-META-UI].

Element / Attribute Description Level Comments

<mdui:UIInfo>/<mdui:DisplayName> Name displayed during HRD and UC.

MUST MUST be provided in GE, FR, IT and EN.

<mdui:UIInfo>/<mdui:Description> Description displayed dur-ing HRD and UC.


<mdui:UIInfo>/<mdui:Logo> Logo displayed during HRD and UC.

MUST MUST be provided either language independent or in GE, FR, IT and EN. In order to facilitate the usage of logos within a user interface, logos MUST:

use a transparent background where appropriate

use PNG

use minimal height of 80 pixels

use aspect ratio between 1:1 and 8:3

The logo MUST be provided as data URL scheme according to [RFC2397], e.g. data:image/png;base64,iVBORw0K...

<mdui:UIInfo>/

<mdui:InformationURL> A URL to local-ized information about the entity operating the RP.

MUST MUST be provided in GE, FR, IT and EN. May be used by the IDV broker to redirect the user to a support page.

<mdui:UIInfo>/

<mdui:PrivacyStatementURL> A URL to local-ized information about the priva-cy practices of the entity oper-ating the RP.


IDV-Specific RP Entity Attributes

The SAML V2.0 metadata specification [SAML-META] includes the <md:Extensions> ele-

ment in various places, including the <md:EntityDescriptor> element, for use in extending

the specification by carrying externally defined content. [SAML-META-ATTR] defines such an

extension element <mdattr:EntityAttributes> as a container for one or more

<saml2:Attribute> or <saml2:Assertion> elements. The IDV platform applies this exten-

sion point to allow an RP to communicate additional information to the IDV platform as

<saml2:Attribute>.

Entity Attribute Name Format and Name Description Level Comments

NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-

format:uri"

Name="urn:oasis:names:tc:SAML:attribute:assurance-

certification"

Minimum request-ed level of assur-ance (LoA) for authentication.

MUST MAY be overridden during run-time in the SAML <AuthnRe-

quest> by the RP.


format:unspecified"

Name="IdPPriorityList"

Give a higher prior-ity to an ordered set of IdPs to make them appear at the top of the HRD list.

MAY All valid IdPs not contained in that list will be appended unsorted to the list.


format:unspecified"

Name="IdPGroups"

Allow overriding and further reduc-ing the possible set

MAY If the IdPPriorityList is defined as well, only IdPs defined in


25/57


of IdPs per relying party. The IdP groups are defined in the domain poli-cy and can be configured per RP.

the configured groups will be con-sidered.


format:unspecified"

Name="originDisclosure"

The authenticating IdP/AA is disclosed to the RP.

MAY If not defined, the domain policy default applies.


format:unspecified"

Name="assertionDisclosure"

The original asser-tion issued by the IdP/AA is append-ed to the assertion.

MAY If not defined, the domain policy default applies.

In chapter "RP Participant Metadata", an example is given.

5.1.2 IdP/AA Metadata

Standard IdP/AA Metadata

Structure: <md:EntityDescriptor>/<md:IDPSSODescriptor>/...

Implicitly defined:

<md:IDPSSODescriptor>[WantAuthnRequestsSigned]: true

<md:IDPSSODescriptor>[protocolSupportEnumeration]: urn:oasis:names:tc:SAML:2.0:protocol

Explicitly defined: Element / Attribute Description Level Comments <md:EntityDescriptor>[entityID] Unique identifier for an IDV partici-

pant. MUST

<md:KeyDescriptor>[use="signing"]/

<ds:KeyInfo> Complete chain

(<ds:X509Certificate> ele-

ments) of the certificate used to sign SAML assertions and responses.

MUST The IDV broker will use this key material to vali-date the signa-ture of the SAML responses.

<md:NameIDFormat> The provided NameIDFormat in the

SAML assertion.

MUST

<md:SingleSignOnService> Describes the endpoint that supports the profiles of the Authentication Re-quest protocol defined in [SAML-PROF].

MUST

Metadata Extensions for Login and Discovery User Interface

The <mdui:UIInfo> container element, defined below, MUST appear within the

<md:Extensions> element of <md:IDPSSODescriptor>, see [SAML-META-UI].

Element / Attribute Description Level Comments

<mdui:UIInfo>/<mdui:DisplayName> Name dis-played during HRD.


<mdui:UIInfo>/<mdui:Description> Description displayed during HRD.


<mdui:UIInfo>/<mdui:Logo> Logo display-ed during HRD.

MUST MUST be provided either language inde-pendent or in GE, FR, IT and EN. In order to facilitate the usage of logos within a user interface, logos MUST:

use a transparent background where appropriate

use PNG

use minimal height of 40 pixels

use aspect ratio between 1:1 and 8:3


26/57


The logo MUST be provided as data URL scheme according to [RFC2397], e.g. data:image/png;base64,iVBORw0K...

<mdui:UIInfo>/

<mdui:InformationURL> A URL to localized in-formation about the entity operat-ing the IdP/AA.

MUST MUST be provided in GE, FR, IT and EN. May be used by the IDV broker to redi-rect the user to a support page.

<mdui:UIInfo>/

<mdui:PrivacyStatementURL> A URL to localized in-formation about the privacy prac-tices of the entity operat-ing the IdP/AA.


IDV-Specific IdP/AA Entity Attributes

The SAML V2.0 metadata specification [SAML-META] includes the <md:Extensions> ele-

ment in various places, including the <md:EntityDescriptor> element, for use in extending

the specification by carrying externally defined content. [SAML-META-ATTR] defines such an

extension element <mdattr:EntityAttributes> as a container for one or more

<saml2:Attribute> or <saml2:Assertion> elements. The IDV platform applies this exten-

sion point to allow an IdP/AA to communicate additional information to the IDV platform as

<saml2:Attribute>.

Entity Attribute Name Format and Name Description Level Comments


format:uri"

Name="urn:oasis:names:tc:SAML:attribute:assurance-

certification"

Maximum level of assurance (LoA) for authentication provided.

MUST Depending on the chosen authentica-tion method / used credential, the LoA can be lower.


format:unspecified"

Name="ConsentObtainedByIdP"

If the UC is ob-tained at the IdP/AA, it can be omitted at the IDV broker.

MAY Per default, user consent is asked by the IDV broker.

In chapter 8.2.1, "IdP/AA Participant Metadata", an example is given.

5.1.3 IDV Broker Metadata

The IDV broker issues two types of metadata:

An IDV domain's own IdP metadata. The format MUST follow [SAML-META]. In chapter

8.1.2, Broker (Domain IdP) Metadata an example is given.

An IDV domain's own RP metadata. The format MUST follow [SAML-META]. In chapter

8.2.2, Broker (Domain RP) Metadata an example is given.

Name Identifiers 5.2

This section defines the treatment of identifiers to be used in an IDV context:

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

urn:oasis:names:tc:SAML:2.0:nameid-format:transient

No other formats are supported. In case additional formats are required for a custom domain, this specification may be extended in a future version.


27/57


Attributes 5.3

5.3.1 Requesting Attributes

All attributes are always mandatory. There are no optional attributes.

5.3.2 Responding Attributes

Handling of Unknown Values

At domain registration time an IdP/AA declares which domain attributes it can serve. If an

IdP/AA does not know the attribute value of a registered attribute for a subject and if no ex-

ceptional value (such as "Unknown") is defined for that attribute, the IdP MUST omit the At-

tributeValue element and MUST provide an empty attribute element in the SAML re-

sponse.

SAML Protocol Message Content (General) 5.4

5.4.1 Guidelines for all Messages

Element / At-

tribute Description Availability eCH-174

[ID] The ID attribute in the root element MUST be present in each mes-sage. The value MUST be unique in the message. It is used as a reference in the signature of the message.

mandatory dito

[Destination] The destination attribute in the root element of each message MUST always be present. Its value MUST be the URL to which the message is sent.

mandatory dito

[IssueInstant] The IssueInstant attribute in the root element of each message MUST always be present. Its value indicates the time when the message was created. This MUST be encoded in UTC.

mandatory dito

[Version] The version attribute in the root element of each message MUST always be present. Its value MUST be 2.0.

mandatory dito

<Issuer> The value of the <saml2:Issuer> element MUST match the

EntityID attribute in the metadata of the entity that created the

message in each message.

mandatory dito

<ds:Signature> All messages MUST be digitally signed with a certificate accepted in

the domain (<ds:Signature> element included).

mandatory dito

[Consent] The consent MUST never be set in SAML requests. The consent is only set in SAML responses if the user did not give the user consent. In this case, the consent is set to urn:oasis:names:tc:SAML:2.0:consent:unavailable. The IDV broker forwards the consent if the IdP/AA is configured to obtain the user consent and sets the consent in its response (see chapter "User Consent").

optional (not spe-cified)

SAML Protocol Message Content (RP Participants) 5.5

5.5.1 SAML AuthnRequest (RP → IDV Broker)

Element /

Attribute Description Availabi-

lity eCH-174 Default RP

Meta

data

Do-

main

<saml2p:NameIDPo

licy>[Format]

<saml2p:NameIDPolicy>

specifies constraints on the name identifier to be used to represent the requested subject. Rules for attribute format:

Transient is less restric-tive than persistent

Persistent is less restric-

optional dito Defined by domain policy

: opti-onal

: manda-tory; values accord-ing to chapter "Name Identi-


28/57


tive than distributed Configuration rules:

The value configured in the RP metadata can only be equal or less restrictive than the value configured on domain level

The value specified in the AuthnRequest can only be equal or less restrictive than the value configured in the RP metadata

fiers"

<saml2p:NameIDPo

licy>[AllowCreat

e]

In case the name id is per-sistent, the attribute Al-

lowCreate MUST be set

and its value MUST be set to true.

optional dito Implicit

<saml2p:Requeste

dAuthnContext>/

<Authn-

ContextClassRef>

The authentication request MAY contain (at most) one <saml2p:RequestedAuth

nContext> element with a <saml2:AuthnContextCl

assRef> element, if an au-

thentication with a higher level is requested than de-fined in the metadata of the RP. The value of the <saml2:AuthnContextCl

assRef> element MUST be

one of the defined levels for a specific domain according to chapter 7.2, Level of As-surance (LoA) for Authenti-cation.

optional dito Defined by RP metadata

: mandato-ry

<saml2p:Requeste

dAuthnContext>/

<Authn-

ContextClass-

Ref>[Comparison]

The Attribute Comparison

MUST be set to minimum.

mandato-ry (if AuthnCo

ntextCl

assRef is

set)

The at-tribute Compar-

ison is

not speci-fied. The default is

exact.

<saml2p:Scoping>

/<saml2p:IDPList

>/

<saml2p:IDPEntry

>

A list with exact one entry may be specified to bypass the HRD screen ("emulated IdP first"). If more than one entry is specified, the re-quest is denied.

optional Not allo-wed

Empty as defined by OASIS in [SAML-CORE] → no indication

[ForceAuthn] The attribute does not affect the behavior of the IDV bro-ker. The attribute is just for-warded from the IDV broker to the IdP to signal the IdP whether it MUST authenti-cate the presenter directly rather than rely on a previ-ous security context or not. If the RP sends forceAuthn "false" alt-

hough the domain has set it to "true", the request is de-nied by the IDV broker.

optional <saml2p

:AuthnR

equest>

element MAY con-tain ForceAu

thn at-

tribute

Either set to 'true' on domain level or otherwise 'false' as defined by OASIS in [SAML-CORE]

Default can be set to "true" on domain level.

[AssertionConsu-

merServiceURL] Specifies by value the loca-tion to which the <Re-

sponse> message MUST

be returned to the requester.

mandato-ry

dito : mandato-ry


29/57


The AssertionConsum-

erServiceURL MUST

match an AssertionCon-

sumerService element of

the metadata of the entity that created the SAML <AuthnRequest>.

[ProtocolBin-

ding] The value of the Proto-colBinding attribute MUST be urn:oasis:names:tc:SA

ML:2.0:bindings:HTTP-

POST.

mandato-ry

dito (im-plicit)

[AttributeCon-

sumingServiceIn-

dex]

Indirectly identifies infor-mation associated with the requester describing the SAML attributes the re-quester desires or requires to be supplied by the identity provider in the <Response>

message.

optional different interpreta-tion (KM)

If no At-tributeConsum-

ingServiceIn-

dex is specified

and no At-tributeConsum-

ingService ele-

ment of the metadata of the RP that created the

SAML <AuthnRe-

quest> has the

attribute isDe-

fault set to true,

the request is con-sidered to be a plain authentication relaying request.

: opti-onal

Not supported despite being supported in [ECH-0174]:

<saml2:Subject>: element MUST not be set → otherwise invalid request (reasoning:

session refresh is not supported)

According to [ECH-0174], the authentication request MUST NOT have any further elements. In particular, the following elements and attributes MUST NOT be set (otherwise the request is invalid):

[Consent]: attribute MUST not be set

<saml2p:Extensions>: element MUST not be set

<saml2p:Scoping>[ProxyCount]: attribute MUST not be set

<saml2:Conditions>: element MUST not be set

[AssertionConsumerServiceIndex]: attribute MUST not be set

Furthermore, the authentication request SHOULD NOT have any further elements. In par-ticular, the following elements and attributes SHOULD NOT be set:

<saml2p:Scoping>[RequesterID]: attribute is ignored on the IDV broker; attribute is not

forwarded

[IsPassive]: attribute MUST not be set to "true" (default is "false") → otherwise invalid

request

[ProviderName]: attribute is ignored on the IDV broker → IDV broker uses metadata in-

fo

5.5.2 SAML Response (IDV Broker → RP)

Guidelines for Responses

Element / Attribute Description Availability eCH-

174

[InResponseTo] The ID of a SAML protocol message in response to

which an attesting entity can present the assertion. The values of the ID attribute in a request and the

mandatory dito


30/57


InResponseTo attribute in the corresponding response

MUST match.

<Status> A code representing the status of the corresponding request. The <saml2p:Response> element MUST contain a

<saml2p:Status> element. That element MUST con-

tain a <saml2p:StatusCode>.

If the authentication request was not successful, the

<saml2p:StatusCode> element MUST contain an

error message according to SAML 2.0 and there will be no assertion.

mandatory dito

<saml2:Assertion> or

<saml2:EncryptedAssertion> In case of a successful authentication request, the <saml2p:Response> element MUST contain a

<saml2:Assertion> element or optionally an encrypt-

ed assertion that follows the "Guidelines for Assertions".

mandatory

(for success-ful requests)

dito

Hints:

Element <Extensions> is not set

Guidelines for Assertions


174

[ID] The <saml2:Assertion> element MUST

contain an ID attribute.

mandatory dito

[IssueInstant] The <saml2:Assertion> element MUST

contain an IssueInstant attribute. The Is-

sueInstant value MUST be set to the time

where the assertion was issued (e.g. not taken over from the authenticating assertion from the IdP).

mandatory dito

<Issuer> The <saml2:Assertion> element MUST

contain a <saml2:Issuer> element. Its value

MUST match the EntityID attribute of the

metadata of the entity that issued the asser-tion.

mandatory dito

<ds:Signature> The <saml2:Assertion> element MUST be

digitally signed with a certificate that is accept-ed in a given domain (element <ds:Signature>).

mandatory dito

<Subject> The <saml2:Assertion> element MUST

contain a <saml2:Subject> element.

mandatory dito

<Subject>/NameID The <saml2:Subject> element MUST con-

tain a <saml2:NameID> element.

mandatory dito

<Subject>/

<SubjectConfirmation> The <saml2:Subject> element MUST con-

tain a <saml2:SubjectConfirmation>

element. The <saml2:SubjectConfirmation> ele-

ment MUST contain an attribute "Method". Its value MUST be urn:oasis:names:tc:SAML:2.0:cm:bea

rer.

The <saml2:SubjectConfirmation> ele-

ment MUST contain a <saml2:SubjectConfirmationData>

element. That element MUST have attributes

InResponseTo, Recipient and No-tOnOrAfter.

The values of the ID attribute in a request and

the InResponseTo attribute in the corre-

sponding assertion MUST match.

mandatory dito

<Subject>/

<SubjectConfirmation>

[Recipient]

The Recipient attribute contains the assertion consumer URL of the RP - the URL to which the assertion had been sent.

mandatory not explicit-ly spe-


31/57


cified

<Conditions> The <saml2:Assertion> element MUST

contain a <saml2:Conditions> element. It

MUST have a NotBefore und NotOnOrAft-

er attribute. Furthermore, it MUST contain a

<saml2:AudienceRestriction> element.

mandatory dito

<Conditions>/

<AudienceRestriction> The <saml2:AudienceRestriction> ele-

ment MUST contain a <saml:Audience>

element.

mandatory dito

<Conditions>/

<AudienceRestriction>/

<Audience>

The <saml2:Audience> element MUST

match the EntityID attribute of the metadata

of the entity for which the assertion has been created.

mandatory dito

<AuthnStatement> The <saml2:Assertion> element MUST

contain exactly one <saml2:AuthnStatement> element. This element MUST contain an AuthnInstant and a <saml2:AuthnContext>

element. The AuthnInstant value is taken

over from the original authenticating assertion.

mandatory dito

<AuthnStatement>/

<AuthnContext> The <saml2:AuthnContext> element MUST

contain a <saml2:AuthnContextClassRef> element.

The value of the

<saml2:AuthnContextClassRef> element

MUST be one of the defined levels for a specif-ic domain according to chapter "Authentication LoA".

mandatory dito

<AuthnContext>/

<AuthenticatingAuthori-

ty>

Zero or more unique identifiers of authentica-tion authorities that were involved in the au-thentication of the principal (not including the assertion issuer, who is presumed to have been involved without being explicitly named here).

optional (available only if "originDis-

closure" is activat-

ed by the RP)

not spe-cified

<AttributeStatement> The <Assertion> element MAY contain a

<saml2:AttributeStatement> element.

optional dito

<AttributeStatement>/

<Attribute> The <saml2:AttributeStatement> ele-

ment MUST contain one or more <saml2:Attribute> elements. Each ele-

ment can contain one or more

<saml2:AttributeValue> elements.

mandatory (if there

is a AttributeState-ment)

dito

<AttributeStatement>/

<Attribute>

[ext:OriginalIssuer]

Attribute elements MAY contain a custom at-

tribute ext:OriginalIssuer.

optional (available

only if "originDis-

closure" is activat-

ed by the RP)

not spe-cified

5.5.3 SAML Error Respo nse (IDV Broker → RP)

The IDV broker MUST return standard SAML error responses.

The response MUST contain a second-level <samlp:StatusCode> value.

Each error response contains an error id (random identifier based on UUID) in the status

message so that the issue can be traced back on demand (e.g. in a support case).

<saml2p:Status>

<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester">

<saml2p:StatusCode Value=

"urn:oasis:names:tc:SAML:2.0:status:AuthnFailed" />

</saml2p:StatusCode>

<saml2p:StatusMessage>

Validation of AuthnRequest failed. Error ID: [UUID]

</saml2p:StatusMessage>

</saml2p:Status>


32/57


If the user did not give the user consent, the attribute Consent is set to

urn:oasis:names:tc:SAML:2.0:consent:unavailable in the SAML response.

SAML Protocol Message Content (IdP Participants) 5.6

5.6.1 SAML AuthnRequest (IDV Broker → IdP/AA, Standard Case)

In case no IDV attributes need to be fetched or IDV attributes are fetched using attribute sets

(default method, see chapter 4.2.1, IdP/AA Communication with use of Attribute Sets (De-

fault)), the SAML <AuthnRequest> from the IDV broker to the IdP/AA looks similar to the

SAML <AuthnRequest> from the RP to the IDV broker.

Therefore, only some specific attributes/elements are explained at this point.

Element / Attribute Description Availability

[ForceAuthn] Set only if set by RP or enforced by domain policy. optional

Hints:

<saml2p:Scoping>[RequesterID]: attribute is not set (RP is not disclosed)

5.6.2 SAML AuthnRequest (IDV Broker → IdP/AA, Extended AuthnRequest)

In case IDV attributes need to be fetched using an extended SAML <AuthnRequest>, the

SAML <AuthnRequest> from the IDV broker needs to be extended by the required attributes:

<saml2p:Extensions>

<saml2:Attribute

NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"

Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"

/>

</saml2p:Extensions>

5.6.3 SAML AttributeQuery (IDV Broker → IdP/AA)

In case IDV attributes need to be fetched using a SAML <AttributeQuery> via side call, the

following message guidelines apply:

The SAML <AttributeQuery> element has to be the root element of the request.


174

<Subject> The <saml2p:AttributeQuery> element MUST contain a

<saml2:Subject> element. mandatory dito

<Subject>/<NameID> The Subject element MUST contain a NameID element that

MUST not have a Format attribute with value

urn:oasis:names:tc:SAML:2.0:nameid-format:transient.

mandatory dito

<Attribute> The <saml2p:AttributeQuery> element MUST contain one or

more <saml2:Attribute> elements. But the

<saml2p:AttributeQuery> MUST NOT contain two or more

<saml2:Attribute> elements having the same Name and

NameFormat attribute.

mandatory dito

<saml2p:Extensions> The <saml2p:AttributeQuery> element MUST contain a

<saml2p:Extensions> element with a <saml2:Assertion>

element that contains the authentication assertion the IDV broker

obtained in the previous SAML <AuthnRequest> to the same

IdP/AA.

mandatory more

generic

Additionally, the <saml2:Assertion> element that contains the authentication statement the

IDV broker obtained in the previous SAML <AuthnRequest> to the same IdP/AA MUST be

sent to the IdP/AA as well.


33/57


There are two options:

Sending the assertion in a WSS header to the IdP/AA

Adding the <saml2:Assertion> element to the <saml2p:Extensions> element of the

SAML <AttributeQuery>

Outlook

One of the two options will be specified in the given document and implemented in a later release

of the IDV platform.

5.6.4 SAML Response (IdP/AA → IDV Broker, Standard Case and Extended

AuthnRequest)

The IDV broker expects similar messages from the IdP/AA as it sends back to the RP ac-

cording to chapter "SAML Response (IDV Broker → RP) ".

In particular, the responses MUST follow the guidelines specified in the previous chapters:

Chapter 5.4.1, Guidelines for all Messages

Chapter Guidelines for Responses

Chapter Guidelines for Assertions, except the elements/attributes disclosing the origin

(AuthnContext/AuthenticatingAuthority, AttributeState-

ment/Attribute[ext:OriginalIssuer]) do not have to be provided

5.6.5 SAML Error Response (IdP/AA → IDV Broker)

The IdP/AA MUST return standard SAML error responses.

The response SHOULD contain a second-level <saml2p:StatusCode> value.

Each error response SHOULD contain an error id (e.g. a random identifier based on UUID) in

the status message so that the issue can be traced back on demand (e.g. in a support case),

similar as described for the IDV broker (see chapter , "SAML Error Response (IDV Broker →

RP)").

If the IdP/AA is configured to request user consent and the user did not give user consent,

the attribute Consent SHOULD be set to

urn:oasis:names:tc:SAML:2.0:consent:unavailable in the SAML response.

Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Security

34/57


Security 6

Baseline Requirements 6.1

In addition to the requirements defined in this section, further baseline requirements will be

defined per IDV domain. Those baseline requirements represent a common policy that ap-

plies to all participants of a particular domain. Furthermore, it will define the expectations and

requirements of the relying party community that will trust the federated authentication infor-

mation.

The baseline requirements for the e-government domains will be based on the following

standards:

eCH-170 V 2.0 standard

IT Basic Protection (IKT-Grundschutz Bund)

Topics that will be addressed in these documents include among others:

Identification and authentication

Local security practices (e.g. physical and personnel controls)

Technical security practices (e.g. computer and network security controls)

Operational practices (e.g. audit practices)

Legal provisions (e.g. liability)

Digital Signatures in a SAML 2.0 Context 6.2

6.2.1 Hash Functions

The following hash functions SHOULD be supported by IDV participants:

Algorithm Minimal Output Length

SHA-2 256

Integration Pilot Domains

Participants of the IDV Integration Pilot Domains MUST support SHA-256:

http://www.w3.org/2001/04/xmldsig-more#rsa-sha256

6.2.2 SAML 2.0 Assertions

SAML assertions MUST be signed by the IdP/AA (SAML responses to the IDV broker) and

by the IDV broker (SAML responses to RP).

IDV domains may put additional requirements to IdP/AA as part of their domain baseline re-

quirements based on their domain policy, e.g.:

SAML assertions MUST be signed by the IdP/AA using a regulated signature to prevent

unauthorized modification

The regulated certificate used to sign the assertion SHOULD contain a PolicyInfor-

mation with the following object identifier for CertPolicyId: <TBD for a specific do-main>

The IdP/AA SHOULD create the regulated signature on a secure signature creation de-

vice

The IdP/AA MUST include the complete chain of the signature certificate into its metadata for certificate path validation according to [RFC5280]. Furthermore, the IdP/AA SHOULD include the signing certificate in the assertion. The IDV broker MUST include the complete chain of the signature certificate into its metada-ta for certificate path validation according to [RFC5280] and SHOULD include the complete

http://www.w3.org/2001/04/xmldsig-more#rsa-sha256


35/57


chain of the signature certificate into the signed SAML assertion for certificate path validation according to [RFC5280] for RP without metadata support.

Assertion Conditions 6.3

One-time usage: Each assertion may only be used once. IDV broker sets "One-Time Use".

As a consequence of this, the RP MUST check the recipient attribute in the SAML response

and make sure that the InResponseTo attribute matches the request of the Service Provider.

Quality of time: SAML assertions contain embedded timestamps to reduce the window of

opportunity for attacks. Therefore, the IDV broker and the IDV IdPs MUST ensure time syn-

chronization. The maximum clock drift from the reference time (together with whose inaccu-

racy) MUST NOT exceed 1 minute or 10% of the minimum period of validity of the IDV asser-

tions for a domain. RPs SHOULD ensure time synchronization as well. The use of NTP

(Network Time Protocol) is recommended.

Short lifetime: Assertions MUST have a limited lifetime. The exact lifetime is defined in the

domain-specific baseline requirements. The assertion of the IDV broker MUST not have a

longer lifetime than the assertion of the issuing IdP/AA.

Pilot Domains

In case of the IDV G2G and G2C pilot domains, the following conventions apply:

NotBefore: Issue instant of IDV broker.

NotOnOrAfter: A maximum of 5 minutes into the future.

The RP MUST check the validity of assertions obtained from the IdP/AA and refuse them if

expired.

Data Transfer Encryption 6.4

All data transfers between participants of IDV have to be protected by TLS.

The IDV broker and the IdP/AA MUST support the following cipher suite for the TLS protocol:

DHE-RSA-AES256-SHA

RP SHOULD support this algorithm.


Participants of the IDV Integration Pilot Domains MUST support DHE-RSA-AES256-SHA.

TLS web certificates can be issued by public CAs or by company internal CAs. If certificates

are issued by a public CA, the CA SHOULD be a member of the CAB forum (see [CAB-

FORUM]) and SHOULD be certified by Webtrust (see [WEBTRUST]).

Domain-specific baseline requirements will be more specific. For instance, the baseline re-

quirements could specify that TLS certificates that are issued by a CSP accepted in a certain

domain MUST be a member of the CAB forum and MUST be certified by Webtrust.

SAML 2.0 Requests and Responses 6.5

SAML 2.0 responses MUST be signed using <ds:signature>.

SAML 2.0 requests MUST be signed using <ds:signature>.

Validity of requests and responses: SAML requests and responses SHOULD have a lim-

ited lifetime. The exact lifetime is defined in the domain-specific baseline requirements.


36/57


Pilot Domains

In case of the IDV G2G and G2C pilot domains, the following convention applies: The IDV broker

checks the IssueInstant of the SAML messages and accepts only messages that are not old-

er than 10 minutes.

Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Attribute Definitions

37/57


Attribute Definitions 7

IDV Name Identifiers 7.1

The name identifier can help to protect the user’s privacy. The IDV platform supports the fol-

lowing name identifiers:

IDV name

identifier

type

Description Name id format returned by IDV broker Comment

Distributed The value of the

nameId issued by the

IdP/AA is optionally

prefixed by the IDV

broker and passed

through

urn:oasis:names:tc:SAML:1.1:nameid-

format:unspecified

May be used in custom do-

mains where all participants

share the same name identi-

fiers. Therefore, the interpre-

tation of the attribute name

is specified on domain level.

Persistent The value of the

nameId is recomput-

ed with a hash


format:persistent

All RP of a domain form an

"affiliation of service provid-

ers" and therefore get the

same persistent name ID

value for an authenticated

identity.

RP persis-

tent The value of the

nameId is recomput-

ed with a hash


format:persistent

Each RP gets a different

persistent name ID. Pre-

ferred over "Persistent" for

privacy sensitive domains.

Transient The value of the

nameId is a random

value


format:transient

From a privacy point of view, the transient name id format exposes the least information and

the distributed name id format exposes the most information.

Domains may have restrictions on the supported name identifier types.

Level of Assurance (LoA) for Authentication 7.2

Levels of assurance are an important part of the trust of the IDV platform. All IDV participants

within a certain domain use their own policy to describe the level of assurance associated

with an instance authenticating a particular user.

This policy allows an IdP/AA to indicate to a RP how much trust is behind the authentication

of a user. RPs, based on their own needs and assessment of risks, determine what level of

assurance they require for an authentication in order to allow the user to access their ser-

vices.

The framework used within the IDV platform is based on the [ECH-0170] and [ECH-0170V2]

(draft version) standards. The core domains will be based on those standards.

In addition to the eCH standard, the IDV platform supports other LoA models for non-core

domains:

All participants (IdPs/AAs and RPs) in a domain agree on a single authentication level

within their domain. All participants agree on a single authentication level which covers

the needs of the domain (i.e. all IdPs/AAs offer the needed level for the domain). During

runtime, no LoA is used because being a participant of the domain implies that the de-

fined trust level is guaranteed implicitly.

All participants (IdPs/AAs and RPs) in a domain agree on their own LoA model. The IDV

platform supports 4 custom LoA levels. The definition is left to the domain. The criteria

Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Attribute Definitions

38/57


and rules for the assignment of the several levels have to be defined in the domain poli-

cies (by the domain management) [TS-504].


The integration pilot domains use a model based on [ECH-0170].

Therefore, the LoA value MUST be one of the following quality levels:

urn:stiam.gov.ch/authenticationassurance/level1




IDV Attributes 7.3

IDV attributes will be defined per domain depending on the domain policy.

There will also be a set of "Common IDV attributes". Domain specific attribute sets may con-

tain such common IDV attributes.

Appendix A provides a draft for the "Common IDV attributes" and for the G2C domain (Inte-

gration Pilot) as well as the G2G domain (Integration Pilot) for illustrative purpose.

http://stiam.gov.ch/authenticationassurance/level1




Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Message Format Examples

39/57


Message Format Examples 8

RP Participant Related Message Format Examples 8.1

8.1.1 RP Participant Metadata

<EntityDescriptor entityID="https://www.example.ch/rp">

<SPSSODescriptor AuthnRequestsSigned="true"

WantAssertionsSigned="true"

protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

<Extensions>

<mdui:UIInfo>

<mdui:DisplayName

xml:lang="de">Online Schalter - Gemeinde Example

</mdui:DisplayName>

<mdui:DisplayName xml:lang="fr">

Guichet en ligne - Municipalité Example

</mdui:DisplayName>

…

<mdui:Description xml:lang="de">

Dies ist der Dienst 'Online Schalter' der Gemeinde.

</mdui:Description>

<mdui:Description xml:lang="fr">

Ceci est le service 'Guichet en ligne' de la municipalité.

</mdui:Description>

…

<mdui:Logo height="40" width="45" xml:lang="de">

data:image/png;base64,iVBORw0K...

</mdui:Logo>

<mdui:Logo height="40" width="45" xml:lang="fr">


</mdui:Logo>

…

<mdui:InformationURL xml:lang="de">

http://www.example.ch/info_de.html

</mdui:InformationURL>

<mdui:InformationURL xml:lang="fr">

http://www.example.ch/info_fr.html


…

<mdui:PrivacyStatementURL xml:lang="de">

http://www.example.ch/dl/privacy_de.html

</mdui:PrivacyStatementURL>

<mdui:PrivacyStatementURL xml:lang="fr">

http://www.example.ch/dl/privacy_fr.html


…

</mdui:UIInfo>

<attr:EntityAttributes>

<saml:Attribute


Name="urn:oasis:names:tc:SAML:attribute:assurance-certification">

<saml:AttributeValue>


</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute

NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"

Name="IdPPriorityList">


https://www.example123.ch/IDVReferenceIdP2/idp





</saml:Attribute>

<saml:Attribute








40/57



Name="IdPGroups">

<saml:AttributeValue>idpGroupReferenceIdps</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute


Name="originDisclosure">

<saml:AttributeValue>true</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute


Name="assertionDisclosure">


</saml:Attribute>

</attr:EntityAttributes>

</Extensions>

<KeyDescriptor use="signing">

<ds:KeyInfo>

<ds:X509Data>



<ds:X509Certificate>MIICXTCCA..</ds:X509Certificate>



<ds:X509Certificate>MIICPzCCA...</ds:X509Certificate>



<ds:X509Certificate>MIICSTCCA...</ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>

</KeyDescriptor>

<KeyDescriptor use="encryption">

<ds:KeyInfo>

<ds:X509Data>

<ds:X509Certificate>MIIEMTCCA...</ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>

</KeyDescriptor>

<NameIDFormat>

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>

<AssertionConsumerService

Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

Location="https://www.example.ch/o_blue_zone/idv_protected/"

index="1" />



Location="https://www.example.ch/o_not_existent/idv_protected/"

index="2" />



Location="https://www.example.ch/o_constructpermit/idv_protected/"

index="3" />



Location="https://www.example.ch/o_register/idv_protected/"

index="4" />



Location="https://www.example.ch/o_taxes/idv_protected/"

index="5" />

<AttributeConsumingService index="1">

<ServiceName xml:lang="en">Blue Zone Parking Card attributes</ServiceName>

<ServiceDescription xml:lang="en">

Attributes used for Blue Zone Parking Card usecase.</ServiceDescription>

<RequestedAttribute FriendlyName="surname"



isRequired="true" />

<RequestedAttribute FriendlyName="given name"


41/57


Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"



</AttributeConsumingService>


<ServiceName xml:lang="en">Construction Permit attributes</ServiceName>


Attributes used for Construction Permit usecase.

</ServiceDescription>


Name=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname







<RequestedAttribute FriendlyName="nationality"

Name="http://www.ech.ch/xmlns/eCH-0113/1/nationality"




<AttributeConsumingService index="4" isDefault="true">

<ServiceName xml:lang="en">Identity Relay attributes</ServiceName>


Attributes used forIdentity Relay usecase.</ServiceDescription>









<RequestedAttribute FriendlyName="date of birth"

Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth"



<RequestedAttribute FriendlyName="gender"

Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender" Name

Format="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"


<RequestedAttribute FriendlyName="nationality"






<ServiceName xml:lang="en">Taxes and Fees attributes</ServiceName>


Attributes used for Taxes and Fees usecase.</ServiceDescription>

<RequestedAttribute FriendlyName="socialsecuritynumber"

Name="http://schemas.xmlsoap.org/

ws/2005/05/identity/claims/socialsecuritynumber"




</SPSSODescriptor>

</EntityDescriptor>

8.1.2 Broker (Domain IdP) Metadata

<md:EntitiesDescriptor

ID="IDVBrokerIDVDemoG2CDomain"

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

http://schemas.xmlsoap.org/%09%09%09%09%09ws/2005/05/identity/claims/socialsecuritynumber

http://schemas.xmlsoap.org/%09%09%09%09%09ws/2005/05/identity/claims/socialsecuritynumber


42/57


Name="IDVBrokerIDVDemoG2CDomain">

<ds:Signature>

<ds:SignedInfo>

<ds:CanonicalizationMethod

Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<ds:SignatureMethod

Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>

<ds:Reference URI="#IDVBrokerIDVDemoG2CDomain">

<ds:Transforms>

<ds:Transform

Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

</ds:Transforms>

<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>

<ds:DigestValue>...</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue>...</ds:SignatureValue>

</ds:Signature>

<md:EntityDescriptor entityID="https://idv-broker.ch/IDVDemoG2C/idp">

<md:IDPSSODescriptor WantAuthnRequestsSigned="true"


<md:Extensions>

<mdui:UIInfo>

<mdui:Logo height="40" width="50">

data:image/png;base64,iVBORw...</mdui:Logo>

<mdui:Description xml:lang="de">IDV Demo Domain G2C desc DE

</mdui:Description>

<mdui:Description xml:lang="en">IDV Demo Domain G2C desc EN

</mdui:Description>

…

<mdui:DisplayName xml:lang="de">IDV Demo Domain G2C

DE</mdui:DisplayName>

<mdui:DisplayName xml:lang="en">IDV Demo Domain G2C

EN</mdui:DisplayName>

…


/static/assets/html/privacy_de.html</mdui:InformationURL>

<mdui:InformationURL

xml:lang="en">/static/assets/html/privacy_en.html</mdui:InformationURL>

<mdui:InformationURL

xml:lang="fr">/static/assets/html/privacy_fr.html</mdui:InformationURL>

…


/static/assets/html/privacy_de.html</mdui:PrivacyStatementURL>

<mdui:PrivacyStatementURL xml:lang="en">

/static/assets/html/privacy_en.html</mdui:PrivacyStatementURL>

…

</md:Extensions>

<md:KeyDescriptor use="signing">

<ds:KeyInfo>

<ds:X509Data>








</ds:X509Data>

</ds:KeyInfo>

</md:KeyDescriptor>

<md:NameIDFormat>

urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>

<md:NameIDFormat>

urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>


43/57


<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-

POST"

Location="https://idv-broker.ch/IDVDemoG2C/SAML2/SSO"/>

<saml2:Attribute

FriendlyName="surname"


NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>

<saml2:Attribute

FriendlyName="name"



<saml2:Attribute

FriendlyName="nationality"



<saml2:Attribute

FriendlyName="gender"

Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender"


<saml2:Attribute

FriendlyName="date of birth"



<saml2:Attribute

FriendlyName="AVS/AHV number"

Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/socialsecnumber"


</md:IDPSSODescriptor>

</md:EntityDescriptor>

</md:EntitiesDescriptor>

8.1.3 SAML AuthnRequest (RP → Broker)

Example of a minimal request

<saml2p:AuthnRequest

ID="AuthnRequest_086233FC206E815753B59B6A346EC7469DDF51EE"

Destination="https://broker.gov.ch/IDVtestG2C/SAML2/SSO"

IssueInstant="2017-08-08T12:10:08.234Z"

Version="2.0"

ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

AssertionConsumerServiceURL="https://sp.example.ch/SAML2.0/SP/AssertionConsumer">

<saml2:Issuer>https://sp.example.ch/IDVReferenceRpG2C/rp1</saml2:Issuer>

<ds:Signature>...</ds:Signature

</saml2p:AuthnRequest>

Example of an enriched request

<saml2p:AuthnRequest ID="AuthnRequest_3C17F12CA86C0AFF265AAD45F3C298C79F35CEEE" Destination="https://broker.gov.ch/IDVtestG2C/SAML2/SSO" IssueInstant="2017-08-08T12:15:40.511Z" Version="2.0"


AssertionConsumerServiceURL="https://sp.example.ch/SAML2.0/SP/AssertionConsumer" AttributeConsumingServiceIndex="1" ForceAuthn="false">

<saml2:Issuer>https://sp-ref.example.ch/IDVReferenceRpG2C/rp1</saml2:Issuer>


https://broker.gov.ch/IDVtestG2C/SAML2/SSO%22

https://sp.example.ch/SAML2.0/SP/AssertionConsumer%22

https://sp-ref.example.ch/IDVReferenceRpG2C/rp1%3c/saml2:Issuer


44/57


<saml2p:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>

<saml2p:RequestedAuthnContext Comparison="minimum"> <saml2:AuthnContextClassRef>


</saml2:AuthnContextClassRef> </saml2p:RequestedAuthnContext> <saml2p:Scoping> <saml2p:IDPList> <saml2p:IDPEntry ProviderID="https://idp.example.ch/IDVReferenceIdP2/idp"/> </saml2p:IDPList> </saml2p:Scoping> </saml2p:AuthnRequest>

8.1.4 SAML Response (Broker → RP)

Default Example

(assertion only)

<saml2:Assertion

ID="_f03add6a-81ff-4c39-97ef-35ae545e15d4"

IssueInstant="2017-08-08T12:18:22.526Z"

Version="2.0">

<saml2:Issuer>https://idp-test.example.ch/IDVtestG2C/idp</saml2:Issuer>


<saml2:Subject>

<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">

2SHajhROHiOCOri4JzkTIF2+znAKdby5RLuUVDKKLwg+1SQKoG+emGtY/fqvWkExcNhpqMFJnY5vKOxUf2GmK

Q==

</saml2:NameID>

<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">

<saml2:SubjectConfirmationData

InResponseTo="AuthnRequest_66DA325FE1F43715A85AA896FED884D910BE2091"

NotOnOrAfter="2017-09-07T12:18:19.418Z"

Recipient="https:/sp.example.ch/SAML2.0/SP/AssertionConsumer">

</saml2:SubjectConfirmation>

</saml2:Subject>

<saml2:Conditions

NotBefore="2017-08-08T12:18:19.417Z"

NotOnOrAfter="2017-09-07T12:18:19.418Z">

<saml2:AudienceRestriction>

<saml2:Audience>

https://sp-ref.example.ch/IDVReferenceRpG2C/rp1

</saml2:Audience>

</saml2:AudienceRestriction>

<saml2:OneTimeUse/>

</saml2:Conditions>

<saml2:AuthnStatement AuthnInstant="2017-08-08T12:18:19.417Z">

<saml2:AuthnContext>

<saml2:AuthnContextClassRef>


</saml2:AuthnContextClassRef>

</saml2:AuthnContext>

</saml2:AuthnStatement>

<saml2:AttributeStatement>

<saml2:Attribute

Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">

<saml2:AttributeValue xsi:type="xsd:string">Muster</saml2:AttributeValue>

</saml2:Attribute>

<saml2:Attribute

Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">

<saml2:AttributeValue xsi:type="xsd:string">Peter</saml2:AttributeValue>

</saml2:Attribute>

</saml2:AttributeStatement>

https://idp.example.ch/IDVReferenceIdP2/idp%22

https://sp-ref.example.ch/IDVReferenceRpG2C/rp1


45/57


</saml2:Assertion>

Enriched example with originDisclosure and assertionDisclosure

<saml2p:Response

ID="_f57d1c67-d567-4b45-b0b8-067a8f97c471"

Destination="https:/sp.example.ch/SAML2.0/SP/AssertionConsumer"

IssueInstant="2017-08-15T15:31:55.903Z"

Version="2.0"

InResponseTo="AuthnRequest_699D74752BF265443EC865E0E5EFB6AB71FF204">

<saml2:Issuer>

https://idv-broker.ch/IDVtestG2C/idp

</saml2:Issuer>

<ds:Signature>...</ds:Signature>

<saml2p:Status>

<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>

</saml2p:Status>

<saml2:Assertion

ID="_5701b025-7f4e-4b80-9191-467e3b8fbf99"

IssueInstant="2017-08-15T15:31:55.906Z"

Version="2.0">

<saml2:Issuer>https://idv-broker.ch/IDVtestG2C/idp</saml2:Issuer>


<saml2:Subject>

<saml2:NameID

Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">

UCUwUHrUpewUMTWpHKXXmexrPMoZFdcfft-

HoFqM66A+bEzL9BdEAeJewAO77OCqJaq9mOjrUdJcmCw1oFS5mQ==

</saml2:NameID>



InResponseTo="AuthnRequest_699D74752BF265443EC865E0E5EFB6AB71FF204"

NotOnOrAfter="2017-09-14T15:31:55.682Z"

Recipient="https:/sp.example.ch/SAML2.0/SP/AssertionConsumer"/>


</saml2:Subject>

<saml2:Conditions

NotBefore="2017-08-15T15:31:55.682Z"

NotOnOrAfter="2017-09-14T15:31:55.682Z">


<saml2:Audience>

https://sp.example.ch/IDVReferenceRpG2C/rp1

</saml2:Audience>


<saml2:OneTimeUse/>

</saml2:Conditions>

<saml2:Advice>

<saml2:Assertion

ID="_5701b025-7f4e-4b80-9191-467e3b8fbf99"

IssueInstant="2017-08-15T15:31:55.869Z"

Version="2.0">

<saml2:Issuer>

https://idp.example.ch/IDVReferenceIdP1/idp</saml2:Issuer>


<saml2:Subject>

<saml2:NameID

Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">

persistent-id

</saml2:NameID>



https://sp.example.ch/IDVReferenceRpG2C/rp1


46/57


<saml2:SubjectConfirmation

Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">


InResponseTo="_7935dfe6-acf3-4d0c-a229-6bab237f05ae"

NotOnOrAfter="2017-09-14T15:31:55.682Z"

Recipient="https://idv-broker.ch/IDVtestG2C/SAML2/POST"/>


</saml2:Subject>

<saml2:Conditions

NotBefore="2017-08-15T15:31:55.682Z"

NotOnOrAfter="2017-09-14T15:31:55.682Z">


<saml2:Audience>

https://idv-broker.ch/IDVtestG2C/sp</saml2:Audience>


</saml2:Conditions>




urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified





<saml2:Attribute


<saml2:AttributeValue xsi:type="xsd:string">

Muster

</saml2:AttributeValue>

</saml2:Attribute>

<saml2:Attribute



Peter


</saml2:Attribute>


</saml2:Assertion>

</saml2:Advice>






<saml2:AuthenticatingAuthority>

https://idp.example.ch/IDVReferenceIdP1/idp

</saml2:AuthenticatingAuthority>




<saml2:Attribute


ext:OriginalIssuer="https://idp.example.ch/IDVReferenceIdP1/idp">


Muster


</saml2:Attribute>

<saml2:Attribute


ext:OriginalIssuer="https://idp.example.ch/IDVReferenceIdP1/idp">


Peter


</saml2:Attribute>


</saml2:Assertion>

</saml2p:Response>

https://idp-ref.example.ch/IDVReferenceIdP1/idp


47/57


8.1.5 SAML Encrypted Response (Broker → RP)

<saml2p:Response

ID="_d46ad451-6a2c-457a-8efb-5adf4efcd107"

Destination="https://seco-idvch-nb.zh.adnovum.ch/SAML2.0/SP/AssertionConsumer"

IssueInstant="2017-08-09T13:26:44.219Z"

InResponseTo="AuthnRequest_B1AB4955530DC453BBADC8F71317E660615F1788"

Version="2.0">

<saml2:Issuer>https://seco-idvch-nb.zh.adnovum.ch/IDVtestG2C/idp</saml2:Issuer>


<saml2p:Status>

<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>

</saml2p:Status>

<saml2:EncryptedAssertion>

<xenc:EncryptedData

Id="_5c16e9809c4f788f939fc636cbe8fcae"

Type="http://www.w3.org/2001/04/xmlenc#Element">

<xenc:EncryptionMethod

Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>

<ds:KeyInfo>

<ds:RetrievalMethod

Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"

URI="#_6871221a8a64462930a05aba742ab52a"/>

</ds:KeyInfo>

<xenc:CipherData>

<xenc:CipherValue>...</xenc:CipherValue>

</xenc:CipherData>

</xenc:EncryptedData>

<xenc:EncryptedKey Id="_6871221a8a64462930a05aba742ab52a">

<xenc:EncryptionMethod

Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">

<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

</xenc:EncryptionMethod>

<ds:KeyInfo>

<ds:X509Data>

<ds:X509Certificate>...</ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>

<xenc:CipherData>

<xenc:CipherValue>...</xenc:CipherValue>

</xenc:CipherData>

<xenc:ReferenceList>

<xenc:DataReference URI="#_5c16e9809c4f788f939fc636cbe8fcae"/>

</xenc:ReferenceList>

</xenc:EncryptedKey>

</saml2:EncryptedAssertion>

</saml2p:Response>

IdP Participant Related Message Format Examples 8.2

8.2.1 IdP Participant Metadata

<EntityDescriptor entityID="https://www.example.ch/idp">

<IDPSSODescriptor

WantAuthnRequestsSigned="true"


<Extensions>

<mdui:UIInfo>

<mdui:DisplayName xml:lang="de">

Niederbipp Online-Schalter

</mdui:DisplayName>

https://seco-idvch-nb.zh.adnovum.ch/IDVtestG2C/idp%3c/saml2:Issuer


48/57


<mdui:DisplayName xml:lang="fr">

Niederbipp Guichet En Ligne

</mdui:DisplayName>

...

<mdui:Description xml:lang="de">

Dies ist der Login-Service der Gemeinde Niederbipp.

</mdui:Description>

<mdui:Description xml:lang="fr">

Ceci est le service-login de la commune Niederbipp.

</mdui:Description>

...

<mdui:Logo height="40" width="45" xml:lang="de">


</mdui:Logo>

<mdui:Logo height="40" width="45" xml:lang="fr">


</mdui:Logo>

...




<mdui:InformationURL xml:lang="fr">



...




<mdui:PrivacyStatementURL xml:lang="fr">



...

</mdui:UIInfo>

<attr:EntityAttributes>

<saml:Attribute


Name="urn:oasis:names:tc:SAML:attribute:assurance-certification"




</saml:Attribute>

<saml:Attribute


Name="ConsentObtainedByIdP">


</saml:Attribute>

</attr:EntityAttributes>

</Extensions>

<KeyDescriptor use="signing">

<ds:KeyInfo>

<ds:X509Data>








</ds:X509Data>

</ds:KeyInfo>

</KeyDescriptor>

<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>

<SingleSignOnService


Location="https://www.example.ch/idp/auth/saml2/sso/" />

<saml:Attribute



FriendlyName="surname" />

<saml:Attribute







49/57



FriendlyName="givenname" />

</IDPSSODescriptor>

</EntityDescriptor>

8.2.2 Broker (Domain RP) Metadata

<md:EntitiesDescriptor

ID="IDVBrokerIDVtestG2CDomain"

Name="IDVBrokerIDVtestG2CDomain">

<ds:Signature>

<ds:SignedInfo>

<ds:CanonicalizationMethod


<ds:SignatureMethod

Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>

<ds:Reference URI="#IDVBrokerIDVtestG2CDomain">

<ds:Transforms>

<ds:Transform

Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

<ds:Transform


</ds:Transforms>

<ds:DigestMethod

Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>

<ds:DigestValue>...</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue>...</ds:SignatureValue>

</ds:Signature>

<md:EntityDescriptor entityID="https://idv-broker.ch/IDVtestG2C/sp">

<md:SPSSODescriptor

AuthnRequestsSigned="true"

WantAssertionsSigned="true"


<md:Extensions>

<mdui:UIInfo>

<mdui:Logo height="40" width="50">

data:image/png;base64,iVBOR...

</mdui:Logo>

<mdui:Description xml:lang="de">IDV TestG2C desc DE</mdui:Description>

<mdui:Description xml:lang="en">IDV TestG2C desc EN</mdui:Description>

...

<mdui:DisplayName xml:lang="de">IDV TestG2C DE</mdui:DisplayName>

<mdui:DisplayName xml:lang="en">IDV TestG2C EN</mdui:DisplayName>

...


/static/assets/html/privacy_de.html


<mdui:InformationURL xml:lang="en">

/static/assets/html/privacy_en.html


...


/static/assets/html/privacy_de.html


<mdui:PrivacyStatementURL xml:lang="it">

/static/assets/html/privacy_it.html


...

</mdui:UIInfo>

</md:Extensions>


50/57


<md:KeyDescriptor use="signing">

<ds:KeyInfo>

<ds:X509Data>








</ds:X509Data>

</ds:KeyInfo>

</md:KeyDescriptor>

<md:KeyDescriptor use="encryption">

<ds:KeyInfo>

<ds:X509Data>


</ds:X509Data>

</ds:KeyInfo>

</md:KeyDescriptor>

<md:NameIDFormat>

urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

</md:NameIDFormat>

<md:AssertionConsumerService


Location="https://idv-broker.ch/IDVtestG2C/SAML2/POST"

index="1" isDefault="true"/>

<md:AttributeConsumingService

index="1"

isDefault="false">

<md:ServiceName xml:lang="en">Default Set EN</md:ServiceName>

<md:ServiceName xml:lang="de">Default Set DE</md:ServiceName>

...

<md:ServiceDescription xml:lang="en">

Minimal attribute set EN.

</md:ServiceDescription>

<md:ServiceDescription xml:lang="de">

Minimal attribute set DE.


...

<md:RequestedAttribute




isRequired="true"/>


FriendlyName="givenname"



isRequired="true"/>

</md:AttributeConsumingService>

<md:AttributeConsumingService

index="2"

isDefault="false">

<md:ServiceName xml:lang="en">Extended Set EN</md:ServiceName>

<md:ServiceName xml:lang="de">Extended Set DE</md:ServiceName>

...


Extended attribute set EN.



Extended attribute set DE.


...





isRequired="true"/>




51/57




isRequired="true"/>





isRequired="true"/>


<md:AttributeConsumingService index="3" isDefault="false">

<md:ServiceName xml:lang="en">Full Set EN</md:ServiceName>

<md:ServiceName xml:lang="de">Full Set DE</md:ServiceName>

...


Full attribute set EN.



Full attribute set DE.


...





isRequired="true"/>





isRequired="true"/>





isRequired="true"/>

<md:RequestedAttribute FriendlyName="gender"

Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender"


isRequired="true"/>


FriendlyName="date of birth"



isRequired="true"/>


<md:AttributeConsumingService index="4" isDefault="false">

<md:ServiceName xml:lang="en">Protected Set EN</md:ServiceName>

<md:ServiceName xml:lang="de">Protected Set DE</md:ServiceName>

...


Protected attribute set EN.



Protected attribute set DE.


...





isRequired="true"/>





isRequired="true"/>


FriendlyName="AVS/AHV number"

Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/socialsecuritynumber"



52/57


isRequired="true"/>


</md:SPSSODescriptor>

</md:EntityDescriptor>

</md:EntitiesDescriptor>

8.2.3 SAML AuthnRequest (Broker → IdP/AA)

AuthnRequest with AttributeSet

<saml2p:AuthnRequest

ID="_947032a6-14ff-4376-95b0-2ac3b0001de0"

Destination="https://idp.example.ch/IDVReferenceIdP1/SAML2/SSO"

IssueInstant="2017-08-08T12:34:46.919Z"

Version="2.0"

AssertionConsumerServiceURL="https://idv-broker.ch/IDVtestG2C/SAML2/POST"


AttributeConsumingServiceIndex="1">

<saml2:Issuer>https://idv-broker.ch/IDVtestG2C/sp</saml2:Issuer>


<saml2p:RequestedAuthnContext Comparison="minimum">




</saml2p:RequestedAuthnContext>

</saml2p:AuthnRequest>

Extended AuthnRequest

Integration Pilot

During the integration pilot, the extended AuthnRequest is not yet supported.

8.2.4 SAML AttributeQuery (Broker → IdP/AA)

Integration Pilot

During the integration pilot, attribute query is not yet supported.

8.2.5 SAML Response on AuthnRequest (IdP → Broker)

<saml2p:Response

ID="_49723af6-d413-42f0-8a89-40a82706e274"

Destination=https://idv-broker.ch/IDVtestG2C/SAML2/POST

IssueInstant="2017-08-08T12:34:48.702Z"

InResponseTo="_947032a6-14ff-4376-95b0-2ac3b0001de0"

Version="2.0">

<saml2:Issuer>https://idp.example.ch/IDVReferenceIdP1/idp</saml2:Issuer>


<saml2p:Status>

<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />

</saml2p:Status>

https://localhost/IDVtestG2C/SAML2/POST


53/57


<saml2:Assertion

ID="_cf74c427-5aec-45c0-b1ab-010eb70ad9fb"

IssueInstant="2017-08-08T12:34:48.703Z"

Version="2.0">

<saml2:Issuer>https://idp.example.ch/IDVReferenceIdP1/idp</saml2:Issuer>


<saml2:Subject>

<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">

persistent-id

</saml2:NameID>



InResponseTo="_947032a6-14ff-4376-95b0-2ac3b0001de0"

NotOnOrAfter="2017-09-07T12:34:48.702Z"

Recipient="https://idv-broker.ch/IDVtestG2C/SAML2/POST" />


</saml2:Subject>

<saml2:Conditions

NotBefore="2017-08-08T12:34:48.702Z"

NotOnOrAfter="2017-09-07T12:34:48.702Z">


<saml2:Audience>https://idv-broker.ch/IDVtestG2C/sp</saml2:Audience>


</saml2:Conditions>









<saml2:Attribute



Muster


</saml2:Attribute>

<saml2:Attribute



Peter


</saml2:Attribute>


</saml2:Assertion>

</saml2p:Response>

8.2.6 SAML Response on AttributeQuery (Broker → IdP/AA)

Integration Pilot

During the integration pilot, attribute query is not yet supported.

Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Extensions and Special Cases

54/57


Extensions and Special Cases 9

Integration of Non-IDV-Conformant IdPs 9.1

In addition to IDV conformant IdPs that are compliant to all aspects defined in this specifica-

tion and to all requirements defined in the domain policy, there may be non-IDV-conformant

IdPs in a domain that may be valuable enough to be integrated.

Such non-IDV-conformant IdPs need to support at least SAML 2.0, must be registered in the

IDV admin application and might need to have configured special transformations (e.g. at-

tribute transformations). This would be the case to support the existing SuisseID in the IDV

pilot domains.

Furthermore, additional adaptions on protocol level may have to be implemented in the IDV

broker.


55/57


IDV Attributes Annex A:

Annex A 1: Overview

IDV attributes will be defined per domain depending on the domain policy.

In this appendix a draft for Common IDV attributes (attributes that are generally available in

the IDV platform) is given for illustrative purpose.

Integration Pilot

Chapters G2C Domain (Integration Pilot) and G2G Domain (Integration Pilot) describe the attrib-

utes that will be available on the integration pilot for illustrative purpose. Those illustrative chap-

ters will be replaced once the domain specifications are available.

Annex A 2: Common IDV Attributes

Friendly

Name Descrip-

tion Name Type Comments

isMem-

berOf Specifies

the organi-

zation for

which the

user acts.

idv:isMemberO

f

xs:string UID-BFS number is used for the value:

UID is for "legally existing" organizations

OID: {joint-iso-itu-t(2) ds(5) at-tributeType(4) organization-

Name(10)}

Example: CHE392445860 Alternatively, urn:oid:2.5.4.10 (SAML

2.0 X.500/LDAP Attribute Profile [SAML-x500] and interoperable SAML 2.0 Web Browser SSO Deployment Profile [Interop]) could be used as name (this was suggested in the past).

eCH-

0097:uidStructureTy

pe

The UID-BFS number could also be provid-ed in a structured form as suggested by [ECH-0097]. Example:

<isMemberOf>

<uidOrganisationIdCategorie

xmlns="http://www.ech.ch/xmlns/

eCH-0097/3">

CHE

</uidOrganisationIdCategorie>

<uidOrganisationId xmlns=

"http://www.ech.ch/xmlns/eCH-

0097/3">

392445860

</uidOrganisationId>

</isMemberOf>

The type of the attribute will be reviewed as

part of the domain policy specification with

members of the IDV architecture board. Addi-

tional feedback from reviewers of the present

document is welcome.

hasFunc-tion

Specifies the func-tion(s) the user occu-pies for the organiza-tion identi-

idv:hasFuncti

on xs:string Example: "Clerk Tax Office, Police Officer"

As in case of the attribute 'isMember-Of' there are simple and more com-plex options to structure the multiple value field. Therefore, the type of the


56/57


fied with memberOf

attribute will be reviewed as part of the domain policy specification with mem-bers of the IDV architecture board. Additional feedback from reviewers of the present document is welcome.

OPEN ITEM

Use of OIDs for the functions (at least for Swiss gov.)?

Alternatively, urn:oid:2.5.4.12

(SAML 2.0 X.500/LDAP Attribute Pro-file [SAML-x500] and interoperable SAML 2.0 Web Browser SSO De-ployment Profile [Interop]) could be used as name (this was suggested in the past). The function value will be reviewed as part of the domain policy specification with members of the IDV architecture board. Additional feedback from re-viewers of the present document is welcome.

Annex A 3: Attributes G2C Domain (Integration Pilot)

In the G2C domain, the attributes will be available with two quality levels. One level contains verified

attributes and one level contains self-declared attributes. Verified attributes can only be requested if

the requested authentication LoA is high enough (e.g. LoA >= 2).

Validated Attributes:

Friendly

Name Description Name Type

Last

name Validated

surname,

family name

http://schemas.xmlsoap.org/

ws/2005/05/identity/claims/surname

icc:StringMaxLength255MinLength1

(xs:string)

First

name Validated

preferred

name or first

name of a

subject

http://schemas.xmlsoap.org/

ws/2005/05/identity/claims/givenname


(xs:string)

Nationali-

ty Validated

ISO 3166-1

alpha-3

codes with

modifica-

tions (use

000 for

stateless

persons,

use RKS for

Kosovars)

http://www.ech.ch/

xmlns/eCH-0113/1/nationality

eCH-0113:countryIdISO3Type

(xs:token)

Gender Validated

gender:

0: unspeci-

fied

1: male

2: female

http://schemas.xmlsoap.org/ws/2005/

05/identity/claims/gender

icc:GenderType

(xs:token)

Date of Validated http://schemas.xmlsoap.org/ws/2005/ xs:date

http://schemas.xmlsoap.org/%09ws/2005/05/identity/claims/

http://schemas.xmlsoap.org/%09ws/2005/05/identity/claims/


http://schemas.xmlsoap.org/%09ws/2005/05/identity/claims/givenname

http://schemas.xmlsoap.org/%09ws/2005/05/identity/claims/givenname

http://www.ech.ch/%09xmlns/eCH-0113/1/nationality

http://www.ech.ch/%09xmlns/eCH-0113/1/nationality

http://schemas.xmlsoap.org/ws/2005/%0905/identity/claims/gender

http://schemas.xmlsoap.org/ws/2005/%0905/identity/claims/gender

http://schemas.xmlsoap.org/ws/2005/%0905/identity/claims/dateofbirth


57/57


Birth date of birth 05/identity/claims/dateofbirth

Mobile

Tele-

phone

Number

Validated

mobile

phone num-

ber

http://schemas.xmlsoap.org/ws/2005/

05/identity/claims/mobilephone


(xs:string)

E-mail

Address Validated e-

mail ad-

dress

http://schemas.xmlsoap.org/ws/

2005/05/identity/claims/emailaddress


(xs:string)

Self-declared Attributes:

For each validated attribute, there is also a self-declared attribute. The self-declared attrib-

utes have a similar friendly name ("Last name" → "Last name (self-declared)"), a derived

name (different name space and additional post-fix) and the same type as the validated at-

tributes.

List: idv:surname_sd, idv:givenname_sd, idv:nationality_sd, idv:gender_sd, idv:dateofbirth_sd, idv:mobilephone_sd, idv:emailaddress_sd

Annex A 4: Attributes G2G Domain (Integration Pilot)

In the G2G domain all attributes are assumed to be validated. Therefore, there is no need for

self-declared attributes.

Friend

ly

Name

Descrip-

tion Name Type

Last

name Validated

surname,

family

name

http://schemas.xmlsoap.org/ws/2005/05/ident

ity/claims/surname


(xs:string)

First

name Validated

preferred

name or

first

name of

a subject

http://schemas.xmlsoap.org/ws/2005/05/ident

ity/claims/givenname


(xs:string)

Additionally, the IDV common attributes isMemberOf and hasFunction are provided in the G2G

domain to enable ABAC for RPs in G2G to delegate

identity management

part of access management

to the organization on whose behalf the user will act.

http://schemas.xmlsoap.org/ws/2005/%0905/identity/claims/dateofbirth

http://schemas.xmlsoap.org/ws/2005/%0905/identity/claims/mobilephone

http://schemas.xmlsoap.org/ws/2005/%0905/identity/claims/mobilephone

http://schemas.xmlsoap.o/

http://schemas.xmlsoap.o/

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress




http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

Documents

WP-Number: 24000...Aug 31, 2017 · Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Introduction 4/57 IDV_24001_Interface_Specification.docx 1 Introduction