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
IDV_24001_Interface_Specification.docx
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
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Introduction
3/57
IDV_24001_Interface_Specification.docx
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
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Introduction
4/57
IDV_24001_Interface_Specification.docx
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>
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Introduction
5/57
IDV_24001_Interface_Specification.docx
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.
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Introduction
6/57
IDV_24001_Interface_Specification.docx
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).
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Introduction
7/57
IDV_24001_Interface_Specification.docx
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-
0107&documentVersion=2.0
[ECH-0113] eCH (2012, Jun) eCH-0113: Spezifikation SuisseID [Online]
http://www.ech.ch/vechweb/page?p=dossier&documentNumber=eCH-
0113&documentVersion=1.0
[ECH-0167] eCH (2014, Jun) eCH-0167: SuisseTrustIAM-Rahmenkonzept [Online]
http://www.ech.ch/vechweb/page?p=dossier&documentNumber=eCH-
0167&documentVersion=1.0
[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]
http://www.ech.ch/vechweb/page?p=dossier&documentNumber=eCH-
0170&documentVersion=1.0
[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-
0170&documentVersion=2.0
[ECH-0174] eCH (2015, Nov) eCH-0174: SuisseTrustIAM‐ Implementierung mit SAML 2.0. [Online]
http://www.ech.ch/vechweb/page?p=dossier&documentNumber=eCH-
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]
https://tools.ietf.org/html/rfc2397
[RFC4949] RFC 4949, Internet Security Glossary, Version 2, Internet Engineering Task Force, August 2007.
[Online]
https://tools.ietf.org/html/rfc4949
[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-
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Introduction
8/57
IDV_24001_Interface_Specification.docx
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 –
Errata Composite, Working Draft 05, 8 September 2015. [Online]
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 –
Errata Composite, Working Draft 07, 8 September 2015. [Online]
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/
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Overview and Structure of the System
9/57
IDV_24001_Interface_Specification.docx
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
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Overview and Structure of the System
10/57
IDV_24001_Interface_Specification.docx
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
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Overview and Structure of the System
11/57
IDV_24001_Interface_Specification.docx
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
IDV_24001_Interface_Specification.docx
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
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Requirements
13/57
IDV_24001_Interface_Specification.docx
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
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Requirements
14/57
IDV_24001_Interface_Specification.docx
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
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Requirements
15/57
IDV_24001_Interface_Specification.docx
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
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Requirements
16/57
IDV_24001_Interface_Specification.docx
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
IDV_24001_Interface_Specification.docx
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
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Runtime Protocols
18/57
IDV_24001_Interface_Specification.docx
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>.
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Runtime Protocols
19/57
IDV_24001_Interface_Specification.docx
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
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Runtime Protocols
20/57
IDV_24001_Interface_Specification.docx
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
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Runtime Protocols
21/57
IDV_24001_Interface_Specification.docx
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_24001_Interface_Specification.docx
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
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification IDV SAML Message Format
23/57
IDV_24001_Interface_Specification.docx
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-
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification IDV SAML Message Format
24/57
IDV_24001_Interface_Specification.docx
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.
MUST MUST be provided in GE, FR, IT and EN.
<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.
MUST MUST be provided in GE, FR, IT and EN.
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.
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-
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.
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-
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
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification IDV SAML Message Format
25/57
IDV_24001_Interface_Specification.docx
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.
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-
format:unspecified"
Name="originDisclosure"
The authenticating IdP/AA is disclosed to the RP.
MAY If not defined, the domain policy default applies.
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-
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.
MUST MUST be provided in GE, FR, IT and EN.
<mdui:UIInfo>/<mdui:Description> Description displayed during HRD.
MUST MUST be provided in GE, FR, IT and EN.
<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
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification IDV SAML Message Format
26/57
IDV_24001_Interface_Specification.docx
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.
MUST MUST be provided in GE, FR, IT and EN.
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
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-
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.
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-
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.
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification IDV SAML Message Format
27/57
IDV_24001_Interface_Specification.docx
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-
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification IDV SAML Message Format
28/57
IDV_24001_Interface_Specification.docx
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
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification IDV SAML Message Format
29/57
IDV_24001_Interface_Specification.docx
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
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification IDV SAML Message Format
30/57
IDV_24001_Interface_Specification.docx
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
Element / Attribute Description Availability eCH-
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-
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification IDV SAML Message Format
31/57
IDV_24001_Interface_Specification.docx
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>
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification IDV SAML Message Format
32/57
IDV_24001_Interface_Specification.docx
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.
Element / Attribute Description Availability eCH-
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.
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification IDV SAML Message Format
33/57
IDV_24001_Interface_Specification.docx
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
IDV_24001_Interface_Specification.docx
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
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Security
35/57
IDV_24001_Interface_Specification.docx
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.
Integration Pilot Domains
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.
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Security
36/57
IDV_24001_Interface_Specification.docx
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
IDV_24001_Interface_Specification.docx
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
urn:oasis:names:tc:SAML:2.0:nameid-
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
urn:oasis:names:tc:SAML:2.0:nameid-
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
urn:oasis:names:tc:SAML:2.0:nameid-
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
IDV_24001_Interface_Specification.docx
and rules for the assignment of the several levels have to be defined in the domain poli-
cies (by the domain management) [TS-504].
Integration Pilot Domains
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
urn:stiam.gov.ch/authenticationassurance/level2
urn:stiam.gov.ch/authenticationassurance/level3
urn:stiam.gov.ch/authenticationassurance/level4
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.
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Message Format Examples
39/57
IDV_24001_Interface_Specification.docx
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">
data:image/png;base64,iVBORw0K...
</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:InformationURL>
…
<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:PrivacyStatementURL>
…
</mdui:UIInfo>
<attr:EntityAttributes>
<saml:Attribute
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oasis:names:tc:SAML:attribute:assurance-certification">
<saml:AttributeValue>
urn:stiam.gov.ch/authenticationassurance/level1
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
Name="IdPPriorityList">
<saml:AttributeValue>
https://www.example123.ch/IDVReferenceIdP2/idp
</saml:AttributeValue>
<saml:AttributeValue>
https://www.example123.ch/IDVReferenceIdP1/idp
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Message Format Examples
40/57
IDV_24001_Interface_Specification.docx
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
Name="IdPGroups">
<saml:AttributeValue>idpGroupReferenceIdps</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
Name="originDisclosure">
<saml:AttributeValue>true</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
Name="assertionDisclosure">
<saml:AttributeValue>true</saml:AttributeValue>
</saml:Attribute>
</attr:EntityAttributes>
</Extensions>
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<!--Signer cert -->
<ds:X509Certificate>MIICXTCCA..</ds:X509Certificate>
<!-- Intermediate cert subject -->
<ds:X509Certificate>MIICPzCCA...</ds:X509Certificate>
<!-- Root cert subject -->
<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" />
<AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://www.example.ch/o_not_existent/idv_protected/"
index="2" />
<AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://www.example.ch/o_constructpermit/idv_protected/"
index="3" />
<AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://www.example.ch/o_register/idv_protected/"
index="4" />
<AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
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"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true" />
<RequestedAttribute FriendlyName="given name"
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Message Format Examples
41/57
IDV_24001_Interface_Specification.docx
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true" />
</AttributeConsumingService>
<AttributeConsumingService index="3">
<ServiceName xml:lang="en">Construction Permit attributes</ServiceName>
<ServiceDescription xml:lang="en">
Attributes used for Construction Permit usecase.
</ServiceDescription>
<RequestedAttribute FriendlyName="surname"
Name=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true" />
<RequestedAttribute FriendlyName="given name"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true" />
<RequestedAttribute FriendlyName="nationality"
Name="http://www.ech.ch/xmlns/eCH-0113/1/nationality"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true" />
</AttributeConsumingService>
<AttributeConsumingService index="4" isDefault="true">
<ServiceName xml:lang="en">Identity Relay attributes</ServiceName>
<ServiceDescription xml:lang="en">
Attributes used forIdentity Relay usecase.</ServiceDescription>
<RequestedAttribute FriendlyName="surname"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true" />
<RequestedAttribute FriendlyName="given name"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true" />
<RequestedAttribute FriendlyName="date of birth"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true" />
<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"
isRequired="true" />
<RequestedAttribute FriendlyName="nationality"
Name="http://www.ech.ch/xmlns/eCH-0113/1/nationality"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true" />
</AttributeConsumingService>
<AttributeConsumingService index="5">
<ServiceName xml:lang="en">Taxes and Fees attributes</ServiceName>
<ServiceDescription xml:lang="en">
Attributes used for Taxes and Fees usecase.</ServiceDescription>
<RequestedAttribute FriendlyName="socialsecuritynumber"
Name="http://schemas.xmlsoap.org/
ws/2005/05/identity/claims/socialsecuritynumber"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true" />
</AttributeConsumingService>
</SPSSODescriptor>
</EntityDescriptor>
8.1.2 Broker (Domain IdP) Metadata
<md:EntitiesDescriptor
ID="IDVBrokerIDVDemoG2CDomain"
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Message Format Examples
42/57
IDV_24001_Interface_Specification.docx
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"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<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>
…
<mdui:InformationURL xml:lang="de">
/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>
…
<mdui:PrivacyStatementURL xml:lang="de">
/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>
<!--Signer cert -->
<ds:X509Certificate>MIICXTCCA..</ds:X509Certificate>
<!-- Intermediate cert subject -->
<ds:X509Certificate>MIICPzCCA...</ds:X509Certificate>
<!-- Root cert subject -->
<ds:X509Certificate>MIICSTCCA...</ds:X509Certificate>
</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>
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Message Format Examples
43/57
IDV_24001_Interface_Specification.docx
<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"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
<saml2:Attribute
FriendlyName="name"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
<saml2:Attribute
FriendlyName="nationality"
Name="http://www.ech.ch/xmlns/eCH-0113/1/nationality"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
<saml2:Attribute
FriendlyName="gender"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
<saml2:Attribute
FriendlyName="date of birth"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
<saml2:Attribute
FriendlyName="AVS/AHV number"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/socialsecnumber"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
</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"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
AssertionConsumerServiceURL="https://sp.example.ch/SAML2.0/SP/AssertionConsumer" AttributeConsumingServiceIndex="1" ForceAuthn="false">
<saml2:Issuer>https://sp-ref.example.ch/IDVReferenceRpG2C/rp1</saml2:Issuer>
<ds:Signature>...</ds:Signature
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Message Format Examples
44/57
IDV_24001_Interface_Specification.docx
<saml2p:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
<saml2p:RequestedAuthnContext Comparison="minimum"> <saml2:AuthnContextClassRef>
urn:stiam.gov.ch/authenticationassurance/level2
</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>
<ds:Signature>...</ds:Signature
<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>
urn:stiam.gov.ch/authenticationassurance/level3
</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>
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Message Format Examples
45/57
IDV_24001_Interface_Specification.docx
</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>
<ds:Signature>...</ds:Signature>
<saml2:Subject>
<saml2:NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
UCUwUHrUpewUMTWpHKXXmexrPMoZFdcfft-
HoFqM66A+bEzL9BdEAeJewAO77OCqJaq9mOjrUdJcmCw1oFS5mQ==
</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData
InResponseTo="AuthnRequest_699D74752BF265443EC865E0E5EFB6AB71FF204"
NotOnOrAfter="2017-09-14T15:31:55.682Z"
Recipient="https:/sp.example.ch/SAML2.0/SP/AssertionConsumer"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions
NotBefore="2017-08-15T15:31:55.682Z"
NotOnOrAfter="2017-09-14T15:31:55.682Z">
<saml2:AudienceRestriction>
<saml2:Audience>
https://sp.example.ch/IDVReferenceRpG2C/rp1
</saml2:Audience>
</saml2:AudienceRestriction>
<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>
<ds:Signature>...</ds:Signature>
<saml2:Subject>
<saml2:NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
persistent-id
</saml2:NameID>
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Message Format Examples
46/57
IDV_24001_Interface_Specification.docx
<saml2:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData
InResponseTo="_7935dfe6-acf3-4d0c-a229-6bab237f05ae"
NotOnOrAfter="2017-09-14T15:31:55.682Z"
Recipient="https://idv-broker.ch/IDVtestG2C/SAML2/POST"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions
NotBefore="2017-08-15T15:31:55.682Z"
NotOnOrAfter="2017-09-14T15:31:55.682Z">
<saml2:AudienceRestriction>
<saml2:Audience>
https://idv-broker.ch/IDVtestG2C/sp</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2017-08-15T15:31:55.682Z">
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
</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>
</saml2:Assertion>
</saml2:Advice>
<saml2:AuthnStatement AuthnInstant="2017-08-15T15:31:55.682Z">
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>
urn:stiam.gov.ch/authenticationassurance/level1
</saml2:AuthnContextClassRef>
<saml2:AuthenticatingAuthority>
https://idp.example.ch/IDVReferenceIdP1/idp
</saml2:AuthenticatingAuthority>
</saml2:AuthnContext>
</saml2:AuthnStatement>
<saml2:AttributeStatement>
<saml2:Attribute
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
ext:OriginalIssuer="https://idp.example.ch/IDVReferenceIdP1/idp">
<saml2:AttributeValue xsi:type="xsd:string">
Muster
</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
ext:OriginalIssuer="https://idp.example.ch/IDVReferenceIdP1/idp">
<saml2:AttributeValue xsi:type="xsd:string">
Peter
</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
</saml2:Assertion>
</saml2p:Response>
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Message Format Examples
47/57
IDV_24001_Interface_Specification.docx
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>
<ds:Signature>...</ds:Signature>
<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"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<Extensions>
<mdui:UIInfo>
<mdui:DisplayName xml:lang="de">
Niederbipp Online-Schalter
</mdui:DisplayName>
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Message Format Examples
48/57
IDV_24001_Interface_Specification.docx
<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">
data:image/png;base64,iVBORw0K...
</mdui:Logo>
<mdui:Logo height="40" width="45" xml:lang="fr">
data:image/png;base64,iVBORw0K...
</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:InformationURL>
...
<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:PrivacyStatementURL>
...
</mdui:UIInfo>
<attr:EntityAttributes>
<saml:Attribute
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oasis:names:tc:SAML:attribute:assurance-certification"
<saml:AttributeValue>
urn:stiam.gov.ch/authenticationassurance/level1
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
Name="ConsentObtainedByIdP">
<saml:AttributeValue>true</saml:AttributeValue>
</saml:Attribute>
</attr:EntityAttributes>
</Extensions>
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<!--Signer cert -->
<ds:X509Certificate>MIICXTCCA..</ds:X509Certificate>
<!-- Intermediate cert subject -->
<ds:X509Certificate>MIICPzCCA...</ds:X509Certificate>
<!-- Root cert subject -->
<ds:X509Certificate>MIICSTCCA...</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
<SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://www.example.ch/idp/auth/saml2/sso/" />
<saml:Attribute
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
FriendlyName="surname" />
<saml:Attribute
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Message Format Examples
49/57
IDV_24001_Interface_Specification.docx
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
FriendlyName="givenname" />
</IDPSSODescriptor>
</EntityDescriptor>
8.2.2 Broker (Domain RP) Metadata
<md:EntitiesDescriptor
ID="IDVBrokerIDVtestG2CDomain"
Name="IDVBrokerIDVtestG2CDomain">
<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="#IDVBrokerIDVtestG2CDomain">
<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/IDVtestG2C/sp">
<md:SPSSODescriptor
AuthnRequestsSigned="true"
WantAssertionsSigned="true"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<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>
...
<mdui:InformationURL xml:lang="de">
/static/assets/html/privacy_de.html
</mdui:InformationURL>
<mdui:InformationURL xml:lang="en">
/static/assets/html/privacy_en.html
</mdui:InformationURL>
...
<mdui:PrivacyStatementURL xml:lang="de">
/static/assets/html/privacy_de.html
</mdui:PrivacyStatementURL>
<mdui:PrivacyStatementURL xml:lang="it">
/static/assets/html/privacy_it.html
</mdui:PrivacyStatementURL>
...
</mdui:UIInfo>
</md:Extensions>
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Message Format Examples
50/57
IDV_24001_Interface_Specification.docx
<md:KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<!--Signer cert -->
<ds:X509Certificate>MIICXTCCA..</ds:X509Certificate>
<!-- Intermediate cert subject -->
<ds:X509Certificate>MIICPzCCA...</ds:X509Certificate>
<!-- Root cert subject -->
<ds:X509Certificate>MIICSTCCA...</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIICXTCCA..</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:NameIDFormat>
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
</md:NameIDFormat>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
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:ServiceDescription>
...
<md:RequestedAttribute
FriendlyName="surname"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true"/>
<md:RequestedAttribute
FriendlyName="givenname"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
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>
...
<md:ServiceDescription xml:lang="en">
Extended attribute set EN.
</md:ServiceDescription>
<md:ServiceDescription xml:lang="de">
Extended attribute set DE.
</md:ServiceDescription>
...
<md:RequestedAttribute
FriendlyName="surname"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true"/>
<md:RequestedAttribute
FriendlyName="givenname"
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Message Format Examples
51/57
IDV_24001_Interface_Specification.docx
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true"/>
<md:RequestedAttribute
FriendlyName="nationality"
Name="http://www.ech.ch/xmlns/eCH-0113/1/nationality"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true"/>
</md:AttributeConsumingService>
<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>
...
<md:ServiceDescription xml:lang="en">
Full attribute set EN.
</md:ServiceDescription>
<md:ServiceDescription xml:lang="de">
Full attribute set DE.
</md:ServiceDescription>
...
<md:RequestedAttribute
FriendlyName="surname"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true"/>
<md:RequestedAttribute
FriendlyName="givenname"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true"/>
<md:RequestedAttribute
FriendlyName="nationality"
Name="http://www.ech.ch/xmlns/eCH-0113/1/nationality"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true"/>
<md:RequestedAttribute FriendlyName="gender"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true"/>
<md:RequestedAttribute
FriendlyName="date of birth"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true"/>
</md:AttributeConsumingService>
<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>
...
<md:ServiceDescription xml:lang="en">
Protected attribute set EN.
</md:ServiceDescription>
<md:ServiceDescription xml:lang="de">
Protected attribute set DE.
</md:ServiceDescription>
...
<md:RequestedAttribute
FriendlyName="surname"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true"/>
<md:RequestedAttribute
FriendlyName="givenname"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true"/>
<md:RequestedAttribute
FriendlyName="AVS/AHV number"
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/socialsecuritynumber"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Message Format Examples
52/57
IDV_24001_Interface_Specification.docx
isRequired="true"/>
</md:AttributeConsumingService>
</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"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
AttributeConsumingServiceIndex="1">
<saml2:Issuer>https://idv-broker.ch/IDVtestG2C/sp</saml2:Issuer>
<ds:Signature>...</ds:Signature>
<saml2p:RequestedAuthnContext Comparison="minimum">
<saml2:AuthnContextClassRef>
urn:stiam.gov.ch/authenticationassurance/level1
</saml2:AuthnContextClassRef>
</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>
<ds:Signature>...</ds:Signature>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</saml2p:Status>
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Message Format Examples
53/57
IDV_24001_Interface_Specification.docx
<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>
<ds:Signature>...</ds:Signature>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
persistent-id
</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData
InResponseTo="_947032a6-14ff-4376-95b0-2ac3b0001de0"
NotOnOrAfter="2017-09-07T12:34:48.702Z"
Recipient="https://idv-broker.ch/IDVtestG2C/SAML2/POST" />
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions
NotBefore="2017-08-08T12:34:48.702Z"
NotOnOrAfter="2017-09-07T12:34:48.702Z">
<saml2:AudienceRestriction>
<saml2:Audience>https://idv-broker.ch/IDVtestG2C/sp</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2017-08-08T12:34:48.702Z">
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>
urn:stiam.gov.ch/authenticationassurance/level1
</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>
</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
IDV_24001_Interface_Specification.docx
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.
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Extensions and Special Cases
55/57
IDV_24001_Interface_Specification.docx
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
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Extensions and Special Cases
56/57
IDV_24001_Interface_Specification.docx
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
icc:StringMaxLength255MinLength1
(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
Identitätsverbund Schweiz (IDV) - IDV Platform Interface Specification Extensions and Special Cases
57/57
IDV_24001_Interface_Specification.docx
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
icc:StringMaxLength255MinLength1
(xs:string)
Address Validated e-
mail ad-
dress
http://schemas.xmlsoap.org/ws/
2005/05/identity/claims/emailaddress
icc:StringMaxLength255MinLength1
(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
icc:StringMaxLength255MinLength1
(xs:string)
First
name Validated
preferred
name or
first
name of
a subject
http://schemas.xmlsoap.org/ws/2005/05/ident
ity/claims/givenname
icc:StringMaxLength255MinLength1
(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.
Top Related