Identity federations operating in a business or consumer context need to prevent the collection of user data across trust service providers for legal and business case reasons. Other reasons include business owners becoming increasingly aware of confidentiality risks that go beyond traditional information security, e.g., the numbers of authentications to an EDI service might provide insights into the volume of invoices, from which one could derive insider information. This presenation proposes extended technical controls supporting more strict privacy requirements, predominantly limited linkability and limited observability. Using a hub-and-spoke federation style following the privacy-by-design principle, this reference architecture addresses the privacy controls mentioned above. Opposed to PET (privacy enhanced technologies) this model does not require advanced cryptography and fits into existing technology stacks such as WS-Trust and SAML WebSSO.

1. A Model for
Privacy Enhanced
Federated Identity Management
Rainer Hörbe, EUSTIX Alliance

2. Privacy Issues in
Federated Identity
Management

3. Technical Privacy Controls for FIM
Standard FIM (e.g. SAML WebSSO)
PE-FIM
• Data minimization:
• Limited unobservability by TTP
• IdPs release only required
• IdP/AP talks to groups of
attributes, only to authorized
services, cannot identify
services
service
• Limited unlinkability between services • Limited unlinkability between
• Identifiers are targeted
services
• Impersonation
• Messaging, payment and
• (HoK)
delivery are pseudonymized;
!
e.g. IdP will proxy SMTP
!
traffic from targets email
address to registered one
Rationale for enhanced privacy: scaling federation across vertical sectors

4. Software Architecture
Research Group
Architectural challenge:
Technical controls to
Provide and evaluate
enhance privacy
principles, techniques,
and tools to support
and facilitate the
development and
evolution of softwareintensive system

5. Software Architecture
Research Group
Options for technical controls
Provide and evaluate
Identity escrow (zero-knowlege proof)
principles, techniques,
Late binding (separate authN from attributes)
and tools to support
Proxy pool (hub+spoke with many hubs)
and facilitate the
User-based IdPs (PAD, IMI) development and
Pseudonym SP, targeted evolution(PE-FIM)
attributes of softwareintensive system
!5

6. 1.5
The Privacy-enhanced FIM Architecture (PE-FIM)
This model proposes an approach to federated identity management (FIM) that is
privacy-friendly with respect to the requirements defined above. It is based on a 3-tier
architecture that is an extended hub-and-spoke model with privacy by design principles applied to it. The hub is called the service broker (SB) in this model.
Software Architecture
Research Group
High-level Architecture.
The very outset of the PE-FIM model is the introduction of a secure pseudonymous
channel to support requirements R1, R2 and R3. The desired property of this bidirectional channel is that an IdP and an SP, or two SPs, can communicate about a principal, where (a) the SPs are pseudonymous to the IdPs, (b) the principal is pseudonymous to the SPs and (c) the IdP’s and SP’s identities are vouched for by the certificate
authority.
Pseudonym SP
one-time
Providecertificates evaluate
and
! principles, techniques,
and
pseudonymous secure channel tools to support
!
Service
and facilitate the
Provider
!
development and
!
message flow
message flow
Service
evolution of softwareBroker
intensive system
IdP trusts CA
Identity
Provider
Certificate
!
Authority
Fig. 2. High-level Architecture
It is assumed, but not shown in!6the picture above, that trust has been established be-

7. Software Architecture
Research Group
Pseudonymous SP
Provide
3-tier architecture (hub-and-spoke) and evaluate
principles, techniques,
Service broker (hub) does not see user attributes
and tools to support
SP issues one-time encryption keys signed by CA
and facilitate the
Group signatures would work as well
development and
Unobservability improves with number of services
evolution of softwareper Service Broker
intensive system
!7

8. Software Architecture
Research Group
Provide and
Targeted Attributes (e-mail) evaluate
principles, techniques,
Targeted email for SP is targeted id @to support
SB
and tools
and @ IdP
Targeted email for SB is targeted id facilitate the
development and
SB, IdP act as MTA and rewrite address
evolution of softwareintensive system
!8

9. Software Architecture
Research Group
Provide and evaluate
Pseudonymous Payment & Delivery
principles, techniques,
and tools to support
Virtual credit cards
and facilitate the
Intermediate PO-boxes(?)
development and
evolution of softwareintensive system
!9

10. Software Architecture
Research Group
Out of scope
Provide and evaluate
Display names (could beprinciples,+ number)
first name techniques,
and tools to support
IP-Addresses (need overlay networks)
and facilitate the
development and
!
evolution of softwareintensive system
!10

11. What else?
The model can be applied to SAML BAE, WSTrust and OIDC as well.
A profile for SAML looks like this:

12. Certificate
Authority
1
1
IdP-side
Metadata
Feed
SP-side
Metadata
Feed 2
7
1
3
1
Service Broker
MX
Login
IdP
9
1
10
1
SAML
5
1
Proxy
2
1
4
1
SP
App
9
1
AP
MX
8
1
Consent
Service
(4) /AuthnRequest/extension/pefim:SPCertEnc/ds:KeyInfo/..
(6) /Assertion/Advice/EncryptedAssertion

13. Project Status
Development underway for PoC using OpenAM,
Shibboleth and pysaml2
Demo @ EEMA/Vienna April 2014
Pilot project: EDI-federation in Austria
!13