Document type Report Title D2.1- TAS Architecture Work Package

Transcription

SEVENTH FRAMEWORK PROGRAMME
Challenge 1
Information and Communication Technologies
Document type
Report
Title
D2.1- TAS3 Architecture
Work Package
WP2
Dissemination level
Public
Editor(s)
Sampo Kellomäki, EIfEL
Preparation date
1 June 2009
Version
15 (1.90)
Legal Notice
All information included in this document is subject to change without notice. The Members of the
TAS3 Consortium make no warranty of any kind with regard to this document, including, but not limited
to, the implied warranties of merchantability and fitness for a particular purpose. The Members of
the TAS3 Consortium shall not be held liable for errors contained herein or direct, indirect, special,
incidental or consequential damages in connection with the furnishing, performance, or use of this
material.
The TAS3 Consortium
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Participant name
K.U. Leuven
Synergetics
University of Kent
University of Karlsruhe
Technische Universiteit Eindhoven
CNR/ISTI
University of Koblenz-Landau
Vrije Universiteit Brussel
University of Zaragoza
University of Nottingham
SAP Research
Eifel
Intalio
Risaris
Kenteq
Oracle
Custodix
Medisoft
Country
BE
BE
UK
DE
NL
IT
DE
BE
ES
UK
DE
FR
FR
IR
BE
UK
BE
NL
Participant short name
KUL
SYN
KENT
KARL
TUE
CNR
UNIKOLD
VUB
UNIZAR
NOT
SAP
EIF
INT
RIS
KETQ
ORACLE
CUS
MEDI
Participant role
Coordinator
Project Manager
Partner
Partner
Partner
Partner
Partner
Partner
Partner
Partner
Partner
Partner
Partner
Partner
Partner
Partner
Partner
Partner
Contributors
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Name
Joseph Alhadeff
Brendan Vanalsenoy
Guglielmo De Angelis
Michele Bezzi
David Chadwick
Brecht Claerhout
Danny De Cock
Seda Gürses
Ingo Dahn
Jeroen Hoppenbrouwers
Thomas Kirkham
Keqin Li
Gilles Montagnon
Jutta Mülle
Jens Müller
Jean-Christophe Pazzaglia
Quentin Reul
Marc Santos
Gang Zhao
TAS3 ICT-216287
Organisation
Oracle
KUL
CNR/ISTI
SAP
KENT
CUS
KUL
KUL
UNIKOLD
SYN
NOT
SAP
SAP
KARL
KARL
SAP
VUB
UNIKOLD
VUB
D2.1– TAS3 A RCHITECTURE Version 15 (1.90)
Page 2 of 211
0 Table of Contents
L IST
OF
F IGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
E XECUTIVE S UMMARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1
2
3
I NTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1
TAS3 A RCHITECTURE
1.2
M ETHODOLOGY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3
N ORMATIVE C LAIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4
R EVIEW
1.5
R EADER ’ S G UIDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
OF
AT
G LANCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
P REVIOUS W ORK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
TAS3 H IGH L EVEL A RCHITECTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1
OVERVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2
B ASIC A RCHITECTURAL E NTITIES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1 Major Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.2.2 Enforcement Points on Web Service Call Path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.2.3 Authorization Subcontinent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.3
M AJOR F LOWS : F RONT C HANNEL
2.4
OVERVIEW
OF
AND
B ACK C HANNEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
DATA M ODELS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4.1 Federation Relations for Core Security Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
2.4.2 Personal Data and Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
2.4.3 Using Sticky Policies to Protect Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
2.4.4 Using Encryption to Protect Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
2.5
AUTHORIZATION P ROCESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.6
E NFORCEMENT P ROCESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.7
C ONFIGURATION P ROCESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.8
AUDIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
C ORE S ECURITY A RCHITECTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1
F LOWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2
TOKENS , ACCESS C REDENTIALS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.1 Attribute Pull Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
3.2.2 Linking Service: Attribute Push Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
3.2.3 Simple Attribute Push Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
TAS3 ICT-216287
Page 3 of 211
TABLE OF CONTENTS
3.3
D ELEGATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.3.1 Invitation Based Token Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
3.3.2 Mandate Tokens Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
3.3.3 Delegation by Direct Authorization Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
3.3.4 Delegation by Role Based Authorization Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
3.3.5 Token Based Delegation to Well Known Delegatee. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
3.3.6 Token Based Delegation of a Received Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
3.3.7 Multi-layer (Chained) Delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
3.4
S UBJECT
3.5
B REAK - THE -G LASS AUTHORIZATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.6
T RUST
3.7
I NTEROPERATION ACROSS T RUST N ETWORKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
OF THE
AND
PII N OT P RESENT -T RANSACTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
P RIVACY N EGOTIATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.7.1 Semantic Interoperability Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8
4
P ROPERTIES
OF
W EB S ERVICE B INDING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
A PPLICATION S PECIFIC A RCHITECTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.1
P ROTOCOL S UPPORT
4.2
L EGACY I NTEGRATION S TRATEGY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.3
ADPEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
FOR
C ONVEYANCE
5
U SING B USINESS P ROCESS M ODELLING
6
OVERSIGHT
6.1
7
66
AND
OF
TO
S TICKY P OLICIES . . . . . . . . . . . . . . . . . . . . . . 69
C ONFIGURE
THE
C OMPONENTS . . . . . . . 74
M ONITORING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
O N - LINE C OMPLIANCE T ESTING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.1.1 Involved Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
6.1.2 On-line Testing Process and Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
6.2
O PERATIONS M ONITORING
AND I NTRUSION
D ETECTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.3
L OG AUDIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.3.1 Log Collection and Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
6.3.2 Privacy Issues: What to Collect and What to Report . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
6.4
F ORMAL C OMPLIANCE AUDITS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.5
A DMINISTRATIVE OVERSIGHT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
C ONCLUSION : TAS3
A NNEX A
A.1
P ROTOCOLS
IS
S ECURE
AND
AND
T RUSTWORTHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
C ONCRETE A RCHITECTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
S UPPORTED AUTHENTICATION
AND
L OGIN S YSTEMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
A.1.1 System Entity Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TAS3 ICT-216287
88
Page 4 of 211
TABLE OF CONTENTS
A.1.2 SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
A.1.3 Shibboleth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
A.1.4 eID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
A.1.5 Smart Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
A.1.6 One-Time-Password Tokens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
A.1.7 OpenID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
A.1.8 CardSpace / InforCard and WS-Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
A.1.9 CA / Netegrity Siteminder Proprietary SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
A.1.10 Citrix, Sun, and other proprietary SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
A.1.11 Web Local Login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
A.1.12 Desktop Login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
A.1.13 Fat Client Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
A.1.14 User Not Present or Batch Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
A.2
S UPPORTED I DENTITY W EB S ERVICES S YSTEMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
A.2.1 Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
A.2.2 Liberty ID-WSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
A.2.3 Bare WS-Security Header or Simplified ID-WSF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
A.2.4 WS-Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
A.2.5 RESTful Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
A.2.6 Message Bus Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
A.3
AUTHORIZATION S YSTEMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
A.3.1 Authorization Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
A.3.2 Policy Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
A.4
T RUST
AND
S ECURITY VOCABULARIES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
A.4.1 Vocabularies for Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
A.4.2 Vocabularies for Basic Attributes (PII) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
A.4.3 Discovery Vocabularies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
A.4.4 Security and Trust Vocabularies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
A.4.5 Audit Vocabularies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
A.5
R EALIZATION
OF THE
D ISCOVERY F UNCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
A.6
R EALIZATION
OF THE
T RUST
A.7
R EALIZATION
OF THE
AUDIT
AND
AND
P RIVACY N EGOTIATOR F UNCTION . . . . . . . . . . . . . . . . . 96
DASHBOARD F UNCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
A.7.1 Audit Event Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
A.7.2 Audit Event Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
A.7.3 Dashboard Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
A.8
R EALIZATION
TAS3 ICT-216287
OF
D ELEGATION F UNCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Page 5 of 211
TABLE OF CONTENTS
A NNEX B
B.1
R ESILIENT D EPLOYMENT A RCHITECTURE (N ON - NORMATIVE ) . . . . . . . . . . . . . . 98
Z ERO D OWNTIME U PDATES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
A NNEX C
C OMPLIANCE R EQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
C.1
OTHER W ORK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
C.2
G ENERAL C OMPLIANCE R EQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
C.2.1 Legal and Contractual Compliance Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
C.2.2 General Technical Compliance Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
C.3
C OMPLIANCE R EQUIREMENTS
FOR
G OVERNING AGREEMENTS . . . . . . . . . . . . . . . . . . . . . . 103
C.4
FOR
T RUST G UARANTORS . . . . . . . . . . . . . . . . . . . . . . . . . . 104
C.5
FOR
S ERVICE P ROVIDERS . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
C.6
FOR
S ERVICE R EQUESTERS . . . . . . . . . . . . . . . . . . . . . . . . . 105
C.7
FOR
DATABASES S TORING PII . . . . . . . . . . . . . . . . . . . . . . . 105
C.8
G ENERAL C OMPLIANCE R EQUIREMENTS
C.9
FOR
T RUSTED T HIRD PARTIES . . . . . . . . . . . . . . 106
FOR I DENTITY
P ROVIDER . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
C.10
FOR
D ISCOVERY P ROVIDERS . . . . . . . . . . . . . . . . . . . . . . . 106
C.11
FOR
T RUST
C.12
FOR
AUDIT P ROVIDER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
C.13
TAS3 -L ITE
A NNEX D
AND
R EPUTATION P ROVIDER . . . . . . . . . . . . . 106
C OMPLIANCE P ROFILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
G ENERALIZED U SE C ASES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
D.1
U SER U SES S ERVICE (F IRST T IME
D.2
A LREADY-L OGGED - IN O PTIMIZATION (SSO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
D.3
U SER U SES DASHBOARD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
D.4
I D P D ETECTED -O PTIMIZATION (SSO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
D.5
U SER U SES S ERVICE , I DENTITY S ELECTOR C ASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
D.6
U SER U SES S ERVICE , L OCAL L OGIN C ASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
D.7
U SER U SES S ERVICE , P ROXY I D P C ASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
D.8
C ONSENTING
TO
PII R ELEASE
OR
IN THE
S ESSION ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
M ANIPULATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
D.8.1 Interaction on Front Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
D.8.2 Interaction on side channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
D.8.3 Interaction via Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
D.9
D.10
U SING L INKING S ERVICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
C HOOSING
AMONG
M ULTIPLE S ERVICE P ROVIDERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
D.10.1 Simple Choice of Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
D.10.2 Trust and Privacy Negotiation Assisted by User Interaction. . . . . . . . . . . . . . . . . . . . . 123
D.11
U SER -N OT-P RESENT T RANSACTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
TAS3 ICT-216287
Page 6 of 211
TABLE OF CONTENTS
D.12
U SER P RESENT D ELEGATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
D.13
U SER -N OT-P RESENT D ELEGATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
D.14
OTHER U SE C ASE W ORK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
D.15
F UTURE U SE C ASE W ORK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
A NNEX E
E.1
TAS3 B USINESS M ODEL (N ON -N ORMATIVE ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
W HAT
SHOULD CONSTITUTE A
T RUST N ETWORK ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
E.1.1 Public vs. Private networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
E.1.2 Branding and reputation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
E.1.3 Users trust perception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
E.1.4 Quality of trust. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
E.2
H OW
E.3
S HOULD T RUST
E.4
W HO
SHOULD RUN THEM ?
E.5
H OW
SHOULD THE GOVERNANCE BE ORGANIZED ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E.6
H OW
ARE
E.7
F ORM
E.8
OVERSIGHT
MANY OF
OF
T RUST N ETWORKS
SHOULD THERE BE ?
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
NETWORKS INTERACT WITH EACH OTHER ?
. . . . . . . . . . . . . . . . . . . . . . . . . 137
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
T RUST N ETWORKS
FINANCED ?
138
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
T RUST G UARANTOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
RESPONSIBILITY AND CONFLICT OF INTEREST . . . . . . . . . . . . . . . . . . . . . . . . . .
144
E.8.1 Kinds of Service Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
E.8.2 Kinds of Trust Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
E.8.3 Principles that Trust Network Should Adopt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
E.8.4 Questions a Trust Network Member Has to Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
E.8.5 Privacy Architecture Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
A NNEX F
T HREATS (N ON -N ORMATIVE ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
F.1
OTHER
WORK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.2
B USINESS
F.3
T RUST
F.4
A RCHITECTURAL
F.5
T RUST
F.6
P ROTOCOL
F.7
AUTHORIZATION
F.8
O NTOLOGY
THREATS
F.9
E XPOSURE
THREATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
THREATS
150
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
MODEL THREATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
150
THREATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
150
MISCONFIGURATION THREATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
150
MISCONFIGURATION THREATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MISCONFIGURATION THREATS
F.10
P RIVACY
F.11
AUTHENTICATION
F.12
I MPERSONATION
TAS3 ICT-216287
THREATS
151
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
151
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
THREATS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
THREATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
153
Page 7 of 211
TABLE OF CONTENTS
F.13
R EPUDIATION
F.14
U NAUDITABILITY
F.15
S OFTWARE
F.16
S ERVICE AVAILABILITY T HREATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
THREATS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
THREATS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
BUG THREATS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
A NNEX G
E NUMERATION
A NNEX H
E XAMPLE P ROTOCOL M ESSAGES (N ON -N ORMATIVE ) . . . . . . . . . . . . . . . . . . . . . 161
H.1
OF
AUDIT E VENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
SAML 2.0 A RTIFACT R ESPONSE
WITH
SAML 2.0 SSO A SSERTION
AND
T WO B OOT-
STRAPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
161
H.2
ID-WSF 2.0 C ALL
WITH
X509 V 3 S EC M ECH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
H.3
ID-WSF 2.0 C ALL
WITH
B EARER (B INARY ) S EC M ECH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
H.4
ID-WSF 2.0 C ALL
WITH
B EARER (SAML) S EC M ECH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
A NNEX I
G LOSSARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
B IBLIOGRAPHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
R EVISION H ISTORY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
TAS3 ICT-216287
Page 8 of 211
0 List of Figures
Figure 2.1: Using TAS3 top level model to start modelling of organizations that participate in Trust Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
Figure 2.2: Major components of Organization Domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
Figure 2.3: Front End calls Web Service, passing through 4 enforcement points. . . . . . . . . . . . . . . . . . . .
23
Figure 2.4: Recursive Web Service calls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
Figure 2.5: Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
Figure 2.6: Front Channel and Back Channel Flows (the numbering indicates typical sequence of
events). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
Figure 2.7: Audit Event Bus (the numbering indicates typical sequence of events, the e-numbers indicate audit events) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
Figure 2.8: Authorization Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
Figure 2.9: Using model to configure Authorization Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
Figure 2.10: Arrangement of enforcement points in web service call flow. . . . . . . . . . . . . . . . . . . . . . . . . .
32
Figure 2.11: Pushing configurations from model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
Figure 2.12: Configuration from Model (the numbering indicates typical sequence of events) . . . . . . . . . .
35
Figure 2.13: Auditing an authorization decision. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
Figure 2.14: Monitoring operation of the network using the configured model. . . . . . . . . . . . . . . . . . . . . . .
37
Figure 3.1: General detailed flow of a service request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
Figure 3.2: Flow at front channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
Figure 3.3: Front channel flow when using Identity Selector.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
Figure 3.4: Flow of front channel call that makes a call on back channel. . . . . . . . . . . . . . . . . . . . . . . . . . .
44
Figure 3.5: Single Sign-On (2,3), Discovery (4), and call to WSP (5). The blue ball represents discovery
bootstrap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TAS3 ICT-216287
46
Page 9 of 211
LIST OF FIGURES
Figure 3.6: Discovery Registration Using Front Channel Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
Figure 3.7: Flow of recursive calls on back channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
Figure 3.8: Linking Service: Registration phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
Figure 3.9: Linking Service: Login with attribute push phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
Figure 3.10: The enhanced login screen for attribute aggregation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
Figure 3.11: Alice Prepares ePortfolio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
Figure 3.12: Bob using Alice’s Web Services by way of invitation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
Figure 3.13: Invitation phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
Figure 3.14: Accept invitation phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
Figure 3.15: Interoperation across contexts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
Figure 4.1: Application Integration: PEP implemented directly in application.. . . . . . . . . . . . . . . . . . . . . . .
70
Figure 4.2: Application Integration: ADPEP implemented in application itself. . . . . . . . . . . . . . . . . . . . . . .
71
Figure 4.3: Application Integration using ADPEP and (A) SOA Gateway, (B) WP9 DB as frontend to
SOA GW, (C) WP9 database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
Figure 6.1: Overview of On-line Compliance Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
Figure 6.2: UML Component Diagram of the On-line Compliance Testing (OCT). . . . . . . . . . . . . . . . . . . .
81
Figure A.1: Liberty Alliance Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
Figure B.1: Layering of resilience features for Front Channel, Back Channel, and data center Back End
services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
Figure B.2: Resiliency implemented using hardware load balancers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
Figure B.3: Resiliency implemented using software load-balancing-fail-over functionality and clustering. .
99
Figure D.1: User accesses Front Ends using Single Sign-On. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Figure D.2: Story board: Using service for 1st time in a session. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
TAS3 ICT-216287
Page 10 of 211
LIST OF FIGURES
Figure D.3: Story board: Using further services after logging in at IdP - Single Sign-On (SSO). . . . . . . . . 111
Figure D.4: Story board: Using Dashboard to audit a business process. . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Figure D.5: Story board: Fully automatic login - Single Sign-On (SSO) - when IdP can be detected. . . . . 115
Figure D.6: Story board: Identity Selector provides IdP User Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Figure D.7: Story board: Using services with local login (not recommended). . . . . . . . . . . . . . . . . . . . . . . 116
Figure D.8: Story board: Login using IdP not trusted by Job Agency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Figure D.9: Story board: Presenting a PII consent question in Front Channel interaction. . . . . . . . . . . . . . 118
Figure D.10: Story board: Presenting a PII consent question using Side Channel interaction. . . . . . . . . . 119
Figure D.11: Story board: Choice of Service Provider. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Figure D.12: Story board: Trust and Privacy Negotiation with User Interaction. . . . . . . . . . . . . . . . . . . . . . 124
Figure D.13: Story board: Alice invites Bob to view her ePortfolio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Figure E.1: Factors Contributing to Trust. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Figure E.2: Main Components of a Trust Network Technically the top level Trust Guarantor has a fundamental role in (1) introducing, (2) monitoring, and (3) auditing the end2end assurance of trust between
the transacting parties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Figure E.3: Trust Perception. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Figure E.4: Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers
(1991, revised 1999), is a marketing book by Geoffrey A. Moore that focuses on the specifics of marketing
high tech products. Moore’s exploration and expansion of the diffusions of innovations model has had
a significant and lasting impact on high tech entrepreneurship. In 2006, Tom Byers, Faculty Director of
Stanford Technology Ventures Program, described it as "still the bible for entrepreneurial marketing 15
years later". This success resulted in several follow-up books and a consulting company, The Chasm
Group.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Figure E.5: Example of Employability Trust Network win-win benefits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Keyword List
1
Architecture, Security, Trust, Privacy
TAS3 ICT-216287
Page 11 of 211
LIST OF FIGURES
2
Architecture Executive Summary
4
This document contains version 1 of the TAS3 architecture. The architecture has been designed in
order to fulfill the following three objectives:
5
i. enable a high level of trust to be built between the various actors (service providers and end users)
3
6
7
8
9
10
11
12
13
14
15
16
17
18
ii. maximize the privacy of user personal information
iii. ensure that all data can be carried securely end to end between users and services.
The above objectives are being fulfilled through a combination of
a. providing users with the ability to meaningfully give their consent to the use of their personal information
b. ensuring a complete set of audit information is recorded by a TAS3 trust network and that users
have the ability to directly or indirectly see the audit information that pertains to their personal
information. Note that there will not be a single central audit log. If an authorized person needs
to drill down into the distributed audit trail, he will need to obtain permission in order to access the
various local audit logs in order to correlate the events and see the "big picture".
c. a legal framework and set of model contracts that will contractually bind all service providers into
operating in a trustworthy manner e.g. so as to honour the choices of users concerning the handling
of their personal information
20
d. a set of trusted third parties that facilitate the sharing of trust related information such as public
keys, authorization attributes, and reputation information
21
e. strong cryptographic algorithms and privacy preserving protocols
19
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
f. sticky policies that cryptographically bind data and policies together, along with a policy enforcement infrastructure that controls access to all resources.
This architecture document describes the conceptual entities that are needed and the services they
should provide in order to operate a TAS3 trust network. These trust and privacy enhancing services
include: authorization services, secure business process management services, delegation services,
privacy preserving discovery services, identity management services, secure repository services and
trust and reputation services. All of these services are usually needed regardless of the applications
that might run in a TAS3 trust network. However, small centralized trust networks may be able to
dispense with one or more of these trust and privacy enhancing services, e.g. discovery or delegation
services, depending upon their requirements.
The TAS3 architecture is designed to be standards and protocol agnostic so that any protocol capable of implementing the flows and satisfying the service requirements can potentially be used. Annex
A maps these services onto the latest state of the art protocols as far as is currently possible. This is
to ensure interworking between the prototypes that will be developed in this project. Further standardization effort will be needed in order to fully complete this mapping and this will be documented in a
future version of this architecture (or in other TAS3 deliverables).
Annex B shows an example deployment architecture that maximizes a service’s availability and is
resilient to both system and network failures.
TAS3 ICT-216287
Page 12 of 211
LIST OF FIGURES
40
41
42
43
44
45
Annex C states the compliance requirements for participants in a TAS3 trust network. Legal, policy
and technical compliance requirements are covered.
Annex D provides a set of use cases which allows the reader to see how an end user might use the
services of a TAS3 trust network.
Annex E contains the first version of a business model that could be used to successfully operate a
TAS3 trust network
46
Annex F summarizes the threats that the TAS3 architecture is designed to protect against
47
Annex G lists the events that should be captured in the secure audit trails of a TAS3 trust network
48
Annex H gives some example protocol messages based on the mapping provided in Annex A
49
Annex I provides a glossary of terms
50
51
52
53
54
55
IMPORTANT NOTE. The TAS3 project has a narrower scope than the architecture that is documented here. This is natural as the novel research contributions of TAS3 are being made only in
some areas of the architecture. However the full architecture needs to be documented as this will
be needed both to successfully test the research results and to provide a production service. We
present a comprehensive architecture that addresses actual use cases end-to-end, rather than simply
an architecture of the services that are within the scope of our research.
TAS3 ICT-216287
Page 13 of 211
56
57
1 Introduction
58
1.1
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
TAS3 Architecture at Glance
The TAS3 architecture provides the high level design of an infrastructure intended to provide the next
generation of trust & security eco-systems that can (1) meet the requirements of complex and highly
versatile business processes, (2) enable the dynamic user-centric management of policies and (3)
ensure end-to-end secure transmission of personal information and user-controlled attributes between
heterogeneous, context dependent and continuously changing systems.
The trusted architecture is built on three foundations: technical, policy and legal.
The technical architecture, introduced and described at a high level in this document, presents the
different services that are needed in order to operate a trust network (or eco-system). Other work
package deliverables provide more detailed designs of some of these services.
The technical architecture proposes a number of Policy Decision Points (PDPs) that are services
capable of evaluating policies of various kinds and returning policy decisions to their callers - the
Policy Enforcement Points (PEPs). The correct enforcement of user’s policies engenders trust in a
network. Many policies in a TAS3 trust network will be sticky policies, meaning that the policy and
the data to which it pertains, are cryptographically bound together, thereby ensuring that the policy is
always there to be correctly enforced. Various types of policy and PDP are envisaged, trust PDPs,
privacy PDPs, authorisation PDPs, delegation PDPs etc. Details of these PDPs and the policies they
support will be provided in more detail in other workpackage deliverables e.g. from WP4, WP5, and
WP7.
The legal framework and set of model contracts will be further developed in WP6. They are being
designed to contractually bind all the service providers into operating in a trustworthy manner, for
example, so as to honour all the choices of users concerning the handling of their personal information.
As many trust enabling factors as possible will be built into the technical infrastructure described in this
deliverable, thereby automating the controls and freeing organisations from the worry and overhead
of ensuring that they do the right thing. When it is not possible to engender trust through technical
controls alone, then legal controls through our model contracts will be used as the controls of last
resort.
This architecture document describes a service oriented trust network. All the conceptual entities
that are needed to form a trust and privacy preserving secure network operate as service providers
and service consumers, and they collaborate together to provide the security services to end users.
These trust, privacy and security services are application independent and are designed to ensure
that whatever application the user is using, the application and its data are as secure, trustworthy and
privacy preserving as is possible, given the risk assessment and cost constraints of the trust network.
(We accept that absolute security is both technically impossible and financially unaffordable.)
The trust and privacy enhancing services offered by TAS3 include:
• authorization services, whose purpose is to answer the question "is this subject authorised to
access this resource in this way"
• authentication services, whose purpose is to identify a subject and validate that the communicating party is indeed the identified subject
• privacy preserving services whose purpose is to provide pseudonymous identities for users and
TAS3 ICT-216287
Page 14 of 211
1.2. METHODOLOGY
minimise the cross linking of identities
98
99
• trust negotiation services whose purpose is to determine if the remote communicating party is
trustworthy enough to start a dialogue
100
101
• secure business process management services whose purpose is to ensure that business processes operate securely, and can be dynamically modified securely
102
103
• delegation services, whose purpose is to delegate credentials from a delegator to a delegate
104
• discovery services, whose purpose is to inform clients where particular services can be found
105
• trusted registries, whose purpose is to keep a directory of all services in the trust network who
are known to provide services conforming to the TAS3 specifications
106
107
• attribute authorities whose purpose is to assert that particular users have particular attributes
108
• identity management services, which are a combination of an authentication service and an
attribute authority
109
110
• secure repository services, whose purpose is to store users’ personal data securely and give
112
users complete control over who should access their data and how they should handle it once
they are given access to it
113
• trust and reputation services, whose purpose is to answer the question "how trustworthy is this
111
actor (service provider or end user)"
114
115
• secure audit services whose purpose is to keep a tamper resistant record of transactions within
the trust network so that legally admissible evidence can be obtained in the case of a dispute.
116
117
118
119
120
All of these services are usually needed regardless of the applications that might run in a TAS3
trust network. However, small centralized trust networks may be able to dispense with one or more
of these trust and privacy enhancing services, e.g. discovery or delegation services, depending upon
their requirements.
128
The TAS3 architecture is designed to be standards and protocol agnostic so that any protocol capable of implementing the message flows and service requirements of the conceptual service providers
can potentially be used by any application. However, in order to ensure interworking between the
prototypes being developed in this project, we have had to choose a subset of current state of the art
protocols. Annex A maps (some of) our services onto the latest state of the art application independent
protocols as far as is currently possible. Further standardization effort will be needed in order to fully
complete this mapping and this will be documented in a future version of this architecture (or in other
TAS3 deliverables).
129
1.2
121
122
123
124
125
126
127
130
131
132
133
Methodology
In presenting the architecture, we follow FMC (Fundamental Modeling Concepts) [FMC03] methodology for presenting the high level static structure. For flow diagrams we use a mixture of UML [UML2]
sequence diagrams and ad-hoc "white boards". The richness of the latter allow us to better convey
relevant control flow and dataflow aspects simultaneously.
TAS3 ICT-216287
Page 15 of 211
1.3. NORMATIVE CLAIM
134
135
136
137
138
139
For more detailed descriptions we use UML [UML2] modelling, with occasional ad-hoc diagrams to
clarify aspects that are not easily communicated using formalisms.
While we usually define, inline, the terminology we use, the authorative definitions are in [TAS3GLOS]
reproduced in Annex I. All architecture documents use this same Glossary and it will not be duplicated
in the individual documents.
The stakeholders in context of TAS3 Architecture are
140
• Users accessing their own data
141
• Professionals working on data of others
142
• Service Providers, TTP Operators, and Trust Guarantor (jointly Deployers)
143
• Security Officers
144
• Implementers
145
• TAS3 Members
146
• Policy Makers
147
• EC Framework Program 7.
148
149
150
151
152
153
The TAS3 mandate is to build secure, trustworthy, and user-centric technology ([TAS3DOW] section
B.0 "Summary"), thus we have adopted methodology where every composition and flow includes a
User facet. Most of the flows are viewed from the User perspective and the business and regulatory
aspects are filled in from this perspective. Given that gaining trust of the Users is fundamental to wide
spread adoption, we have opted to emphasize security, transparency, privacy, and user control when
trading off efficiency and simplicity.
156
This document has two goals: (1) Act as an authorative and prescriptive definition of the TAS3
architecture, and (2) communicate the architecture to the stakeholders, especially Deployers and Implementers. The latter goal is much in line with "Architect as Communicator" in Fig-1 of [FMC03].
157
1.3
154
155
158
159
160
161
162
163
164
165
166
167
168
169
170
Normative Claim
This document describes the TAS3 Architecture version 1 in a normative and prescriptive way. Any
implementation or deployment claiming "TAS3 compliance" MUST abide by this document as well
as Annex A "Protocols", and Annex C "Compliance". A deployment usually has to satisfy additional
requirements of the Trust Guarantor’s Governance or Consortium Agreement and certification procedures, some of which concern the software implementation and others the organizational properties.
Use of TAS3 Brand is governed by a separate TAS3 Brand Agreement.
This document uses the keywords (MUST, SHOULD, etc.) of [RFC2119]. All text is normative unless
expressly identified as non-normative. Prose and specification have precedence over examples, which
in absence of normative text, should be considered RECOMMENDATIONS. Examples as used in the
documents are illustrative of the application of the relevant principles contained in the documents and
are not statements of principles.
This architecture, and related documents are copyrighted works of TAS3 Consortium members, as
identified and dated. All Rights Reserved. This architecture, and related documents, are versioned
TAS3 ICT-216287
Page 16 of 211
1.4. REVIEW OF PREVIOUS WORK
173
and subject to change without notice. No warranty or guarantee is given. This architecture, and related
specifications can be implemented on Royalty Free terms by anyone. However, no warranty regarding
IPR infringement is given. For further details, please see [TAS3CONSOAGMT].
174
1.4
171
172
175
176
177
178
179
180
181
182
183
184
185
186
187
188
Review of Previous Work
TAS3 extends the State of the Art, as established by Identity Web Services Framework [IDWSF08],
[HafnerBreu09], the Nessi Reference Architecture [NexofRA09], and Access-eGov Platform Architecture [AeGArch07]. [IDWSF08] includes a high level view, derived from documented requirements, and
a low level implementable profile of various specifications backed up by interoperability and certification programs that verify interoperability in real life. [NexofRA09] only provides high level view and does
not address identity issues (they even use term "federation" inaccurately, liable to cause confusion with
Identity Federations) or interoperable protocol profiles - the definition of NEXOF Compliant Platform
(NCP) is too vague and there are no interoperability or certification programs - [NexofRA09] fails to
recognize clear prior art in [IDWSF08]. TAS3 extends the State of the Art by combining the web service, or SOA, framework with comprehensive authorization and trust management system, modelling
domain, compliance validation (i.e. interoperability), and legal framework - in a whole that is concretely
implementable. TAS3 addresses Long lifetime, Different Owners, and heterogenous IT environment
concerns listed in [NexofRA09], Section 3.3. NexofRA discovery does not address discovery indexed
by identity, though it does address discoverability by developers, which may be important for adoption.
194
[AeGArch07] architecture does not specify any concrete and interoperable implementation profile
and its security details are vague. Never-the-less, they mention (but do not normatively reference)
SAML SSO (no version), and WS-Security (no specific version or profile). They do recognize need for
registry and discovery function, but do not discuss the interesting parts. Overall it appeared that their
main ambition is not in architecture. They overviewed existing art and picked SOA and applied it to
their problem domain using existing concepts without details research in the architecture area.
195
They use WSMO (http://www.wsmo.org/) based WSMX (Web Services Execution Environment).
189
190
191
192
193
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
The Web Service Modeling Ontology (WSMO) aims at describing Web Services in a machine understandable format, and thus enabling the automatic discovery, selection and composition of Web Service. As a result, WSMO provides a semantic to allow multiple organisations to cooperate for the completion of a service. For example, the Accredetation of Prior Learning APL process [TAS3D91PilotUC]
requires multiple organisation to be contacted to build the portfolio of a candidate. WSMO is divided in
four core components; namely ontologies, web services, goals, and mediators. The ontology element
provides a syntax to describe ontological entities (e.g. concept, relation, axiom), which can then be
used to represent the semantic of a domain of discourse. In other words, the ontology provides a common conceptualisation of the domain used the other WSMO components. The web service element
semantically defines every aspect relevant to web services, such as functionalities and interfaces. For
example, the functionality of a web service is expressed in terms of its capabilities and of the pre- and
post-conditions associated to them. The goal element specifies the users’ objectives to be fulfilled by
the execution of one or more web services. Finally, the mediator element establishes interoperability
between mismatched resources. For example, it resolves mismatches in heterogeneous ontologies by
finding mappings between their respective ontological entities.
TAS3 ICT-216287
Page 17 of 211
1.5. READER’S GUIDE
211
1.5
212
This document conforms to the TAS3 project-wide glossary [TAS3GLOS] reproduced in Annex I.
213
214
215
216
217
218
219
220
221
222
223
Reader’s Guide
If you are a nontechnical reader, skimming this document and perhaps consulting Figs 2.1 and
2.2 may be useful. You should also consult [TAS3BIZ], reproduced in Annex E "Business Model",
which gives a good motivation for the work shown here. You may also find [TAS3WP] and web site
www.tas3.eu helpful in understanding the overall TAS3 concept.
If you are a researcher, this document is the right place to start to see where your research may fit
within the architecture.
If you are a software developer you will want to read this document, but you will also want to read
carefully Annex A "Protocols", which details protocol versions and gives suggestions about available
open source packages that implement these protocols.
If you are a deployer, you should skim this document, perhaps look at Annex A "Protocols", and then
work through Annex C "Compliance" as you prepare for your TAS3 certification.
TAS3 ICT-216287
Page 18 of 211
224
225
2 TAS3 High Level Architecture
226
2.1
227
228
229
230
231
232
233
234
235
236
237
238
239
240
Overview
Basic security measures. Secure encryption, message digest, and digital signature
algorithms are used through out where applicable. All Users and System Entities are
authenticated to appropriate degree. For the latter this means PKI authentication, but for
the former anything from passwords to hardware tokens is possible. The details of these
algorithms are not repeated here, but are covered in Annex A "Protocols" and Annex C
"Compliance".
The TAS3 Architecture is a reusable overarching design that can be instantiated any number of times.
It specifies a Trust Network (TN) and the manner in which the players, including Users and Service
Providers, interact in the Trust Network. The TN may be composed of several organizations, mainly
Service Providers (SPs), each of which may constitute a subnetwork and may participate in several
other Trust Networks. The architecture addresses interaction of the subnetworks with each other
and the top level Trust Networks. We also foresee multiple Trust Networks coexisting and interacting
to various degrees. An organization can simultaneously belong to multiple TNs as long as it can
simultaneously satisfy the requirements of each network.
TAS3 Trust Network Domains
Audit
Organization A Domains
...
Organization B Domains
Audit & Monitor
Modelling &
configuration
Management
Model
Modelling &
configuration
Management
Runtime &
Enforcement
Figure 2.1: Using TAS3 top level model to start modelling of organizations that participate in Trust Network.
241
Each Trust Network works in the legal context defined by its Governance Agreement. This architecTAS3 ICT-216287
Page 19 of 211
2.2. BASIC ARCHITECTURAL ENTITIES
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
ture specifies some functions that are strictly necessary for protocol flows to work, and other functions
that are necessary to satisfy nonfunctional properties like "secure" and "trustworthy". To impose on
the players that the latter functions are implemented as well, we rely on legal obligation that stems
from the Governance Agreement, as well as certification and audit programs, operated by the Trust
Guarantor, to check that the legal obligations are met initially and on continued basis.
TAS3 Trust Network Domain. Consider Fig-2.1 where a Trust Network (TN), has chosen to adopt
the overall TAS3 approach (which this and other documents specify). This means that at the "Summit"
there is a Trust Guarantor (TG) who imposes on the TN the rules and model of operation. TG usually
employs a Security Officer to maintain and enforce the model. The individual organizations may also
have Security Officers responsible for their internal modelling and auditing.
Model. The Trust Network Domain configuration will be expressed using business process models,
ontologies, and other models. The models are refined by each organization in their Modelling and Configuration Management. There will be several ontologies: architectural roles (e.g. Service Requester,
Services Provider, Identity Provider), security ontology, privacy and data protection ontology and trust
ontology. Payload services may define application specific ontologies, but they are not in scope of the
TAS3 architecture. Ontologies in TAS3 are further discussed in [TAS3D22UPONTO]. Some mandatory policies emanating from EU will be modelled by the TAS3 project and incorporated to every TAS3
Compliant Trust Network Model (Req. D1.2-6.15-MinPolicy ).
Audit and Oversight. The Trust Guarantor in its oversight role will operate compliance validation
and audit functions. Each organization is expect to operate similar functions locally as Audit & Monitor.
The audit trail stays principally within the organization, with Trust Guarantor only seeing pointers.
There are some networkwide reporting and auditing requirements that guarantee that other parties in
the network, and especially users, have enough transparency to operation of each party. This helps
to transparently understand that what has happened is legitimate, prevent fraud, and increase overall
trust in the network - a key business goal of TAS3 .
Runtime and Enforcement conserns delivering the useful payload services, with appropriate mechanisms to authenticate and identify Users and Systems, as well as authorize the operations. Most of
technical realization of TAS3 happens in this area.
272
Cross Domain and Cross Context. TAS3 Architecture expressly enables operation of services
across domains. This can mean several organizations in one Trust Network, or it could even mean
interworking of several Trust Networks.
273
2.2
274
In this section we drill down in the static component view of TAS3 architecture.
275
2.2.1 Major Components
270
271
276
277
278
279
280
281
282
Basic Architectural Entities
Our architecture, see Fig-2.2 starts with User interacting with the Runtime & Enforcement area. Since
TAS3 architecture is user centric, all action starts directly or indirectly with the User. Even offline,
user-not-present, processes are seen to have been authorized by the User at some earlier time.
In the Runtime area, the User will interact with Payload services to obtain the tangible business
benefits that motivated him to use the services in the first place. However, for the Payload to work in
secure and trustworthy manner, services from Infrastructure and Discovery areas are needed. For the
system as a whole to remain secure and trusted, functions in the Audit and Monitor area are needed.
TAS3 ICT-216287
Page 20 of 211
R
Client
Application
Web Browser
R
Organization Domain
Modelling &
Configuration
Management
Runtime & Enforcement
Infrastructure
Payload
Front End
Services
Identity Provider
Authorization
Dashboard
Web Services
Business process
Engine
Delegation
Discovery
Dashboard
Trust Reputation
Trust Network
Process Manager
Audit
IDMapper
Registry Server
Linking
Trust & Privacy
Negociator
Event Bus
Management
R
R
R
Audit &
Monitor
Audit
Compliance Validation
Operation Monitoring
Figure 2.2: Major components of Organization Domain.
283
284
285
286
287
288
289
290
291
292
293
294
They will receive their input through Audit Event Bus of the Runtime environment.
Front End Service. User’s principal point of interaction with the system is a GUI, most commonly a
Web GUI. This is a special kind of Service Provider that instead of speaking Web Services, e.g. SOAP,
offers a user friendly interface. The Front End Services often call Web Services to perform all or parts
of the functionality they provide. It is possible that the GUI is generated to match a Business Process
Model.
Web Service. Machine accessible endpoint from which data or action services can be obtained.
Machine-to-machine nature of Web Services is in contrast with the user-to-machine nature of the
Front End Services.
The exact sequence of Web Services called will depend on a business process, whether expressly
modelled or implicit to the design of the web services. A business process can encompass several
Front Ends and the Web Services they call.
301
Business Process Engine is an orchestrating entity that controls how Front Ends and Service
Providers, often Web Services, work together to achieve the objectives of the business process. It
is depicted here as being a separate service, but "in process" realizations are equally likely. In such
case the Business Process Engine would be inside the Front End Service, perhaps as linked in library.
The role of the Business Process Engine is to serve payload business processes. There is a similar
Trust Network Process Manager entity that, while technically similar, will exclusively execute business
processes critical to the TN itself.
302
Dashboard is an important auditing and trust building feature of the TAS3 Architecture. It is a user
295
296
297
298
299
300
TAS3 ICT-216287
Page 21 of 211
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
interface, a Web GUI, that allows the User to understand and audit how the system as a whole uses his
Personally Identifiable Information (PII). The Dashboard may also integrate a user interaction facility,
PII Consent Service, for asking users consent or other input that is required for a business process to
advance. All these features provide transparency. (Reqs. D1.2-2.11-Transp, D1.2-3.3-Dash, D1.2-6.3WhatHowWhyWho, and D1.2-12.15-Valid)
Identity Provider is the point where Users actually authenticate to the system. After authentication,
the IdP issues a Single Sign-On (SSO) token so that the Front End Service can complete the login
process. IdP has also an important role in providing Id Mapper bootstrap token for the User.
Authorization. This box actually represents an entire subcontinent of functionality. Authorization is
pervasive in TAS3 architecture. This topic is treated in more detail in Section 2.2.3.
Delegation provides mechanisms for one User to allow another User to use FE or WS services
on his behalf. Delegation also includes mechanisms for introducing users to one another, such as
invites. In some cases User can be replaced in delegation by a juridical person. In delegation both
the delegator and delegatee may be authenticated indirectly. A situation similar to delegation arises
when User instructs a service to act on his behalf. In this case the delegatee is a system entity, usually
a Service Provider, and is authenticated directly. The act-on-behalf delegation is handled by the ID
Mapper component. (Req. D1.2-7.1-Deleg)
Trust Reputation encompasses a number of components that deal with gathering reputation data,
usually via Audit Event Bus, and computing trust scorings that are then used in Authorization and
Trust and Privacy Negotiator components. The trust and reputation system is also used to detect
certain classes of fraud (Req. D1.2-7.21-Safe).The architecture and design of this subsystem is further
elaborated in WP5 deliverables.
Trust Network Process Manager. There are many maintenance processes that a trust network
must realize in order to work dynamically and react to threats rapidly. These include intake process
for users (Req. D1.2-6.1-IntakePers), intake and certification process for organizations (Req. D1.26.2-IntakeOrg), and user’s access to his own data and audit trail (Req. D1.2-6.8-UserAccess). The
application specific business processes belong to Business Process Engine, above.
Id Mapper is used to translate User’s IM token (Id Mapper bootstrap token) to a token usable for
Web Service that is about to be called. Such translation is necessary as the user is known by different
pseudonym at different services. This is used to express act-on-behalf relationships where Service
Provider (delegatee) wields a token provided by Id Mapper (or in some cases by IdP). (Req. D1.2-2.3BMs)
Registry Server contains knowledge about which end point serves which type of service for any
given User. Typically Registry is queried as a preparatory step of web service call proper, but it could
be queried in advance. (Req. D1.2-2.3-BMs)
Linking Service provides a facility for a user to indicate how he wishes his attributes to be aggregated.
Trust and Privacy Negotiator. This is the server side of the negotiation. Every Service Requester,
such as Front End Service, must implement Trust and Privacy Negotiator Client (not shown in the
figure). Trust and Privacy Negotiator functions in many ways similar to the registry, but instead of
returning all end points, only some are returned based on trust scoring.
Modelling and Configuration Management is connected to the TN level modelling. It also contains
local ontologies, such as trust and privacy ontologies, and local Models and Configurations. All of
these may be edited using Modelling Tools. From Models and Ontologies, configuration items can
be generated and pushed to the Runtime using Management Event Bus, as governed by the Trust
TAS3 ICT-216287
Page 22 of 211
348
349
350
351
352
353
354
355
356
Network Process Manager.
An essential element of this architecture are community-managed ontologies (Model in Fig-2.2),
which allows for unambiguous, but flexible, meaning agreement at all times. We can envisage several
roles for these ontologies. It first provides a machine-understandable documentation of the architecture as well as a formal vehicle to exchange explicit semantic agreements (i.e. commitments) between
partners and, eventually, systems. Thus, these commitments will enable the enforcement of (organisational and/or legal) policies within the TAS3 architecture. For example in Role-Based Access Control
(RBAC), the role of a subject need to be provided with some semantics (e.g. a list of attributes) to be
able to enforce authorization based on the privileges assigned to that role.
364
Secondly, the ontologies will assure that relevant parts of the system commit to the same interpretation of possibly ambiguous elements to allow for meaning alignment, certification and early conflict
discovery. These ontologies will enable improved understanding; common methods of expressing
terms enabling people and organisations to better trust each other in these application environments.
TAS3 will integrate these architecture elements into a fully embedded trust framework to automate
business processes managing personal information, which will result in considerable societal benefits.
The Semantic Interoperability Engine (Fig-3.15) will facilitate the interoperability across different contexts (e.g. across different organizations). Ontologies are further discussed in [TAS3D22UPONTO].
365
2.2.2 Enforcement Points on Web Service Call Path
357
358
359
360
361
362
363
Front End Service
Legend
Infrastructure
Authorization
Web Service
Web Application
Service Application
R
R
R
R
R
PEP Out
R
Web
GUI
PEP In
R
PEP Out
PEP In
(optional)
R
R
R
Stack
Service Requester
Stack
Service Responder
Service Requester
Figure 2.3: Front End calls Web Service, passing through 4 enforcement points.
TAS3 ICT-216287
Page 23 of 211
366
367
368
369
370
371
372
Considering Fig-2.3, a Front End (FE) is composed of a Web GUI, a Web Application (the payload
of the front end), and a Service Requester module which is used to call Web Services. The counter
part of the Service Requester is the Service Responder module of the Web Service.
Service Requester is a software module that encapsulates the mechanics of performing a Web
Service call. An implementation of the Service Requester module will be provided as a deliverable of
the TAS3 Project. However, it is possible to implement this independently as long as all requirements
prescribed here are maintained.
376
Service Responder is a software module that encapsulates the mechanics of accepting a Web
Service call and responding to it. An implementation of the Service Responder module will be provided
as a deliverable of the TAS3 Project. However, it is possible to implement this independently as long
as all requirements prescribed here are maintained.
377
Traffic Lights
373
374
375
378
379
380
381
382
383
384
385
386
387
388
PEPOut-Rq. Service Requester Outbound Policy Enforcement Point (PEP). This PEP is used to
check whether data can be submitted to the Web Service, or whether the call can be made at all. The
PEP will contact organization’s Master PDP to obtain a policy decision.
PEPIn-Rs. Service Responder Inbound PEP. This PEP is used to check whether data or call can be
accepted by the Web Service.
PEPOut-Rs. Service Responder Outbound PEP. This PEP is used to filter the data on responder
side and to perform any responder obligations attached to the data. If no data can be returned, an
error response will still be returned.
PEPIn-Rq. Service Requester Inbound PEP. This PEP is used to perform any obligations attached
to the response.
Recursive Call
393
As shown in Fig-2.4, it is possible to chain web services calls, such that the application layer of
upstream server may invoke as client a down stream service. There is no difference whether the
Service Requester module resides in right hand side of a Front End or a Web Service, turned into
Web Services Client (WSC). This pattern can be repeated in any tree topology to any depth of call however in practical implementation the call depth MAY be limited to 7 to avoid infinite recursion.
394
2.2.3 Authorization Subcontinent
389
390
391
392
395
396
397
398
399
400
401
402
403
404
405
406
407
408
Authorization is everywhere in TAS3 Architecture. It often gets rolled up in small, but very meaningful
symbol in the architecture. This is why we call authorization a "subcontinent" unto itself. It is described
more fully in [TAS3D71IdMAnAz]. This section addresses Reqs. D1.2-2.19-AzCredi, D1.2-2.20-Az,
D1.2-4.5-ComplyPolicy, D1.2-4.6-BrkGlass, D1.2-6.4-Min, D1.2-7.6-Az.
Fig-2.5 depicts some of the components involved in the authorization. By far the most common
case is that some payload service, such as a Front End or Web Service, needs to get an authorization
decision and initiates the subflow.
Policy Enforcement Point (PEP). This is a software module usually built into the payload service.
There are four fundamental types of PEP, as shown in Fig-2.3: in and out variants on Service Requester and Service Responder sides.
Master Policy Decision Point (Master PDP). The PEP calls Master PDP to obtain the authorization
decision. Typically each oranization will run a Master PDP (though other arrangements are possible).
All logic of the authorization decision is masked behind the Master PDP. Thus the exact implementation
details of Policy Decision Point Stack are irrelevant for the PEPs. The MastePDP handles coordination
TAS3 ICT-216287
Page 24 of 211
Web Service
Front End Service
Web Application
Web Service
Service Application
R
Data Service
R
R
R
R
R
Web
GUI
Service Requester
Service
Responder
Service
Requester
Service
Responder
Data
storage
Figure 2.4: Recursive Web Service calls.
409
410
411
412
413
414
415
416
417
418
419
420
421
422
and routing of requests to the PDPs in the stack and aggregates the authorization decisions received
from the PDP. In a way it can be viewed as a PDP proxy with some smarts in it.
The Master PDP is responsible for arranging Break-the-Glass Authorization, see Section 3.5 and
[TAS3D71IdMAnAz].
Trust Network PDP processes the policies that are coordinated at the Trust Network level. It can
be implemented as a central Trust Network-wide service, or it can be distributed so that there is an
instance of a Trust Network PDP at each SP, but the policies are centrally coordinated and pushed to
the instances, perhaps using the Trust Network Process Manager.
Organization PDP processes the policies that an organization maintains. These policies may be
over and above the the Trust Network-wide policies. The distinction from Trust Network PDP is maintained because the authority for deciding the policies is different.
User PDP function may implement User specific policies, i.e. policies set by the User. This could
also involve evaluation of Sticky Policies. In practise, the User PDP may be implemented inside the
Master PDP process.
427
Trust PDP is an interface to the Trust and Reputation Management subsystem which allows the
Master PDP to query whether a contemplated action is acceptable from Trust and Reputation perspective. Such query has the advantage that the Trust and Reputation system does not need to
disclose to the Master PDP the exact parameters that lead to this decision. The deliverables of WP5
will elaborate on structure and design of Trust PDP and Trust and Reputation System at large.
428
Credential Validation Service (CVS) is a subsystem that helps PEP to establish the validity of the
423
424
425
426
TAS3 ICT-216287
Page 25 of 211
2.3. MAJOR FLOWS: FRONT CHANNEL AND BACK CHANNEL
Dashboard
Payload
R
R
Discovery
R
Infrastructure
Authorization
Policy Enforcement
Point
R
R
Credential validation
service
R
Master
Policy Decision Point
R
Policy Information
Point
Infrastructure
Policy Decision Point Stack
Trust Network Organization
PDP
PDP
Policy
Store
Policy
Store
User
PDP
Trust
PDP
Policy
Store
Trust
Store
Figure 2.5: Authorization.
429
430
431
432
433
credentials and attributes it is about to pass to the Master PDP. Typically these are received from front
channel interaction or from an earlier web service call. The validation involves checking that they are
properly signed and that PKI trust to the signing authority exists. Some namespace and syntax checks
may be performed as well. The CVS may call on other components of the architecture to perform its
functions.
440
Policy Information Point (PIP) is used to fetch additional attributes that may be needed for policy
evaluation. PIP may call, in a recursive manner, on other components of the architecture to perform
its functions. Special care needs to be taken in preventing infinite recursion and to ensure that the
policies in the recursive levels allow the information to be returned for purpose of policy evaluation.
PIP may be called either from PEP or from Master PDP. Exact choice is a question of optimization.
The set of attributes needed for policy evaluation is difficult to determine. This is a research problem
we hope to solve.
441
2.3
434
435
436
437
438
439
442
443
444
445
446
Major Flows: Front Channel and Back Channel
Implementable Flows. The flows we present are designed to be implementable with
existing state-of-the-art protocols and software stacks. In particular standards based approaches are used for authentication, delegation, token passing, identity mapping, service
discovery, authorization, and web services calls. Despite this, the present high level architecture is designed to be standards agnostic so that any protocol capable of implementing
TAS3 ICT-216287
Page 26 of 211
2.3. MAJOR FLOWS: FRONT CHANNEL AND BACK CHANNEL
447
448
the flows and satisfying the requirements can potentially be used. See Annex A "Protocols" for details.
1
TAS3 TN Model
2, 4
Authentication
3
Front Channel, Web GUI Interaction
Modelling
Runtime
Modelling
Az
DashB
FE A1
IdP B
Re B
Back Channel
Web Services
Layer
Az
6
5
Az
IDMap
WS B1
Az
7, 9
8
10
Az
Az
WS A2
WS B2
Audit & Monitor
Audit & Monitor
Org B
Org A
(Context A)
TAS3 TN Compliance, Audit, and Monitor
(Context B)
Figure 2.6: Front Channel and Back Channel Flows (the numbering indicates typical sequence of events).
449
450
451
452
453
454
455
456
457
458
459
460
From Fig-2.6 we can identify certain important principles (the authorization process is depicted in
summary form as box "Az" to reduce clutter, see Section 2.5 for full description):
1. There can be any number of organizations in the Trust Network and each of these organizations
may run a number of web sites (labelled as FE - Front End in the figure), Web Services (WS), and
infrastructure services (sometimes called Trusted Third Parties).
2. Some architectural roles, like Identity Provider (IdP) can usefully be operated by several organizations in a Trust Network. The important point is that all the components are part of the model of the
Trust Network and subject to its oversight.
3. Users will use their "home" IdP (e.g. IdP provided by their employer or educational institution) for
Single Sign-On (SSO), but this does not prevent them from using web sites (labelled as FE - Front
End in the figure, this is often called "front channel usage" or "user present scenario") of the other
organizations (Req. 3.1 from D1.4), subject to access control decisions, of course.
TAS3 ICT-216287
Page 27 of 211
2.4. OVERVIEW OF DATA MODELS
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
4. The usage of a web site often triggers Web Services calls on the back channel. Finding out exactly
which servers to contact and what credentials to use is handled by User’s Discovery and ID Mapper
services ("IDMap" in the Fig-2.6) (Req. 8.1 from D1.4). Usually the Discovery Service is rather
tightly coupled to the IdP.
5. It is feasible and common that Web Services can be called across organizational boundaries. Discovery and trust negotiation within the model set by the Trust Network will enable this to be possible.
6. When auditable events happen, in addition to local logging, a summary of the data is sent to the
Audit Event Bus. Subscribed to the audit summaries are: (i) User’s Dashboard service so that the
User can always see what happened and is in control; and (ii) the organizational and Trust Network
audit layers. See blue arrows in Fig-2.7.
7. Although all organizations can potentially have all components, the fact that cross organization
web site usage and service calls are explicitly provided for, makes it possible for an organization
to outsource some, or all, of these services. Or the other way around, some organization may
specialize in only providing the infrastructure services. This approach is often desirable to manage
conflicts of interest.
478
This is a very flexible architecture and allows the responsibility for provision of services and infrastructure to be sliced and diced in many ways, according to business needs rather than technical
limitations.
479
2.4
480
2.4.1 Federation Relations for Core Security Architecture
476
477
481
482
483
484
485
486
487
488
489
Overview of Data Models
N.B. On first reading it may be advisable to skip this section as understanding of flows
shown in Fig-3.4 will be useful.
One of the fundamental principles of the Core Security Architecture is use of federations, which may
support persistent or transient identifiers. When correctly used, these types of identifiers allow privacy
to be preserved by not leaking any correlation handles. This section addresses Reqs. D1.2-2.14-Priv,
D1.2-7.8-NoColl, and D1.2-7.16-Nym.
In order to implement persistent and pseudonymous federations, the IdP and IM have to keep state.
In general, the federation table for an IdP that supports persistent pseudonymous identifiers will hold
mappings as follows:
493
User at IdP1 --> [ encrypted pseudonym of user at SPA,
encrypted pseudonym of user at SPB,
...
encrypted pseudonym of user at SPN ]
494
The federation table for IM needs similar mappings
490
491
492
495
496
497
498
User’s pseudonym at IM --> [ encrypted pseudonym of user at SPA,
encrypted pseudonym of user at SPB,
...
encrypted pseudonym of user at SPN ]
TAS3 ICT-216287
Page 28 of 211
2.4. OVERVIEW OF DATA MODELS
1
TAS3 TN Model
2, 4
Authentication
3
Modelling
Runtime
Modelling
Az
e4
DashB
FE A1
Az
Audit
Event
Bus
IdP B
Re B
Back Channel
Web Services
Layer
e5
e3
6
5
e6
Az
e7,
e9
IDMap
WS B1
Az
7, 9
e10
10
Az
WS A2
WS B2
Audit & Monitor
LogMon
Audit & Monitor
Org B
Org A
(Context A)
8
e8
Az
(Context B)
Figure 2.7: Audit Event Bus (the numbering indicates typical sequence of events, the e-numbers indicate audit
events)
499
500
501
502
503
504
505
506
507
508
509
510
511
512
The IdP and IM may include attribute data in the tokens they emit. This attribute data can be kept in
any suitable data structure, usually indexed by user and sometimes by SP, or both.
The IM needs additional data structure to determine what services are available to a User. In its
simplest form this would consist of
User’s pseudonym
---------------789IM
789IM
579IM
579IM
Service Type
-----------Role Author.
HR Authority
Role Author.
HR Authority
SP EntityID
------------C.example.com
B.example.com
C.example.com
B.example.com
but other more general realizations can include data needed for Trust and Privacy Negotiation phase
of Discovery. These will be explored in the Trust and Privacy Negotiation documentation.
An IdP may have a limited form of this table to cover the necessity of emitting IM bootstrap token
during SSO.
TAS3 ICT-216287
Page 29 of 211
2.5. AUTHORIZATION PROCESS
513
514
515
516
All parties - IdP, IM, and SP (FE or WS) - need to maintain some metadata about each other. Such
metadata may include SOAP endpoints, protocol profiles and bindings to use, etc. These will generally
be specified in protocol specific documents as adopted in Annex A "Protocols", but for general idea
the reader may want to see [SAML2meta].
519
There is also the requirement for a user to be able to aggregate his attributes together in order to
gain access to web services. This requires an attribute linking service, which is fully described in
[TAS3D71IdMAnAz].
520
2.4.2 Personal Data and Applications
517
518
521
522
523
524
A SP can use whatever data model it desires (TAS3 Architecture is not prescriptive in this regard) in
storing the data about the Users as long as it meets security and privacy guarantees detailed in Annex
C "Compliance". The persistent pseudonym of the User suggests an obvious database key, but other
arrangements are possible.
528
TAS3 Architecture foresees aggregation of data from multiple sources with its support for policy
aggregation. One common realization of this approach is to consider a document as a collection of
external data streams, please see [TAS3D81RepoSW]. This approach will be supported by some of
the TAS3 software deliverables (e.g. output of WP8).
529
2.4.3 Using Sticky Policies to Protect Data
525
526
527
530
531
532
533
534
Sticky policies can be attached to most data items and are especially foreseen to protect personal
data and control its dissemination. The purpose for which the data was collected is expressed as
sticky policy. This section addresses Reqs. D1.2-2.21-DataProtLaw, D1.2-6.5-Purpose, and D1.24.1-EnfUCPol. Data origin and collection method can also be indicated using sticky policies (Req.
D1.2-6.8-UserAccess).
538
Sticky policies are evaluated as part of the authorization process. They should ideally be bound to
the data they protect by encryption and signing solution that would prevent disclosure of the data unless
the policy evaluates to permit. However, this is a difficult research problem and will be addressed in
other TAS3 deliverables.
539
2.4.4 Using Encryption to Protect Data
535
536
537
542
All protocol flows use encryption. Usually this will be in form of connection level encryption, but in
certain cases application layer public key encryption will be used to protect tokens or attribute data
while it is in transit through an intermediary (e.g. IM token when passing through FE).
543
2.5
544
This section partially addresses Req. D1.2-6.12-Sec.
540
541
545
546
547
548
549
Authorization Process
Fig-2.8 depicts refined structure of the Authorization Process.
1. Central notion is that the Web Service PEP ("=" above the WS1 in the figure) calls a Master PDP,
which then gathers the authorization from whatever sources it can.
2. Some of the data used for the decision may have come from the Web Service itself (it may have
been inline in the Request, or the Web Service may know it otherwise), but if additional data is
TAS3 ICT-216287
Page 30 of 211
2.6. ENFORCEMENT PROCESS
Trust Network level model
Runtime and
Enforcement
Domain
Modelling and
Configuration
Management Domain
=
=
Frontend Services
Dashboard
IdP
*
*
Disco
=
=
WS2
WS1
Master
PDP
Modelling
Tool
*
Trust
PDP
Call
PIP
Models and
configurations
Trust Store
Policy Store
=
= =
Backend WS
Connectors
= Routing &
aggregation
= PEP
*
Audit and Monitoring Domain
=
Figure 2.8: Authorization Process
550
551
552
553
554
555
needed, the Master PDP will contact Policy Information Points (PIPs) as appropriate. (Processing
of PIP request itself is an instance of Enforcement and Authorization Process, thus giving all of this
rather recursive flavour.)
3. Trust and/or Reputation may be a factor in the authorization decision. This is handled by modelling
the Trust and Reputation Provider (labelled as just "Trust" in the figure) as just another PDP that
the Master PDP calls. The feedback and inputs to the Reputation computation are not shown here.
557
4. Given that sticky policies may potentially be written in different policy languages, the Master PDP
will detect the language and call appropriate PDP to have the policy interpreted.
558
2.6
559
This section partially addresses Req. D1.2-6.12-Sec.
556
560
561
562
563
564
565
Enforcement Process
When a Web Services call is made, there are several control points in the flow, as shown in Fig-2.10.
1. Request is first controlled by a Requester, i.e. on Client side, for being an acceptable request.
For example, if the request is about to submit data to the Service Provider, there may be several
policies about what can be submitted.
2. The controls can have multiple facets, i.e. the application programmer may have programmed in
some implicit policies, the organization that operates the application may have some policies of
TAS3 ICT-216287
Page 31 of 211
2.6. ENFORCEMENT PROCESS
Runtime and
Enforcement
Domain
Modelling and
Configuration
Management Domain
=
=
Frontend Services
Dashboard
IdP
*
*
Disco
=
=
WS2
WS1
Master
PDP
Modelling
Tool
*
Potential
direct
configuration
of a PEP
Trust
PDP
Call
PIP
Models and
configurations
Trust Store
Policy Store
Configure PDP
from the model
= =
=
Backend WS
Connectors
= Routing &
aggregation
= PEP
*
=
Figure 2.9: Using model to configure Authorization Process
Client App
Built-in rules of the application
Built-in rules of the service
Rules of the operator
Org D PDP
Org C PDP
Alice
Service
Rules of the operator
Bob
TN PDP
PEP
Rq Out
PEP
Rs Out
Rules of the TN
1
Master
PDP
4
Master
PDP
Trust PDP
2
3
PEP
Rs In
PEP
Rq In
Alice PDP
Personal rules
Corp C Firewall
or Packet Filter
Bob PDP
Personal rules
Corp D Firewall
or Packet Filter
Figure 2.10: Arrangement of enforcement points in web service call flow.
TAS3 ICT-216287
Page 32 of 211
2.7. CONFIGURATION PROCESS
566
567
568
569
570
571
572
573
574
575
576
577
578
579
its own, the Trust Network is certain to have policies, and finally the User himself may have set
up some policies (which may involve attaching sticky policies to the data). Conceptually these are
addressed by a PEP contacting Master PDP which may contact stake holder specific PDPs. If
different stake holder policies result in a conflict, the Master PDP implements a Conflict Resolution
Policy to arrive at a decision. An alternative approach is to use Identity Governance Framework
[IGF] CARML declaration to set up the PEP, or some part of it.
3. After request has been authorized to send, the Service Provider will examine if the request is
acceptable using a similar stack of PEPs. Examination on Service Provider side is the "traditional"
enforcement point that most people think about. It filters out inappropriate data requests as well as
illicit writes.
4. When preparing to ship response, the Service Provider uses a PEP and Master PDP to further filter
the response. Although the request side PEP should have made sure that only legitimate requests
can ever get processed at the Service level, the returned results may still need some scrutiny, or
this facility can be used to attach obligations and sticky policies to the returned data.
583
5. When Client receives the response, it examines it with a PEP and Master PDP. Such examination
may be necessary to understand if there were sticky policies attached, or to perform obligations.
Given the rules under which the Service Provider released the data, it may be that Client finds that
it can not use the data for the intended purpose and therefore has to reject the request.
584
6. Not depicted, but logically part of the Client Request sending side are also
580
581
582
585
a. discovery
586
b. trust negotiation and establishment
587
c. signing of request
588
7. Not depicted, but logically part of the Service Provider Request processing are also
589
a. trust negotiation and establishment
590
b. validation of message structure
591
c. signature validation
592
593
594
8. Not depicted, but logically part of the Service Provider Response sending side are also
a. signing of response
9. Not depicted, but logically part of the Client Response reception side are also
595
a. validation of message structure
596
b. validation of correlation
597
c. signature validation
598
d. processing obligations
TAS3 ICT-216287
Page 33 of 211
2.7. CONFIGURATION PROCESS
TAS3 CoT Model
Modelling and Configuration Management Domain
Runtime and Enforcement Domain
Discover usage
& configuration
Modelling
Tool
IdP
=
=
Frontend Services
Dashboard
=
*
= =
*
Disco
Middletier Web Services
Automatically push
consistent security
configuration
Models and
configurations
=
* *=
=
Backend WS
Use model to drive
visualization of workflow
and system
Auditing &
Compliance
Tools
Operation
Monitoring
Connectors
= Routing &
aggregation
= PEP
*
=
Figure 2.11: Pushing configurations from model.
599
600
601
602
603
604
605
606
2.7
Configuration Process
TAS3 is pervasively model driven. Fig-2.11 shows how a business process model can drive auditing
processes, or even influence the Dashboard user interface so that Users can visualize the processes.
Fig-2.9, shows how models are used to configure policies for the PDPs. It also shows an alternate
approach where PEP itself can be directly configured, e.g. using Identity Governance Framework [IGF]
CARML and/or AAPML.
From the model the Trust Guarantor is able to derive
• Basic trust configuration, i.e. who belongs to the network
607
- a white list of members
608
- metadata to configure trust in the members
609
610
611
612
613
• Configurations to be pushed to operational elements of the network so that they will consistently
enforce the process and trust model and the security model of the Trust Network.
• Operations Monitoring setup, e.g. if alerts are coming from some node, what Networks Operations Centre (NOC) process should they enter, where should they be disseminated, who should
see them, and who is responsible for response
TAS3 ICT-216287
Page 34 of 211
2.8. AUDIT
1
TAS3 TN Model
2, 4
Authentication
3
Modelling
Runtime
Modelling
Az
DashB
FE A1
Back Channel
Web Services
Layer
Az
Model
IdP B
Re B
Model
6
5
Az
IDMap
WS B1
Az
7, 9
8
10
Az
Az
WS A2
WS B2
Audit & Monitor
Audit & Monitor
Org B
Org A
(Context A)
(Context B)
Figure 2.12: Configuration from Model (the numbering indicates typical sequence of events)
614
• On-line compliance testing configuration. This will drive a robot, spider if you like, that will comb
through the Trust Network on a regular basis to verify that each service is in compliance with the
policies that it publicly manifests.
615
616
619
The Organizations A and B participate in the Trust Network. They also model their business processes, extending and refining the global model. They, too, will benefit from ability to automatically
configure and monitor the components of their infrastructure.
620
2.8
617
618
621
622
623
624
625
626
Audit
No central audit log. There will not be any central audit log. Only audit data released
routinely out of an organization or Service Provider are references to audit events and
anonymized summary data. If an audit needs to drill into the audit trail, the authorized
auditor will be given access, upon escalation, to fetch or view the local audit trails and
ability to correlate the events to form a "big picture". Without such authorization correlation
will not be possible. This principle applies to the User’s Dashboard as well.
TAS3 ICT-216287
Page 35 of 211
2.8. AUDIT
627
628
629
The audit domain is essential to maintain the validity of the trust fabric in the infrastructure. The
domain will receive data on authorisation decision as illustrated in Fig-2.13. This enables the domain
to become a central point for monitoring of authorisation processes in individual TAS3 instances.
Runtime and
Enforcement
Domain
Modelling and
Configuration
Management Domain
=
=
Frontend Services
Dashboard
*
IdP
*
=
Discover
actual usage
Disco
=
WS2
WS1
Master
PDP
Modelling
Tool
*
Trust
PDP
Feedback
for
behavioral
trust
Call
PIP
Models and
configurations
Trust Store
Policy Store
=
= =
Backend WS
Connectors
= Routing &
aggregation
= PEP
*
=
Figure 2.13: Auditing an authorization decision.
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
The services in the auditing and monitoring domain will receive other forms of data linked to trust
from the TAS3 infrastructure. This data will also include information on service invocations and workflow execution. The data from the results of these events will be stored in two main sets of services in
the auditing and monitoring domain, there are auditing and compliance tools and operation monitoring
tools.
It is important to note that these two sets of information will be handled quite separately. The
operation monitoring tools will be operated by the applications code and will be application specific,
whereas the auditing and monitoring will be operated by the TAS3 security layer and will be application
independent.
The data collected from the monitoring in the audits can be then used by elements in the infrastructure such as the Dashboard. This will enable users to look at both how their data has been used in
the infrastructure and also if any services have failed in this execution. In cases of failure or rogue
behaviour the negative feedback from this can be fed to the Trust and Reputation service.
Some Audit Principles:
• Nobody should be able to tamper with the audit trail without detection. This includes insertion or
removal of audit records, altering of audit records and deletion of entire audit files.
TAS3 ICT-216287
Page 36 of 211
2.8. AUDIT
TAS3 CoT Model
Modelling and Configuration Management Domain
Runtime and Enforcement Domain
Discover usage
& configuration
Modelling
Tool
IdP
=
=
Frontend Services
Dashboard
=
*
= =
*
Disco
Middletier Web Services
Models and
configurations
Automatically push
consistent security
configuration
=
* *=
=
Backend WS
Auditing &
Compliance
Tools
Operation
Monitoring
Connectors
= Routing &
aggregation
= PEP
*
=
Figure 2.14: Monitoring operation of the network using the configured model.
646
• Nobody should be able to put together the entire audit trail without proper authorization
647
• When answering a user audit request, the initial answer may have coarse granularity, such as
648
649
650
651
organizations that have accessed. Only upon more thorough, authorized, investigation more
detail, such as employees that have accessed would be revealed.
Relevant prior art will be incorporated in a future version of this document including regulatory compliance and best practises from
652
• Directive 95/46/EC and other guarantees offered by EU wide data protection legislation
653
• SOX [SOX02]
654
• SAS70
655
• COBIT
656
• ISO/IEC 27001
657
• Liberty Alliance
658
- Identity Assurance Framework [IAF]
TAS3 ICT-216287
Page 37 of 211
2.8. AUDIT
659
- Identity Governance Framework [IGF] Privacy Constraints
660
• COSO
661
• PCI DSS [PCI08]
TAS3 ICT-216287
Page 38 of 211
662
663
3 Core Security Architecture
666
This section specifies much of the logistics that allow the identity of the user to be passed around
between the architectural entities. This is a nontrivial problem, especially if pseudonymous delegated
identity is to be supported, combined with recursive calls.
667
3.1
664
665
668
669
670
Flows
This section addresses Reqs. D1.2-2.14-Priv, D1.2-2.15-Resp, D1.2-2.18-AnCredi, D1.2-2.19-AzCredi,
D1.2-2.20-Az, D1.2-6.12-Sec, D1.2-6.17-TechBind, D1.2-7.3-An, D1.2-7.8-NoColl, D1.2-7.16-Nym,
D1.2-7.21-Safe, D1.2-4.2-BPPrivacy, D1.2-4.4-CourtProof.
Alice Organization
Bob
Organization
Alice
Client
Application
PEP
TPN
Master
PDP
Stack
(WS)
TPN
Stack
(WS)
PEP
Master
PDP
Bob
Service
Web service call
Discover suitable service
Can we send data?
Acceptable request?
Acceptable response?
(any obligation)
Acceptable response?
(perform obligations)
Figure 3.1: General detailed flow of a service request
671
672
673
674
675
Fig-3.1 shows the core flow.
1. A client application wishing to call some service in another organization, initiates the call.
2. The Client PEP will enforce outbound authorization decision. To be able to do this, it first engages
in Trust and Privacy Negotiation, which is a discovery process, see Section 3.6, and then forwards
the request to the web services stack.
TAS3 ICT-216287
Page 39 of 211
3.2. TOKENS, ACCESS CREDENTIALS
676
677
678
679
680
3. Web services Stack (the "Stack") will compose a request message including the identity tokens that
are needed and signs the message. It then send the message to the Stack on the service side.
4. The service Stack will authenticate the sending Stack and verify the digital signature. The acceptance of the message will depend on a degree of trust on the signing party, which was established
during the Trust and Privacy Negotiation.
682
5. The service inbound PEP will consult the Master PDP to determine if the service request should be
allowed to go forward.
683
6. The inbound PEP will pass the request to the payload service, which will reply.
684
7. The outbound PEP of the Service will validate that the data can be released and attach obligations.
685
8. The Stack at the service correlates the response to the request, signs it and sends the response.
681
686
687
9. The client Stack receives the response, checks its correlation with the request, and verifies the
signatures in the response.
689
10. The client inbound PEP checks that the response is authorized and complies with the obligations
that were received.
690
11. The payload message is passed to the Client Application.
688
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
3.2
Tokens, Access Credentials
A central problem in multi-tier (or recursive) web services architecture is propagation of identity, or
identity handle, to all tiers, while preserving privacy separation (resilience to collusion) between the
parties.
The identity handle can allow, if chosen, linking of user’s consequtive visits together so that the
service can collect data about the user for future reference and provision of the service. In this case
the user is persistently identified, but to preserve privacy, the user will be identified differently towards
different parties. This prevents collusion by the parties.
Sometimes it is undesirable for the service to link relate visits of the user together. In this case
user is identified transiently, i.e. by one-time pseudorandom identifier (Req. D1.2-7.18-Seq). Within
one overall session, user can be identified persistently towards one service while at the same time
transiently towards another service.
In general access credentials come in the form of tokens that are digitally signed by a system entity,
usually a Trusted Third Party, such as an IdP or ID Mapper service. Reader can use SAML assertion
[SAML2core] as a mental model, though this is not the only possible technology choice.
This section addresses Reqs. D1.2-7.4-MultiCred and D1.2-7.18-Seq.
3.2.1 Attribute Pull Model
Target model. Fully capable. All use cases work and best privacy properties. This model
has been extensively studied in Liberty Alliance standardization work (n.b. this does not
limit its applicability to Liberty ID-WSF - same concept can be implemented using other
web service specifications, albeit with lesser maturity). This model addresses minimal
TAS3 ICT-216287
Page 40 of 211
712
713
disclosure particularly well, thus contributing to satisfying Reqs. D1.2-2.14-Priv D1.22.21-DataProtLaw, D1.2-6.4-Min, D1.2-7.5-Min, and D1.2-7.12-CredStepUp.
716
The Pull Model consists of front channel SSO layer and back channel web services layer. The "pull"
refers to the strategy where attributes are requested from their authorative sources only on as needed
basis. This has several benefits:
717
1. Minimal disclosure - only needed attributes are generated and shipped
714
715
718
719
720
721
722
723
724
725
726
727
2. Direct relationship with Attribute Authority. No intermediaries which could gain undue knowledge.
This may also reduce crypto overhead as protection against the in-transit man-in-the-middle is not
needed.
3. Intermediaries do not need to guess what attributes might be needed down the web services call
chain or in a particular variant of a business process.
4. Fully dynamic and recursive operation that supports several Business Process Topologies. At least
all forms of sequence (horizontal or vertical) and trees are supported. Support for a DAG would
seem feasible. Other topologies need further study.
Use Case User U authenticates with a service provider A through her IdP1. A needs to invoke further
service providers with reference to U.
730
Problem Definition If the trusted architecture uses a unique, even if random and transitory, userID
throughout then such a userID would allow multiple parties to collude and correlate all data
belonging to U.
731
Objective The system must avoid producing correlation handles in the process.
728
729
732
733
734
735
Solution Idea Each service provider knows the user by a different random userID, a persistent pseudonym.
And these pseudonyms are held by a mapping service. When one service provider wants to
pass on the request to another service provider, it can ask mapping service for a lookup of the
pseudonymous userID in the target service provider.
740
Given that the user’s pseudonym at the other provider is encrypted in transit, this solution avoids any
service providers sharing correlation handles. (N.B. In this system the two service providers invoking
each other’s services may still be able to directly collude, see Threat T107-LogTokLeak, but the service
providers at the ends of a chain of services where chain length > 2 can not collude. The solution is to
not log the tokens, see CR53-DontLogTok.)
741
3.2.1.1 Front Channel
736
737
738
739
742
743
744
745
746
747
Trivial situation is when the payload application consists entirely of a web gui or web site, without any
web services call. Never-the-less, this is a very important flow because it is the most common way for
Users to interact with the system. It is also a necessary precondition for the web services flows to be
initiated and bootstrapped with the necessary tokens, including the IM access token.
Example: In our concrete example U authenticates and makes a service request to A which invokes
another service provider B which also contains information about user U.
748
749
Assumptions:
TAS3 ICT-216287
Page 41 of 211
Auth
entic
a
tion
SSO
2
3
IDP_1
A
1
123A
Web GUI
PID E(123)A
PDP
PEP
Web Application
Service Requestor
Front End service A
Figure 3.2: Flow at front channel
750
• IdP has a table that lists the user name and the password of the user.
751
• IdP passes the permanent userID with a given Service Provider to that Service Provider ev-
753
ery time the user logs in to the IdP from the Service Provider. The identifier is conveyed in
a token, e.g. <username: sampo; attribute: member of tas3; other: permanent
754
userID of user with different service providers>
752
755
756
The Steps of the Protocol with one layer of Service Provider Invocations
1. User U wants to access service provider A and starts interaction with A.
758
2. U is redirected to IdP1 (n.b. IdP discovery is not addressed in this flow, though industry standards
like [SAML2core] and [CardSpace] do address it)
759
3. U logs in at IdP1. The authentication method is out-of-scope for this flow.
757
760
761
762
763
764
765
IdP1 returns two encrypted tokens to A:
TokenAuthn the token contains U s permanent pseudonymous userID 123A4. It is encrypted such
that only A can read it and authenticate the user.
TokenIM the token is encrypted for the IM and contains the permanent pseudonymous userID of
U with IM which is 789IM. The token is bound to A (contains an indication that only A can use
it towards IM).
TAS3 ICT-216287
Page 42 of 211
766
767
768
A authenticates U with TokenAuthn (possibly Single Sign-On - SSO). If it is a stand alone service,
A returns the results of the services to U and A is done.
3.2.1.2 Front Channel Using Identity Selector
8. Deliver content
Browser
CardSpace
User
1. Access Page
5. Token
SSO
Layer
6. WS-Fed
POST
4. User selects
managed card
and is sent to STS
STS IP
3. User
chooses
InfoCard
auth
WS-Fed RP
SAML IdP
7. SAML POST
(w/bootstrap)
2. Redir to
SAML IdP
Front End
(SAML SP / WSC)
A1. Discover
Web Services
Layer
A2. WSF Call
Discovery
Service
B2. Simple
WSF
Call
WSP1
STS
TokXlate
WSP2
B1. Obtain token for WSP2
Figure 3.3: Front channel flow when using Identity Selector.
772
Identity Selector technology aims at solving the IdP selection problem. The central proposal in the
area is InfoCard, which is realized by Microsoft CardSpace and some open source Identity Selectors.
InfoCard can be deployed in direct fashion, but the problem has been availability of SAML 2.0 tokens.
This is usually solved by deploying InfoCard in a proxy setup, as shown in Fig-3.3.
773
3.2.1.3 Back Channel, Simple
769
770
771
774
775
776
777
This flow expands on front channel by adding one web services call on back channel. This section
addresses Req. D1.2-3.10-JITPerm.
Example: In our concrete example U authenticates and makes a service request to A which invokes
another service provider B which also contains information about user U.
778
779
Assumptions:
TAS3 ICT-216287
Page 43 of 211
Auth
entic
a
tion
SSO
2
3
IDP_1
A
1
IM
123A
E(789)IM
use only: A
8 times
Web GUI
PDP
PID E(123)A
PID E(789)IM
PEP
Web Application
IM
E(789)IM
use only: A
8 times
Service Requestor
7
4
Front End service A
6
5
B
PEP
E(456)B
B
PDP
IM
E(456)B
PEP
IM
Service Responder
E(789)IM
use only: B
8 times
E(789)IM
use only: B
8 times
Service Responder
789 -> E(456)B
Identity Mapper IM
Service Provider B
PII
Figure 3.4: Flow of front channel call that makes a call on back channel.
780
781
782
783
784
785
• There is service provider IdMapper (IM). Each user usually has one IM that knows the permanent userIDs at the different service providers.
• IdPs know the IMs of the users (there are several ways to know. See section on user registration
in this document to be written.)
• IdP/IM produce IM tokens. The IM tokens include the following information (which means this
information is known to the IdP s and IMs):
786
- IM address
787
- the permanent pseudonymous userID of the user at the IM
788
- which service provider can use the token
789
790
791
792
793
794
- how many times and how long the token can be used (some of that could be pushed to a
PDP attached to the IM, except the constraint about who can use it)
1. (Same as above.) User U wants to access service provider A and starts interaction with A.
2. (Same as above.) U is redirected to IdP1 (n.b. IdP discovery is not addressed in this flow, though
industry standards like [SAML2core] and [CardSpace] do address it)
TAS3 ICT-216287
Page 44 of 211
795
796
797
798
3. (Same as above.) U logs in at IdP1. The authentication method is out-of-scope for this flow.
TokenAuthn the token contains U s permanent pseudonymous userID 123A4. It is encrypted such
801
it towards IM).
802
A authenticates U with TokenAuthn (possibly Single Sign-On - SSO).
799
800
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
4. A needs to use other service provider B to complete the services and needs the permanent
pseudonymous userID for U in B. For this A passes TokenIM from IdP1 to IM.
The service provider B is selected based on Trust and Privacy Negotiator’s efforts to find a suitably
trusted SP from the database maintained by the IM (or some other part of the Discovery functionality). (Req. D1.2-3.10-JITPerm)
IM decrypts TokenIM from IdP1 and sees the user U registered as 789IM in its database. This with
the token serves to authenticate the user to IM. Provided that the expiration time of the token is
relatively short, the user can be assumed to be present (User Present scenario).
B looks up the userID of 789IM for service provider B which is 456B (the lookup values can be in
encrypted form).
5. IM encrypts two new tokens for the invoked service providers B and gives them to A.
TokenUIDinB the token is encrypted for B. The token contains the pseudonymous identity of user
U at B. In this case it is: 456B.
TokenIM the token is encrypted for the IM and contains the userID of U with IM which is 789IM
The token is bound to B.
6. A sends a request to B for a service for U and sends the two tokens from the IM.
B decrypts the token and recognizes the user as having UserID 456B in its database.
B sees that 456B is the user U . It calls the authorization function to see if U is authorized. Assuming
the answer is granted, the service is provided.
If B needs to invoke further services with a service provider C it communicates with the IM of U
using its TokenIM and repeats the steps 4 through 6. See the recursive case, below.
7. B returns a result to A which completes the service and returns result to user U.
If a User has multiple IMs, multiple IM tokens would be generated if there was no way to ask User’s
choice or other deciding rule to pick just one. This may result in practise nearly all IMs being aware of
each other, but this need not always be the case and even partially populated IM matrix would remain
useful to the user. Further, the IM matrix may be different for different users.
TAS3 ICT-216287
Page 45 of 211
829
830
831
832
833
834
835
836
837
838
839
840
3.2.1.4 IM Bootstrap Token Minting and Passing through Front Channel
A key complication in the operation of the back channel is how to get the ball rolling, i.e. where do the
first tokens come, before we can discover more tokens. The simple idea of just using the front channel
token has undesireable privacy ramifications as it would provide a correlation handle between the SP
and the discovery.
Such correlation handle can be avoided by bootstrapping procedure where the IdP provides a separate, encrypted, token for access to the discovery. Although SP will be an intermediary in passing the
token to the discovery, it can not learn a correlation handle due to the encryption. Consider Fig-3.5
where the Single Sign-On (SSO) assertion (a7n), shown as red oval, is minted by the IdP, with another
assertion, the discovery bootstrap token shown as blue ball, in it. The SP will establish session for
the User (Principal) using the SSO assertion. When it needs to call a web service, it will extract the
bootstrap token and pass it to the discovery.
=
=
=
=
SSO a7n
bootstrap
cred
mint
3
2.1
IdP
Federation
Database
DS
4.2
2
4
Discovery
Database
Principal
1
SP/WSC
WSP
5
Figure 3.5: Single Sign-On (2,3), Discovery (4), and call to WSP (5). The blue ball represents discovery
bootstrap.
841
842
843
844
845
846
847
848
849
850
851
One might ask how does the discovery know all the services the user has and what identity to
include in the token. Many methods are possible, but ultimately the discovery maintains a federation
database of pseudonyms at each web service for the user. This is very similar to what IdP maintains
and it is not uncommon for IdP and discovery to be operated by the same organization.
One way to create the database is to bulk provision it.
Other way is to have user’s actively register the services they consider theirs. Consider Fig-3.6
where user first (1) visits a service, perfoming a Single Sign-On, thus establishing his pseudonymous
identity at the service. Then (2) user triggers the service to register itself as one of the user’s services.
At this point the discovery database records what it should send as users identity in a subsequent web
service call. When the call is made, first the discovery step (4) is made to obtain the token and then
(5) the actual web service call with the correct identity.
TAS3 ICT-216287
Page 46 of 211
Profile
DB
RPP
PP
WSC
2. REG(ENC1(RD), RPP)
SP
1. SSO(P1, ENC1(RD))
WSP
5. Q(ENC3(RPP))?
A(attributes)
3. SSO(P2, ENC2(RD))
4. DISCO(ENC2(RD), "PP")?
RESOFFER(ENC3(RPP))
Shop
SP
Principal
WSC
0. Login(uid)
IdP
WSP
Disco
0. Q(uid)
0. R(RD)
uid
Auth
DB
uid
Reg
DB
RD
Figure 3.6: Discovery Registration Using Front Channel Interface.
TAS3 ICT-216287
Page 47 of 211
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
3.2.1.5 Improvement Idea: Late IM Token Request
N.B. The IM does not get used at the last step of the chain. It has to produce n + 1 tokens
for n invocations. This introduces a slight inefficiency.
An improvement of the efficiency of the process is as follows:
Each service provider is only given the authn token and is not given the IM token. If the service
provider can provide the service then no IM token is needed. If the service provider needs to contact
another service provider, then it contacts the IM to ask for the ID of the user at the next service provider.
It refers to the user using the permanent ID by which the user is known to the IM and B (e.g. 456B
for B or 123A for A). In this case 789IM is never known to any of the service providers and is internal
to the IM. The IM can use the permanent ID to look up the user, find its local ID (789) then locate the
permanent ID at the next service provider and send this encrypted for the next service provider, back
to the requesting service provider for it to forward to the new service provider.
Problems with this approach, if there are multiple IMs, the service provider will not know which one
to contact. If there is only one IM, this is ok. But, the protocol is not standard. Where as the protocol
we defined above is a standard liberty alliance protocol.
867
868
3.2.1.6 Back Channel, Recursive
869
870
1. (Same as above.) User U wants to access service provider A and starts interaction with A.
872
2. (Same as above.) U is redirected to IdP1 (n.b. IdP discovery is not addressed in this flow, though
industry standards like [SAML2core] and [CardSpace] do address it)
873
3. (Same as above.) U logs in at IdP1. The authentication method is out-of-scope for this flow.
871
874
875
876
TokenAuthn the token contains U’s permanent pseudonymous userID 123A4. It is encrypted such
879
it towards IM).
880
A authenticates U with TokenAuthn (possibly Single Sign-On - SSO).
877
878
881
882
883
884
885
886
887
888
4. A needs to use other service provider B to complete the services and needs the permanent
pseudonymous userID for U in B.For this A passes TokenIM from IdP1 to IM.
The service provider B is selected based on Trust and Privacy Negotiator’s efforts to find a suitably
trusted SP from the database maintained by the IM (or some other part of the Discovery functionality).
IM decrypts TokenIM from IdP1 and sees the user U registered as 789IM in its database. This with
the token serves to authenticate the user to IM. Provided that the expiration time of the token is
relatively short, the user can be assumed to be present (User Present scenario).
TAS3 ICT-216287
Page 48 of 211
2
Auth
entic
ation
3
SSO
A
123A
IM
IDP_1
E(789)IM
use only: A
8 times
1
Web GUI
PDP
PEP
PID E(123)A
PID E(789)IM
Web Application
A req: PII
IM
E(789)IM
use only: A
8 times
Service Requestor
B
IM
11
Service Responder
5
B
E(789)IM
use only: B
8 times
E(456)B
Identity Mapper IM
IM
E(789)IM
use only: B
8 times
6
PEP
B req: Role
Authority
IM
Service Responder
PII
PEP
Front End service A
E(456)B
PDP
4
E(789)IM
use only: B
8 times
789 -> E(456)B
789 -> E(fgh)C
7
8
C
E(fgh)C
Service Application
IM
Service Requestor
E(789)IM
use only: C
2 times
PII Service B
10
C
E(fgh)C
IM
E(789)IM
use only: C
2 times
9
PEP
fgh -> TAS3
Service Responder
Role Authority C
Figure 3.7: Flow of recursive calls on back channel.
TAS3 ICT-216287
Page 49 of 211
889
890
891
892
893
894
895
896
897
898
899
900
901
902
B looks up the userID of 789IM for service provider B which is 456B (the lookup values can be in
encrypted form).
5. IM encrypts two new tokens for the invoked service providers B and gives them to A.
TokenUIDinB the token is encrypted for B. The token contains the pseudonymous identity of user
U at B. In this case it is: 456B.
TokenIM the token is encrypted for the IM and contains the userID of U with IM which is 789IM
The token is bound to B.
6. A sends a request to B for a service for U and sends the two tokens from the IM.
B decrypts the token and recognizes the user as having UserID 456B in its database.
B sees that 456B is the user U . It calls the authorization function to see if U is authorized. Assuming
the answer is granted, the service is provided.
7. In course of providing the service, B wishes to call C. This is termed "recursive call" and such
pattern can occur to any depth. B starts by discovering service of type "Role Authority", sending
the IM token to the Identity Mapper.
907
8. The Identity Mapper decrypts the IM token and recovers the pseudonymous persistent ID 789IM,
which is then used to locate from the database of IM the pseudonym of the User at service C,
which is the only service of type "Role Authority" registered for the User. Identity Mapper returns
two tokens: (i) the pseudonym of user at C encrypted such that only C can open it ("E(fgh)C" in
figure), and (ii) IM token that C may use to make further web services calls.
908
9. B calls C, passing the tokens along.
903
904
905
906
909
910
911
912
913
10. C decrypts the token "E(fgh)C" and recovers the persistent pseudonym "fgh". It uses this key to
look up the role from the database and returns it to B.
11. B uses the role to authorize the request (6) and returns a result to A which completes the service
and returns result to user U.
Steps 7 through 10 can be repeated any number of times in a recursive fashion.
914
915
3.2.2 Linking Service: Attribute Push Model
916
This section addresses Req. D1.2-7.15-PushCred.
917
918
919
920
921
922
The Linking Service model is described more fully in [TAS3D71IdMAnAz]. We just give a brief
summary of the model here.
The Linking Service model is based on the following assumptions/requirements:
• users typically have multiple attributes (authorisation credentials) assigned by multiple authorities and they are known by different identifiers at each authority
• some service providers will require many of these credentials in order to grant access
TAS3 ICT-216287
Page 50 of 211
2. U
se r
red
irec
ted
4
. IdP
3
to c
n
th
1
hos
R
’
s
u
efer
a
en
A
t
tribu
ral t
r
IdP
e
t
o
e
s
s
L
+
inkin
U
gS
1. Service
ervi
Request
ce
Service Provider
s referral
w
o
ll
fo
P
5. S
Linking
2 and 3
ked IdPs
n
li
to
ls
a
Service 6. Referr
al
eferr
r
s
llow
P fo
utes
7. S
attrib rral
s
’
2
P
refe
IdP 2
8 . ID
ws
o
l
t es
l
fo
i bu
r
t
P
t
sa
9. S
P3’
D
I
10.
IdP 1
IdP 3
Figure 3.8: Linking Service: Registration phase.
923
924
925
926
• the user does not want the inconvenience of having to authenticate (login) to each of the attribute
authority in order to obtain credentials to give to the service provider
• the service provider does want strong cryptographic evidence that each of the authorisation
credentials does belong to the user who has initiated the session
927
• the user should be able to set up his policy for which attributes are aggregated by which SPs
928
• the user should be able to provide consent each time his attributes are aggregated by an SP.
929
930
931
932
933
934
935
936
937
938
The Linking Service is a new component that is under the control of the user, and allows the user to
set his link release policy for which of his IdPs may be linked together so that their attributes can be
aggregated and sent to the same SP. The user may in addition set an attribute release policy at each of
his IdPs that is authoritative for more than one attribute, to say which SP can receive which subset of his
attributes from this IdP. Taken together, the link release policy and the set of attribute release policies
give the user complete control over which of his attributes can be aggregated together and released
to which service providers. The GUI for the link release policy has already been described in Section
D.9. The GUI for the attribute release policy will be very similar to this, but instead of associating IdPs
with SPs, the user will associate attributes with SPs. Note that in many cases attribute release policies
will not be needed since most IdPs are typically only authoritative for one attribute.
TAS3 ICT-216287
Page 51 of 211
IdP 1
2.
3
4.
1.
5.
Linking
Service
6.
7.
8.
IdP 3
Service Provider
9.
8.
7.
IdP 2
1. User makes a service request. 2. User is redirected to her chosen IdP 3. User
authenticates to IdP 1. 4. IdP 1 returns an authentication statement + attribute
assertions + referral to linking service 5. SP follows referral 6. Linking service looks up
IDP 1:PID 1 of user and finds links to other IdPs. 7. Linking service requests attributes
from linked IdPs using respective PIDs 8. IdPs return signed and encrypted (to SP)
attribute assertions. 9. Linking service relays all attribute assertions to SP.
Figure 3.9: Linking Service: Login with attribute push phase.
940
Once the user has linked his IdPs together and set his link release policy at the Linking Service, the
user contacts an SP for a service. The front channel steps are as follows
941
1. User contacts SP asking for a Service
942
2. SP and/or user interact, allowing IdP choice as usual
943
3. User is redirected to chosen IdP and Authentication with the IdP takes place as usual
939
945
4. In addition the User can tick a box giving consent for attribute aggregation to take place in this
session (see Fig-3.10)
946
5. User is redirected back to SP and is granted access to the service.
944
947
948
949
950
951
The back channel communications that take place between steps 4 and 5 above are as follows:
1. The IdP sends an authentication SSO statement to the SP, containing a random identifier for the
user. This prevents the SP from correlating the user’s requests in different sessions. (Note that if
the user wishes to be correlated he can arrange for the linking service to send a unique identifier
attribute from one of his attribute authorities during the attribute aggregation process, for example,
TAS3 ICT-216287
Page 52 of 211
Figure 3.10: The enhanced login screen for attribute aggregation.
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
a National Health Number from the Health Authority if the SP is a medical application, or a unique
ID from the authenticating IdP). The IdP also sends an attribute statement containing the user’s
attributes at this IdP, and an attribute statement containing referral(s) to the user’s linking service(s).
Each referral contains the unique ID of the user as known by the Linking Service and it is encrypted
to the public key of the Linking Service.
2. The SP acts on the referral(s) and contacts the LS’s discovery service asking it to return the linked
IdPs’ discovery services, along with a Boolean saying "I will do it or You do it for me".
3. The LS decrypts the unique ID of the user, looks this up in its database and finds all the user’s
linked accounts. If the SP has asked to perform aggregation itself, the linking service returns a
Response containing referrals to the discovery services of the user’s linked IdPs.
4. The SP now sends a query message to each of the IdP’s discovery services, requesting the contact details of the user’s attribute authority. Alternatively, if the linking service is performing the
aggregation on behalf of the SP, it sends the same message to each IdP.
5. The IdP’s discovery service locates the user’s local account by decrypting the user’s unique ID in
the referral, and maps the random identifier from the authentication assertion into the user’s local
account id. The IdP returns a Response containing the contact details of the attribute authority
where the random identifier is now valid
6. The SP or linking service sends an Attribute Query message to the attribute authority, using the
random identifier, whereupon the attribute authority returns a digitally signed attribute assertion
encrypted so that only the SP can read it.
973
7. If the linking service is doing the aggregation, it collects together all the encrypted responses from
all the IdPs and then forwards the complete package to the SP.
974
8. The SP now has the following digitally signed assertions:
972
975
976
977
978
979
980
981
a. An authentication assertion from a trusted IdP saying that the user has been authenticated, and
is to be known by this random id for this session
b. A set of attribute assertions from trusted attribute authorities saying that the user known by this
random id possesses this set of attributes
c. Based on the above the SP can authorize the user to access the requested resources, sure in
the knowledge that trusted authorities have both authenticated the user and assigned attributes
to her.
TAS3 ICT-216287
Page 53 of 211
982
3.2.2.1 N-Tier Linking Service Model
983
This section addresses Req. D1.2-7.1-Deleg.
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
If the SP above needs to subcontract one or more tasks to a backend service, and that backend
service is to act from an authorization perspective as if the user herself had contacted it directly, then
the backend service will need to be given the user’s authorization attributes. The exact model for how
this is to be done is for further study in the following years of the project. Whilst there have been
many previous models for dynamic delegation of authority none of them to the best of our knowledge
have supported attribute based delegation simultaneously with privacy protection of the delegator’s
and delegate’s identities. The following models at least are suitable for further study:
A. Trusted SP. The first SP simply forwards the initial authentication statement and referrals from the
authenticating IdP to the backend SP, and the backend SP follows exactly the same process as the
first SP (described above). (Note that the attribute statements cannot be forwarded as these were
targeted specifically for the first SP and encrypted to it.) The disadvantages of this method are:
a. the backend service must trust that the first SP is authorised to forward the user’s authentication
statement to it. Otherwise a rogue SP could illegally forward the authentication statement to a
backend SP in order to defraud the user;
b. the user either has to know beforehand which backend services are going to be contacted, so
that she can proactively sets up specific Link Release Policies for these backend SPs, or if she
does not know or is unaware that backend services are to be involved, she has to set up a
default policy for All Other Services (as described in Section D.9). Otherwise the backend SP is
likely to deny access to the subcontracted task.
B. Direct Delegation. The user contacts a delegation service and delegates her attributes to the
first SP, bestowing these credentials with delegation rights. The first SP uses these credentials to
authorize the user, and then delegates them further to the backend SP, optionally bestowing further
delegation rights on the backend SP in case it needs to subcontract further. The advantage of this
model is that the backend SP does not need to trust the first SP as much, since the latter has
specifically been delegated rights to it by the user. Further research is still needed here, since it
is currently not known precisely how to delegate an aggregated set of attributes issued by multiple
attribute authorities when the user is known by different identifiers at each authority. We will need to
find a way to combine the linking and delegation services to work together in a trustworthy manner.
C. FileSpace. We use a completely different model for multiple credential authorisation, termed
FileSpace [Chadwick09]. This gives the user a set of files which he can copy freely between
devices and service providers. Service providers can also freely copy the files between each other
to delegate authority on behalf of the user. The files are actually encrypted authorization credentials signed by their respective attribute authorities. Consequently they are useless to the recipient
(who can be a thief or a genuine SP) until it gets the decryption key. Herein lies the twist. The
user is the only person with the private key that can decrypt them. Thus before any front end or
backend SP can utilise the credentials they must ask the user for the decryption key. Once they
have the decryption key they know that (a) the user is the genuine owner of the credentials as she
was able to decrypt them, (b) the attributes genuinely belong to the user because they are signed
by a trusted attribute authority, and (c) the user has given consent for them to be used (because
she provided the decryption key). If we place the user’s private key in the Dashboard, then each
SP that wants to authorize the user must first contact the Dashboard asking for a decryption key
TAS3 ICT-216287
Page 54 of 211
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
and the user can keep track of progress of his task as various events arrive at the Dashboard. She
can then give consent (or not) as appropriate.
D. Shibboleth Portal. The Shibboleth community has developed a delegation model, initially targeted
at web portals and portlets, but generalized so that it can be used for any web services based
delegation. It is based on the Liberty Alliance ID-WSF Enhanced Client or Proxy SSO Profile
[SOAPAuthn2] instead of the SAML 2.0 Web Browser SSO Profile [SAML2prof] which Shibboleth
currently uses for SSO. It works by the first SP going back to the user’s IdP to authenticate itself
and ask for a new authentication statement allowing it to become a delegate of the user and a
delegator to a backend SP. The user’s initial authentication exchange with the IdP is enhanced to
allow the user to specifically authorize delegation by the SP it is contacting. This causes the IdP
to insert a new token into the authentication statement which authorizes the recipient (the SP) to
call it back to become a delegate. After the SP has authenticated and authorized the user, the SP
contacts a backend SP and quite naturally is required to authenticate to the latter, as is any user.
So the SP then contacts the IdP, authenticates to it (say by using mutual TLS) and passes the
token from the user’s authentication statement. This notifies the IdP that the SP is entitled to act
as a delegate of the user, so it issues an authentication statement in the name of the original user,
to the SP. This statement is targeted at the backend SP, and again contains a token that allows
the backend SP to call it back to become a delegate of the user in future. The first SP passes the
authentication statement to the backend SP and thereby masquerades as the user.
1046
E. Subcontracting. Of course the first SP can always subcontract the backend SP to perform the task
on its own behalf (as is typically done in manufacturing supply chains today), in which case the
user’s attributes are not needed by any backend service.
1047
3.2.3 Simple Attribute Push Model
1044
1045
1048
1049
1050
1051
1052
Recommended approach for initial deployments that have not yet developed full infrastructure.
In this model some commonly needed, or "enabler", attributes such as Trust Network membership
or role are supplied directly as part of Single Sign-On (SSO) or web service tokens. Other perhaps
justifiable attributes, that do not provoke overdue privacy or legal implications, could be
1053
• legally nonbinding nickname for greeting user
1054
• user’s preferred language
1055
1056
1057
1058
1059
1060
1061
1062
1063
This model implies that IdP or IDMapper assume some of the responsibilities of an Attribute Authority. This is well supported in existing protocols and available software implementations. It is also
probably the largest operation model in use today in existing federations. For example, this is the
model used by all Shibboleth implementations such as the UK academic community federation which
has over 800 IdPs and SPs since it was launched in August 2008. The number is still continuing to
grow linearly with another 20 or so providers being added per month.
Drawbacks of this approach are
1. Only a very narrow set of attributes will be universally needed by nearly all Front Ends or Web
Services.
TAS3 ICT-216287
Page 55 of 211
3.3. DELEGATION
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
2. Danger of nonadherence to minimal disclosure principles - its easy to have creep where "just one
more" attribute is added to support "just one more" application. This is also wasteful in that cost for
generating attribute statements that are seldom needed is still paid on every transaction.
A solution to this is to have an Attribute Release Policy (ARP) at the IdP which provides rules for
which attributes should be released to which SPs. In this way the attributes can be effectively
filtered before release. The ARP is set by the user and/or the IdP itself, and open source software
does exist for this. The design is very similar to the IdP Release Policy of the Linking Service
described in Section 3.2.2, above. Still, this approach lacks granularity as the attribute needs of
a SP are assumed to be always the same, while in reality SP may run various different business
processes with different needs.
1074
3. Postponement of moving to full pull model.
1075
3.3
1076
This section addresses Reqs. D1.2-3.7-Deleg and D1.2-7.1-Deleg.
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
Delegation
Technical clarification: Here "Delegation" means assignment of decision powers, and access rights they imply, from one User to another User. This is distinct from merely instructing some web application or service to act on ones behalf - some other practitioners call
also this "delegation", but we find a service merely executing on instructions of a user so
common that it is the base case, and does not need special mention.
Delegation is analogous to giving personal banker the right to manage your portfolio, while
action on behalf happens when bank executes wire transfer upon you direct orders.
General properties of delegation are
• Express and auditable act of creation (e.g. issue power of attorney), with indication of registration (where needed).
1087
- Specification of delegatee ("Performer" of a web service action)
1088
- Specification of delegator ("Target" of a web service action)
1089
- Specification of scope
1090
- Actions and/or
1091
- Resources
1092
- Role based delegation
1093
- Specification of expiry and other constraints
1094
• Sub-delegation, when this ability is expressly mentioned in constraints
1095
• Ability to revoke
1096
- At any step of sub-delegation chain
1097
- Any superior anchestor can revoke any descendant
1098
- Audit
TAS3 ICT-216287
Page 56 of 211
3.3. DELEGATION
1099
• Divulgation of issuer’s signing private key MUST NOT be used as a mechanism of delegation.
1100
• Expression of the delegation and target in web services calls at any level of recursion
1101
• Verification by Relying Party: mandate assurance & authenticity (typically verify sig on token +
1102
1103
1104
1105
1106
1107
1108
1109
query of MA for revocation info + evaluation of possible constraints)
• Transparency: ability for user to verify which mandates have in fact been exercised or formally
accepted.
This could be implemented by the Delegation Service feeding information about each invitation
usage to the Audit Event Bus, where the Dashboard can pick up the information and display it
to the user when user comes to consult it. Also, when Service Responder, or its CVS or PDP,
consumes a delegation token, it will inform the Audit Event Bus so that the Dashboard can have
the big picture of the delegation usage.
1111
Delegation is also discussed in section 6 "The Delegation Service" of [TAS3D42Repo] and in section
6 of Deliverable D7.1 [TAS3D71IdMAnAz].
1112
3.3.1 Invitation Based Token Approach
1110
DS A
IdP A
Deleg A
ePortfolio
(Front End)
CB A
Alice
(principal)
Album A
University A
Figure 3.11: Alice Prepares ePortfolio.
1113
1114
1115
1116
1117
1118
1119
Assume Alice has used ePortfolio Front End to construct some artifacts about her career (see Fig3.11), including attestation from University A that she has a degree, and some exhibits, in Album A of
the work she has already done.
Now, Alice can invite her job coach Bob to access these artifacts as Web Services, see Fig-3.12.
First Bob resolves the invitation to the necessary access tokens and then accesses the services. Of
course Bob is action through the Job Search Front End.
On access (2a) two tokens will be present
TAS3 ICT-216287
Page 57 of 211
3.3. DELEGATION
DS A
IdP A
Deleg A
ePortfolio
(Front End)
CB A
Alice
(principal)
Album A
1
0. Invitation
2a
University A
2b
DS B
IdP B
Job Search
(Front End)
Deleg B
Bob
(principal)
Figure 3.12: Bob using Alice’s Web Services by way of invitation.
1120
1121
1122
1123
1124
1125
1126
Target Identity Delegation Token, encrypted for Album A and usable by Job Search, containing Alice’s pseudonym at Album A. This token indicates that the access is by invitation and not by
Alice being present in the transaction. The Delegation token can also include description of
which part of the user’s resource at the Service Provider can be accessed and how.
Subject Identity Token, encrypted for Album A and usable by Job Search, containing Bob’s pseudonym
at Album A. This token indicates that Bob is performing the operation and that Bob is present in
the transaction (at front channel).
1127
Details of the Invitation Flow
1128
Consider Figs 3.13 and 3.14 and the depicted steps as follows:
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1. Delegator (Bob) selects the resource to share at the Service Provider. Service Provider knows who
Delegator is as Bob used Single Sign-On to login to the SP.
2. Once a resource has been selected, Delegator is transferred to the user interface of the Delegation
Service. The Delegation Service generates an Invitation Ticket, which is formatted as URL pointing
back to the Web GUI of the Delegation Service, but with a nonce component that is hard to guess.
The invitation is remembered in the database of the Delegation Service.
3. The Delegator then gives the invitation to Delegatee. The Delegator does not need to know the
specific identity of the Delegatee in the network. However, if the Delegator cares, he could use out
of band means of ascertaining that the Delegatee that receives the invitation is the person to whom
he wishes to delegate, e.g. instead of emailing the invitation, deliver it personally.
4. The Delegatee now resolves the invitation by clicking the URL and lands at the Web GUI of the
Delegation Service, which asks the Delegatee to identify itself by means of an IdP (usually Single
Sign-On). This IdP can be different from Delegator’s IdP as long as the Delegation Service and
TAS3 ICT-216287
Page 58 of 211
3.3. DELEGATION
SP
765SP
IM_B
E(789)IM_B
use only: SP
8 times
PID1 E(765)SP
PID1 E(321)DS
PID1 E(789)IM_B
Bob, Delegator
1b
Invitation
sdfah.html
IDP_B
1a
3a
SSO
2a
1
SSO
3
Alice, Delegatee
2b
Web GUI
PEP
PDP
Invitation
sdfah.html
Web Application
Delegation
Service
2
PII
Bob's
Resource
Policy of SP
"Bob's R"
Service Provider
Invitation DB
Resource SecretURL
"Bob's R" sdfah.html
PID in DS
321
PDP
Resource
SecretURL
PID in DS
Artefa
ct
PID in SP
"Bob's R"
sdfah.html
321
Artefa
ct
E(123)SP
Artefact
PID in SP
Delegtion
Policy
Figure 3.13: Invitation phase
1142
1143
1144
1145
1146
1147
1148
1149
1150
the SP are willing to trust it. Various mechanisms, that are described in Sections 3.7 and 3.6, to
establish the trust exist.
If Delegatee does not have any IdP, then Delegatee should register with some IdP, otherwise he
can not continue the flow.
N.B. A flow is possible where the invitation itself grants access to the resource without
any need to authenticate the delegatee. While this flow may be interesting in some commercial settings, it lacks sufficient audit and accountability safe guards to be included in
the TAS3 architecture.
5. Delegation Service invokes Delegatee’s Identity Mapping Service to convert the identity of the delTAS3 ICT-216287
Page 59 of 211
3.3. DELEGATION
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
egatee are the Delegation Service to the identity of the Delegatee at the SP and stores it in the
invitation database. The identity will be encrypted so that only SP can open it.
6. The Delegation Service generates an artifact with nonce properties and associates it with the invitation. It then redirects the Delegatee to the user interface of the SP, passing the artifact in the
query string.
7. SP dereferences the artifact by contacting on back channel the Delegation Service, which looks up
the invitation using the artifact and generates a Delegation Token binding together the authorized
resource (known from time when invitation was created) and the Delegatee (known from step 5);
signs the token, and ships it to the SP.
8. The SP PEP now passes the invoking identity, i.e. the Delegatee, known from Single Sign-On
and the (contents of) Delegation Token to the PDP, which will authorize the operation. Typically
the authorization rule will require that the accessed resource and invocation identity match the
Delegation Token.
In this flow, the Delegation Service and the SP could be merged, effectively optimizing steps 2 and
7 to function calls. While such merge is technically sound, it may hinder development of competitive
market for the delegated services. The flows in [TAS3D42Repo] Appendix 2 "Proof of Ownership
Using Permanent IDs" essentially presents the invitation flow where the invitation is then embedded in
a composite document. That Appendix does not show how the Proof of Ownership URL (PoOURL) is
dereferenced. Essentially the steps 4-8 could be performed, or other means to authorize the access
could be used. It is important to understand that reliance on mere invitation does not leave audit trail
trace about who accessed. The delegatee really needs to be identified (e.g. by SSO to Delegation
Service) for the audit trail to be useful.
Essentially the steps 4-8, above, could be performed, or other means to authorize the access could
be used. It is important to understand that reliance on mere invitation tokens (secret URLs) does not
provide identity information to the audit trail about who accessed the document. But if authentication
and authorisation of the PII recipient took place because a fixed proof public URL was used, then full
audit information is provided.
Reuse of Invitation
One salient property of this flow is that the first time the invitation is dereferenced, it gets bound to a
concrete user. In subsequent attempts to dereference the invitation a check can be made that it is the
same user (but if requirement really is that the token should be reusable by different users, then this
check can be omitted).
Application of Invitation Approach to Back Channel Web Service Calls
1185
The invitations approach can be extended to cover back channel web service calls as well. This
topic will be elaborated in the next version of this deliverable (D2.1 M30).
1186
3.3.2 Mandate Tokens Approach
1187
This approach is described in [Peeters09].
1184
1188
1189
1190
Next version of this deliverable (D2.1 M30) will outline application of Mandate Tokens to TAS3 architecture, including
• Emission
TAS3 ICT-216287
Page 60 of 211
3.3. DELEGATION
PID2 E(123)SP
PID2 E(769)IM_A
PID2 E(457)DS
DS
457DS
IM_A
E(769)IM_A
use only: SP
8 times
IDP_A
Alice, Delegatee
4b
Bob's
Resource
SP
123SP
IM_A
E(769)IM_A
use only: SP
8 times
4a
8
6b
4
6
6a
Invitation
sdfah.html
Art_1
Delegation Token
Resource: "Bob's R"
Delegatee: E(123)
Web GUI
PEP
Web Application
PDP
7b
7a
Delegation
Service
Art_1
PII
"Bob's R"
Bob's
Resource
Policy of SP
2
Service Provider
5a
IM_A
E(769)IM_A
use only: SP
8 times
5b
SP
123SP
Invitation DB
769 E(123)SP
769 E(457)DS
ID MAPPER A
Resource SecretURL
"Bob's R" sdfah.html
PID in DS
321
PDP
Resource
SecretURL
PID in DS
Artefa
ct
PID in SP
"Bob's R"
sdfah.html
321
Artefa
ct
E(123)SP
Artefact
Art_1
PID in SP
E(123)SP
Delegtion
Policy
Figure 3.14: Accept invitation phase
1191
• Push Model
1192
• Pull Model
TAS3 ICT-216287
Page 61 of 211
3.3. DELEGATION
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
3.3.3 Delegation by Direct Authorization Rule
In this model the resource owner, knowing delegatee’s full identification, creates an access control rule
at the resource, i.e. sticky policy, that simply authorizes the delegatee to access the resource.
The ability to assign access to other user can be regulated by policies that are checked by the sticky
policy interface, e.g. by consulting a PDP.
When delegatee accesses the resource, he identifies himself using the usual token passing flow,
see Section 3.2, and the PDP is able to match his identity to the sticky policy authorizing the access.
Difficulties are
1. The Delegator has to have a solid identifier for the delegatee. This may be difficult for a human to
know and accurately enter. It is possible to offer to the delegator a browsing or search interface
of all potential delegatees, but such list may be unacceptable from data protection perspective and
can be difficult to implement in a distributed way.
A better alternative may be to adopt the invitation steps 1-4 from section 3.3.1 and modify the step
4 so that it edits the access control rule.
2. The resource has to have a sticky policy editing interface and access to this interface needs to be
well controlled. Online editing of policies increases exposure and potential for compromise.
3. If policy editing interface is centralized (e.g. in Dashboard), the identification of the resource to
which the policy applies may be difficult. This can be solved to an extent by Discovery. The the
policy editing interface of the resource would have to be web service based, with proof of presence
of the delegator.
1214
4. Privacy is poor as the requirement to know delegatee’s identity widely excludes pseudonymous
approaches.
1215
5. Invitations are not supported
1216
3.3.4 Delegation by Role Based Authorization Rule
1213
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
In this model the resource owner creates an access control rule at the resource, i.e. sticky policy, that
authorizes anyone having a given role to access the resource.
The ability to assign access to a role can be regulated by policies that are checked by the sticky
policy interface, e.g. by consulting a PDP.
The assignment of a role to a delegatee is performed by some role authority outside control (but still
accountable through TAS3 oversight) of the resource owner. The usually role assignment is performed
using a special Sharing GUI that the role authority accesses (his authorativness is checked by separate
access control policy verifying that he is a role authority). The role authority needs to identify the
delegatee and then assign the role.
The role is stored in delegatee’s role repository, which can be his Attribute Provider.
When delegatee accesses the resource, he identifies himself using the usual token passing flow,
see Section 3.2, and the PDP is able to retrieve his role and match that to the sticky policy authorizing
the access. The role retrieval may be through push or pull model.
In its basic form the RBAC allows any role holder access to any resource that accepts the role and
the identity of the role holder is irrelevant, thus permitting use of pseudonyms or transient identifiers
that improve the privacy.
TAS3 ICT-216287
Page 62 of 211
3.3. DELEGATION
1233
1234
1235
1236
1237
1238
1239
However the fact that the resource is not constrained is a problem. This could be solved by having
as many roles as there are resources, but this would lead to combinatorial explosion in the number of
roles and quickly become unworkable. Also, the role identifier itself could become a correlation handle
across the resources of a user.
A way to constrain the role is to parametrize it. Parametrized roles have a main part that specifies the
role proper and then a parameter that specifies to which resource the role applies. Since parametrized
role identifier has unique identifier properties, it is highly liable to become a correlation handle.
1242
This approach adds flexibility, but still suffers from need to have exposed policy editing interface and
to some degree about the problem of identifying the delegatee and resource. In parametrized variant
any privacy protection is quickly lost.
1243
3.3.5 Token Based Delegation to Well Known Delegatee
1240
1241
1244
1245
1246
1247
If Delegatee’s accurate identification can be known, the delegator can instruct a Delegation Service to
create a signed (by Delegation Service) token for accessing his resource. The fact that he can make
this delegation is checked against issuing policies, such as "data owner can delegate access to it".
The token can then be stored for future use in several places:
1248
1. In Attribute Authority of the Resource Owner
1249
2. In Attribute Provider of the Delegatee
1250
3. In token store of the Delegation Service
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
When Delegatee accesses the resource, he can push the token, obtained from (2) or (3), to the web
service that provides the resource. The token will identify the resource to which it applies, this is the
Target Identity.
Sometimes the mere presence of the delegation token is sufficient for accessing the resource, this
would be considered a bearer token.
However, in a more common case, the Delegatee also pushes a token identifying himself, e.g. a SSO
token. This expresses the Subject Identity, i.e. the identity of the user performing the access. This
allows the delegation token to be constrained to a user who can present token evidence of actually
being the Delegatee. This is essentially a Holder-of-Key proof and produces strong audit trail that
identifies who delegated and to whom.
1265
Another variant is for the resource providing the web service to pull the delegation token from one
of the sources. If Subject Identity is not known, but the accessed resource is known, then (1) can be
used. In effect the discover of the Attribute Authority is keyed on the identity of the resource owner.
Token can also be retrieved from (3). Finally, if the Subject Identity is known, pulling the token from (2)
becomes possible.
1266
3.3.6 Token Based Delegation of a Received Role
1261
1262
1263
1264
1267
1268
1269
1270
If a user has a role, given to it by some role authority, and policy permits delegation of this role, the
user can go to the Sharing GUI and ask a delegation token to be issued with known delegatee and
known target resource. Accurately identifying the delegatee and the target are serious problems as
described above.
TAS3 ICT-216287
Page 63 of 211
3.4. SUBJECT OF THE PII NOT PRESENT -TRANSACTION
1271
1272
1273
The ability to delegate only "received role" is expressed by Delegation Service having a policy which
states that delegator can only delegate roles he has himself, as determined by the roles the authority
has assigned to the user.
1275
The issued token is then stored for use by method (2) or (3) as discussed earlier. The token can be
used for access either by push or pull methods.
1276
3.3.7 Multi-layer (Chained) Delegation
1274
1277
1278
1279
1280
1281
The token based delegation methods described above lend themselves to multi-layer delegation. In
this case the delegation is with right to sub-delegate and the delegatee is able to request that further
delegation tokens are created, or that an invitation is created.
For access authorization generally only the last step of a delegation chain is important, but for audit
purposes the full chain is needed.
1283
The flows and tokens associated with multi-layer delegation are a topic of research in the TAS3
project and will be further elaborated in a future version of this deliverable (D2.1 M30).
1284
3.4
1285
There are two main categories for supporting PII-Subject-Not-Present transactions
1286
1. PII Subject consented at some earlier time.
1282
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
Subject of the PII Not Present -Transaction
If the consent was expressed by the PII Subject by creating a policy that authorizes the delegation,
then we need to establish from the audit trail that only the user could have created the policy.
If token based delegation is used, PII-Subject-Not-Present could be implemented by "cacheing" an
access credential for long time. Due to obvious problems with long term valid access credential,
we only allow cacheing the discovery bootstrap credential. Using this credential the WSC MUST
request a fresh access credential for the PII-Subject-Not-Present transaction immediately before
attempting the transaction. This ensures that the PII Subject has control and visibility since the
Discovery will be a third party to the transaction, allowing additional audit correlation. Discovery
can also be used as centralized revocation point for the consent to the off-line transaction up to the
point when the transaction is actually made.
The discovery token was originally issued for a purpose and when a transaction token is requested,
including the PII-Subject-Not-Present situation, a purpose MUST be declared so that the authorization process at the discovery can make appropriate decisions.
2. Transaction is permitted by law or contract without consent of the PII Subject. In this case the big
problem is that as the PII Subject might never have been present we need to consider how the
Legitimate Initiator (LI) identifies the PII Subject in the first place.
a. The PII Subject has a federated account at the Legitimate Initiator. In this case the LI can ask
the IdP to issue a discovery token. Such issuance needs to be strictly controlled. The LI is first
authenticated (e.g. using PKI at TLS level) and then LI presents the legitimate purpose why the
token is sought. The IdP will consult a PDP which will make the policy decision whether under
these circumstances the discovery token should be issued. The audit trail shall rigorously reflect
these events. After the discovery token has been obtained, the rest of the steps are as in (1).
TAS3 ICT-216287
Page 64 of 211
3.5. BREAK-THE-GLASS AUTHORIZATION
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
b. The PII Subject has an account at the Legitimate Initiator, but it is not federated. The issuance
step of (a) will have additional request to create the federation. If the PII Subject eventually ends
up using the LI through SSO, the already created federation will be used.
c. The PII Subject does not have an account anywhere. In this case a stand-in account needs to
be created first and then the process of (b) and (a) will be followed. If the PII Subject eventually
starts using the LI using SSO, a problem remains on how to associate the PII Subject to the
already existing account. This may be possible by asking some identifying information, such as
sector specific or national identifier upon first SSO use. If asking such information is infeasible, or
the PII Subject can supply wrong information, we may well end up with user having two accounts
at the LI. Depending on the circumstances, this may not be a problem, or an administrative
procedure may be needed to combine the accounts.
3.5
Break-the-Glass Authorization
This section addresses Reqs. D1.2-3.9-BPRecover, D1.2-4.6-BrkGlass, and D1.2-7.22-BrkGlass. See
[TAS3D71IdMAnAz] for further discussion of the Break-the-Glass authorization.
In a Break-the-Glass scenario an operation would not normally be authorized given the actor and
the resource (including owner of the resource), but given justified and legitimate imperative need, the
operation is authorized, usually with additional auditing enabled.
A classical example would be an unconscious patient brought to an emergency ward. The physician
has imperative need to access the patient records, yet the patient can not consent to the access.
The Break-the-Glass authorization is an area of active current (2009) research and TAS3 architecture will in its future versions incorporate the best innovations in this area. Our current approach is as
follows
PEP driven Break-the-Glass (RECOMMENDED approach): The PEP attempts authorization which
fails for normal access. At this point PEP determines if Break-the-Glass could be applicable (could be
indicated by PDP or structurally known by the PEP). If so, the PEP may proceed to ask consent from
the actor ("Do you want to invoke Break-the-Glass privileges and additional auditing?") using interaction facilities of the architecture, or in some cases may enable the Break-the-Glass automatically.
Enabling Break-the-Glass forces additional audit messages to be generated at the PEP and by the
service overall. It is also possible that the Break-the-Glass authorization is explicitly asked from the
PDP in which case there will be audit entry also on the PDP side, permitting better cross correlation of
the audit trails.
Policy editing driven Break-the-Glass: In this approach, after initial denial of the authorization,
some mechanism is invoked to modify the policy such that the same actor will succeed in obtaining authorization. This approach is NOT RECOMMENDED due to complex security implications of
allowing policy editing.
Role driven Break-the-Glass: This is similar to the Policy Editing approach, but the edit happens in
the role authority. This approach is NOT RECOMMENDED for much the same reasons as Policy Editing: the role authority needs to be strictly controlled and introducing automated role editing mechanism
is not desirable.
Delegation driven Break-the-Glass: In this approach after the failure, the actor visits the delegation authority and claims Break-the-Glass situation. The delegation authority verifies according to
its policies if the Break-the-Glass delegation is appropriate given the actors role, etc., the resource,
and the context of the request. If acceptable, the Delegation Authority issues a delegation token with
TAS3 ICT-216287
Page 65 of 211
3.6. TRUST AND PRIVACY NEGOTIATION
1352
1353
1354
1355
special field that indicates the Break-the-Glass nature of the delegation and records the fact to its audit
trail. When the delegation token is wielded at the PEP, it recognizes the delegation authority as trustworthy and notices the Break-the-Glass indication, enabling more extensive logging. This approach
can be made to work.
1363
External Break-the-Glass IdP driven approach: This approach is a front channel special case of
the PEP driven approach with some features of the Delegation driven approach. The particularity is
that the PEP redirects the user, with indication of the resource to be accessed, to a special IdP which
is responsible for verifying (probably querying a PDP) whether the user is eligible for Break-the-Glass
access. If so, it issues a token indicating that the user is eligible and has been granted access, what
resource is to be accessed, and the fact that Break-the-Glass has been invoked. The PEP seeing this
token grants access, but enables additional logging. The special IdP will also have audit trail of the
events, so it will be possible to cross check the trails.
1364
3.6
1365
This section addresses Req. D1.2-7.17-Increm.
1356
1357
1358
1359
1360
1361
1362
1366
1367
Trust and Privacy Negotiation
Trust and Privacy Negotiation logistics and flows are subject to TAS3 research. A future version of
this deliverable (D2.1 M30) will report on these mechanisms in detail.
1374
To give rough overview, the Trust and Privacy Negotiation can be carried at two levels: on Front
Channel a user interface (Web GUI of a Front End) will step user through sequence of mutually revealing more information until agreement can be reached and transaction can be completed. This may
involve the user agreeing to relax policies on his data, or the Service Provider agreeing to honour some
additional user policy that it did not offer originally. The second level is Trust and Privacy Negotiation
in the back channel. The Discovery Service plays a large role in the Trust and Privacy Negotiation at
this level. The mechanics are further described in [TAS3D41ID].
1375
3.7
1368
1369
1370
1371
1372
1373
1376
1377
1378
1379
Interoperation Across Trust Networks
General approach for interoperation across Trust Networks is described in [LibertyInterFed], which
focuses on the token passing flows in inter-federation situation. In addition to token passing, interoperability at data level is needed, i.e. the ontologies in use in the different Trust Networks either need to
be the same or they need to be mapped. In particular, authorization critical data needs to be mapped.
1381
Next version of this deliverable (D2.1 M30) will provide specifics of interoparation, based on TAS3
research and implementation experience.
1382
3.7.1 Semantic Interoperability Engine
1383
This section satisfied Reqs. D1.2-2.23-SemIOP, D1.2-3.14-PIIPolicyDisco, and D1.2-3.15-SecPreserve.
1380
1384
1385
1386
1387
1388
1389
1390
A semantic interoperability provides different mechanisms to map ontological entities from heterogeneous entities. Castano et al. [Castano07] identify two main categories of ontology matching techniques; namely linguistic and contextual matching techniques. Linguistic techniques evaluate the similarity among ontological content (i.e. classes, roles and instances) based on their names or labels.
The main characteristic of these techniques is that they evaluate the similarity between two strings
of characters. For example, the edit distance counts the minimum number of changes, such as insertion, deletion and replacement of characters, required to transform one string into the other string
TAS3 ICT-216287
Page 66 of 211
3.7. INTEROPERATION ACROSS TRUST NETWORKS
Modelling (conceptual level)
Modelling (conceptual level)
Semantic Interoperability Engine
Ontology A
Existing Transforms
Ontology B
Runtime
Runtime
Service
Requester
Az
Transformer
Az
Service
Responder
Audit & Monitor
Audit & Monitor
Org B
Org A
(Context B)
(Context A)
Figure 3.15: Interoperation across contexts.
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
[Levenshtein66]. Although linguistic techniques often provide highly precise mappings, these techniques tend to fail when there is little lexical overlap between the labels of ontological entities. Contextual matching techniques can remedy this problem by assuming that some of the meaning of an entity
is conveyed by its context. For example, Dieng and Hug [Dieng98] calculate the similarity between
two concepts based on their direct super-classes and/or direct subclasses and/or sibling classes. The
semantic interoperability engine will include different algorithm of these types, and thus be able to deal
with a wide range of mismatches. As a result, multiple organisations using different conceptualisation
will be able to interoperate to achieve a common goal.
As shown in Fig-3.15, the Semantic Interoperability Engine (SIE) works at conceptual level. It can
be used process the two ontologies to produce Transforms that may be stored for later use. SIE can
run as a scheduled batch to update the transforms, or change in either ontology can be used to trigger
SIE. Finally it may be possible to invoke SIE dynamically whenever an existing transform is not yet
available.
At runtime an efficient Transformer uses the Transforms to translate data in the messages that are
exchanged. TAS3 focus is on using this mechanism to transform security, trust, and privacy related
attributes such as roles. However, the mechanism in itself could be used for payload data transformation as well. The transform can be done in sending or receiving end. The Transformed has to be
positioned such that each PEP (which calls PDP, passing the attributes along) will have the security
related attributes in its own vocabulary. In the sending end this means after authorization, in receiving
end before authorization.
TAS3 ICT-216287
Page 67 of 211
3.8. PROPERTIES OF WEB SERVICE BINDING
1411
1412
1413
1414
1415
1416
1417
3.8
Properties of Web Service Binding
Web Service Binding is a set of features that the communications layer is assumed to have. These
features are often required by more sophisticated protection mechanisms like the tocken passing flows.
They often address basic and well known threats like replay, unauthorized, and man-in-the middle
attacks in basic way while other mechanisms may address the same topics comprehensively, but in a
more expensive way. Many of these features may seem selfevident, but we need to list them even if
just to state the obvious.
1419
1. Mutual authentication of the communicating entities MUST be possible. Usually this is done using
transport layer digital certificates, but other approaches are possible.
1420
2. Link confidentiality MUST be possible, usually using transport layer encryption.
1421
3. Correlation
1418
1422
- Request-Response Correlation
1423
- Business Process identification in correlation
1424
4. Redirection support for flexibility
1425
5. Recredentialing support (Req. D1.2-3.9-BPRecover )
1427
6. Asynchronous support SHOULD be implemented (this will be addressed in a future version of this
document)
1428
7. Interaction Callback (or Exception Request)
1426
1429
- Interaction Redirect (Req. D1.2-3.9-BPRecover )
1430
- Interaction Service (Req. D1.2-3.9-BPRecover )
1431
1432
8. Digital signing of messages for nonrepudiation (Reqs. D1.2-2.11-Transp, D1.2-2.15-Resp, D1.24.4-CourtProof )
TAS3 ICT-216287
Page 68 of 211
1433
1434
4 Application Specific Architecture
1435
4.1
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
Protocol Support for Conveyance of Sticky Policies
Most of the protocol flows of TAS3 use industry standard Web Services bindings and Web Services
payload protocols. It is an explicit design goal that existing services are enabled with minor disruption.
A pertinent problem with existing payload service protocols is how to express the sticky policies
that generally have to be bound to the data with a digital signature. Following approaches have been
identified
1. Treat all data in one request-response pair as having the same Sticky Policies. In this cases relatively nonintrusive methods like SOAP headers and LDAP controls can be used to indicate the
sticky policies. We call this Security Header (SH) approach. This approach is already available as
UsageDIrective SOAP header defined in [IDWSF08].
2. Use the extension points of the payload protocol to express the Sticky Policies. We call this approach Application Protocol Enhancement (APE), see [TAS3D71IdMAnAz] section 8.2. This approach gives granular Sticky Policies that are naturally associated with the data and does not alter
top levels of protocol processing. If client and server are updated to understand this scheme then
it works well. Eventually new payload protocols should be specified with TAS3 APE feature built in.
A danger of this approach is that if the client is not updated, it may just silently ignore the Sticky
Policies.
3. Expand the data model to carry sticky policies. This is really a special case of APE with similar
merits and problems. One benefit is that it is sometimes easier to extend a datamodel than a
protocol.
4. Encapsulating Security Layer (ESL), see [TAS3D71IdMAnAz] section 8.2. Wrap the payload protocol in a TAS3 defined encapsulating protocol that contains all the TAS3 specifics and in particular
the sticky policies. Advantages of this approach include
1458
• The encapsulated protocol does not need to be modified at all
1459
• Possibility to add sticky policies to protocols that do not offer extension points and that are not
1460
1461
1462
1463
1464
1465
1466
1467
1468
under control of the implementer.
Disadvantages of this approach are
• More invasive on outer layers of the protocol stack. This may make it difficult to integrate to
existing protocol stack.
• If the payload protocol is not SOAP, or otherwise has poor impedance match to the TAS3 ESL
protocol, then integration may be impossible.
• Association of the sticky policies to the data will require awkward correlation of data items to
the policies. In particular, if the data does not have item specific IDs, it may be necessary to
resort to use of techniques such as [XPATH99].
TAS3 ICT-216287
Page 69 of 211
4.2. LEGACY INTEGRATION STRATEGY
1469
1470
1471
1472
1473
Given the multiplicity of approaches, each with its merits, the problem arises as to which one should
be used. Luckily all can coexist in the same Trust Network. This is made possible by expressing
different approaches as different Service Types so that it is possible to discover services that make the
approach supported by the client possible. Another approach is to use autodetection, observing the
namespaces and elements passed in the SOAP payload to determine which one is being used.
1478
Which of the approaches works best and difficulty of supporting several in parallel are topics of
active research in TAS3 . A future version of this document will give better guidance for selection of the
approach. Currently (May 2009) the APE approach has been successfully used in situations where
payload protocol was under our control. The ESL approach has been prototyped, but the specifics of
this protocol are still to be determined.
1479
4.2
1474
1475
1476
1477
1480
1481
Legacy Integration Strategy
For TAS3 architecture to be useful, it needs to be adopted. To adopt TAS3 an existing application faces
some implementation choices.
Web Service (e.g. Attribute Authority)
Data Service
Service Responder
Stack
User
F
E
Application with PEP built in
PEP-In
(accept req)
TAS3
SOAP
PEP-Out
(filter)
XACML (in SOAP envelope)
Master PDP
Figure 4.1: Application Integration: PEP implemented directly in application.
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
Conceptually simplest, but in terms of new code to write probably most costly approach is shown in
Fig-4.1: just build a TAS3 compliant PEP into the legacy application. This approach has the advantage
of allowing full control over the enforcement process, including the inputs to the Master PDP. The
disadvantage is the learning curve to learn TAS3 architecture in sufficient detail to implement it correctly
and to get certified.
Fig-4.2 depicts a slightly different strategy where application only implements a simple PEP, which
then communiates with the Application Indepentent PEP (AIPEP) supplied by the TAS3 Project. In
this approach, the AIPEP component handles most of the TAS3 specific parts and can be an already
certified component, making compliance certification easier.
However, in this model the need to communicate between AIPEP and ADPEP arises. The communication pattern could be either Encapsulating Security Layer (ESL) or Application Protocol Enhancement (APE), as described in the Section ??
TAS3 ICT-216287
Page 70 of 211
4.3. ADPEP
Data Service
Service Responder
Stack
User
F
E
AIPEP
ADPEP
AIPEP-In
(accept req)
TAS3
SOAP
Application
AIPEP-Out
(filter)
Master PDP
Figure 4.2: Application Integration: ADPEP implemented in application itself.
1494
1495
1496
1497
1498
Fig-4.3 illustrates some specific integration strategies with the intent of enabling legacy data sources
that can not be modified. In (A) the SOA Gateway evolves to support TAS3 architecture, in (B) the SOA
GW is frontended by the WP9 database which supports the TAS3 architecture aspects. If export of the
legacy data is an option, then it may be simplest to import the data to WP9 database and dispense
with the legacy data source entirely (C).
Data Service
Service Responder
Stack
User
F
E
TAS3
SOAP
AIPEP
AIPEP-In
(accept req)
AIPEP-Out
(filter)
Application
Dependent
PEP
WP9
SOA Gateway
WP9
database
WP9
database
Legacy
Data Source
WP9
SOA GW
Data
A
B
C
Master PDP
Figure 4.3: Application Integration using ADPEP and (A) SOA Gateway, (B) WP9 DB as frontend to SOA GW,
(C) WP9 database.
TAS3 ICT-216287
Page 71 of 211
4.3. ADPEP
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
4.3
ADPEP
The Application Dependent Policy Enforcement Point (ADPEP) is a gateway that provides access to
the TAS3 infrastructure for applications like web applications with a web frontend, business process
engines, databases or repositories and many other systems, which are either requesting or responding
over a TAS3 secured and trusted channel. Per section 2.2.1 (see also Fig-2.2), the ADPEP belongs to
the Front End Services and Web Service components inside the Payload boundary.
As described in Section 2.2.2, the ADPEP is divided into two different types of Application Dependent
Policy Enforcement Points:
1. ServiceRequester ADPEP: This web service is part of the Front End Services. Internally, the ServiceRequester ADPEP constitutes together with the Stack, the Service Requester. The Stack handles SOAP protocol details. The Application Independent Policy Enforcement Point (AIPEP) contacts Master PDP, which contacts different PDPs like User PDP, Organization PDP or a Trust PDP
to decide whether a requested is trusted or not.
The main task of the ServiceRequester ADPEP is to collect all required information for an appropriate request that has to be checked by the TAS3 authorization infrastructure. Further information about the payload, which builds up the request, can be found in [TAS3D81RepoSW] figure
8. Common information about the functionalities of the ServiceRequester ADPEP can be found in
[TAS3D81RepoSW] and in [TAS3D83CliSW].
The next steps before sending the request are done by the ’Stack’. As mentioned before, the ’Stack’
(and its main component: the AIPEP) is application independent. Its main task is the preparation
of the request. The message has to be signed and augmented according to web services binding.
WP4, WP5 and especially WP7 work on this security related part of the service requester. Whereas
WP8 is responsible for the application dependent part.
2. ServiceResponder ADPEP: This second application dependent service, which functions as responder, is part of the Service Responder component in the Web Service boundary (see Fig-2.3). In
analogy to the ServiceRequester ADPEP, the ServiceResponder ADPEP also needs the ’Stack’
(with AIPEP and its underlying PDPs) to function correctly. That means, signing and preparation of
the message according to the web service binding, the policy checks and the communication with
the ’Trust policy decision point’, as done by the ’Stack components’.
The main task of the ServiceResponder ADPEP is to receive requests, route them in an appropriate
way to the ’Service Application’ and then send back the response to the requester. More details
about the functionalities of the ServiceResponder ADPEP can be found in [TAS3D81RepoSW] in
chapter 3.2.
Auxiliary components in the both ADPEP Services
To fulfil the mentioned functions of the both ADPEP Services (Requester and Responder), some
auxiliary services are required. These services belong to tasks (Task 8.3 - see DoW), which are
documented in [TAS3D82BackOffice].
These services neither store person related data nor serve the user directly. They provide ontologies
and metadata, perform search and aggregation operations and transform data into specific formats.
The back office services are a component of the TAS3 Trusted Application Infrastructure but not of the
core TAS3 Trust and Security Infrastructure.
The main Auxiliary or Back Office Services and Components are:
TAS3 ICT-216287
Page 72 of 211
4.3. ADPEP
• The Generic Data Format ([TAS3D82BackOffice], section 2.1.2) used to store data in TAS3
1541
repositories1
1542
• Services to transform ([TAS3D82BackOffice], section 2.1) data from a custom source format to
1543
the Generic Data Format and from the Generic Data Format to a format, which is requested
(and supported).
1544
1545
• Aggregation Service ([TAS3D82BackOffice], section 2.2) and Policy Aggregation ([TAS3D82BackOffice],
1546
chapter 8)
1547
• Request Logger Service ([TAS3D82BackOffice], section 3.2) to store information on requests
1548
issued and responses received by TAS3 web services for auditing and maintenance purposes
1549
1
Marc: not applicable for eHealth because of legal issues.
TAS3 ICT-216287
Page 73 of 211
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
5 Using Business Process Modelling to Configure the
Components
This section addresses Reqs. D1.2-3.2-ModelDrivenCfg, D1.2-3.12-SPManifest, D1.2-6.3-WhatHowWhyWho,
and D1.2-6.4-Min.
The TAS3 architecture covers a lot of functionality and some of this functionality needs to be configured carefully to match each other to ensure smooth operation from the perspective of the users, such
smooth operation is perceived by users as dependability and trustworthiness, so it is a prerequisite for
good public image of a Trust Network.
Correct configuration will also be essential for ensuring that services function securely. Given that
most security technology is quite brittle and even minute misconfigurations lead to failure, there will
be operational and commercial pressure to turn off those nonfunctional, but essential features that
appear to be "causing trouble". This is an extremely dangerous slippery slope that any Trust Network
MUST avoid. Liberty Alliance and SAML Interoperability and Certification programmes have clearly
demonstrated this to be a real peril. Therefore it is necessary that it is possible to correctly configure
the trust network such that it will work right on the first try.
Complexity of a typical Trust Network, along with all of its member systems, is of such a high degree
that it is infeasible to configure it sufficiently correctly by a manual approach. Humans make mistakes.
An automated, model driven configuration is the only way to create accurate and correct configuration.
1570
The corner stone is Business Process Modelling. From this model, which exists both at the top Trust
Network level and at the organizational level, it should be possible to derive the following outputs:
1571
1. Circle of Trust parameters to facilitate federation and SSO configuration
1569
1572
a. White list of roots of trust for both authentication and authorization
1573
b. Trusted Certificates for TLS [RFC3548] and Signing
1574
c. Metadata for entities
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
2. Declarative Statements about attribute needs of the Clients as well as policies under which providers
are willing to release attributes. This output will come in the form of [CARML] and [AAPML] files,
see further [IGF], that can be used to automatically configure IGF enabled layers of Client Request
PEP and Provider Request PEP.
3. Some of the top level policies that apply to the Trust Network and its members. This should facilitate
configuration of the PDPs.
4. Policies, Business Process Models, and Interface Descriptions (e.g. WSDL) that are needed as
input for the Automated Compliance Validation.
5. Business Process Models that are needed as input for Business Process Visualization at the Dashboard.
6. Policy and business process model descriptions needed by the Configuration and IT infrastructure
management, e.g. CMDB, ITIL, etc.
TAS3 ICT-216287
Page 74 of 211
1587
1588
1589
1590
1591
1592
1593
1594
1595
Contractual information behind a business process will influence the business process model itself
and has an impact on the security rules, roles, and policies related to the business process.
Security rules that guide selection of web services and use of secure entities (data), i.e. influence
the discovery service.
Security exceptions during business processes will raise an exception. Unhandled exceptions will
block or break the process (go to an operator or help desk). The challenge is to handle the exceptions
by explicit routines in the business process modelled routines or in some cases by using alternative
paths (i.e. subprocesses) to allow the process to complete or even to look ahead and avoid exceptions
before they occur by such means.
1596
Business processes can have more complex topology than just trees.
1597
There is no centralized log, just references to local logs are passed out.
TAS3 ICT-216287
Page 75 of 211
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
6 Oversight and Monitoring
For a TAS3 compliant Trust Network to gain a trustworthy reputation and to ensure that belonging
to the Trust Network really enables lower cost of operation through lesser fraud, improved trust, and
ultimately less need for formal audits, it must take proactive and mandatory activities to monitor its
activities and stop any fraudulent practises before they become a problem, ideally even before they
become publicly known.
This section addresses Reqs. D1.2-2.11-Transp, D1.2-2.12-Compr, D1.2-2.15-Resp, D1.2-2.16Mitigate, D1.2-2.17-AuditUntamp, D1.2-2.21-DataProtLaw, D1.2-2.22-GovtAccess, D1.2-12.13-Vfy,
and D1.2-12.15-Valid.
In TAS3 , the monitoring should happen at levels of
1. Continued automated, robotic, testing that compares results to both modelled expectations and
past results. This is one of the focus areas of TAS3 . See: On-line Compliance Testing (OCT).
2. Operations monitoring to determine upness and performance of services, as well as detection
of anomalies. Trouble ticket system for reporting and rectification of operational errors, as well
as intrusion detection scans and monitoring are included here as well. Use of industry standard
solutions is recommended as TAS3 does not plan additional research in this area.
3. Log audit. Some part of log audit is handled in operations monitoring, above, but logs will contain
a wealth of additional information, such as usage patterns to inform new investment and areas
of innovation, which can be extracted using data mining techniques. Use of industry standard
solutions is encouraged in general as the only connection with TAS3 research is in the area of
gathering inputs for reputation scoring.
4. Formal compliance audits should occasionally be carried out manually to ensure that the automated
monitoring and audit mechanisms, above, are functioning correctly. These audits may be mandated
by legislation or by governance agreement and are typically fairly costly affairs with reputable outside consultants specializing in organizational and IT audits. TAS3 contribution for this area stems
from recommendations and guidelines of the project legal team.
5. Administrative Oversight. The Trust Guarantor will take necessary administrative steps to ensure
that the Trust Network is adequately monitored, mostly automatically, but with necessary and timely
manual intervention. The Trust Guarantor may, according to the Governance Agreement, be monitored by an Advisory Board, Management Board, and ultimately General Assembly.
1630
Section of 4.3.7 "Management" of [NexofRA09] discusses the need for management interfaces in
services components. TAS3 is compatible with these requirements.
1631
6.1
1632
This section addresses Reqs. D1.2-6.14-Compat, D1.2-6.15-MinPolicy, and D1.2-12.16-OnlineTst.
1629
1633
1634
1635
1636
On-line Compliance Testing
Implementation of SOA based applications result from the integration of several services. Services
composing an application can change at run-time without informing all the other services integrated in
the application. Furthermore, features like dynamic binding, or context-dependency prevent knowing
before run-time the actual interaction among service instances.
TAS3 ICT-216287
Page 76 of 211
6.1. ON-LINE COMPLIANCE TESTING
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
Speaking in general terms, services are typically controlled and owned by different organizations.
Thus, dealing with architectures that are not under the full control of one organization, means that
the service lifecycle cannot be structured in well-defined development stages. In particular, for a
(composite) service it is not clear when testing activities starts or should end.
To ensure trust and dependability the TAS3 architecture must also include adequate technology and
actors to test that services within a TAS3 Trust Network behave in compliance with their expected
specifications. Such testing activities must be performed on-line by special TAS3 guards, verifying that
the services with a choreography actually behave as expected.
To achieve trustworthy SOA, there is the need to develop and use a methodology and tools supporting the "perpetual" (i.e. event-driven, periodically) and automatic testing of software services. The
benefits with the "perpetual" and automatic testing we envision:
1648
• repeatability of testing (improving the efficiency and the efficacy of the test)
1649
• increase the quality and the trust perceived by the users of the service
(optional, in
the future)
Model and
Interface Policy
Organization under test
FE
under
test
PDP
under
test
Test, Test,
Policy Test
Robot
Test
WS
under
test
Report
Test, Test, Test
Frontend GUI
Test Robot
Web Service
Test Robot
cmp
Planner
OCT
(schedule tests)
Expected
Test Results
Deployment Compliance Validation Agency
(contracted by Trust Guarantor)
Past Real
Test Results
(optional, in
the future)
Figure 6.1: Overview of On-line Compliance Testing
1650
1651
1652
1653
1654
1655
1656
1657
1658
The extent to which compliance is tested may vary, also depending on the registration information
that should accompany services (e.g. models describing interfaces, policies, usage, etc.), which is
part of the governance contract.
A minimal assumption is that services should access and perform within a TAS3 infrastructure according to an explicitly declared set of policies and that the infrastructure should not allow violation to
the declared policy, or at least should recognize such violation. Testing is applied in order to reduce the
risk that services within a TAS3 infrastructure will get in contacts with unreliable services. Therefore
services within a TAS3 compliant infrastructure will be regularly submitted to testing session aiming to
assess that a service does not break its policy.
TAS3 ICT-216287
Page 77 of 211
1662
As important remark, we advise that this on-line testing approach does not prevent the execution of
canonical off-line testing activities (e.g. where the service is tested by its developer trying to anticipate
possible usage scenarios), rather it is an additional mean to increase the trustworthiness of the TAS3
architecture.
1663
6.1.1 Involved Actors
1664
On-line Compliance Testing impacts on the following of actors of the TAS3 scenario.
1659
1660
1661
1665
• Ecosystem
1666
- Service Provider
1667
- Reputation Providers
1668
- Software Certification agencies
1669
- Deployment certification and audit agencies
1670
- Compliance Authority
1671
• Components
1672
- Web Service (WSP)
1673
- IdP (Identity Provider)
1674
- Service Registry
1675
- Id Mapper
1676
- Linking Service
1677
- Organizational PDPs
1678
- Trust Network PDP
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
6.1.2 On-line Testing Process and Architecture
The TAS3 architecture includes an on-line testing infrastructure, in which, the TAS3 services are tested
according to a set of published models describing specific behavioural characteristics of the service
itself. In the following, the term OCT refers both to the on-line compliance testing process and to the
infrastructure that implements it.
With respect to the current scope of the TAS3 architecture, the compliance testing functionality
requires that each service exposes within the TAS3 choreography its public interface (i.e. its exported
operations) and the public policies it will comply with (or a references to them). In particular, each
service is tested on-line when it requests to be registered to a TAS3 directory service. Further on-line
test sessions can be activated by the compliance testing (i.e. Trust Network level) directory service
either in event-driven or periodic fashion.
Directory Services within a TAS3 architecture interact with testing components to detect services
failures . The compliance testing increases trust both on the TAS3 architecture and the linked services.
A software service willing to be registered to a TAS3 directory service, may also have to comply with
other policies that are not publicly manifested. In this case the service will not be tested with respect
to such policies since such behaviour is hidden from the external interfaces of the service.
TAS3 ICT-216287
Page 78 of 211
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
During the on-line compliance testing process, references to the service should not be retrievable
by means of the directory service. At the end of the compliance verification process, if and only if all
the tests have been successfully executed, service references will be listed by the directory service.
During the on-line testing, the OCT activates tester robots. Each tester invokes the service under
test simulating service requests with identity credentials taken from a pre-packed identity test suite.
The tester robot collects the service reply (i.e. either a response message, or a deny access), and
compares it with the expected results: a difference between the service reply and the expected result
reveals a mismatch between how the service policy is manifested and how the policy is implemented
within the service.
Note that the TAS3 architecture has a precise requirement that error messages returned after a
request for a resource (e.g. "access denied" message) must be identifiable as such. Applications might
masquerade error messages for user-friendliness (e.g. they could produce a "pretty formatted" page);
nonetheless, the TAS3 architecture needs to be able to unambiguously recognize error messages
without the need to delve into the semantics of the payload of the message. This is accomplished by
each application declaring to the on-line compliance testing infrastructure at least one successful and
one failing test case with exact description of what the messages look like and what are the relevant
parts.
In real life scenarios, a service under test may need to access external services when invoked by the
tester robot. Indeed, in some cases a testing interaction between the service under test and externally
invoked service may have permanent effects (e.g. on a stateful resource). Let’s consider that the
service under test queries the directory service to lookup a relevant end point. In this case, OCT
should consider that the registry may return a reference to a Proxy version of the required service: this
service will implement the same interface as the required service. Doing so, the real implementation
of registered services is hidden to those services waiting for compliance validation - a useful feature
while project is ongoing and full service is yet unavailable.
In such cases, the directory service and OCT have to be able to link to an existing service proxy or
to generate new ones. Obviously this will increase the complexity of the framework and asks for the
provisioning of service description models suitable for automatic generation of service stubs.
1724
Fig-6.2 depicts a UML Diagram describing the components of the On-line Compliance Testing framework. In the following we list a detailed descriptions of each component:
1725
• Compliance Validator Discovery Service: according to the architecture given in Fig-2.2, this com-
1723
1729
ponent enhances the functionality provided by the Discovery Service. In particular, the Compliance Validator Discovery Service is a Discovery Service able to apply the compliance validation
at runtime. The Compliance Validator Discovery Service aggregates three sub-components: the
Compliance Validator, the Proxy Factory and the Pending Services DB.
1730
• Compliance Validator : this component activates the testing session when a service makes a
1726
1727
1728
1733
request for being included in a TAS3 infrastructure. The testing session will result in a sequence
of invocations to the services requesting to be registered. In case the testing session does not
highlight any error the service will be registered otherwise the request will be rejected.
1734
• Tester Robot: this is the component that actually runs the test on a given service. In particular,
1731
1732
1736
the Compliance Validator activates the Tester Robot passing to it a reference to the service that
needs to be tested and to the corresponding test suites to use.
1737
• Request Generator: this component defines which is the next invocation to make to the service
1735
1738
under test in order to assess its correctness;
TAS3 ICT-216287
Page 79 of 211
1739
1740
1741
1742
1743
• Test Checker: this is the component that checks that the replies of the service under test actually
conform to what is specified;
• Test Attribute Generator: this component defines which attribute values are to be used in the
testing invocations.
• Front Channel Tester: this component extends the Tester Robot adding to the tester component
1747
specific features to interact with the front channel of a service application in TAS3 . Since this
component is a Tester Robot, it has all the features that a Tester Robot has, including the
relationship with the other components (e.g. Request Generator, Test Checker, Test Attribute
Generator).
1748
• Back Channel Tester: this component extends the Tester Robot adding to the tester component
1744
1745
1746
1752
specific features to interact with the back channel of a service application in TAS3 . Since this
component is a Tester Robot, it has all the features that a Tester Robot has, including the
relationship with the other components (e.g. Request Generator, Test Checker, Test Attribute
Generator).
1753
• DB of Roles as Signed Test Response: this DB contains the identity test suite that the tester can
1749
1750
1751
1754
1755
1756
1757
1758
1759
1760
1761
1762
use to test other services simulating a different identity.
• DB Test Report: in this DB the compliance validator logs the result of a testing session and the
possible failures highlighted.
• Proxy Factory: this component automatically generates proxy services to simulate already registered services.
• Pending Services DB: this DB will contain the identities of services that requested to enter a
TAS3 infrastructure precinct but still did not pass the testing session. Services in such DB are
not returned as result of a discovery request. Identities are removed from this DB when the
corresponding testing session is terminated.
1764
Note that, each entity (i.e. components or artifacts) in the diagram, has a role with respect to the
domain organization. Specifically, according to the general architecture depicted in Fig-2.2:
1765
• The artifacts Public Interface, and Public Policy, are entities within the Modelling & Configura-
1763
1766
1767
tion Management area,
• The OCT components (Compliance Validator Discovery Service, Compliance Validator, Tester
1770
Robot, Request Generator, Test Checker, Test Attribute Generator, Front ChannelTester, Back
Channel Tester, DB of Roles, DB Test Report, Proxy Factory, and Pending Services DB) are
entities within the Audit & Monitor area,
1771
• The components IDP, Discovery Service, and Web Service, are entities within the Runtime &
1768
1769
1772
Enforcement area.
TAS3 ICT-216287
Page 80 of 211
package Data[
ContinuedAutomaticComplianceValidationArch
<<component>>
FrontChannel Tester
<<component>>
Tester Robot
<<component>>
BackChannel Tester
]
<<artifact>>
Public Interface
For example according to the
SP-Initiated SSO with Redirect
and POST Bindings schema at
Fig.12 of the SAML
Specification
<<manifest>>
<<component>>
Web Service
Likely SAML
Tokens
<<component>>
Request Generator
<<component>>
Test Checker
<<manifest>>
Test Invocations
<<use>>
<<component>>
DB of Roles as
Signed Test Response
<<artifact>>
Public Policy
<<component>>
IDP
Registration Request
<<component>>
Discovery Service
Extracted Form the idP
During Test Preparation
Extracted Form the Directory Service
During Test Preparation
<<component>>
Test Attribute
Generator
<<component>>
CompliaceValidator
<<component>>
DB Test Report
<<use>>
<<component>>
Compliance Validator
Discovery Service
<<component>>
Proxy Factory
<<component>>
Pending Services DB
Figure 6.2: UML Component Diagram of the On-line Compliance Testing (OCT).
TAS3 ICT-216287
Page 81 of 211
6.2. OPERATIONS MONITORING AND INTRUSION DETECTION
1773
1774
1775
1776
1777
1778
1779
6.2
Operations Monitoring and Intrusion Detection
[NexofRA09], section 4.3.7 "Management", paragraph 4, highlights the need for operational monitoring.
While such monitoring is not a requirement for technical interoperability of TAS3 framework, it will be
necessary to maintain reputation of TAS3 Service Provider and/or Trust Guarantor. This topic is not an
area for TAS3 research work. Consequently:
1. Standard operations monitoring approaches such as SNMP [RFC1157] and Nagios [Nagios] SHOULD
be implemented.
1782
2. Each organization in the Trust Network MUST be protected by network level firewall or packet filter.
Any deny events from the firewall SHOULD be fed to the Intrusion Detection Channel of the Audit
Event Bus.
1783
3. Each organization in the Trust Network SHOULD operate an Intrusion Detection System (IDS) to
1780
1781
1784
a. Detect well known attacks (e.g. ping of death)
1785
b. Port scanning
1786
c. Abusive patterns of usage
1787
1788
1789
1790
1791
1792
1793
Any suspicious events from the IDS SHOULD be fed to the Intrusion Detection Channel of the Audit
Event Bus.
6.3
Log Audit
This section addresses Reqs. D1.2-2.17-AuditUntamp, D1.2-3.3-Dash, D1.2-6.10-Redress, and D1.27.21-Safe.
Log audit has several goals
1. In case of attempted repudiation, prove that events happened
1795
2. For investigation, browse and visualize events so that a human investigator can get a relevant and
sufficient overview.
1796
3. On an ongoing basis automatically detect noncompliant events
1797
4. On an ongoing basis ensure that the systems are functioning correctly
1798
5. Provide statistics about users and their behaviour
1799
6. Provide statistics about system use and behaviour
1794
1801
7. Provide baseline of information that allows trust, security, and access control mechanisms to be
cross checked
1802
Log audit raises several issues
1803
A. Collection
1800
TAS3 ICT-216287
Page 82 of 211
6.3. LOG AUDIT
1804
B. Distribution
1805
C. Privacy
1806
D. Retention
1807
E. Falsification
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
F. Omission
G. Denial of Service and overwhelming the logging system
The log audit could also be used for billing in some circumstances, but in general we recommend
that billing systems be built separately so that they can be cross checked against the logging to detect
errors.
A taxonomy of audit events is presented in Annex G "Enumeration of Audit Events".
Some design requirements for Audit Log Files are discussed in [TAS3D42Repo]. Further requirements include
I. Append mode of access: Only append mode of access should be allowed, so that users or
applications cannot rewind an audit log file and delete or modify information that has already
been stored there
II. Authorised writing: Only authorised parties should be able to append log records to the audit trail.
Though unauthorised applications or attackers may gain access to the audit trail and try to append
fake log records to the audit trail, or modify or remove the audit trail, this should be detected by
the tamper detection mechanism.
III. Timestamps: Every record in the audit trail should be timestamped to provide a trusted record of
when the audit data was received. We note that if the audit service is trusted to record the audit
data without tampering with it, then it should also be trusted to append the correct time to the
data. Therefore we do not require a secure time stamping service.
IV. Secure communication: if the audit service operates as a web service then there should be secure
communications between the clients and the server in order to ensure tamper resistance, data
integrity and authorised connection.
V. Secure storage on untrusted media: Since an audit trail may be viewed on untrusted machines,
the security mechanisms should ensure persistent and resilient storage of the audit trail, and
ensure detection of tampering of the audit trail - modification, deletion, insertion, truncation, or
replacement. If tampering is detected, the audit service should be able to notify the security
auditor.
VI. Support multiple simultaneous clients: The audit service should be easily and conveniently accessible and it should be able to serve multiple client applications simultaneously.
VII. Logging efficiency: The computational work and the storage size required by the audit service
should be as efficient as possible.
VIII. Contents transparency: the audit service should be able to record any digital content coming from
any repository service.
TAS3 ICT-216287
Page 83 of 211
6.3. LOG AUDIT
1841
1842
1843
IX. Authorised reading: Since the audit trail may contain personal or sensitive information, then the
audit service should ensure that only authorised applications or people have the privilege to read
the audit trail. The audit trail may be encrypted to further protect confidentiality.
1844
6.3.1 Log Collection and Storage
1845
This section addresses Req. D1.2-2.22-GovtAccess.
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
In the TAS3 architecture the audit trail is collected and stored locally primarily at the system entities,
such as SPs, IdPs, the IM, and the like or near them in the organizations that operate these entities.
Everyone that collects a log is bound by a Governance Agreement so that responsible behaviour can
be enforced when technical solutions fall short in some area of protection.
The log events originate in various components at various times, see Annex G "Enumeration of Audit
Events" for an idea of the types of events that will be generated. For example, Web Services Stack
component will check signatures on the tokens (assertions) that are presented and log both positive
and negative outcomes.
The system entities that collect the audit trail or the centralized audit function of the organization
report the events in summary form, essentially just pointers to the actual audit records, to the Audit
Event Bus. Each component may keep its local log in its own format (in future we may provide standard
format), but the summary logging to the Audit Event Bus will follow TAS3 standard format (this format
will be presented in a future version of this architecture). To facilitate standard format summary logging,
TAS3 may provide a reusable software library.
The Audit Event Bus is divided in channels to which different events are broadcast. This allows
minimal exposure as subscriptions can be on the basis of only relevant events. The subscriptions
can also be controlled such that only authorized parties with "need to know" can see certain types of
events (see req IX above).
The Audit Event Bus is potentially implemented as part of a more generic Event Bus infrastructure,
but due to special privacy and security requirements, Audit Events MUST NOT be mixed with other
business messages, unless in encrypted form. If the generic event bus supports an encrypted private
channel, a VPN if you like, then sharing of the infrastructure may be possible.
1870
The Audit Bus infrastructure MUST be free of conflicts of interest. In particular, it should not be
operated by one of the SPs. In case the Event Bus sharing is implemented, then the operator of the
shared infrastructure MUST be free of conflict of interest as well.
1871
6.3.2 Privacy Issues: What to Collect and What to Report
1868
1869
1872
1873
1874
This section to be fleshed out in project month M30 release of D2.1. It will satisfy Req. D1.2-4.2BPPrivacy.
The main issues are
1875
1. Avoid logging anything that could become a correlation handle
1876
2. Avoid logging PII unless absolutely necessary
1877
1878
1879
Generally a lot of detail will be logged locally. This will include the tokens used in identification the
user, usually in pseudonymous form as well as the PII handled by the Service Provider. This detail
tends to be necessary to legally protect the Service Provider.
TAS3 ICT-216287
Page 84 of 211
6.4. FORMAL COMPLIANCE AUDITS
1880
6.4
Formal Compliance Audits
1881
This section will be developed in the D2.1 of M30.
1882
- Legal compliance
1883
- Penetration testing
1884
- Disaster recovery exercises
1885
6.5
1886
This section partially addresses Req. D1.2-6.10-Redress.
1887
1888
1889
Administrative Oversight
Administrative oversight and stake holder issues are covered in [TAS3BIZ], reproduced in Annex E
"Business Model", .
This section will be developed in the D2.1 of M30.
TAS3 ICT-216287
Page 85 of 211
1890
1891
7 Conclusion: TAS3 is Secure and Trustworthy
1894
Comprehensive approach of the TAS3 architecture and framework achieves real and tangible overall
security and trustworthiness gains when compared with state of the art for multiplayer networks of
comparable size. TAS3 features that contribute to this are
1895
1. Legal concerns are built-in from the ground up
1896
2. A comprehensive and strong digitally signed audit trail
1892
1893
1898
3. A conditionally pseudonymous audit trail to guarantee the privacy of Users who play by the rules,
while allowing abuse to be exposed through collaboration of Service Providers.
1899
4. A fully pseudonymous design at all layers to protect user privacy
1900
5. Fully encrypted and digitally signed messages using strong algorithms
1897
1901
1902
6. Based on state-of-the-art Single Sign-On protocol standard (SAML 2.0) which has had extensive
security review
1903
• Extensive security review and scrutiny already done
1904
• Multiple commercial and open source implementations that are mature.
1905
• Certification program for implementations further ensures quality
1906
1907
7. Based on state-of-the-art Identity Web Service Protocol standards (ID-WSF 2.0) which have had
extensive security review
1908
1909
• Multiple commercial and open source implementations
1910
• Certification program for implementations further ensures quality
1911
1912
8. Enhanced authorization infrastructure which significantly improves upon the current XACMLv2
standard
1913
1914
• Multiple commercial and open source implementations
1915
9. Ability to use risk control and reputation
1916
10. Use of ontologies to ensure consistent interpretation of data and authorization rules
1917
11. On-line Compliance Testing for early detection of discrepancies and problems
1918
12. Business Process Modelling driven configuration to ensure consistently correct configuration
1919
1920
1921
1922
13. TAS3 has performed a systematic threat analysis (see Annex F) to ensure that the architecture
addresses the widest possible range of security and privacy threats.
14. Software engineering techniques used by the project to consistently achieve high quality and absence of security bugs in the software components that are TAS3 deliverables.
TAS3 ICT-216287
Page 86 of 211
1923
1924
1925
1926
1927
1928
1929
TAS3 Architecture is novel as a blueprint that brings together identity management, attribute based
access control, business process modelling, and dynamic trust. The architecture, with Annex A, acts
as an interoperability profile for various standards based protocols covering these areas. Other areas
of innovation are user transparency features like Dashboard, user accessible audit trail, and automated
compliance validation; privacy protection using sticky policies; marriage of trust and privacy Negotiation with discovery and trust scoring; secure dynamic business processes; and built-in first class
support for delegation.
TAS3 ICT-216287
Page 87 of 211
1930
1931
1932
1933
1934
1935
1936
1937
1938
Annex A: Protocols and Concrete Architecture
This section describes the TAS3 Concrete Architecture and protocol choices in a normative and
prescriptive way. Please note that the high level architecture described in the preceding sections can
be implemented using other protocols than the ones chosen here. To promote interoperability we
make fairly specific choices. If you choose to use other choices, you MUST NOT call your system
TAS3 compliant and you SHOULD write a profile that describes your choices.
To complement the specification of protocols here, the reader may want to consult Fig-8.18 in
[HafnerBreu09] for an overview of the functinality available in various specifications.
1941
The choice of procols has been guided by commitment to open standards as recommended in
section 2 of [UNDP07]. This also serves to address Reqs. D1.2-2.4-MultiVendor, D1.2-2.5-Platform,
and D1.2-2.6-Lang.
1942
A.1
1943
This section addresses Reqs. D1.2-2.18-AnCredi, D1.2-6.12-Sec, D1.2-7.3-An, and, D1.2-7.10-Target.
1944
A.1.1 System Entity Authentication
1939
1940
1945
1946
Supported Authentication and Login Systems
TAS3 adopts X.509v3 public key certificates as primary means of authenticating system entities. This
will apply over TLS and ClientTLS connections and may also apply in digital signatures.
1948
For bilateral authentication Client TLS MUST be supported. HTTP Basic authentication MAY be
supported.
1949
A.1.2 SAML
1947
1953
Given the already broad adoption of SAML 2.0 by the eGovernment and academid communities across the world (e.g. DK, NZ, etc.), this choice is effectively already made for
us. By choosing SAML 2.0 we enable many existing eGovernment and academic projects
easily to become TAS3 compliant in future.
1954
1. TAS3 adopts SAML 2.0 Assertions, see [SAML2core], as primary and recommended token format
1950
1951
1952
1956
2. TAS3 adopts SAML 2.0 as primary and recommended SSO system, see [SAML2core]. (Req. D1.23.10-JITPerm)
1957
3. TAS3 RECOMMENDS that SAML 2.0 implementations are Liberty Alliance Certified.
1958
4. SAML 1.0, 1.1 [SAML11core], 1.2, as well as Liberty ID-FF 1.2 [IDFF12] MAY be supported
1955
1959
1960
5. Redirect - POST SSO profile MUST be supported by all front channel participants, see [SAML2prof]
and [SAML2bind].
1962
6. Redirect - Artifact - SOAP SSO profile MUST be supported in IdP and SHOULD be supported in
Front End (SP), see [SAML2prof] and [SAML2bind].
1963
7. Redirect Single Logout Profile MUST be supported, see [SAML2prof] and [SAML2bind].
1961
TAS3 ICT-216287
Page 88 of 211
A.1. SUPPORTED AUTHENTICATION AND LOGIN SYSTEMS
1964
8. IdP Extended Profile, see [SAML2conf], namely IdP Proxying, MUST be supported
1965
9. Other SAML profiles MAY be supported
1966
1967
1968
1969
1970
1971
1972
1973
1974
10. SAML metadata MUST be supported, see [SAML2meta]
11. Well Known Location (WKL) method of metadata exchange MUST be supported, see [SAML2meta]
section 4.1 "Publication and Resolution via Well-Known Location", p.29, for normative description
of this method.
12. In redirect binding [RFC1951] deflate compression MUST be used. [RFC1952] format MUST NOT
be used.
A.1.2.1 Authentication Request
1. MUST use NameIDPolicy/Format of Persistent when implementing Pull Model (Req. D1.2-7.8NoColl).
1976
2. MUST use NameIDPolicy/Format of Transient when implementing Linking Service based Push
Model.
1977
3. MUST set NameIDPolicy/SPNameQualifier
1978
4. MUST set NameIDPolicy/AllowCreate flag at all times true
1979
5. SHOULD not set IsPassive flag (in some cases there may be justified reasons to do otherwise)
1980
6. MUST use AssertionConsumerServiceIndex
1981
7. MUST NOT use ProtocolBinding or AssertionConsumerServiceURL
1982
8. Step-up authentication, using Authentication Context Class References MUST be supported.
1983
A.1.3 Shibboleth
1975
1984
1985
1986
Shibboleth MAY be supported. Shibboleth based on SAML 2.0 is RECOMMENDED. Supporting Shibboleth enables higher education institutions to adopt TAS3 with minimal reconfiguration and reinvestment.
1991
We have not fully validated all use cases with Shibboleth. Specific points of contention include lack
of full user identification, e.g. statement that User is a student or staff member of university, without
giving out a persistent pseudonym. While a valid approach that better protects the user’s privacy than
the use of a persistent ID, it may not be able to address all the use cases, especially in the commercial
world where service providers wish to link a user’s requests together.
1992
A.1.4 eID
1993
European eID cards are supported as an authentication method available at SAML 2.0 IdP.
1994
A.1.5 Smart Cards
1995
Smart cards are supported as an authentication method available at SAML 2.0 IdP.
1987
1988
1989
1990
TAS3 ICT-216287
Page 89 of 211
A.1. SUPPORTED AUTHENTICATION AND LOGIN SYSTEMS
1996
A.1.6 One-Time-Password Tokens
1998
One-Time-Password Tokens, such as RSA Tokens or Yubikey, are supported as an authentication
methods available at SAML 2.0 IdP.
1999
A.1.7 OpenID
1997
2001
OpenID [OpenID] MAY be supported. If supported, OpenID 2.0 MUST be used as earlier versions
have known security flaws.
2002
It should be noted that OpenID’s globally unique identifier model does not provide privacy protection.
2000
2006
We have not validated whether it is possible to implement TAS3 architecture using OpenID. One
specific point of uncertainty is passing the IM bootstrap token at SSO time. No native OpenID mechanism is known to exist (standadized; ad-hoc approaches are known). One suggestion, applicable to
the RESTful binding would be to use OAUTH.
2007
A.1.8 CardSpace / InforCard and WS-Federation
2003
2004
2005
2009
Card Space MAY be supported. If supported, at least SAML 2.0 token format MUST be supported.
The token MUST also support passing IM bootstrap token.
2010
A.1.9 CA / Netegrity Siteminder Proprietary SSO
2008
2011
2012
2013
2014
2015
Siteminder MAY be supported. However, we have not validated whether it is possible to implement
TAS3 architecture using Siteminder. Prospects do not look particularly good as the Siteminder protocol
and product can not easily be configured to convey the IM bootstrap token.
• Not standards compliant, but by far the most relevant player on the market
A.1.10 Citrix, Sun, and other proprietary SSO
2017
MAY be supported. However, we have not validated whether it is possible to implement TAS3 architecture using these.
2018
A.1.11 Web Local Login
2019
We have not validated whether it is possible to implement TAS3 architecture using local login approach.
2016
2020
*** should validate ASAP
2021
• Ad-hoc approaches
2022
2023
2024
A.1.12 Desktop Login
We have not validated whether it is possible to implement TAS3 architecture using desktop login approach.
2025
• Terminal servers: Mind-The-Box, Citrix, Windows TS, etc.
2026
• Active Directory PDC
TAS3 ICT-216287
Page 90 of 211
A.2. SUPPORTED IDENTITY WEB SERVICES SYSTEMS
2028
The Desktop login approach suffers from similar security problems as the Fat Client Login, which
see below.
2029
A.1.13 Fat Client Login
2030
We have not validated whether it is possible to implement TAS3 architecture in this case.
2027
2031
2032
2033
The main security problem in Fat Client Login is that the fat client itself becomes an intermediary
to the authentication process, handling sensitive credentials. Some notion of Trusted Computing Path
may help to address verifying that the fat client is not compromised.
2035
If Fat Client Login is a requirement, we RECOMMEND Liberty Advanced Client approach, see
[AdvClient] and [SOAPAuthn2].
2036
A.1.14 User Not Present or Batch Operations
2034
2039
Currentely no standards based support. TAS3 specifies some approaches for doing this, see [TAS3D41ID],
mainly based on using advanced authorization to obtain discovery token without authenticating the
User.
2040
A.2
2041
The web services must satisfy some technical requirments
2037
2038
2042
2043
2044
2045
2046
2047
Supported Identity Web Services Systems
• Messages MUST be correlated, so each response is bound to request in an auditable way
- Message ID correlation
- Business Process Model and Instance IDs (or context or instance) to allow overarching
correlation of several request-response pairs (e.g. to avoid actors who would have conflicts of interest overall that might not be identified when only working at level of individual
request-response pairs)
2049
- PDP can receive this easy enough as an environment parameter and this is needed
to support dynamic separation of duties
2050
- Gap: business process modelling does not express this?
2051
- Consider URL format hierarchical ID
2052
- Better typed, like LDAP DN format, or query string
2048
2053
• Requester and Responder MUST be identified (Req 10.4)
2054
• Synchronous web service calls MUST be supported
2055
• Asynchronous calls SHOULD be supported where needed. Business Process Engines will han-
2056
2057
dle asynchrony.
• Subscribe - Notify mechanism SHOULD be supported where needed
2058
- subscription for events will be vital to pick up errors and notify of events like break the glass
2059
- subscribe and publish ws-eventing
TAS3 ICT-216287
Page 91 of 211
2060
2061
2062
- Event bus as a subscribe and publish mechanism
• Maximum availability and use digital signature and encryption technologies, i.e. technical solutions to security and trust problems.
2063
A.2.1 Framework
2064
1. MUST support SOAP 1.2
2065
2. MUST support XML-DSIG [XMLDSIG], a.k.a. RFC3275
2066
3. MUST support Exclusive XML Canonicalization [XML-EXC-C14N]
2067
4. MAY support simple sign [SAML2SimpleSign]
2068
5. MUST support XML-Enc [XMLENC]
2069
A.2.2 Liberty ID-WSF
2070
1. MUST support 2.0
2071
2. MAY support 1.2
2072
3. MUST support following sec mechs, see [SecMech2]
2073
- "urn:liberty:security:2005-02:TLS:Bearer"
2074
- "urn:liberty:security:2006-08:TLS:SAMLV2" (Holder-of-Key)
2075
2076
4. MAY support following sec mechs for testing, but MUST NOT permit their use in production environments
2077
- "urn:liberty:security:2005-02:null:Bearer"
2078
- "urn:liberty:security:2006-08:null:SAMLV2" (Holder-of-Key)
2079
5. MAY support other TLS [RFC2246] based sec mechs
2080
6. MUST NOT permit non TLS sec mechs in production environments
2081
7. Implementations SHOULD be Liberty Alliance certified, see [IDWSF2SCR].
2084
8. Implementations MUST support <ProcessingContext> urn:liberty:sb:2003-08:ProcessingContext:Simul
SOAP header and implement a "dry-run" feature using it. Partially satisfies Reqs. D1.2-12.13-Vfy
and D1.2-12.16-OnlineTst.
2085
A.2.3 Bare WS-Security Header or Simplified ID-WSF
2082
2083
2087
1. SHOULD NOT use, as many important security features such as message correlation, replay detection, and identification of end points are not supported by this mechanism.
2088
2. Document resultant limitations if not implementing full ID-WSF.
2086
TAS3 ICT-216287
Page 92 of 211
Liberty
Federation
Framework
ID-FF
SAML 2.0
Enables identity federation
and management through
features such as
identity/account linkage
Simplified Sign-On, and
simple session
management.
Liberty Identity Service Interface
Specifications (ID-SIS)
Enables interoperable identity services such as
personal identity profile, contact book,
presence, and so on
Liberty Web Services
Framework (ID-WSF)
Provides the framework for building interoperable
identity services, permissions based attribute
sharing, identity service description and discovery,
and the associated security profiles.
Liberty specifications build on existing standards
(SAML, SOAP, WS-Addressing, WS-Security, XML, etc.)
Figure A.1: Liberty Alliance Architecture.
2089
2090
A.2.4 WS-Trust
• MAY support [WSTrust]
2092
We have not validated whether it is possible to implement TAS3 architecture using WS-Trust. ***
validating this is a priority
2093
• Needs heavy profiling to be interoperable, users of WS-Trust should undertake to write such
2091
2094
2095
2096
2097
2098
2099
profile.
A.2.5 RESTful Approach
MAY support. We RECOMMEND support on basis of OAUTH [OAUTH], but implementers should take
in account security advisories published on oauth.net web site.
We have not validated whether it is possible to implement TAS3 architecture using RESTful approach.
2101
RESTful enablement is nice to have, but should not compromise elegance of the SOAP solution and
may be less capable (i.e. it is enough that the RESTful approach solves front channel use cases).
2102
A.2.6 Message Bus Approach
2100
2103
2104
2105
• MAY support AMQP [AMQP06]
*** We need to investigate how this would actually work. Focus of the investigation is likely to be
AMQP as that has been pencilled for use in Audit Event Bus.
TAS3 ICT-216287
Page 93 of 211
A.3. AUTHORIZATION SYSTEMS
2106
A.3
2107
This section addresses Reqs. D1.2-2.19-AzCredi and D1.2-2.20-Az.
2108
A.3.1 Authorization Queries
2109
1. MUST support XACML 2.0 [XACML2] request-response contexts for authorization queries
2110
2. MAY support other versions of XACML
2111
3. MAY support XACML policy language
2112
2113
Authorization Systems
4. MUST support XACML SAML Authorization Query extension [XACML2SAML] in order to allow
policies to be dynamically passed to the PDP
2121
All communication between the PEP and PDP will be using SOAP based XACML SAML profile. This
profile is mostly independent of rules language. Thus the PERMIS and trust and reputation language
specificity will be mostly contained within the PDPs themselves. The only exception is the obligation
vocabulary which must be understood by the PEP and therefore needs to be standardised. This is a
major effort that will be started in the TAS3 project. On the other hand, the sticky policies, which will be
passed over the wire in the protocol exchange, will be engineered such that they transparently pass
from the data store to the appropriate field of the XACML request without the PEP proper really having
to understand them.
2122
A.3.2 Policy Languages
2123
TAS3 does not mandate any specific policy language. However, consider following possibilities:
2124
1. PDP SHOULD support XACML 2.0 policy language [XACML2]
2125
2. PDP MAY support PERMIS x.x policy language
2126
3. PDP MAY support P3P x.x policy language
2127
4. PDP MAY support PrimeLife x.x privacy policies
2128
A.4
2114
2115
2116
2117
2118
2119
2120
Trust and Security Vocabularies
2130
Usage of ontologies in TAS3 is thoroughly addressed in [TAS3D22UPONTO], which will map some of
these vocabularies.
2131
A.4.1 Vocabularies for Authorization
2132
Some work has been done in RADIUS [RFC2138] and Diameter [RFC3588].
2129
2133
[SAML2context] is mainly about authentication, but authorization is also touched.
2134
This section will be expanded in a future version of this document.
TAS3 ICT-216287
Page 94 of 211
A.5. REALIZATION OF THE DISCOVERY FUNCTION
2135
A.4.2 Vocabularies for Basic Attributes (PII)
2136
Use of following vocabularies of PII is RECOMMENDED:
2137
• LDAP inetOrgPerson [RFC2798]
2138
• Liberty Personal Profile specification [IDPP]
2139
• X.500 standards, such as [X520] and [X521]. See also [RFC2256].
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
A.4.3 Discovery Vocabularies
Main vocabulary for discovery is the Service Type taxonomy described in [Disco2]. This taxonomy is
complemented by discovery options that further describe the service. This vocabulary SHOULD be
used when applicable.
Each Liberty service specifies its own Service Type value as well as a number discovery options.
For example, see [IDDAP], [IDPP], or [DST21].
A.4.4 Security and Trust Vocabularies
See [SAML2context] and [SecMech2] for a vocabulary of security mechanisms that MUST be used
when applicable.
A.4.5 Audit Vocabularies
Audit events from RADIUS [RFC2139] and Diameter [RFC3588] are RECOMMENDED for use where
applicable.
2157
This section will be expanded in a future version of this document. As audit is active research topic,
we benefit from the research during the TAS3 project to specify this section in detail in the final version
of thie document.
2158
A.5
2155
2156
Realization of the Discovery Function
2159
• MUST support Liberty ID-WSF 2.0 Discovery Service specification [Disco2]
2160
• MAY support [Disco12]
2161
• MAY support UDDI, however this may require significant extentions to UDDI. Such extentions
2162
2163
2164
2165
2166
would need to be profiled.
See [NexofRA09], section 5.4 "The Overview-Model", fig 18, for a view of the interaction between
service registration and service discovery. Unfortunately the referred document fails to recognize the
need for per-identity service registrations, unless the oblique reference, where no difference is made
between service requester entity and the data subject, in section 5.4.4 "Service Discovery" counts.
TAS3 ICT-216287
Page 95 of 211
A.6. REALIZATION OF THE TRUST AND PRIVACY NEGOTIATOR FUNCTION
2167
2168
2169
2170
2171
2172
2173
2174
A.6
Realization of the Trust and Privacy Negotiator Function
The protocol to realise the trust negotiation functionality has yet to be finalised. Candidate protocols
are:
i. the one used by TrustBuilder 2 [TrustBuilder2]
ii. one based on the Web Service Profile of XACML [Anderson07] as enhanced by [Mbanaso09]
iii. one based on an enhanced Liberty Discovery Service [Disco2]
Whichever protocol is finally chosen it must be able to support a ceremony to gaining incremental
levels of mutual trust. The Web GUI of the Front End MUST support the ceremony.
2176
Trust and Policy Negotiation generally takes authentication and identifiaction of all parties for granted,
but then computes a trust score which typically governs the access control decisions.
2177
A.7
2178
A.7.1 Audit Event Bus
2179
Tentative protocol choice (in order of preference):
2180
1. AMQP [AMQP06]
2181
2. Liberty Accounting Service [AcctSvc] with subscriptions and notifications [SUBS2] and [DesignPat].
2182
3. Diameter [RFC3588]
2183
4. RADIUS [RFC2138]
2184
A.7.2 Audit Event Ontology
2175
2185
2186
2187
2188
Realization of the Audit and Dashboard Function
• Enumeration of mandatory edit events according to some standard
- RADIUS and Diameter communities have defined at least some messages
• ZXID logging documentation [ZXIDREADME] provides an idea, at least applicable to SSO
A.7.3 Dashboard Function
2189
• Dashboard should also realize the "PII Consent Service" or "Privacy Manager" at large.
2190
• SHOULD support Liberty Interaction service [Interact2]
TAS3 ICT-216287
Page 96 of 211
A.8. REALIZATION OF DELEGATION FUNCTION
2191
A.8
2192
The model and protocol to realize the delegation function is still to be determined. Candidates are:
2193
2194
Realization of Delegation Function
i. Mandate Tokens [Peeters09]
ii. People Service [PeopleSvc] and Cross Principal Referenceing [SOAPAuthn2]
2195
iii. The use of a delegation issuing service [ChadwickEA09]
2196
iv. Other approaches (ID-ToK / WS-Trust) [WSTrust]
2197
2198
2199
2200
2201
2202
v. Ad-hoc and proprietary approaches
The People Service approach supports invitations as described in [TAS3D42Repo] under Section
5.3 Secret URLs. It also supports the whole flow described in 3.3.1. The People Service can be seen
roughly equal to Delegation Service specified in TAS3 architecture and somewhat similar to Delegation
Issuing Service specified in [ChadwickEA09]. Therefore TAS3 shall refine the People Service until it
meets all the requirements.
TAS3 ICT-216287
Page 97 of 211
2203
2204
2205
2206
2207
2208
2209
2210
Annex B: Resilient Deployment Architecture (Non-normative)
This section addresses Req. D1.2-2.8-Avail.
For TAS3 services to be dependable, they need to be deployed so that they are resilient to system
and network failure. Resiliency and efficiency are the first lines of defense against Denial of Service
attacks that try to attack simple catastrophic vulnerabilities or overwhelm the system on the point where
it is most inefficient. Resiliency needs to be considered at several layers, namely on the Front Channel
and on the Back Channel.
UA
UA
Load Balancing and Routing
Frontend Server Farm
Mid tier, SOA
B ackends, core services
Figure B.1: Layering of resilience features for Front Channel, Back Channel, and data center Back End services.
2213
Note that the virtual IP address is hosted either in hardware load balancer, or one member of a
cluster. Fail-over of the virtual IP is arranged using Virtual Router Redundancy Protocol (VRRP)
[RFC3768].
2214
B.1
2215
This section addresses Req. D1.2-7.19-DynaUpd.
2211
2212
2216
2217
2218
2219
2220
2221
2222
2223
2224
Zero Downtime Updates
For continued availability of the system, Zero-Downtime-Update (ZDTU) technilogy SHOULD be
implemented through out. If horizontal scaling path and failure recovery have been implemented, then
ZDTU can be implemented easily by taking out of farm one server at a time and updating it. Downside
of this approach is that the farm will temporarily be in an inconsistent state.
If consistency of the farmis at all times a requirement, no easy ZDTU approach exists. One approach
is to bring up new "hot standbys" along side of the old configuration and then do instantaneous switch.
As the switch over is less than 1 second, this could be considered ZDTU.
Never-the-less, as TAS3 is business process driven and as business processes can take long time
to complete (if human interaction is required, this could easily mean days or weeks), thus consistent
TAS3 ICT-216287
Page 98 of 211
B.1. ZERO DOWNTIME UPDATES
UA
UA
Virtual IP
Redundancy using VRRP
Hardware Loadbalancers
FE2
FE1
WSP-B
WSP-A
Backend I
FE3
Backend II
Backend III
Figure B.2: Resiliency implemented using hardware load balancers.
UA
UA
Virtual IP
Redundancy using VRRP
Hardware Loadbalancers
FE2
FE1
Load Balancing
and Routing
built into products
or protocols
WSP-B
WSP-A
Backend I
FE3
Backend II
Backend III
Virtual IP provided
by Clustering
Data Replication
to maintain coherence
Figure B.3: Resiliency implemented using software load-balancing-fail-over functionality and clustering.
2225
2226
ZDTU is infeasible in practise and the business process modelling should explicitly foresee handling
of upgrade situations, i.e. how old processes are handled after the general upgrade.
TAS3 ICT-216287
Page 99 of 211
2227
2228
Annex C: Compliance Requirements
2229
C.1
Other Work
2230
• [SAML2conf]
2231
• [IDWSF2SCR]
2232
C.2
2233
C.2.1 Legal and Contractual Compliance Requirements
2234
CR21-Lawful All legal requirements MUST be satisfied. Members MUST operate within the law.
2235
CR22-Arch All normative requirements of [TAS3ARCH] MUST be satisfied.
2236
CR23-Proto All normative requirements of [TAS3PROTO] MUST be satisfied.
2237
2238
2239
General Compliance Requirements
CR24-File Each member MUST be registered on the file at the Trust Guarantor. The filing MUST
include details appropriate for the jurisdiction to identify the entity to the extent needed to raise
a law suit and/or coordinate investigation with the tax authorities. Typically this means at least
2240
a. Entity name
2241
b. Address
2242
c. Company registration or VAT number
2243
d. Version of Governance Agreement signed and date signed (Req. D1.2-6.13-Contract)
2244
2245
2246
2247
2248
Whenever this information changes, the member MUST prompty inform the Trust Guarantor.
CR25-Policy Each member MUST conspiciously publish a Privacy Policy and Terms of Use for their
services on the internet. Member must make available a registry description and offer consultation, rectification, and/or removal of PII.
The Policy and the Terms MUST address at least
2249
a. Entity name and contact for inquiries
2250
b. Data retention policy
2251
c. How is User identified (database keys, properties, such as pseudonymity, of identifier, etc.)
2252
d. With whom data is exchanged and why
2253
e. Whether the policy may change and how existing customers are handled upon the change.
2254
A member MUST adhere to its own Policy and Terms.
TAS3 ICT-216287
Page 100 of 211
C.2. GENERAL COMPLIANCE REQUIREMENTS
2255
2256
2257
2258
2259
2260
C.2.2 General Technical Compliance Requirements
CR26-SSL All transactions that have monetary value or pass authentication credentials MUST run
over encrypted (e.g. TLSv1, SSL or VPN) or physically secure network connections. Alternately
the payload itself may be encrypted to similar strength, e.g. using [XMLENC].
For a network to be considered secure, it must achieve a security level equivalent to using any
of the following cipher suites (assuming safe and sound key management practises):
2261
a. RSA1024-MD5-3DES-CBC
2262
b. DSA1024-SHA1-AES128-CBC
2263
c. RSA-AES-128-SHA
2264
d. TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
2265
2266
2267
This compliance requirement satisfies Reqs. D1.2-2.21-DataProtLaw and D1.2-6.11-Confid.
CR27-Sig All digital signatures MUST achieve at least the security level equivalent to using any of the
following cipher suites (assuming safe and sound key management practises):
2268
a. RSA1024-SHA1
2269
b. DSA1024-SHA1
2270
2271
2272
2273
2274
2275
2276
See threat T141-AltSig.
CR28-Vfy When data is signed, the intended recipient (see Audience) MUST verify the signature and
MUST reject the operation if the verification fails. Verification of the signature MUST include in
addition to the actual crypto operations, establishing that the signature was generated by the
claimed trusted source.
For each verification, whether failed or successful, audit trail items MUST be generated, documenting at least
2277
a. Signed data or its message digest (SHA1 or MD5)
2278
b. Who signed and how his trustworthiness was established
2279
c. Date of signature and vertification and the credibility of both
2280
d. Outcome of the verification
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
e. In case of verification failure due to failed message digest, the input to the message digest
function
f. In case of verification failure due to failed public key crypto operation, the input to the
operation (e.g. the message digest of the signed data).
See threat T141-AltSig.
CR29-Revoc Whenever long lived or revocable credentials are used (e.g. public key in signature
verification), a revocation list or online status service (e.g. OCSP) SHOULD be consulted. If
credential is SAML assertion, then long lived means more than 60 seconds. The revocation
check SHOULD be done using Assertion Query Profile described in [SAML2prof].
The result MAY be cached for efficiency for duration indicated in relevant protocol and architecture specifications, but lacking clear indication, it should not be cached for longer than risk
assessment dictates (if you are confused, do not cache for more than 10 seconds).
TAS3 ICT-216287
Page 101 of 211
C.2. GENERAL COMPLIANCE REQUIREMENTS
2293
2294
CR210-Rnd All signature and crypto operations MUST use a secure source of cryptographically
strong random numbers. Acceptable sources include
2295
a. Hardware approaches based on electic noise
2296
b. /dev/random
2297
c. /dev/urandom on busy machines and when seeded from strong source
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
d. Pseaudo random number generator with at least 128bit cycle, when seeded from a strong
source (such as user input as in PGP).
Unacceptable sources include
i. Any predictable source
ii. Only seeding with current time and/or process identifier
iii. Less than 128bit cycle or search space
The random number pool should be consulted whenever new randomness is needed, but at the
same time care should be taken to make sure that the pool is not unduely depleted of entropy.
This is especially a risk whe using /dev/urandom.
Care should be taken to not to leak the random numbers except as strictly mandated by the
protocols.
CR211-Uniq Whenever unique identifiers are called for, uniqueness must either be absolute (within
specified namespace) or statistical with at least 128bits of search space.
See threat T61-Replay.
CR212-Trail Audit trail, including logs, MUST be digitally signed or otherwise tamper proof. Tamperproofness MUST achieve at least the security level equivalent to using any of the following cipher
suites (assuming safe and sound key management practises):
2315
a. RSA1024-SHA1
2316
b. DSA1024-SHA1
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
Depending on circumstances, such as hosting of services in a untrusted data center, the logs
SHOULD also be encrypted to achieve a security level equivalent to using any of the following
cipher suites (assuming safe and sound key management practises):
i. RSA1024-MD5-3DES-CBC
ii. DSA1024-SHA1-AES128-CBC
See threat T142-Tamper.
This compliance requirement addresses Reqs. D1.2-2.17-AuditUntamp, D1.2-2.15-Resp, D1.26.10-Redress, D1.2-6.17-TechBind, D1.2-4.4-CourtProof.
CR213-Backup All backups or batch data transfers MUST be in encrypted form ensuring security level
equivalent to using any of the following cipher suites (assuming safe and sound key management
practises):
TAS3 ICT-216287
Page 102 of 211
C.3. COMPLIANCE REQUIREMENTS FOR GOVERNING AGREEMENTS
2328
a. RSA1024-3DES-CBC
2329
b. DSA1024-AES128-CBC
See threat T101-LeakBackup and Req. D1.2-2.21-DataProtLaw.
2330
2331
2332
2333
2334
2335
2336
2337
CR214-CertSAML If SAML assertions are involved the software implementation MUST have passed
the relevant SAML certification administered by the Liberty Alliance certification program.
CR215-CertIDWSF If Liberty ID-WSF is involved the software implementation MUST have passed the
relevant certification administered by the Liberty Alliance certification program.
CR216-EntAn When Systems Entities are required to authenticate each other or assymmetrically one
party, HTTPS MUST be supported and other X509v3 certificate based methods (PKI) MAY be
supported. HTTP Authentication header based methods MAY be supported.
2341
Authentication requirement CAN be satisfied at VPN, SSL, or application layer (e.g. application
layer credentials or trusted digital signature over data). In any case, the authentication MUST
be part of the audit trail in a cryptographically strong way and SHOULD be referenced by the
summary audit events.
2342
This satisfies Req. D1.2-7.3-An.
2338
2339
2340
2343
2344
2345
CR217-CertCert Certificates used for entity authentication and digital signatures MUST be obtained
from a trustworthy authority. Designation of acceptable authorities MUST be made in the Governance Agreement of the Trust Network.
2349
CR218-PrivKey Private Keys MUST be adequately protected. In the minimum this should mean
procedural protections against exposure during generation, certification, install, and backup, as
well as operational protection using file system permissions. Disclosure of private keys MUST
be on strictly need to know basis.
2350
C.3
2351
CR30-GA Governing Agreement should at least address
2346
2347
2348
2352
Compliance Requirements for Governing Agreements
a. Governance structure, such as advisory and audit boards
2354
b. Criteria to join and stay on the network, including certification and audits (Req. D1.2-6.14Compat)
2355
c. Process for removal from the network
2356
d. Process for complaints, arbitration, and disciplinary action (Req. D1.2-6.9-Complaint)
2357
e. Commercial liability and its fair appropriation
2353
2358
f. Liability due to negligence in criminal cases and its fair appropriation
2359
g. Privacy protection
2360
h. Redress for users that have suffered unwarranted disclosure (Req. D1.2-6.10-Redress)
2362
i. Minimal mandatory security practises and policies (Reqs. D1.2-6.11-Confid and D1.26.15-MinPolicy )
2363
j. Acceptable use for Service Providers
2361
TAS3 ICT-216287
Page 103 of 211
C.4. COMPLIANCE REQUIREMENTS FOR TRUST GUARANTORS
k. Acceptable use for Users
2364
l. Requirement to be legally bound (Reqs. D1.2-6.16-Bound and D1.2-6.17-TechBind)
2365
2366
2367
CR31-CheckList Any prospective Trust Network member should document the answer to the following questions:12
2368
a. Are you collecting or using PII as part of the service?
2369
b. Do you have a Privacy Policy that you are bound to follow?
2370
c. Do you use PII for any purpose other than providing the service?
2372
d. Do you get User’s consent or let him opt out before his information is used for other purposes than providing the specific service?
2373
e. Do you share my information beyond your company or family of companies?
2371
f. Do you get my consent or let me opt out before your share my information with any other
company not needed to provide the specific service?
2374
2375
g. Do you allow me to manage these preferences over time and change my options?
2376
2377
C.4
Compliance Requirements for Trust Guarantors
2379
CR41-CoI Trusted Guarantor MUST NOT have a conflict of interest with any of the parties that are
designed to trust it.
2380
CR42-Records Trust Guarantor MUST maintain credible business records, including:
2378
a. Members of the Trust Network (see CR24-File).
2381
2382
C.5
Compliance Requirements for Service Providers
2384
CR51-DNSpub Service Provider MUST use DNS to publish its network addresses in a symbolic form.
This requirement facilitates reconfigurations of the network. It is a well accepted "best practise".
2385
CR52-BPM Service Provider’s business processes MUST be modelled.
2383
2386
2387
2388
2389
2390
CR53-DontLogTok Service Requester SHOULD NOT log, even in encrypted form, the the tokens
destined to the Service Responder or other parties if threat T107-LogTokLeak is a concern. If
audit trail requires logging tokens, then the tokens must be blinded so that the correlatable part
is not visible or the token MUST be encrypted such that legitimate viewers of audit trail can
decrypt it, but SP itself can not.
Compliance with this requirement is established with audits.
2391
2392
2393
CR54-CorrConsent Service Provider MUST have user’s consent before leaking a correlation handle
of any kind.
1
2
This list is from Joseph’s "Convening Trust Authority" presentation, 20090320
*** needs rewrite to disambiguate my and me
TAS3 ICT-216287
Page 104 of 211
C.6. COMPLIANCE REQUIREMENTS FOR SERVICE REQUESTERS
2394
2395
2396
CR55-MDExp Service Provider MUST implement Well-Known Location (WKL) method of metadata
export, see [SAML2meta] section 4.1 "Publication and Resolution via Well-Known Location",
p.29, for normative description of this method.
2400
CR56-MDImp Service Provider MUST implement Well-Known Location (WKL) method of metadata
import, see [SAML2meta] section 4.1 "Publication and Resolution via Well-Known Location",
p.29, for normative description of this method. The Import MUST NOT unintentionally lead to a
trust relationship.
2401
CR57-VfyAn Service Provider MUST authenticate the Service Requester according to CR216-EntAn.
2397
2398
2399
2403
CR58-An Service Provider MUST authenticate itself to the Service Requester according to CR216EntAn.
2404
C.6
2402
2405
2406
2407
2408
2409
2410
Compliance Requirements for Service Requesters
CR61-DNS Service Requester MUST use DNS to resolve names. This requirement facilitates configuration and provides a load balancing method (round robin DNS) for the SPs. DNS query results
MUST NOT be cached beyond their TTL.
CR65-MDExp Service Requester MUST implement Well-Known Location (WKL) method of metadata
2414
CR66-MDImp Service Requester MUST implement Well-Known Location (WKL) method of metadata
trust relationship.
2415
CR67-VfyAn Service Requester MUST authenticate the Service Provider according to CR216-EntAn.
2411
2412
2413
2417
CR68-An Service Requester MUST authenticate itself to the Service Provider according to CR216EntAn.
2418
C.7
2416
2419
2420
2421
Compliance Requirements for Databases Storing PII
Since Databases Storing Personally Identifiable Information (PII) usually are SPs, the requirements for
SP also apply.
A future version of this document will specify in detail
2422
• Special encryption concerns
2423
• Special privacy protection
2424
• Record keeping and audit
TAS3 ICT-216287
Page 105 of 211
C.8. GENERAL COMPLIANCE REQUIREMENTS FOR TRUSTED THIRD PARTIES
2425
C.8
General Compliance Requirements for Trusted Third Parties
2427
CR81-CoI Trusted Third Party MUST NOT have a conflict of interest with any of the parties that are
designed to trust it.
2428
C.9
2426
2429
2430
2431
2432
2433
Compliance Requirements for Identity Provider
CR91-CoI Identity Provider MUST NOT have a conflict of interest with any of the Service Providers or
Users. In general, IdP functions can not be performed by a SP.3
CR95-MDExp Identity Provider MUST implement Well-Known Location (WKL) method of metadata
2437
CR96-MDImp Identity Provider MUST implement Well-Known Location (WKL) method of metadata
trust relationship.
2438
C.10
2434
2435
2436
2439
2440
2441
2442
2443
Compliance Requirements for Discovery Providers
CR101-CoI Discovery Providers MUST NOT have a conflict of interest with any of the Service Providers
or Users. In general, the discovery and token mapping functions can not be performed by a SP.
CR105-MDExp Discovery Service MUST implement Well-Known Location (WKL) method of metadata
2447
CR106-MDImp Discovery Service MUST implement Well-Known Location (WKL) method of metadata
trust relationship.
2448
C.11
2444
2445
2446
Compliance Requirements for Trust and Reputation Provider
2450
CR111-CoI Trust and Reputation Provider MUST NOT have a conflict of interest with any of the Service Providers or Users to which it provides trust scorings.
2451
C.12
2449
2452
2453
2454
Compliance Requirements for Audit Provider
CR121-CoI Audit Provider, Audit Event Bus operator, or shared Event Bus Operator MUST NOT have
a conflict of interest with any of the Service Providers or Users. In general, apart from SP internal
audit, the audit functions can not be performed by a SP.
3
David: An organisation can run both an IDP and an SP. How does this requirement stop this from happening. And large
multinationals will run both. So this requirement cannot be enforced.
TAS3 ICT-216287
Page 106 of 211
C.13. TAS3 -LITE COMPLIANCE PROFILE
2455
2456
2457
2458
2459
2460
2461
2462
2463
C.13
TAS3 -Lite Compliance Profile
The compliance requirements have been drafted to ensure true security and accountability. However
we recognize that some of the compliance requirements are quite onerous and could be a hindrance
to TAS3 adoption in some low value situations. Therefore we define in this section a TAS3 -Lite profile
that can be used in low value situations as long as the risks are recongnized and the deployment is
not misrepresented as fully TAS3 compliant. The TAS3 -Lite relaxations are as follows:
1. CR24-File and CR25-Policy are dropped. Informal means should be used to achieve the same end
result. Dropping these requirements seriously compromises the ability of the Trust Network and the
Users to hold parties accountable.
2465
2. CR214-CertSAML and CR215-CertIDWSF are dropped due to financial cost of the certification.
Attending cheaper informal interop events is still highly recommended.
2466
3. CR217-CertCert is dropped. Self-certification is allowed.
2464
2468
4. CR30-GA is dropped. Informal governance structure is allowed. The consequence of this is most
likely that parties can not be held responsible in case of serious violations.
2469
5. CR52-BPM is dropped. Informal modelling is still recommended.
2467
TAS3 ICT-216287
Page 107 of 211
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
Annex D: Generalized Use Cases
Non-normative. The simulated user interface screenshots in this section are NOT normative. They serve merely to illustrate one feasible way of designing the user interface.
The user interface flows are also non-normative, for example the IdP detection or alreadylogged-in detection may follow different paths. Every step of the way, confirmation questions, wizards, and other user interface devices may be inserted. Depending on business
model and branding choises of the Trust Network, there may be some graphical guidelines
and restrictions, see [TAS3BIZ] and Governing Agreement of the Trust Network.
This section addresses Req. D1.2-2.13-Easy, among others.
These Use Cases deal with User Interaction, therefore they do not illustrate the rather large Web
Services proportion that TAS3 architecture mainly aims to address. Never-the-less, in a User Centric
system, we must start with the user - without his impulse (direct or indirect) the back-end Web Services
should never happen.
A general assumption has been that Single Sign-On (SSO) will be used, though some other approaches are foreseen as well. Long tail services should especially use SSO as it is unreasonable to
ask for user registration for one-off service request.
IdP A
Alumni Portal
(Front End)
Job Agency
(Front End)
Alice
(principal)
Dashboard
Federated SSO
Figure D.1: User accesses Front Ends using Single Sign-On.
2487
2488
2489
2490
2491
2492
2493
2494
Methodology. In the Story Boards that follow, the sequence describes user’s preception. It does NOT describe protocol flow, which can at times be quite different from User’s
preception. For example, many SSO protocols call for HTTP redirects, so technically
speaking any transfer between screens should pass via User Agent. A big circle in diagram means a protocol step that usually is optimized so that no page is shown to the
user (but astute users may notice some flicker). When the optimization for some reason
does not work out, the regular user interface screen will be shown. We apply Cognitive
Walkthrough method [Wharton94] to elaborate the story boards.
TAS3 ICT-216287
Page 108 of 211
D.1. USER USES SERVICE (FIRST TIME IN THE SESSION)
2495
D.1
User Uses Service (First Time in the Session)
2496
The first time use of a service in a session consists of
2497
• First the User interacts with the Front End (FE)
2498
• The User is redirected to IdP (cf. Req 3.1 Existing Accounts)
2499
• The User logs in at IdP
2500
• The User is redirected back to the protected content
2501
This means minimum three steps, but there could be more if there are confirmation questions.
Trust Seals. As can be seen, the user interface is expected to display trust seal of the
Trust Network and may display TAS3 seal as well. These are intended as visible indicators that public associates with trust. Their exact design and realization, including the
possibility of not displaying them at all, will depend on the particular Trust Network.1
2502
2503
2504
2505
1
Alumni Portal
TAS3
TN
2
TAS3
TN
Please Login
You have requested protected
content, please login.
Using: IdP 1
Identity Provider 1
Username:
Password:
Login
3
Login
Alumni Portal
TAS3
TN
Welcome, Alice!
Here is your study plan.
... (protected content)
User
Figure D.2: Story board: Using service for 1st time in a session.
2506
Cognitive Walkthrough
2507
1. Choice of IdP
1
Some skeptics argue that trust seals provide false sense of security, pointing out that in practise sites with seals, like
"Verified by Verisign", have in fact been more fradulent that the sites without the seals. This may, however, be simple defect
in management of those seal programs.
TAS3 ICT-216287
Page 109 of 211
D.2. ALREADY-LOGGED-IN OPTIMIZATION (SSO)
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
Motivation User has taken initiative to perform a task he thinks can be accomplished using a web
site. He realizes that some form of authentication or authorization will be required. When the
User navigates to the task, a dialog is presented asking for authentication so that authorization
can be granted. User will consider engaging in this dialog because they feel the sytem is
trustworthy, based on the Trust Seals and based on past successful experiences.
Available and understandable User will be guided by modality of the interaction to a situation
where he will either have to proceed with selection of an IdP or will have to abandon the task.
Choosing another task that does not require authentication is also an option. The interaction
should be structured such that the requirement for authentication will become evident early
on, so that User avoids performing work only to find out that he is unable to proceed.
Feedback The available IdP choices that are presented should be as narrow and relevant as
possible. Federated SSO research recognizes IdP selection as a major problem. Once IdP is
chosen and button is pressed, clear feedback is provided that User has landed on the IdP web
site. The IdP screen should provide contextual information about the task which motivated the
authentication (such feedback is lacking in step 2 of Fig-D.2).
2. Login
Motivation User is in the mind set of completing a task and will perform this step if he reasonably can. This mind set is reinforced by IdP providing feedback as to what task requires the
authentication.
Biggest challenge and incovenience for the User will be the necessity to present authentication credentials. This inconvenience can be mitigated by use of Single Sign-On.
2527
2528
2529
2530
2531
2532
2533
2534
2535
Available and understandable Availability of the logon and the acceptable forms of credentials
should be self-evident from the first screen of the IdP. First screen should lay visible all options
and avoid any hierarchical navigation to arrive to the desired option.
Feedback Successful authentication will lead to User being returned to the Front End web site.
This in itself is a form of feedback, but it should be reinforced by the web site providing a clear
welcome greeting, stating that the User has been authenticated (and possibly authorized as
well).
2536
3. Login complete. This use case ends here, but an application specific use case will start here.
2537
D.2
2538
2539
Already-Logged-in Optimization (SSO)
Same as above, but without IdP authenticating the user again. The flow does not need to stop at IdP
at all. Optimized SSO use case, showing the full convenience of SSO, leading to 2 step process.
2540
2541
2542
1. Choice of IdP: Same cognitive walkthrough as in previous section.
2543
2. Login: No cognitive walkthrough needed as no user interface will be presented.
2544
3. Login complete. This use case ends here, but an application specific use case will start here.
TAS3 ICT-216287
Page 110 of 211
D.3. USER USES DASHBOARD
1
Job Agency
TN
TAS3
(2)
Identity Provider 1
Using: IdP 1
Session already
active, no need
to login again (SSO).
Login
3
Job Agency
TAS3
TN
Welcome, Applicant!
Here are your competencies.
User
Figure D.3: Story board: Using further services after logging in at IdP - Single Sign-On (SSO).
2545
D.3
2546
This use case addresses Reqs. D1.2-2.11-Transp and D1.2-3.3-Dash.
2547
2548
User Uses Dashboard
In this use case the user interacts with the TAS3 Dashboard in order to determine the status of a
business process he is engaged in. It consists of the following steps:
2549
• The user logs into the Dashboard (possibly using SSO)
2550
• The user sees a page with an overview of the transactions
2551
• The user drills down to visualise a particular business process.
2552
• The user views a particular audit trail and discovers a suspect item.
2553
• The user requests a legally binding audit statement about the transaction.
2554
• Competent authority requests further information about the transaction from the Service Provider
2555
that holds the detailed audit trail.
2556
2557
1. Engaging Dashboard and Choice of IdP
2558
2559
2560
2561
Motivation User has taken initiative to find out about the state of some business process or the
handing of his PII. User understands, due to training or awareness campaigns, or because
a noice was given in the beginning of the business process, that this is possible. User may
have found out about the possibility by surfing the web or through a search engine. The mere
TAS3 ICT-216287
Page 111 of 211
(1)
(2)
Dashboard
Identity Provider 1
IdP is detected and
User automatically
redirected to it.
Session already
active, no need
3
TAS3
TN
Welcome, Alice!
1. Currently open processes
- Competencies certification at Job Agency
- Life-long learning at Alumni Portal
2. Recent completed processes
Click
- M.Sc. degree
3. Archive
User
4
Dashboard
Dashboard
TAS3
Competencies Certification at Job Agency
Active Business Process Visualization
You Are Here
AP
TN
5
Dashboard
TAS3
TN
Detail of request to Alumni Portal
Req ID X23AD of 30.3.2009 by Job Agency
* Requested Information: Name, DoB
* Policy pledges: PL334 (non commercial)
* Returned Information: Name, YoB
* Obligations: O765 (retention)
* Audit trail pointers: M123, R343, T225
Click
Figure D.4: Story board: Using Dashboard to audit a business process.
2562
2563
2564
possibility may spark the User’s interest and get him to try the Dashboard out. User may
also have noticed an irregularity or complained to some instance and been told to consult his
Dashboard.
2566
Available and understandable Since User is assumed to take initiative, a major hurdle will be
how the user finds out about the Dashboard and how to contact it. Some possibilities
2567
a. A link to the Dashboard is provided as part of the user interface of each business process.
2565
TAS3 ICT-216287
Page 112 of 211
2568
b. A link to Dashboard is provided in every web site that participates in the Trust Network.
2569
c. Trust Network operates some sort of a portal and the link can be found there.
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
d. Dashboard engages in Search Engine Optimization (SEO) so that User is sure to find
the Dashboard through a popular search engine.
Once the user has found out about the Dashboard, the problem shifts to the IdP selection and
authentication. In Fig-D.4 we have assumed that IdP can be detected and User is already
logged in, as the case typically would be immediately after engaging some Front End (e.g.
the Job Agency).
However, if time has passed, user may need to choose explicitly an IdP and explicitly authenticate, as in Section "User Uses Service (First Time in the Session)". A confusing situation can
arise where user has tried to access the Dashboard, but the first screen he sees is the IdP
authentication screen (because IdP detection worked, but user was not logged in yet). This
situation should be mitigated either by IdP providing enough context about the operation that
is motivating the authentication, or by the Dashboard imposing a splash screen even when
IdP choice is already known.
Feedback If IdP was detected and user was already logged in, the first feedback will be Dashboard
logged in welcome screen. If authentication is needed, then the IdP context message or the
splash screen solutions should be adopted, as described in the previous paragraph.
2587
2. Login: no specific cognitive walkthrough requirements. See discussion in in the First Time use
case.
2588
3. Choose Business Process to Audit
2586
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
Motivation User set out on his quest to perform this task.
Available and understandable The list of the business process instances should be structured so
that all business process instances are reachable while at the same time the processes user is
most likely to be interested in are presented first or more prominently. Due to potentially large
number of processes, we may need to resort to hierarchy or search functions. An ontology of
business processes will help in setting up the hierachy and search.
The business processes should be titled and described in language that the User can relate
to. In particular, while codes can be provided for accuracy and reference, every business
process should have a human readable name. The resultant translation issues will have to be
recognized and addressed.
Feedback Choice of a business process instance will lead to its visualization where User can
clearly identify What, Who, When, and similar information so that user can confirm he has
made the right choice. If choice was wrong, User should easily be able to choose another
instance.
4. Choose Detail of Business Process Instance to Audit
Motivation Once user sees visualization of the business process instance, he will need to drill
down to relevant detail. This may be driven by User’s curiosity or perceived notion of culpable
part.
TAS3 ICT-216287
Page 113 of 211
D.4. IDP DETECTED-OPTIMIZATION (SSO)
2607
2608
2609
2610
2611
Available and understandable The visualization has to be structured so that it honestly depicts
the essence of the business process without cluttering the view with details that can be
reached later. Every step that User is expected to perform (or has already performed) should
be visible as well as major processing steps that are not in User’s control, especially those
that involve transfer or manipulation of PII.
All descriptions of the steps should be succinct and in human language, with translation issues
addressed. Codes and references for the instance and steps can be provided for accuracy,
but these should never supplant the human description.
2612
2613
2614
To assist User in drilling into detail, the user interface should make it patently evident where
this possibility exists, e.g. by using high-lighting techniques.
2615
2616
2617
2618
2619
2620
2621
2622
Feedback User is assisted in contemplating the choice of drill-in by high-lighting of available options. Once a step is chosen for scrutiny, user will see visualization of that step in great detail.
The visualization will be titled in such a way that it is evident to the User that it pertains to the
step he chose in the business process instance overview.
5. View detail and request audit item from Front End
Motivation User needs to get evidence about a step of a process
2623
6. View audit item (not depicted in the figure)
2624
7. Escalate (not depicted in the figure) (Req. D1.2-6.9-Complaint)
2625
D.4
IdP Detected-Optimization (SSO)
2628
This flow, see Fig-D.5, can further optimize the already logged in case by allowing the Job Agency to
detect that the user has already chosen IdP and therefore use the IdP to log the User in automatically.
Essentially the ceremony becomes a one step process.
2629
D.5
2626
2627
User Uses Service, Identity Selector Case
2632
In the Identity Selector flow, see Fig-D.6, the User never interacts with the IdP directly. Instead, the
Identity Selector provides a user interface (step 3) for the IdP to query authentication credentials. User
experience is entirely managed by the "ceremony" that the Identity Selector presents.
2633
D.6
2630
2631
2634
2635
2636
2637
2638
2639
2640
User Uses Service, Local Login Case
N.B. This use case is not recommended. You should use SSO based approaches instead.
We document it here only to illustrate the problems associated with multiple logins.
The assumption is that the user will use more than one service. This highlights the inconvenience
of user having to authenticate separately to each service. There are further complications under the
hood, not least of which are privacy threats. This scenario could be called explicit account linking.
While we consider supporting this scenario to be in scope, we do not recommend it unless there is no
alternative, or as temporary solution.
TAS3 ICT-216287
Page 114 of 211
D.7. USER USES SERVICE, PROXY IDP CASE
(1)
(2)
Job Agency
Identity Provider 1
IdP is detected and
User automatically
redirected to it.
Session already
active, no need
3
Job Agency
TAS3
TN
Welcome, Applicant!
User
Figure D.5: Story board: Fully automatic login - Single Sign-On (SSO) - when IdP can be detected.
1
Job Agency
TN
TAS3
2
Identity Selector
Choose Identity Provider for This Transaction:
content, please login using
Identity Selector
Login
Alice
at
IdP2
Alice
at
IdP1
TAS3
TAS3 TN
TN
Click
User
4
Job Agency
TAS3
TN
Welcome, Applicant!
3
Identity Selector
Please Login to IdP1
Username:
Password:
Login
Figure D.6: Story board: Identity Selector provides IdP User Interface.
TAS3 ICT-216287
Page 115 of 211
D.7. USER USES SERVICE, PROXY IDP CASE
1
Job Agency
TAS3
TN
2
Please Login
Username:
Password:
Alumni Portal
TN
TAS3
Please Login
Username:
Password:
Login
3
Login
Job Agency
TN
TAS3
Welcome, Applicant!
User
Figure D.7: Story board: Using services with local login (not recommended).
2641
2642
2643
D.7
User Uses Service, Proxy IdP Case
This sequence, see Fig-D.8, illustrates the experience of a user logging in to SP that does not directly
trust his IdP. The trust is mediated by the "middle" IdP that SP trusts.
2646
This sequence can be further optimized if the middle IdP can somehow automatically detect which
IdP is the home IdP (similar to Section IdP Detected Optimization SSO) and, of course, if the User is
already logged in the SSO optimization of Section Already Logged-in Optimization SSO.
2647
D.8
2644
2645
Consenting to PII Release or Manipulation
2649
This section addresses Reqs. D1.2-6.3-WhatHowWhyWho, D1.2-6.6-Consent, D1.2-6.7-Reconsent,
D1.2-4.1-EnfUCPol.
2650
D.8.1 Interaction on Front Channel
2648
2651
2652
2653
The obvious choice of having the requesting SP collect User’s consent has an obvious conflict of
interest issue. In some legal contexts this may be acceptable, but in general we need a way for either
the releasing party or some Trusted Third Party to collect the consent.
2657
Alternatively, not shown here, the user may explicitly provide his consent by authenticating to the releasing party and authorising it to release the PII to the SP. Further user cases for accessing releasing
parties who are repositories and authorising third party access to repository contents are provided in
[TAS3D42Repo].
2658
2654
2655
2656
TAS3 ICT-216287
Page 116 of 211
D.8. CONSENTING TO PII RELEASE OR MANIPULATION
2
Identity Provider 1
(1)
TAS3
Job Agency
TN
Please choose your home IdP.
IdP is chosen by Job
Agency’s trust relationship,
without user input.
Use: IdP 2
Login
User
4
Job Agency
TAS3
TN
3
Welcome, Applicant!
Identity Provider 2
TAS3
TN
Please Login
Username:
Password:
Login
Figure D.8: Story board: Login using IdP not trusted by Job Agency.
2659
1. IdP choice as usual
2660
2. Authentication as usual
2661
3. User triggers action, as usual
2662
4. Consent to release of PII
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
Motivation User will be motivated to take action because it is imposed to him by the modal flow of
the interaction. User will be pleased to take action because asking consent is in his protection,
but Users do get annoyed if you ask too often - to solve this we would need Privacy Agent,
whose Use Cases are to be elaborated later (M30 D2.1?).
Available and understandable Presentation of the consent question is a major challenge. It
needs to be succinct, yet comprehensive and legally binding. Some Users will want high
degree of detail and control, while others will be confused by too many options. Fig-D.9 depicts a dummied-down interface. This may not be appropriate for some users.
Feedback Once consent is given, User lands on page that uses the consented information. This
may be sufficient in its own right, but could be enhanced by high-lighting the information on
the page the user just consented to.
2674
5. Business process continues with the PII as usual
2675
D.8.2 Interaction on side channel
2676
2677
This Use Case is similar to the previous one. Only difference is that the consent is asked using a Side
Channel, such as mobile phone or instant messaging. The side channel provides an independent
TAS3 ICT-216287
Page 117 of 211
1
Job Agency
TN
TAS3
(2)
Identity Provider 1
Using: IdP 1
Session already
active, no need
Login
3
Job Agency
TAS3
TN
Welcome, Applicant!
User
Refresh
4
5
PII Consent
TAS3
TAS3
TN
TN
Job Agency wants to know
your competencies. Please
consent to release of:
[x] High school grades
[x] University diploma
Job Agency
Detail of competency
provided from
University.
Consent
Cancel
Figure D.9: Story board: Presenting a PII consent question in Front Channel interaction.
2678
means of communication, a type of second factor to the consent.
2680
The Side Channel approach can also be convenient when consent needs to be asked deep in SOA
Web Services calls where Front Channel is not available.
2681
In User-not-present transaction the Side Channel may be the only option for asking user’s consent,
2679
TAS3 ICT-216287
Page 118 of 211
1
Job Agency
TN
TAS3
(2)
Identity Provider 1
Using: IdP 1
Session already
active, no need
Login
3
User
C
(4)
Job Agency wants to know
your competencies. Please
consent to release of:
[x] High school grades
[x] University diploma
Reply to this SMS with
code x98sd1 if you agree.
[Reply]
TAS3
Please wait while your consent
is asked via mobile phone.
TAS3
TN
Welcome, Applicant!
SMS
Refresh
SMS
Job Agency
Job Agency
5
Job Agency
TAS3
TN
TN
provided from
University.
Cancel
Figure D.10: Story board: Presenting a PII consent question using Side Channel interaction.
2682
or else the business process needs to be stopped until user provides consent via Dashboard.
TAS3 ICT-216287
Page 119 of 211
2683
2684
2685
D.8.3 Interaction via Dashboard
In User-not-present transaction the business process may stop until user provides input or consent via
Dashboard. This alternative will be covered in a future version of this document.
TAS3 ICT-216287
Page 120 of 211
D.9. USING LINKING SERVICE
2686
2687
2688
2689
2690
D.9
Using Linking Service
1. The Linking Service should be user friendly. It may be the only interface that users see for linking
their attributes together (other approaches are possible, see "pull model").
2. A welcome screen explains the purpose of the Linking Service2 and guides the user through the
process of attribute linking.3 It has
2691
a. Picking list for choosing IdP
2692
b. "Connect" button
2693
c. "View linked accounts" button
2694
d. "Make linked accounts available to services" button
2695
e. Notice or pledge about respecting User’s privacy
2698
3. When the user selects the "Connect" button, the linking service will redirect the user to the selected
IdP, allowing the user to login. After login, the user will be redirected back to the linking service
welcome screen.
2699
4. When the user selects "View my linked accounts" he will be presented with the screen with
2696
2697
2700
2701
2702
a. A table containing two columns, labelled "Organisation" and "Temporary Account Identifier" and
at the left hand side by each table entry will be a tick box that the user can tick to remove the
linked account. Above the column of tick boxes will be the word Delete.
2704
b. "Delete" button, which will remove the chosen accounts from the table and return the user to this
page
2705
c. "Home Page" button, which will take the user to Welcome screen
2703
2707
d. "Make my linked accounts available to services" button, which will take the user to the next
screen.
2708
e. Notice or pledge about respecting User’s privacy
2706
2709
2710
2711
2712
2713
2714
2715
2716
2717
5. When the user selects the "Make my linked accounts available to services" button he will be presented with a screen containing
a. An explanation about opt-in in the linking (if you do not make accounts available, the default will
be no linking).
b. A table with 3 columns and a delete tick box beside each row of the table. The table columns are
"Service", "Organisation" and "Temporary Account Identifier". The table will always be empty for
new users when they first approach this screen.
c. A picking list of all the services in the federation, obtained from the metadata of the federation.
The first entry in the list will be "All Other Services".
2
David: Users must be given confidence that their personal information will be handled with care according to their
instructions, and that it will be deleted when they say so. Part of this is accomplished with messages designed to give the
users confidence and trust in the linking service.
3
David: Users should be offered the minimum of hassle and effort when setting up their links. This means they should be
given picking lists and other aids wherever possible. They should never have to type in long URLs.
TAS3 ICT-216287
Page 121 of 211
D.10. CHOOSING AMONG MULTIPLE SERVICE PROVIDERS
2718
2719
2720
2721
d. Once the user selects a service provider or "All Other Services" from the picking list, a picking
list of all the IdPs that are currently linked together and that appear in the table of the My
Linked Accounts Screen, minus the IdPs that have already been paired with the selected service
provider is displayed.
The first row of this picking list will be "All My Linked Accounts". The user will then pick one of
his linked accounts or "All My Linked Accounts". If the user picks "All My Linked Accounts" a
wild card will be inserted into the third column. If the user picks one of his accounts then the
third column will be automatically completed with the account Persistent ID unless the user has
two or more accounts at the same IdP, in which case the third column will contain a picking list
of Persistent IDs sent from that IdP, minus any already selected for this service provider.
2722
2723
2724
2725
2726
2727
It is important that the table always lists the service providers in alphabetical order so that the
user can easily see which links he has set up for which SPs, and for every SP, the linked IdPs
are in alphabetical order.
2728
2729
2730
2731
2732
2733
2734
2735
2736
e. "Delete" button, which will remove the chosen accounts from the table and return the user to this
page
f. "Home Page" button, which will take the user to Welcome screen
g. "View my linked accounts" button, which will take the user to the screen referred to in step (4),
above.
D.10
Choosing among Multiple Service Providers
2739
Sometimes user will have choice of multiple possible providers for a given service. In this situation
Trust and Privacy Negotiation function can be used to narrow down the list. If after narrowing down
more than one choice still remains, it may be reasonable to ask the user to make the choice.
2740
D.10.1 Simple Choice of Provider
2741
2742
2743
2744
2745
4. Choose Service Provider
2737
2738
2746
2747
2748
Motivation The decision point will be imposed to the user through modal user interaction. User
will be motivated to make the choice as he may guard different information, e.g. different
personae, at different Attribute Authorities.
2750
Available and understandable User’s choice should only be solicited if there is genuine choice.
System should implement automatic discovery and detection as much as possible.
2751
The choices should be formulated in human language, with translations as appropriate.
2749
2752
2753
2754
Feedback Once User makes his choice, he will land on the requestor’s page. This in itself may
be sufficient feedback, but indicating on the page where the information came from is recommended.
TAS3 ICT-216287
Page 122 of 211
1
Job Agency
TN
TAS3
(2)
Identity Provider 1
Using: IdP 1
Session already
active, no need
Login
3
Job Agency
TAS3
TN
Welcome, Applicant!
User
Refresh
4
5
Job Agency
TAS3
Your competencies are available
from multiple sources.
Please choose:
University
Employer
Job Agency
TAS3
TN
TN
provided from
University.
Get
Cancel
Figure D.11: Story board: Choice of Service Provider.
2755
D.10.2 Trust and Privacy Negotiation Assisted by User Interaction
2756
2757
TAS3 ICT-216287
Page 123 of 211
1
Job Agency
TN
TAS3
(2)
Identity Provider 1
Using: IdP 1
Session already
active, no need
Login
3
Job Agency
TAS3
TN
Welcome, Applicant!
User
Refresh
4 Trust and Privacy Negotiator
TAS3
5
TAS3
TN
TN
Your competencies are available
from multiple sources.
Please choose trustworthy:
University (T=9)
Employer (T=4)
Job Agency
provided from
University.
Get
Cancel
Figure D.12: Story board: Trust and Privacy Negotiation with User Interaction.
2758
2759
2760
4. Negotiate appropriate supplier for service or information
TAS3 ICT-216287
Page 124 of 211
D.11. USER-NOT-PRESENT TRANSACTION
2761
2762
2763
2764
2765
2766
2767
2768
2769
Motivation User will be forced to the decision point by modal user interface flow. User will be
motivated to make a choice either because he has no prior relationship with proposed SPs
and he needs to rely on trust preceptions, or because user wants to be in control and avoid
machine deciding for him.
Available and understandable Presenting complex trust based decision is not easy. This topic
will be further researched during TAS3 project.
Feedback Once User makes his choice, he will land on the requestor’s page. This in itself may
be sufficient feedback, but indicating on the page where the information came from is recommended.
2771
Further Use Cases depicting complex Trust and Privacy Negotiations will be elaborated in other
project deliverables.
2772
D.11
2773
User-not-present scenario can be driven in three ways:
2770
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
User-Not-Present Transaction
1. User has been present in some earlier time and authorized, indirectly, the transaction. Audit trail
MUST show this authorization.
2. There is an over-arching legal or legitimate business requirement. Existence of such requirement
MUST be demonstratable from the audit trail.
3. "Break the glass" scenarios. Again audit trail MUST capture legitimate reason why the scenario
was invoked and the audit trail should be especially detailed about the actions performed under the
break the glass authority.
Actual triggering of the event will depend on a business process. To gain acute authorization to
execute the operation, the business process will have to declare its intent and show evidence why it
should be authorized (see (1) and (2), above). Then, the operation MUST be thoroughly recorded in
the audit trail.
2786
User’s only contact point with User-Not-Present transaction is to audit it after the fact using the
Dashboard.
2787
D.12
2788
See Fig-D.13.
2785
2789
2790
2791
User Present Delegation
• Problem of choosing to whom to delegate, buddy list visualization
- How to obtain human readable names without violating privacy of the buddies?
Delegation of permissions to access repositories is addressed more fully in [TAS3D42Repo].
TAS3 ICT-216287
Page 125 of 211
D.13. USER-NOT-PRESENT DELEGATION
1
Alumni Portal
detect IdP 1
2
IdP 1
Authenticates
Alice
Alice
3
Alumni Portal
TAS3
TN
4
Alice’s
ePortfolio
Delegation Server A
TAS3
Share
Send Invitation
To: Bob
Resource: Alice’s ePortfolio
Invite: http://alumni.ex/x23a
5
Alumni Portal
TAS3
TN
Send
TN
Bob
Using: IdP 2
6
Login
IdP 2
Authenticates
Bob
7
Delegation Server A
TAS3
8
Alumni Portal
Accept Invitation
From: Alice
Resource: Alice’s ePortfolio
[x] Invite Alice
TAS3
TN
TN
Accept
Welcome, Bob!
Here is Alice’s study plan.
Figure D.13: Story board: Alice invites Bob to view her ePortfolio.
2792
2793
2794
D.13
User-Not-Present Delegation
This will cover situations such as administrative or judicial decisions that result in delegation without
the User necessarily wanting the delegation to happen.
TAS3 ICT-216287
Page 126 of 211
D.14. OTHER USE CASE WORK
2795
2796
2797
2798
We will explore these use cases in more detail in a future deliverable (M30 D2.1).
D.14
Other Use Case Work
[TAS3D42Repo] has an extensive section on use cases, which should be viewed as a complement or
extension of what is presented here.
2800
[TAS3D14DESIGNREQ] has some usage scenarios, especially relating to the pilots, although they
are not refined into use cases.
2801
D.15
2799
2802
2803
Future Use Case Work
Some other User Cases we may elaborate on, or that will be elaborated in other TAS3 deliverables,
include:
2804
• Full elaboration of the Trust and Privacy Negotiation Use Case(s)
2805
• SP BPel4People UI
2806
• Trust Guarantor UI
2807
• SP registration process UI
2808
• Bulletin board UI’s
2809
• Statistical services from anonymised data UI
2810
• Situation where additional data request deep in the recursive Web Services or business process
2811
2812
2813
2814
2815
2816
2817
2818
2819
requires Step-Up authentication
• Processes that may take long time and have start stop states taking longer than a web service
call can be reasonably expected to take.
BPEL engine can monitor this: any timeout is service failure and recorded as such. All service
providers must agree to terms SLA on sign up to TAS3 network and a key element of this will be
service reliability and performance.
- Human steps in process flow can be slow (e.g. process can be waiting sometimes for days
/ weeks)
• Use case: User wants to audit and complain
2820
- like on ebay give negative feedback and influence reputation of Service Provider
2821
- Complaining to wrong entity
2822
- Misidentifying probable cause
2823
- Ability trace all the way to the legal evidence
2824
2825
• 3rd party wants to audit or demonstrate that something happened,
- nonrepudiation
TAS3 ICT-216287
Page 127 of 211
D.15. FUTURE USE CASE WORK
2826
2827
- articulation to proof in law suits
• Registering a new service to the trust network
TAS3 ICT-216287
Page 128 of 211
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
Annex E: TAS3 Business Model (Non-Normative)
TAS3 (Trusted Architecture for Securely Shared
Technology Standards
Services), aims at the creation of a secure and
and Guidelines
effective means for individuals to online monitor and control their personal information, when
Business and Privacy
this is produced, used, or requested by service
3
Guidelines
providers. TAS business models will have to
provide an answer to the social innovation trends
An Ecosystem of
that underpin it. As such the TAS3 technologInteroperable
Products
ical development will have to proceed alongand Services
side non-technological innovations and innovations based more on the notion of a demandled services economy. A key task of the DemandFigure E.1: Factors Contributing to Trust.
led Innovation is the promotion of dialogue between users and service providers. User-led
innovation is promoted in traditional business sectors, in private and public services, and in sectors
which generate new demand.
TAS3 aims to achieve this vision either via a distributed or central
approach, however emphasizing the sharing and componentization of services and user-centricity in
terms of service provision and data storage. Our working assumption is that the only robust and practical way to achieve this goal is to create a so-called "Trust Network". Within a Trust Network information
exchange and transactions are supported by guarantees in terms of both quality and the various trust
& security components (authentication, authorizations, data privacy and trust management). Underpinning the Trust Network is a set of services called the Trust Network Infrastructure Services (TNIS)
providing a core trust infrastructure supporting information exchange based on user control in the trust
networks.
Trust
Central to the operation of the network based trust infrastructure is the use of specific Trusted Third
Parties (TTPs) for mechanical & legal validation of services (providers + requesters) and (end-) users
in the networks. The trusted third parties also interface with a higher level definition of trust metrics
overseen by a top level Trust Guarantor. It is envisaged that cross Trust Network communication will
be enabled by co-operation between Trust Guarantors. This eventually will result in a Trust Ecosystem.
1. All parties in the Trust Network (i.e. (1) end-users, (2) service providers & requesters, including
(3) TTPs) will be represented by tangible legal entities that agree to the terms of the trust network
before participating in it. The top level Trust Guarantor will set these terms and therefore define the
laws / nature of the trust network and has to fulfill both technical and legal audit roles in the trust
network.
2. All parties including end-users, service providers/requesters of application specific services (i.e.
eHealth tools) and service providers/requesters of TTP services (i.e. authentication) will be monitored by the overall TAS3 Trust Network Infrastructure Services (TNIS) that spans the specific trust
network, its trusted services and the related and information exchange. Any party breaching of the
terms of the Trust Network ecosystem and/or trust network will be reported to / monitored by the
Trust Guarantor.
3. Any breaches of terms or failures of the Trust Network are the responsibility of the Trust Guarantor.
Therefore the body has to act upon such cases and eject / penalize members of the ecosystem
who break its rules. For example this could be done (1) via reduction of trust ranking of specific
TAS3 ICT-216287
Page 129 of 211
E.1. WHAT SHOULD CONSTITUTE A TRUST NETWORK?
Figure E.2: Main Components of a Trust Network Technically the top level Trust Guarantor has a fundamental
role in (1) introducing, (2) monitoring, and (3) auditing the end2end assurance of trust between the transacting
parties.
2873
2874
2875
2876
2877
2878
2879
2880
2881
services, (2) by legal action on the basis of the TAS3 legal contract, including the expulsion of the
involved party. This level of support will lead to an a-priori assumption that it is basically safe to
transact with any member of the network, promoting trust in the whole network which leads to its
acceptance and widespread use. This brings down (compliance) costs of doing business, reduces
fraud and abuse of information, and ultimately leads to new innovative ways of transacting.
This vision raises some fundamental questions that need to be addressed:
E.1
What should constitute a Trust Network?
TAS3 is developing a generic architecture for securely shared services related to personal information.
This Architecture is to be implemented in four parts:
2882
• business requirements
2883
• technical requirements
2884
• policy requirements
2885
• Legal requirements.
2886
2887
2888
2889
The parties covered by the TAS3 architecture fall into three main categories:
• Trust (infrastructure or service) entities : trust guarantors and its certified Third Trusted parties
such as authentic sources or identity providers)
• Application specific Service Providers (in TAS3 these are either employability or eHealth related)
TAS3 ICT-216287
Page 130 of 211
2890
• End-users (individuals)
2892
All parties should consider the technical, policy and legal requirements to be the minimum requirements of the architecture.
2893
• In the case of technology requirements, there may be limited flexibility in some implementation
2891
2894
2895
parameters to ensure interoperability:
• In the case of policies, they can be used in 2 ways. Participants to the TAS3 consortium can
2900
either adopt the policies promulgated as their own, or can map their policies to the model policies
to assure that they meet the minimums required. The policy blocks presented by TAS3 can be
used to create policies or are to use existing possible legacy policies and map onto the TAS3
definitions. Participants may need to provide evidence of the policy gap analysis if they rely on
existing policies for compliance and also may need a mapping tool.
2901
• Lastly, the legal requirements are reduced into contracts tailored to the role that each participant
2896
2897
2898
2899
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
is playing, so they must be completed and adhered to. When registering to the Trust Network,
the contract terms will bind organizations to technical and policy requirements, both in terms
of those expressed at the intra- and inter-organizational level as well as in terms of using the
appropriate trust technologies to honor the preferences and choices of users as to use and
sharing of personal information.
Trust verification and assurance are essential elements of the TAS3 Infrastructure, and thus the
organization and cooperation of trust enablers in the operation and oversight of trust is essential. The
co-operation is hierarchical in terms of the use of Trust Network level definitions, down to user and
service definitions.
TAS3 Trust Networks are monitored & trust assured by (1) an independent Trust Guarantor supported
by one of more (2) TAS3 certified Third Trusted Parties (TTPs). Both must be in an absolute position
that provides them with an oversight role without having to provide services that place them in a
position of conflict with data subjects.
The TAS3 Consortium members will periodically review the architecture requirements from a trust
and oversight perspective or may engage in more frequent reviews as a result of changes in legal
requirements, regulatory requirements, or cases that require new terms.
A TAS3 Trust Network therefore will usually consist of:
a. Trust Network Governing Board. The board manages the affairs of the trust network. Depending
on the domain this might be a public-private-partnership (PPP) consisting for instance of the main
societal eHealth or employability domain stakeholders.
For instance, in the Limburg province in the Netherlands, such PPP is currently in the making
for a regional employability platform. It involves representatives of the employers, labor unions,
educational sector, local governments, industry sectors,
b. Trust Guarantor. The trust guarantor is the technical operator of the trust network and its Trust
Network Infrastructure Services (TNIS)
c. User Representation. The Trust Network will need some form of end-user representation. Depending on the type if Trust network this can range from existing end-user representatives such as
labor unions, industry sector federations, government, grass roots user groups, ?) In essence this
boils down to "organizing the communality"
TAS3 ICT-216287
Page 131 of 211
2931
2932
2933
2934
2935
d. Governments. We notice that governments in UK and the Netherlands (both at local and national
level) are gearing up to help initiate / organize / facilitate the needed communality around usercentric data and services and the trust this requires.
The TAS3 Trust Network Governance Agreement as monitored and audited by the Trust Guarantor
therefore has the following tasks:
2936
• Monitor the governance structure of the Trust Network
2937
• Register, certify, oversee and audit of the TTPs active in the Trust Network.
2938
• Register, certify, oversee and audit the Service Providers
2939
2940
The certified Trusted Third Parties, working in framework set by the Trust Network as executed by
the Trust Guarantor will typically be existing actors possibly performing the following functions:
2941
• Identity Providers (IdPs), to be certified by the TG
2942
• Discovery and registries, to be certified by the TG
2943
• Reputation Providers, to be certified by the TG
2944
• PKI (q.b.) to be certified by the TG
2945
• Authentic attribute sources, to be certified by the TG
2946
• Etc?
2947
2948
Service Providers, may participate in multiple TNs (having a non-exclusive relationship), and choose
their TTPs from available choice within each TN.
2949
• Service Providers that act as data requestors
2950
• Service Providers that act as data providers (running trusted repositories)
2951
• Service Providers that act as data originators
2952
End-Users can expect the following services from the Trust Network:
2953
• Certification and audit procedures
2954
• Branding (might/should be reputation based on live tangible metrics. Problem with brand is that
2955
2956
2957
2958
2959
2960
2961
it can take on a life of its own
• Secure and dependable technical infrastructure assuring trusted sharing of his personal information.
A Trust Network is built around an accountable legal entity, the Trust Guarantor (TG). Accountability
implies both oversight and (legal) responsibility. The issues of obligations and liability must be clarified
in the agreements that bind the party and must be appropriate to both the role and risk assumed
by each party. The TG organizes and charters multiple technical Trusted Third Parties (TTPs) in
TAS3 ICT-216287
Page 132 of 211
2962
2963
2964
2965
2966
2967
2968
order to perform specific and partial trust functions of the Trust Network. The sum of the delegated
TTP functions may or may not cover ALL the operational functions of the Trust Guarantor. If it does,
the remaining responsibility of the trust guarantor consists of overall management, certification and
auditing.
A TTP will typically NOT have an exclusive relationship with TN and can operate in several TNs.
TTPs should be leveraged to gain faster take-up and market acceptance of the Trust Network. Often
this is also both inevitable and necessary because:
2969
• the TG does not have all the skills needed
2970
• there are already players in the market like:
2971
- Certification Authorities
2972
- issuing certificates
2973
- credit check operators
2974
- providing reputation
2979
Other participants of a Trust Network are Service Providers who transact with each other, and Users
who use the services of the Service Providers. Users also have a special role in that they may commit
into the network data that needs special protection. The Trust Network and its Infrastructure Services
only exist for the benefit of its users, not to enslave them and will be reflected in the way the user data
policies are respected.
2980
E.1.1 Public vs. Private networks
2975
2976
2977
2978
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
The Trust Network is generally foreseen to be a public and nonexclusive entity: anyone, User, Service
Provider, or even Trusted Third Party operator, willing to be certified can participate. Trust Networks
may compete on issues such as cost, trust level, terms of use and even competence of members
(i.e. specialists). That being said, TAS3 Trust Networks do not exclude the possibility to run private
exclusive networks. Enabling such private networks however, is a non-goal, but is not an anti-goal
either.
From that perspective a Trust Ecosystem (consisting of several Trust Networks) becomes possible
that are made up of component TN systems. This would allow some parties to seek to develop private,
closed or exclusive networks that are compatible with the TAS3 infrastructure but not subject to it. In
itself this may enable some information transfers across providers that are both in public and private
networks in order to service particular customer needs, but would not necessarily imply that such
private providers were under the TAS3 Governance model or direct oversight. Thus TAS3 may also be
considered a portable standards-based business model, but those wishing to use it for that purpose
will need to appropriately adapt it and develop their own oversight models.
Each Trust Network is governed by a Governance Agreement to which all parties agree.
PS: In implementing the TAS3 requirements, two equally valid models may be used simultaneously.
Some players may wish to adopt whatever criteria are created by TAS3 , where others may map their
existing criteria to TAS3 to demonstrate equivalent compliance and interoperability. As we work on
the development and pilots of TAS3 we shall seek to maintain whatever flexibility is possible that is
consistent with governance, oversight and end-to-end security.
Trust Network participants will be subject to a general framework contract. This covers the overall
rules of engagement for any user (end-user or service provider) of the Network and creates the needed
TAS3 ICT-216287
Page 133 of 211
3007
relationships for obligations to be enforced against service providers. For these service providers
this general framework agreement is then supplemented with role and transaction based contracts,
covering not only what is allowed within the Trust Network, but also how data acquired for specific
purposes should be handled beyond the reach of the TNIS monitoring capabilities (read: behind the
service provider firewall).
3008
E.1.2 Branding and reputation
3003
3004
3005
3006
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
3028
3029
3030
3031
3032
3033
Depending on the constitution of the Trust Network Governing Board the notion of branding the Trust
Network may or may not be effective. If the Trust Network is merely an organization that operates the
technical/legal Trust Infrastructure Services branding may or may not work.
In fact, when not backed up by a community of practice, Trust brands in some cases have shown to
fail, e.g. some of the websites carrying a certification brand have never-the-less been fraudulent (even
more so than sites without certification). I.e. a brand is not a guarantee in itself. This argument could
go as far as recommending that no brand should be used in order to avoid inducing users into the false
belief that a brand guarantees something. Users are not able to remember the historical track record
of a brand and will instead trust it on basis of first impression or recent marketing.
If however the Trust Network/Guarantor is foremost setup to trust-enable a public-private-partnership,
(covering for instance the employability services in a region) and this PPP is acting as the Trust Networks’ Governing Board, then such a community of practice and/or its TN may well become a solid
brand.
While branding is foremost a user perception related term, more tangible trust is to be expected from
real time reputation. In fact the TAS3 type of Trust Networks are based on trust which has to be user
defined and real time, while brand is not defined by users nor is it real time. Nevertheless we would
argue that TAS3 - where possible - should try to combine both approaches and in fact both are needed
to produce end2end trust:
The notion of BRAND has a connotation with user trust perception. Users are expected to perceive
the brand as trusted, though if the network is mismanaged and the trust is not earned, the opposite
may happen. The brand will also be used in certification: only valid participants are allowed to display
the brand.
REALTIME REPUTATION however requires measurable trust metrics. TAS3 therefore builds in reputation into the system of transaction guarantee, i.e. 100% compo if you use a gold star ranked service
provider or 50% if you use a grey star ranked service provider and the SLA of TAS is breached.
3040
Finally, to build a Trust Network, build its brand and promote its adoption, technologies and products
implementing the technologies will be needed. In a mature market these may be available off-theshelf. However in an early innovator market, such as TAS3 type of TNs, ensuring that these are
available and of high enough usability and quality can be instrumental to the success of the network.
The Trust Guarantor therefore needs to work with all system participants and technology developers to
ensure this is the case. Similarly, even user friendly and user centric applications require some basis
of familiarity or necessity for uptake among consumer/citizen users, which will have to be addressed.
3041
E.1.3 Users trust perception
3034
3035
3036
3037
3038
3039
3042
3043
3044
Users should be able to join trust networks by agreeing to terms and conditions of use. The User
can then allow his personal information to be shared within the network in order to become part of
distributed composite applications & services. It is the central focus of TAS3 that when users present
TAS3 ICT-216287
Page 134 of 211
3045
3046
3047
3048
3049
3050
their personal information to a TAS3 Trust Network, they can trust that it will be not used out of context
of the terms that they agreed when joining the network and the policies set out for the actual transaction. The trust is based on the end2end assurance provided by the Trust Guarantor, and relies on
a combination of technical monitoring and enforcement capabilities and legal contracts signed by all
involved parties. More specifically, legal contracts extend the reach of enforcement beyond the TN
perimeter and beyond the service providers’ firewall.
Figure E.3: Trust Perception.
3051
3052
3053
3054
3055
The ultimate guarantee that the data will not be misused is presented by the trusted guarantor who
effectively takes on the liability for their respective trust networks. When joining the network the user
will agree that in the case of breach the guarantor will compensate / take action to rectify. Service
providers in the domain are tied in by the same rules. The action taken might include legal actions,
insurance claims, service provider depreciations of exclusion, etc?
3058
Beyond the brand perception of a TAS3 trust network, its’ trust model works foremost on the user
defining policies for their own personal information when joining a network and at the time of the
transactional network decisions based on the users’ information.
3059
E.1.4 Quality of trust
3056
3057
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
A key business opportunity in TAS3 is the concept of user trust perception. As users present their data
to TAS3 various methods of reporting can be used to keep the user in the loop. For example some
users may wish to keep a close account of what applications their data is being used in or the status
of their application execution. This can be achieved through the use of the trust dashboard. Trust
dashboards will help the user to discover & select the appropriate trusted service providers according
to specific terms and return them in trust rank order like Google.
Users could sign up for different qualities of dashboard and this will be reflected in the cost of the
application. These could be scaled in terms of price. The least expensive dashboard could present
users with almost a ’fire and forget’ interface to TAS3 networks allowing application invocation and
presentation of results when done.
TAS3 ICT-216287
Page 135 of 211
E.2. HOW MANY OF TRUST NETWORKS SHOULD THERE BE?
3070
3071
3072
3073
A more expensive and top of the range dashboard could notify via a variety of means the various
hops that the user’s data may have in a trust network as it is used in applications. This could be
achieved via email, SMS, etc. Service providers could compete to provide new innovative ways to
report on the progression of the users data through the network
3079
Overall the user’s perception of trust can be seen as related to their knowledge, and this needs to
be reflected in the way users can interact with TAS3 . It is likely that the GUI to TAS3 will not carry much
weight in terms of trust perception as users will be directed to choose from reputation rankings and
elements such as cost. Some users may interact through specific TAS3 interfaces whilst others may
use TAS3 embedded in existing applications. In both cases the users need to sign off on their policy
refinements and have a means by which they can be notified of their data use.
3080
E.2
3074
3075
3076
3077
3078
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
How many of Trust Networks should there be?
First of all we like to restate that an important goal of the TAS3 project is to create documentation and
software so that Trust Networks will be easy to setup, whatever their application domain.
As argued above, we expect TAS3 TNs to emerge around a clear business need, as perceived and
made operational by Public-Private-Partnerships (PPP). Early models are likely to be government (1)
initiated, (2) facilitated, (3) mediated, (4) anchored or even (5) owned (notice the increasing governmental involvement).
PS: Of course this view has its limitations: it would for instance seem unreasonably stifling to outright
forbid private Trust Networks. Society and public debate should establish what distinguishes a public
Trust Guarantor from a private one and what regulation should apply to each kind. On the other hand,
let’s not forget that a TN represents foremost the user’s interest (and personal information).
As such a Trust Network as something similar to a bank or telecoms operator. There is room for
more than one and indeed having several will promote healthy competition. However, due to the
special infrastructure utility role, Trust Networks are likely to be heavily regulated and there would only
be a handful of them.
3096
Conclusion: With the TAS3 project initiated from a need for trusted sharing of personal information,
we see Trust Networks arise from two angles:
3097
• With the user as the ONLY ’lifelong’ continuum within Trust Networks, the variety and scope of
3095
3098
3099
the TN is likely to be fitted around the users’ health wealth and happiness!
• From an service providers perspective we see two orthogonal axis or attraction pools:
3100
- regional development, interests & communality
3101
- Domain/industry sector specific interests.
3102
3103
3104
3105
3106
3107
As such we expect a bottom-up approach with smaller, local initiatives being used as reference
cases and national governments overseeing the results and eventually building momentum for larger,
possibly national roll-outs, where different trust networks can be interlinked into Trust Ecosystems. In
fact the Trust Ecosystem level could be the goal of the TAS3 project guiding principles, standards &
methods (and tools?), promoting them to new candidate Trust Networks. It may also be the correct
level to discuss cross-country issues.
TAS3 ICT-216287
Page 136 of 211
E.3. SHOULD TRUST NETWORKS INTERACT WITH EACH OTHER?
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
E.3
Should Trust networks interact with each other?
As TAS3 services mature, the focus will shift towards building efficient larger trust ecosystems, which
means connecting different context networks and avoiding overlapping functions. Again TAS3 is build
from the ground up as a generic & domain-independent architecture. Multiple Trust Networks (say a
European wide and interlinked employability trust networks) can be linked into for instance a larger
European Employability Trust Ecosystem. This requires that the involved Trust Networks cooperate
and have established a set of common rules of engagement, both at technical and legal level. Besides
providing first insights and comments, the TAS3 project however considers the Trust Ecosystem level
to be outside of the scope of the project and of its demonstrators.
We are presuming sectoral/national trust ecosystems at the outset. But these ecosystems may be
comprised of trust network solar systems in galaxies that in turn make up the universe of the national
sector. The business, technological, policy and legal contractual root of these interlocking players will
be the architecture defined by TAS3 which will enable interoperability, where needed. Not all players
will interact with each other, but rather interact as required by need. It is impossible to predict in
advance all of the specific participants to any transaction type, as user needs and preferences must
be factored. The idea of parallel, but disjointed Trust Networks lacks credibility in today’s globalized
world. The users would not be able to understand why the networks do not talk to each other and
a multitude of kludgy or illicit "gateways" would spring into existence whether we want or not. Much
better policy is to foresee the interaction directly in the architecture.
3131
However roaming the trust concept from one TN to another is quite challenging and requires standardization of the different trust concepts. Nevertheless commercial systems have proven to be quite
adequate in solving these types of unclean interfaces. As long as someone is willing to carry the liability for occasional mismatches and leaks, it can be made to work. Risk management is good enough
if you can’t prevent the risks entirely. This is for instance how the credit card system works.
3132
E.4
3127
3128
3129
3130
3133
3134
3135
3136
3137
3138
3139
3140
Who should run them?
Initially we expect the involved (innovating) project authority to govern the TN. Later on the powers that
be will take over, unless the initiators manage to cross the chasm.
Trust Network should be run by a credible and long lasting legal entity, with the necessary strong
user community impact. Without government backstop, there might be a question of credibility to
oversight, for instance. As such Trust Network is likely to be a non-for-profit PPP or Consortium type
of organization, run by a representative governing board. The Trust Guarantor on the contrary has a
specialist operational task probably best suited for a commercial entity, contracted by the TN.
Nevertheless, just for the sake of it, we list some other alternatives:
3141
• Public-Private partnership with a user community impact
3142
• New for profit company founded for the purpose (needs to build reputation)
3143
• New non-profit foundation or association created for the purpose (needs to build reputation)
3144
• Existing non-profit foundation or association
3145
• Certification Authority
TAS3 ICT-216287
Page 137 of 211
E.5. HOW SHOULD THE GOVERNANCE BE ORGANIZED?
Figure E.4: Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers (1991,
revised 1999), is a marketing book by Geoffrey A. Moore that focuses on the specifics of marketing high tech
products. Moore’s exploration and expansion of the diffusions of innovations model has had a significant and
lasting impact on high tech entrepreneurship. In 2006, Tom Byers, Faculty Director of Stanford Technology
Ventures Program, described it as "still the bible for entrepreneurial marketing 15 years later". This success
resulted in several follow-up books and a consulting company, The Chasm Group.
3146
• Other major (consumer) player
3147
• Government institution
3148
• Government
3149
• EU
3150
• Charity
3151
• Bank (they run your money, why not you personal data?)
3152
• Insurance Brokers (you honest broker represents users)
3153
• United Nations
3158
A special peril would seem to be that the Users are easily left without representation (they are not
foreseen to sign the Governance Agreement). Part of this problem is that there is no obvious party that
could represent the users. Should they be represented by some consumer organization? We noted
that Labor unions stepped up for the employability use case in the Netherlands, but on a more general
level, outreach to privacy and consumer organizations would be recommended.
3159
E.5
3154
3155
3156
3157
3160
3161
3162
How should the governance be organized?
Since the Trust Network ’polices’ the sharing of services and personal information exchange between
multiple parties, it seems natural that the representative societal stakeholders that traditionally help
manage users, providing them with a service offering, are the prime candidates to be brought onboard.
TAS3 ICT-216287
Page 138 of 211
E.5. HOW SHOULD THE GOVERNANCE BE ORGANIZED?
3163
3164
3165
3166
3167
3168
3169
3170
3171
a. On the one hand will TAS3 enable them to evolve into demand-led service providers (representatives) and on the other hand they are needed create momentum for the trust network to become
accepted as the ’new way forward’.
b. Overall we see national and local governments as the possible initiator and the most likely facilitator
to help engage the stakeholders in adhering to the Trust Network compliance. Some caution is
needed in defining the role of governments, since in a user-centric service economy they are also
service providers like any other.
c. Hence the need for a society-wide Public-Private-Partnership, where all representative parties involved will need:
3172
1. a clear win-win for their members and constituency (why)
3173
2. adhere to TAS3 compliance and its common rules of engagement (how)
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187
3. a board seat and a responsibility in governing the Trust Network, following the Trust Network
governance agreement (what)
The basic premise of Trust Networks is that transactions of monetary value will be involved. There
will also be data protection issues to which liability is attached. Liabilities will eventually bring the Trust
Guarantor, Service Providers, Trusted Third Parties or indeed even an end-user in court. Law and
legal contracts will therefore provide the ultimate safety nets.
All parties are bound by contracts which set out rights and obligations. Users will sign documents
related to terms and conditions, but they will be geared to the exercise of their rights and recourse,
although it will also set out the need for them to be bound to their choices and act in ways that nobody
undermines the system or attempt to defraud or otherwise injure other parties literally or figuratively. It
therefore seems logically that governments sooner or later are going to regulate the Trust Networks.
To stave off excessive regulation and to delay regulation in general, Trust Guarantors have active
interest to self-regulate. This places heavy emphasis on the Trust Network’s Governance Agreement.
Such a Governance Agreement should address:
3188
• Governance structure, such as advisory and audit boards
3189
• Criteria to join and stay on the network, including certification and audits
3190
• Process for removal from the network
3191
• Process for complaints
3192
• Commercial liability and its fair appropriation
3193
• Liability due to negligence in criminal cases and its fair appropriation
3194
• Privacy protection, including redress for users (Req. D1.2-6.10-Redress)
3195
• Minimal mandatory security practices (Req. D1.2-6.11-Confid)
3196
• Acceptable use for Service Providers
3197
• Acceptable use for Users
3198
• Licensing of Trusted Third Parties, and their liability
TAS3 ICT-216287
Page 139 of 211
E.6. HOW ARE TRUST NETWORKS FINANCED?
3199
3200
3201
3202
3203
3204
3205
3206
E.6
How are Trust Networks financed?
a. A TAS3 Trust Network represents the trust assurance for a new way of working between service
providers and users. The Trust Network therefore is merely an instrument and, at best, "a conditio sine qua non" for supporting a new demand-led services economy model. The TN therefore
foremost replaces (and claims to improve) the existing services and their underlying business processes by changing them into trusted, online web services. We do believe tough that by putting
the user in the center, new, and innovative user-centered services will be developed, which did not
exist in the old service economy.
3208
b. Financing the Trust network and its operational Trust Network Infrastructure Services (TNIS) therefore is foremost a replacement cost & benefit issue. The two main questions then are:
3209
• How much money is saved by using a user-centric online trust network, compared to the
3207
3210
3211
3212
3213
3214
3215
3216
3217
scattered service provider centric services?
• How much of these saving can be spend on financing the Trust Network?
c. There is no easy answer. Firstly, one has to calculate the REAL and often hidden cost of let’s
say, the lifelong employability of a worker. Today that cost is not even considered from a lifelong
perspective! It is spread over any number of service provider cost models.
d. The way forward therefore seems to be to define the specific win-win benefits for the separate main
stakeholders that come onboard to found the Trust Network.
By now it is clear that Trust Networks will have operational costs:
3218
• Procurement and maintenance of technical infrastructure
3219
• Member acquisition costs
3220
• Member management costs
3221
• User acquisition costs
3222
• User management costs
3223
• Trust branding costs (marketing)
3224
• Audit costs
3225
• Legal costs
3226
• Liability and insurance costs
3227
• General management costs
3228
3229
3230
Trust Network can be financed in a variety of ways
• Initial capital injection for
- Procurement of technical infrastructure
TAS3 ICT-216287
Page 140 of 211
E.6. HOW ARE TRUST NETWORKS FINANCED?
3231
- Procurement of legal contract framework
3232
- Initial trust branding costs (marketing)
3233
- Initial member acquisition
3234
- General set up
3235
• Fees from Service Providers: there is a need to accommodate many types of Service Providers:
3236
- Fixed yearly fee
3237
- Per transaction
3238
- Per number of Users
3239
- Per yearly business volume
3240
- Revenue share
3241
- Member management fees
3242
- Audit fees
3243
• Fees from Trusted Third Parties
3244
- Trusted Third Parties are allowed to have a fee structure of their own
3245
- Need to accommodate many types of TTPs; for
3246
• Fees from Users:
3247
- Fixed yearly fee
3248
- Usage fees from Users. (The tricky part is to collect them)
3249
- Per transaction
3250
- Per number of Users
3251
- Per yearly business volume
3252
- Revenue share
3253
- Member management fees
3254
- Audit fees
3255
• Advertisement
3256
- Placement of advertisement in authentication steps
3257
- Right to place advertisements in Service Providers
3258
- Revenue share from Service Provider advertising revenue
3259
• Proceeds from foundation grant investment portfolio
3260
• Government subsidy, research funding, taxes in a fair way. Perhaps a model where bill for
3261
3262
3263
3264
broadband
• Internet connection includes some fee.
The TAS3 architecture should enable all of the above forms of raising revenue, or at least not block
any of them.
TAS3 ICT-216287
Page 141 of 211
E.7. FORM OF TRUST GUARANTOR
Figure E.5: Example of Employability Trust Network win-win benefits.
3265
3266
3267
3268
3269
3270
3271
3272
3273
3274
3275
3276
3277
3278
3279
3280
E.7
What form of Trust Guarantor is most suited to operate and manage
the Trust Network Infrastructure Services, a centralized or shared
trust model?
The Trust Network Governance Board will appoint a Trust Guarantor to oversee, operate and technically & legally manage the Trust Assurance guaranteed by the Trust Network. While the Trust Guarantor will likely use a centralized model for starters, it is clear that there are already several third
trusted parties guaranteeing identities, or authentic sources, etc... Today they are scattered, each
having their own - often offline - trust models. The Trust Guarantor will have to incorporate and enable
these existing third trusted parties all while providing the end2end trust assurance for sharing personal
information. This capability will be build upon the stakeholder engagement
The Trust Guarantor will likely be a privately held, for-profit company that holds the technical and
legal and business skills to operationally oversee and promote the Trust Network, on the request and
on behalf of the Trust Network Governing Board. The Trust Guarantor architecture and compliance
requirements will need to be matched to Government requirements & regulation.
The Trust Guarantor tasks include:
1. Assure Compliance to TAS3 specification. This includes:
TAS3 ICT-216287
Page 142 of 211
E.7. FORM OF TRUST GUARANTOR
3281
3282
a. Operate or outsource the certification program for software products to be used in the Trust
Network.
3284
b. Operate or outsource the certification program for deployments, i.e. the participating Service
Providers, and possibly others like IdPs.
3285
c. Operate or outsource an audit programme for the deployments
3286
d. Process complaints and arrange for arbitration or disciplinary action
3287
e. Market the network to both Service Providers and Users
3283
3288
3289
3290
f. Maintain government compliance & endorsement as "The Trust Network"
g. Guarantee minimal cost participation for non-profits
2. Operate necessary technical infrastructure.
3292
Depending on how the Trust Guarantor organizes (1) its business and (2) the Trust Network this
may include:
3293
a. Execute an IdP function or arrange for others to operate IdPs in the network
3294
b. Authentication providers, in as far as this is not integrated into IdP.
3295
c. Discovery and registry functions
3296
d. Dashboard and audit results publication portal
3291
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3316
e. Possibly a certification authority of some sort - this is likely to be outsourced. Certificate or
credentials validation or revocation will be a central responsibility of Trust Guarantor.
f. Network level PDP
g. Reputation system, or arrange for someone to run the reputation system.
h. Where users have choice of multiple providers, the Trust Guarantor will need to ensure all in fact
work and if not, may need to provide an integration solution, such as a gateway.
i. Where interaction between networks happens, the Trust Guarantor may operate a gateway that
mediates.
3. Managing liability
Panopticon threat One especially pertinent risk in running a Trust Guarantor is that it may gain
excessive knowledge to the operations of the SP members or the Users and their business
processes. This is the so called "panopticon" threat. It can be mitigated by careful division of
responsibilities using externally contracted Trusted Third Parties, each of which operates in
its own isolated, regulatory scheme.
Government regulation Governments should consider regulating sound operation practices for
Trust Guarantors. For example, it might be mandatory to outsource the IdP function. It may
also be that regulation will require Users to be able to choose their dashboard or audit provider
from choices that are available within the network.
The Trust Guarantor should also be able to make ultimate decisions on suspensions of parties,
and will be liable to the core functionality of the trust networks it is responsible for.
TAS3 ICT-216287
Page 143 of 211
E.8. OVERSIGHT RESPONSIBILITY AND CONFLICT OF INTEREST
3317
3318
3319
3320
Outsourcing Trust Guarantor is a business entity that has liability. The actual running of the Trust
Network may involve several outsourced, franchised, or otherwise farmed out functions. The
most obvious of these are Identity Provider (IdP), Authentication Provider (usually same as
IdP), Discovery Service (DS), Reputation Provider (Rep), and Audit Function.
Thus an actual network will be configured to trust a number of IdPs, DSes, and Reps. In
a strict view, all of these entities should be viewed as Trusted Third Parties (TTP), but from
business perspective what matters is that they are endorsed by the Trust Guarantor. As such
the Trust Guarantor is the ultimate TTP policing the other TTPs and allowing them to enter
the network. A clear legal definition of shared and accountability and responsibility will be
paradigm in order to foster public trust in the network.
3321
3322
3323
3324
3325
3326
3327
4. The Trust Guarantor monetary streams are:
• Trusted Third Parties contracted on case-by-case basis.
3328
3329
- Most of these will involve cash outflow
3330
- Some cases cash inflows may be possible. Never-the-less, to be negotiated.
3331
• Government Service Providers pay a yearly fee, to be negotiated
3332
• Commercial Service Providers pay as negotiated, but preferred basis is revenue share or per
transaction
3333
• Small Service Providers pay small
3334
3335
- yearly fee
3336
- an one-off Service Provider setup fee
3337
- support fees once initial support package has been exhausted
3338
• Value added telephone & (first/second level) helpdesk support for users
3339
• Advertising in authentication process where feasible
3340
• Licensing fees or Revenue Sharing from Trusted Third Parties
3341
• Insurance against liability
3344
In the above listing, there are many charter requirements to guarantee that the Trust Guarantor will
operate ’within reason’. Since TAS3 is in position to license its brand and possibly some of its IPR, it
should be in position to negotiate with prospective Trust Guarantor to get these charter items included.
3345
E.8
3342
3343
3346
3347
3348
3349
3350
3351
3352
How do you differentiate between parts of the trust network with
oversight responsibilities and service providers that are relevant
to trust but may have conflicting interests?
E.8.1 Kinds of Service Providers
All business actors, other than end-users, are modeled as Service Providers. Obviously there are
different types of Service Providers with different legal requirements.
Requesters or Clients and agents Provide some service to the end-user and in performing this service, will invoke other services, some to perform an action, others to store or retrieve data.
TAS3 ICT-216287
Page 144 of 211
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362
3363
3364
3365
3366
Infrastructure specific service providers In case the Trust Guarantor does not execute these services which are core to the functionality of the trust network, they can be outsources to Infrastructure Service providers. They provide the core application functions such as accounting,
monitoring etc on behalf of the trusted Guarantor. A generic TTP can also be seen as infrastructure specific. The business model / price they operate on may be fixed with the trusted
Guarantor in order to guarantee availability.
Application specific services These services provide the main functions of the network and make
it domain specific. For example in an employability network you will have application specific
services such as job matching services and CV translator. These types of services can offer a
variety of prices and may compete in service selection brokering and negotiation; the cost may
reflect a more real-time supply and demand / market place model.
Authentic Data Sources (Data Originators) These are authorative / authentic source of data may
certify its veracity. They may also wish to control where and how the data is used. An originator
may use a repository to store the data, or it may act as a repository by itself.
3369
Data (Repository) Providers These store data on behalf of the user or service provider, but the
data in itself may have originated or is referenced outside the repository. Effectively the data
provider’s repository is handling data on behalf of someone.
3370
E.8.2 Kinds of Trust Entities
3367
3368
3373
Trust entities will fall out of the TAS3 architecture, i.e. the business model should not nail them down
before architecture is decided. However, we can say with fairly good degree of confidence that at least
following types of trust entities will exist:
3374
1. PKI Certification Authorities (CAs)
3371
3372
3375
• Issue SSL and signing certs to system entities
3376
• Potentially issue certs to users as well (we should avoid this if at all possible)
3377
• Handle certificate revocation and online status checks (OCSP)
3378
• No particular conflict of interest seen. TG could well be CA.
3379
• However, established players exist on market, so it makes sense to leverage them.
3381
2. User registration authorities. (PS: Sometimes IdPs perform the user registration function as well,
but this need not necessarily be so)
3382
3. Identity Providers (IdPs)
3380
3383
• Authentication
3384
• SSO
3385
• Possibly some initial attributes
3386
• Possibly a discovery and/or token issuance service bootstrap
3387
Main problems with IdPs are
TAS3 ICT-216287
Page 145 of 211
3388
• Visibility to federation relationships
3389
• Traffic analysis, know who is who’s customer and how often
3390
• Potential visibility to authentication credentials
3391
3392
3393
3394
Since IdP can see so much, its best of there is no single IdP. The Trust Guarantor therefore probably
should not perform this role itself. Instead it should charter or license others to do it. However, to
avoid Conflict of Interest, an IdP SHOULD NOT be run by a SP.
4. Discovery service, service registry, or token mapper
3395
• Who provides what service to whom
3396
• Where do users keep their data
3397
• Indirection layer in providing end point URLs
3398
• Credential mapping, from original to specific use
3399
3400
3401
Problems are similar to IdP. Further technical reasons usually dictate that that Discovery is operated
by same entity as IdP.
5. Relationship Service
3402
• Who has invited whom to have sharing relationships
3403
• Social network
3404
• Groups
3405
• Delegation use cases
3406
• Almost certainly should be distinct from IdP to avoid accumulating too much information in
3407
3408
3409
one place
• Technically easy to have multiple PS
6. Organizational PDPs
3410
• Local to organizations operating the SPs
3411
• Authorizations must be trusted blindly
3412
• The PDP gets to see quite a lot of traffic analysis info
3413
7. TAS3 network-wide PDP
3414
• Enforces the network wide rules
3415
• Authorizations must be trusted blindly
3416
• The PDP gets to see quite a lot of traffic analysis info
3417
3418
3419
8. Reputation Providers
• Reputation based trust scores are computed from usage pattern data and from PII. Both
sensitive, but both can also be influenced by savvy users.
TAS3 ICT-216287
Page 146 of 211
• Multiple instances encouraged to avoid accumulation of too much info of this nature in one
3420
place
3421
3422
9. Authorative data sources
3423
• Sometimes known as Policy Information Points (PIPs)
3424
• PDPs and reputation scoring can rely on authorative attribute data, thus supplier of this data
has to be trusted
3425
• The way the data was collected in the first place has to be trusted
3426
3427
10. Policy Authorities
3428
• Where do the policies that drive various PDPs come from?
3429
• Are they dynamic or field upgradeable?
3430
11. Business Process Model authorities.
• Many TAS3 components are driven by business models, so whoever programs these and has
3431
ability to update the installed base, has a lot of power
3432
• Dynamic BPM where the actual model itself can change and be propagated instantaneously
3433
to the consumers of the model
3434
3435
12. Ontology authorities
• When trying to compare apples to apples, e.g. to make authorization decision, the authority
3436
that defines the equivalence classes of terminology can control the outcome.
3437
• Field upgradeable or dynamic ontologies are likely to be used, thus it matters what authority
3438
lies behind them.
3439
• This threat is similar to the process model one
3440
3441
3442
3443
3444
3445
3446
3447
13. The domain name system
It may arise that in some situations integrity of DNS will affect trust. Usually we should be able to
avoid relying on this by using digital signatures, but there may be special cases, e.g. error situations
where signature is not applied, which could then open the door to phishing or hijack attacks. Please
note that the audit dashboard, while probably trusted by the user, need not be trusted in process
of making any access decisions. The dashboard can, however, be one of the channels from which
the reputation system gets its information.
3448
E.8.3
Principles that Trust Network Should Adopt
3449
A TN should adopt following principles:
3450
1. Personal Data should only be collected and/or processed for fair and legitimate business purposes.
3451
2. The purpose(s) for collection must be clearly specified.
3452
3. The collection related to those purposes must be relevant and non-excessive.
TAS3 ICT-216287
Page 147 of 211
3453
4. Personal data must be accurate and, where needed, up-to-date.
3455
5. Use, and subsequent use, of personal data cannot be incompatible with the purposes specified and
should be with the consent of the data subject
3456
6. Appropriate security (technical and organizational) measures against
3454
3458
7. Unauthorized/unlawful/accidental access; modification, disclosure, destruction, loss or damage to personal data must be in place.
3459
8. Controllers and processors have duties to maintain confidentiality of information.
3460
9. Sensitive data may be subject to greater restrictions.
3457
3461
3462
10. Data subjects have the right to know what types of data are being maintained and have the right to
access and correct personal data.
3465
It should be noted that consent often bears important adjectives of clear, unambiguous or explicit.
From a technical point of view, this requires that the user "opt in" to the collection of personal information.
3466
E.8.4 Questions a Trust Network Member Has to Answer
3467
1. Are you collecting/using PII as part of the service?
3468
2. Do you have a privacy policy that you are bound to follow?
3469
3. Do you use PII for any purpose other than providing the service?
3463
3464
3471
4. Do you get my consent or let me opt out before my information is used for other purposes than
providing the specific service?
3472
5. Do you share my information beyond your company or family of companies?
3470
3474
6. Do you get my consent or let me opt out before your share my information with any other company
not needed to provide the specific service?
3475
7. Do you allow me to manage these preferences over time and change my options?
3476
E.8.5
3477
1. Identify why information is needed
3478
2. Provide appropriate notice and obtain consent for use of information
3479
3. Limit information collected to that which is required for the legitimate business need
3480
4. Limit access to information to those that need it for the business function
3473
Privacy Architecture Elements
3482
5. Retain information only as long as reasonably needed to complete the business function and securely delete it (or possibly anonymise it).
3483
6. Secure information as required in a manner proportionate to its nature and sensitivity
3481
TAS3 ICT-216287
Page 148 of 211
3484
7. Maintain the integrity and accuracy of the information
3485
8. Provide access and possibility of correction
TAS3 ICT-216287
Page 149 of 211
3486
3487
Annex F: Threats (Non-Normative)
3489
This section addresses Reqs. D1.2-2.7-Safe and D1.2-2.8-Avail. Also Req. D1.2-2.9-Correct is
touched from secure programming perspective.
3490
F.1
3488
Other work
3491
• [SAML2security]
3492
• [IDWSFSecPriv]
3493
• [NIST-SP800-30]
3494
• [Meier09] provides a check list and [Meier08] a short list
3495
F.2
Business threats
3496
T21-IDTheft Identity Theft
3497
T22-Illegal Illegal transactions
3498
F.3
3499
T31-OverPrivil Over-privileged process and service accounts.
3500
T32-UnTTP Untrustworthy Third Party.
3501
F.4
3502
T41-BPMflaw Business process modelling flaws. How to audit or validate the model?
3503
T42-BPMdel Accidental deletion of process steps such as authorization or validation
3504
T43-Berserk Dynamically adaptive business process gone wild
3505
F.5
3506
T51-TNins Insertion of illegitimate members in trust network.
Trust model threats
Architectural threats
Trust misconfiguration threats
3508
T52-Mole Moles in trust network. A previously trusted member turns into rougue. How to detect?
How to rectify?
3509
T55-PolluteRep Pollution of reputation of other party
3510
T56-Augment Illicit augmentation of reputation by party itself
3507
TAS3 ICT-216287
Page 150 of 211
F.6. PROTOCOL MISCONFIGURATION THREATS
3513
T57-Deface Defacing Front End web site can cause damage to reputation of the Front End. Defacing
attacks can happen through same means as phising (T111-Phish) and also through break-ins,
either through network, or physical.
3514
T58-WrongCAs Insertion of wrong CAs into a trust network
3515
T59-WrongAAs Wrongly assigning source of authority to an attribute authority
3516
T510-WrongLOA Wrong assertion of LOA value by an IDP
3517
F.6
3518
T61-Replay Replay attack. See CR211-Uniq.
3519
T62-UnEncLink Unencrypted links e.g. SSLnull cipher suites.
3520
T63-UnAnLink Unauthenticated links
3521
F.7
3522
T71-WrongGrant Returning grant instead of deny leading to unauthorised access
3523
T72-WrongDeny Returning deny instead of grant leaving to DOS.
3524
T73-WrongObs Returning wrong obligations
3525
T74-MissingObs Missing obligations from authz decisions
3526
T75-OKAC Attribution of wrong access rights to an otherwise trusted member
3527
F.8
3511
3512
Protocol misconfiguration threats
Authorization misconfiguration threats
Ontology threats
3529
T81-SameButDiff Same term meaning different things to two parties leads to illicit access, due to
wrong rule inadvertently matching.
3530
F.9
3528
3531
3532
3533
3534
Exposure threats
T91-Eavesdrop Exposure of data due to network sniffing or eavesdropping. Counter measure: encrypt data and manage keys right.
T91-DBLeak Exposure of data due to database files or transaction logs. Counter measure: encrypt
data and manage keys right.
3536
T92-TamperNet Modification of data in transit. Counter measuers: signing or verification of a hash
over the data.
3537
T93-TamperDB Modification of data in database.
3535
TAS3 ICT-216287
Page 151 of 211
F.10. PRIVACY THREATS
3538
3539
3540
T94-ExptLeak Error condition or exception reveals too much data or system details (usually to aid
debugging). Exception output that appears in user interface or over the network is especially
damning. Leakage to logs is also a threat.
3542
T95-CoreLeak Error condition or exception causes a core dump that reveals too much data or system
details (usually to aid debugging).
3543
F.10
3544
T101-LeakBackup Eavesdropping on backups (see CR213-Backup)
3541
Privacy threats
3547
T102-Correlation Database correlation by colluding entities (solution: do not leak correlation handles,
i.e. use pseudonyms - see Architecture, Core Security Architecture, Access Credentials, Pull
Model)
3548
T103-TAIdP IdP collects traffic analysis (and then sells or illicitly use it). Some counter measures:
3545
3546
3549
• TN wide data retention policy, audit this: add compliance requirement
3550
• Pure play IdP operator vs. mixed functions
3551
• Centralized IdP well managed may be a good idea
3552
T104-TADI Disco collects traffic analysis (and then sells or illicitly use it)
3553
T105-TA3rd Traffic Analysis by Third Party
3554
T106-CorrAudit Correlation handles of audit trail will also become correlation handles.
3555
3556
3557
3558
3559
3560
3561
T107-LogTokLeak If WSC parties keeps log of User’s pseudonym along with encrypted form of User’s
identifier at WSP, then WSC and WSP can correlate and collude using the encrypted form.
However this threat is acute only between directly interacting parties. In a chain of web services
calls longer than 3, the nonneiboughring parties are not in position to collude using this attack.
Current solution is to forbid logging the tokens, see CR53-DontLogTok.
T108-PhishPII Tricking user to reveal PII through phising attack that poses a real looking web page
to solicit PII. See also access version of the threat: T111-Phish.
3563
T109-SocEngPII Social Engineering, talking users to revealing PII. See also access version of the
threat: T112-SocEng.
3564
T1010-SnoopPII Network eavesdropping to record PII.
3565
T1011-KbdLogPII Keyboard logger or other malware to record credentials.
3566
T1012-MalwarePII PII theft, e.g. copy private contact book, using malware.
3567
T1013-PIITheft Physical theft of PII.
3562
TAS3 ICT-216287
Page 152 of 211
F.11. AUTHENTICATION THREATS
3568
3569
3570
F.11
Authentication threats
T111-Phish Tricking user to reveal his authentication credentials through phising attack that poses a
real looking web page to solicit user’s access credentials. This could be created through
3571
a. DNS manipulation
3572
b. Cross site scripting
3573
c. Inappropriate insertion of content in legitimate site
3574
d. Containment of legitimate site in illegitimate frame
See also PII version of threat: T108-PhishPII.
3575
3576
T112-SocEng Social Engineering, talking users to revealing access credentials.
See also PII version of threat: T109-SocEngPII.
3577
3578
T113-SnoopCred Network eavesdropping to record credentials.
3579
T114-KbdLog Keyboard logger or other malware to record credentials.
3580
T115-Malware Credential theft, e.g. copy private key, using malware.
3581
T116-Theft Physical credential theft.
3582
T117-Dict Dictionary attack on password
3583
T118-Brute Brute force attacks of simply trying out all credentials.
3586
T119-Cookie Cookie replay attack. Use previously recorded cookie in context where authentication
did not happen. Also arises if expired session cookie is allowed as a factor in authentication,
resulting stronger factor not being demanded.
3587
T1110-Lure Luring users to do stupid things like
3584
3585
3588
a. Visit web sites that phish or contain malware
3589
b. Install malware and troians
3590
c. Voluntarily give out credentials or PII
3591
F.12
3592
T121-Gift Users giving away their credentials to others
3593
T122-Loss Users losing their credentials
3594
3595
3596
3597
Impersonation threats
T123-Careless Users not protecting their credentials properly e.g. posting passwords on post-it stickers
T124-Delegation Authentication delegation models in which the delegate assumes the user’s original
ID instead of using their own (e.g. as in Shibboleth see https://spaces.internet2.edu/display/ShibuPort
TAS3 ICT-216287
Page 153 of 211
F.13. REPUDIATION THREATS
3598
F.13
3599
T131-Repud Repudiation of events by any party (system entity or user).
3600
F.14
3601
T141-AltSig Alteration of signed message (see CR27-Sig and CR28-Vfy)
3602
T142-Tamper Alteration of audit trail (see CR212-Trail)
3603
T143-LeakLogs Eavesdropping on logs (see CR212-Trail)
3604
T144-NoAud Insufficient auditing in the first place
3605
F.15
3606
3607
3608
3609
3610
3611
3612
3613
3614
3615
3616
Repudiation threats
Unauditability threats
Software bug threats
T151-Overflow Buffer overflow attack, to gain injection and execution of code, usually leading to
compromise of the machine. Also heap overflow.
T152-Inject SQL Query Injection attack, causing database engine to execute unauthorized database
statements. This threat also covers similar attacks on other databases or downstream services
like shell scripts (command injection).
T153-NI Access control, signature verification, or other security feature not implemented. Testing only
positive cases can easily ignore this type of threat. It is imperative that the test suites also
include negative testing.
T154-Input Input MUST at all times be validated to conform to the expected syntax, and input in
general should never be trusted unless there is a cryptographical or structural guarantee of
trustworthiness. Some particular perils
3617
a. Explicit inputs
3618
b. Environment variables
3619
c. URL and query string
3620
d. CGI form fields
3621
e. Cookies
3622
f. HTTP headers
3623
g. SOAP headers
3624
h. Processing contexts of all sorts passed between software modules
3626
i. Fields of certificates (from untrusted source, but you would not know until you manipulated
the certificate to find out if it is trusted).
3627
j. Metadata
3625
3628
k. Messages from event bus
TAS3 ICT-216287
Page 154 of 211
F.16. SERVICE AVAILABILITY THREATS
3629
3630
3631
3632
3633
3634
3635
3636
3637
3638
3639
3640
3641
3642
l. Data coming from database (even if database is supposed to be trusted, it may have been
compromised, thus checking for proper format will help to detect the breach and contain
it).
m. Deserialization of any data. This is particularly acute whan using eval to deserialize JSON
data.
Perl(1) tainted feature provides a way to track untrusted user input. All untrusted input MUST
be scrutinized for attack vectors, such as directory climbing (".." or " " = home directory) as a
path component. Where relative path is expected, an absolute path - one starting by "/" - MUST
NOT be allowed. All shell(1) or SQL escape characters (see also T152-Inject) are of highest
suspicion until proven to be secure.
When validating input, preferred strategy is to test if input is good and anything that does not
pass is bad. The alternative strategy of looking for known bad things (like ".." in path) is much
weaker and prone to errors.
T155-Mem Code MUST NOT
3643
a. Dereference a Null Pointer
3644
b. Use Freed Memory
3645
c. Doubly Free Memory
3648
T156-Fmt Format string mismatch. In printf(3) format string it is easy to get the format specifiers and
actual arguments mixed, resulting inappropriate format specifier being used for a given piece of
data.
3649
T157-Trunc Truncation of value. Sometimes truncated value can have different meaning.
3650
T158-Signed Signed conversion of a value that may not have been identified.
3646
3647
3656
T159-CliValid Reliance on client side validation is no good for server as an alternate client will not perform the validation. Server MUST at all times perform all security critical validations. Client side
validation has value in (i) improving user experience and feedback, (ii) reducing network traffic
by not submitting obviously invalid inputs, (iii) protecting client side processing like AJAX applications. Such applications MUST be suspicious of what is sent to them by server, in particular if
they use JSON and plan to use eval() for processing it.
3657
T1510-XSiteScript Cross Site Scripting.
3651
3652
3653
3654
3655
3658
3659
T1511-Stack Stack overflow. Similar to T151-Overflow, but specifically applied to the argument and
call stack of most compiled programs.
3661
T1512-HTML Using non-validated input in the HTML output stream. This could lead into insertion of
JavaScript on the generated page.
3662
T1513-PtrSub Improper Pointer Subtraction
3663
T1514-EqEq Assignment (=) instead of comparison (==).
3660
TAS3 ICT-216287
Page 155 of 211
F.16. SERVICE AVAILABILITY THREATS
3664
F.16
3665
T161-DoS Denial of Service by massive network load.
3666
3667
3668
3669
3670
3671
3672
Service Availability Threats
T162-DNS Poisoning DNS or taking DNS down will prevent legitimate players from communicating
with each other.
T163-Expt Using program flaw or exception to trigger excessive resource consumption (spinning process, writing all logs full, and leaking memory) or to cause a service to crash.
T164-GC Feeding service request pattern (e.g. monotonically increasing input size so that previously
freed memory is never enough to satisfy the new request) that causes fragmentation of memory,
excessive or ineffective garbage collects, or memory leaks.
TAS3 ICT-216287
Page 156 of 211
3673
3674
3675
3676
Annex G: Enumeration of Audit Events
To understand the wealth of audit trail data we start by enumerating them all:
1. Session Events Channel:
3677
a. Session creation (possibly even an anonymous session)
3678
b. Session upgrade (e.g. SSO on an anonymous session, step-up auth)
3679
c. Session refresh
3680
d. Session termination
3681
e. Session expiry
3682
3683
f. Session revival (if appropriate, could be used as a factor in authentication)
2. User Authentication Events Channel:
3684
a. Positive
3685
b. Failure with Retry
3686
c. Definitive Failure
3687
3. Token Issuing Channel:
3688
3689
3690
a. Tokens issued with:
i. Issuer
ii. Subject
3691
iii. Audience
3692
iv. Policy constraints
3693
3694
v. Validity time and/or usage count
vi. General content of the token
3695
b. Token validation at relying party
3696
c. Token use, to the appropriate extent
3697
d. Token revocation when applicable
3698
4. Authorization Channel:
3699
a. Az request parameters
3700
b. Az decision returned
3701
3702
3703
3704
3705
5. Service Requester Channel:
a. Choice of Service Provider
i. Discovery
ii. Hardwired choice of Service
iii. Automated or algorithmic Choice of Service
TAS3 ICT-216287
Page 157 of 211
3706
iv. Choice of Service solicited from the User
3707
b. Trust negotiation steps
3708
c. Consent to send data
3709
d. Service Call event
3710
3711
i. Signature preparation, including choice of signing key
ii. Log of content of the message
3712
iii. Peer authentication
3713
iv. Success or failure to send message
3714
3715
3716
e. Service Call exception
i. Redirect or end point change
ii. Recredentialing
3717
iii. Interaction requested
3718
iv. Replay after interaction
3719
3720
3721
3722
3723
3724
3725
3726
3727
3728
3729
3730
3731
v. Dry-run
f. Service Call Response
i. Log of content of the message
ii. Peer authentication (usually by Request-Response pattern)
iii. Success or failure to receive message
g. Service Call Response exception
i. Failures, as detailed on the Faults Channel
ii. Application layer success or failure
h. Obligations processing
i. Presence of obligation
ii. Specific processing steps
iii. Failure to process obligation
6. Service Responder Channel:
3732
a. Trust establishment and trust negotiation steps
3733
b. Request Acceptance
3734
c. Response filtering and authorization decision
3735
d. Attachment of obligations
3736
7. PII Collection Channel
3737
8. PII Release Channel
3738
9. User Registration Channel:
3739
a. Register
3740
b. Modify
TAS3 ICT-216287
Page 158 of 211
3741
3742
c. Deregister
10. SP Registration Channel:
3743
a. Register
3744
b. Modify
3745
c. Change of Control
3746
d. Deregister
3747
11. User Reputation Channel:
3748
a. Explicit complaint or praise
3749
b. Other events that affect reputation
3750
12. Service Reputation Channel:
3751
a. Explicit complaint or praise
3752
b. Other events that affect reputation
3753
13. Browsing Event Channel (usually not shared)
3754
14. Faults Channel:
3755
a. Malformed protocol message
3756
b. Insufficient sec mech
3757
c. Signature verification fault
3758
3759
3760
i. Malformed
ii. Crypto (public key or hash)
iii. Certificate validity (missing CA trust chain)
3761
d. Inappropriate use
3762
i. Audience
3763
3764
3765
ii. Constraints
e. Expired tokens
f. Replay of message or token
3766
g. Unsolicited message
3767
h. Missing database entry
3768
3769
i. Explicit fault report
15. DoS Channel:
3770
a. Invocation frequency alert
3771
b. Data volume alert
3772
c. Explicit DoS report (e.g. from monitoring organizations)
TAS3 ICT-216287
Page 159 of 211
3773
16. Intrusion Detection System and Firewall ACL Channel:
3774
a. Scan alert
3775
b. Attack fingerprint alert
3776
c. Firewall deny rule triggered
3777
3778
3779
3780
17. Operations monitoring Channel:
a. Server / Service
i. Up
ii. Down
3781
iii. Scheduled downtime
3782
iv. Congested
3783
3784
3785
v. Retry
vi. Fail Over
18. Audit Operation Channel (very restricted circulation):
3786
a. Undertaking audits
3787
b. Outcomes of audit
3788
19. Billing Event Channel
3789
20. Customer Care Event Channel
TAS3 ICT-216287
Page 160 of 211
3790
3791
Annex H: Example Protocol Messages (Non-Normative)
3794
These XML blobs, taken from [ZXIDREADME], are for reference only. They are not normative. They
have been pretty printed. Indentation indicates nesting level and closing tags have been abbreviated
as "</>". The actual XML on the wire generally does not have any whitespace.
3795
H.1
3792
3793
3796
3797
3798
3799
3800
3801
3802
SAML 2.0 Artifact Response with SAML 2.0 SSO Assertion and Two
Bootstraps
Both bootstraps illustrate SAML assertion as bearer token.
<soap:Envelope
xmlns:lib="urn:liberty:iff:2003-08"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<soap:Body>
3803
3804
3805
3806
3807
3808
3809
3810
3811
3812
3813
3814
3815
<sp:ArtifactResponse
xmlns:sp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="REvgoIIlkzTmk-aIX6tKE"
InResponseTo="RfAsltVf2"
IssueInstant="2007-02-10T05:38:15Z"
Version="2.0">
<sa:Issuer
xmlns:sa="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
https://a-idp.liberty-iop.org:8881/idp.xml</>
<sp:Status>
<sp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></>
3816
3817
3818
3819
3820
3821
3822
3823
3824
3825
3826
3827
3828
<sp:Response
xmlns:sp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="RCCzu13z77SiSXqsFp1u1"
InResponseTo="NojFIIhxw"
Version="2.0">
<sa:Issuer
<sp:Status>
<sp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></>
3829
3830
3831
<sa:Assertion
TAS3 ICT-216287
Page 161 of 211
H.1. SAML 2.0 ARTIFACT RESPONSE WITH SAML 2.0 SSO ASSERTION AND TWO
BOOTSTRAPS
3832
3833
3834
3835
3836
ID="ASSE6bgfaV-sapQsAilXOvBu"
Version="2.0">
<sa:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
3837
3838
3839
3840
3841
3842
3843
3844
3845
3846
3847
3848
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#ASSE6bgfaV-sapQsAilXOvBu">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signat
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>r8OvtNmq5LkYwCNg6bsRZAdT4NE=</></></>
<ds:SignatureValue>GtWVZzHYW54ioHk/C7zjDRThohrpwC4=</></>
3849
3850
3851
3852
3853
3854
3855
3856
3857
3858
<sa:Subject>
<sa:NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
NameQualifier="https://a-idp.liberty-iop.org:8881/idp.xml">PB5fLIA4lRU2bH4HkQ
<sa:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<sa:SubjectConfirmationData
NotOnOrAfter="2007-02-10T06:37:41Z"
Recipient="https://sp1.zxidsp.org:8443/zxidhlo?o=B"/></></>
3859
3860
3861
3862
3863
3864
<sa:Conditions
NotBefore="2007-02-10T05:32:42Z"
NotOnOrAfter="2007-02-10T06:37:42Z">
<sa:AudienceRestriction>
<sa:Audience>https://sp1.zxidsp.org:8443/zxidhlo?o=B</></></>
3865
3866
<sa:Advice>
3867
3868

3869
3870
3871
3872
3873
3874
3875
3876
3877
3878
<sa:Assertion
ID="CREDOTGAkvhNoP1aiTq4bXBg"
Version="2.0">
<sa:Issuer
<ds:SignedInfo>
TAS3 ICT-216287
Page 162 of 211
BOOTSTRAPS
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/
<ds:Reference URI="#CREDOTGAkvhNoP1aiTq4bXBg">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-si
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></>
<ds:DigestValue>dqq/28hw5eEv+ceFyiLImeJ1P8w=</></></>
<ds:SignatureValue>UKlEgHKQwuoCE=</></>
<sa:Subject>
<sa:NameID/> 
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/></>
<sa:Conditions
NotBefore="2007-02-10T05:32:42Z"
NotOnOrAfter="2007-02-10T06:37:42Z">
<sa:Audience>https://sp1.zxidsp.org:8443/zxidhlo?o=B</></></></></>
3879
3880
3881
3882
3883
3884
3885
3886
3887
3888
3889
3890
3891
3892
3893
3894
3895
3896
3897
3898
3899
3900
3901
3902
3903
<sa:AuthnStatement
AuthnInstant="2007-02-10T05:37:42Z"
SessionIndex="1171085858-4">
<sa:AuthnContext>
<sa:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:Password</></></>
3904
3905
<sa:AttributeStatement>
3906
3907

3908
3909
3910
3911
3912
<sa:Attribute
Name="cn"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<sa:AttributeValue>Sue</></>
3913
3914

3915
3916
3917
3918
3919
3920
3921
3922
3923
3924
3925
<sa:Attribute
Name="DiscoveryResourceOffering"
NameFormat="urn:liberty:disco:2003-08">
<sa:AttributeValue>
<di12:ResourceOffering
xmlns:di12="urn:liberty:disco:2003-08"
entryID="2">
<di12:ResourceID>
https://a-idp.liberty-iop.org/profiles/WSF1.1/RID-DISCO-sue</>
<di12:ServiceInstance>
TAS3 ICT-216287
Page 163 of 211
BOOTSTRAPS
<di12:ServiceType>urn:liberty:disco:2003-08</>
<di12:ProviderID>https://a-idp.liberty-iop.org:8881/idp.xml</>
<di12:Description>
<di12:SecurityMechID>urn:liberty:security:2005-02:TLS:Bearer</>
<di12:CredentialRef>CREDOTGAkvhNoP1aiTq4bXBg</>
<di12:Endpoint>https://a-idp.liberty-iop.org:8881/DISCO-S</></></>
<di12:Abstract>Symlabs Discovery Service Team G</></></></>
3926
3927
3928
3929
3930
3931
3932
3933
3934
<!-- ID-WSF 2.0 Bootstrap for Discovery. The credential (bearer token) is inline.
3935
3936
3937
3938
3939
3940
3941
3942
3943
3944
3945
3946
3947
3948
3949
3950
3951
3952
<sa:Attribute
Name="urn:liberty:disco:2006-08:DiscoveryEPR"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<sa:AttributeValue>
<wsa:EndpointReference
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecu
notOnOrAfter="2007-02-10T07:37:42Z"
wsu:Id="EPRIDcjP8ObO9In47SDjO9b37">
<wsa:Address>https://a-idp.liberty-iop.org:8881/DISCO-S</>
<wsa:Metadata xmlns:di="urn:liberty:disco:2006-08">
<di:Abstract>SYMfiam Discovery Service</>
<sbf:Framework xmlns:sbf="urn:liberty:sb" version="2.0"/>
<di:ProviderID>https://a-idp.liberty-iop.org:8881/idp.xml</>
<di:ServiceType>urn:liberty:disco:2006-08</>
<di:SecurityContext>
<di:SecurityMechID>urn:liberty:security:2005-02:TLS:Bearer</>
3953
<sec:Token
xmlns:sec="urn:liberty:security:2006-08"
usage="urn:liberty:security:tokenusage:2006-08:SecurityToken">
3954
3955
3956
3957
<sa:Assertion
ID="CREDV6ZBMyicmyvDq9pLIoSR"
Version="2.0">
<sa:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsi
<ds:Reference URI="#CREDV6ZBMyicmyvDq9pLIoSR">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig
3958
3959
3960
3961
3962
3963
3964
3965
3966
3967
3968
3969
3970
3971
3972
TAS3 ICT-216287
Page 164 of 211
H.2. ID-WSF 2.0 CALL WITH X509V3 SEC MECH
<ds:DigestValue>o2SgbuKIBzl4e0dQoTwiyqXr/8Y=</></></>
<ds:SignatureValue>hHdUKaZ//cZ8UYJxvTReNU=</></>
<sa:Subject>
<sa:NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
NameQualifier="https://a-idp.liberty-iop.org:8881/idp.xml">
9my93VkP3tSxEOIb3ckvjLpn0pa6aV3yFXioWX-TzZI=</>
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/></>
<sa:Conditions
NotBefore="2007-02-10T05:32:42Z"
NotOnOrAfter="2007-02-10T06:37:42Z">
<sa:Audience>https://a-idp.liberty-iop.org:8881/idp.xml</></></
<sa:AuthnStatement AuthnInstant="2007-02-10T05:37:42Z">
<sa:AuthnContext>
urn:oasis:names:tc:SAML:2.0:ac:classes:Password</></></></></
3973
3974
3975
3976
3977
3978
3979
3980
3981
3982
3983
3984
3985
3986
3987
3988
3989
3990
3991
3992
N.B. The AttributeStatement/Attribute/AttributeValue/EndpointReference/Metadata/
SecurityContext/Token/Assertion/Conditions/AudienceRestriction/Audience is the same
3995
as the IdP because in many products the IdP and Discovery Service roles are implemented by the
same entity. Note also that the audience of the inner assertion is the discovery service where as the
audience of the outer assertion is the SP that will eventually call the Discovery Service.
3996
H.2
3993
3994
3997
3998
3999
4000
4001
4002
4003
4004
4005
4006
4007
4008
4009
4010
4011
4012
4013
4014
4015
ID-WSF 2.0 Call with X509v3 Sec Mech
<e:Envelope
xmlns:e="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:b="urn:liberty:sb:2005-11"
xmlns:wsse="http://docs.oasis-open.org/wss/20 04/01/oasis-200401-wss-wssecurity-secext-1.
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0
xmlns:wsa="http://www.w3.org/2005/08/ addressing">
<e:Header>
<wsa:MessageID wsu:Id="MID">123</>
<wsa:To wsu:Id="TO">...</>
<wsa:Action wsu:Id="ACT">urn:xx:Query</>
<wsse:Security mustUnderstand="1">
<wsu:Timestamp wsu:Id="TS"><wsu:Created>2005-06-17T04:49:17Z</></>
<wsse:BinarySecurityToken
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profi
wsu:Id="X509Token"
EncodingType="http://docs.oas is-open.org/wss/2004/01/oasis-200401-wss-soap-message
MIIB9zCCAWSgAwIBAgIQ...</>
TAS3 ICT-216287
Page 165 of 211
H.3. ID-WSF 2.0 CALL WITH BEARER (BINARY) SEC MECH
4030
<ds:SignedInfo>
<ds:Reference URI="#MID">...</>
<ds:Reference URI="#TO">...</>
<ds:Reference URI="#ACT">...</>
<ds:Reference URI="#TS">...</>
<ds:Reference URI="#X509">
<ds:DigestValue>Ru4cAfeBAB</></>
<ds:Reference URI="#BDY">
<ds:DigestValue>YgGfS0pi56p</></></>
<ds:KeyInfo><wsse:SecurityTokenReference><wsse:Reference URI="#X509"/></></>
<ds:SignatureValue>HJJWbvqW9E84vJVQkjDElgscSXZ5Ekw==</></></></>
<e:Body wsu:Id="BDY">
<xx:Query/></></>
4031
The salient features of the above XML blob are
4016
4017
4018
4019
4020
4021
4022
4023
4024
4025
4026
4027
4028
4029
4032
• Signature that covers relevant SOAP headers and Body
4033
• Absence of any explicit identity token.
4038
Absence of identity token means that from the headers it is not possible to identify the taget identity.
The signature generally coveys the Invoker identity (the WSC that is calling the service). Since one
WSC typically serves many principals, knowing which principal is impossible. For this reason X509
security mechanism is seldom used in ID-WSF 2.0 world (with ID-WSF 1.1 the ResourceID provides
an alternative way of identifying the principal, thus making X509 a viable option).
4039
H.3
4034
4035
4036
4037
4040
4041
4042
4043
4044
4045
4046
4047
4048
4049
4050
4051
4052
4053
4054
4055
4056
ID-WSF 2.0 Call with Bearer (Binary) Sec Mech
<e:Envelope
xmlns:b="urn:liberty:sb:2005-11"
xmlns:wsa="http://www.w3.org/2005/03/ addressing">
<e:Header>
<wsa:MessageID wsu:Id="MID">...</>
<wsu:Timestamp wsu:Id="TS">
<wsu:Created>2005-06-17T04:49:17Z</></>
<wsse:BinarySecurityToken
ValueType="anyNSPrefix:ServiceSess ionContext"
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-messageTAS3 ICT-216287
Page 166 of 211
H.4. ID-WSF 2.0 CALL WITH BEARER (SAML) SEC MECH
4057
4058
4059
4060
4061
4062
4063
4064
4065
4066
4067
4068
4069
4070
4071
4072
4073
4074
4075
4076
4077
4078
4079
4080
4081
4082
4083
4084
4085
4086
4087
4088
4089
4090
4091
4092
4093
4094
4095
wsu:Id="BST">
mQEMAzRniWkAAAEH9RWir0eKDkyFAB7PoFazx3ftp0vWwbbzqXdgcX8fpEqSr1v4
YqUc7OMiJcBtKBp3+jlD4HPUaurIqHA0vrdmMpM+sF2BnpND118f/mXCv3XbWhiL
VT4r9ytfpXBluelOV93X8RUz4ecZcDm9e+IEG+pQjnvgrSgac1NrW5K/CJEOUUjh
oGTrym0Ziutezhrw/gOeLVtkywsMgDr77gWZxRvw01w1ogtUdTceuRBIDANj+KVZ
vLKlTCaGAUNIjkiDDgti=</>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig #">
<ds:SignedInfo>
<ds:Reference URI="#BST">...</>
<ds:Reference URI="#BDY">
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1 "/>
<ds:DigestValue>YgGfS0pi56pu</></></>
...</></></>
<xx:Query/></></>
H.4
ID-WSF 2.0 Call with Bearer (SAML) Sec Mech
<e:Envelope
xmlns:sb="urn:liberty:sb:2005-11"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<e:Header>
<sbf:Framework version="2.0-simple" e:mustUnderstand="1"
e:actor="http://schemas.../next"
wsu:Id="SBF"/>
<wsa:MessageID wsu:Id="MID">...</>
<wsu:Timestamp wsu:Id="TS">
<wsu:Created>2005-06-17T04:49:17Z</></>
4096
4097
4098
4099
4100
<sa:Assertion
Version="2.0"
ID="A7N123"
TAS3 ICT-216287
Page 167 of 211
4101
4102
4103
4104
4105
4106
4107
4108
4109
4110
4111
4112
4113
4114
4115
4116
4117
4118
4119
4120
4121
4122
4123
4124
IssueInstant="2005-04-01T16:58:33.173Z">
<sa:Issuer>http://idp.symdemo.com/idp.xml</>
<ds:Signature>...</>
<sa:Subject>
<sa:EncryptedID>
<xenc:EncryptedData>U2XTCNvRX7Bl1NK182nmY00TEk==</>
<xenc:EncryptedKey>...</></>
<sa:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/></>
<sa:Conditions
NotBefore="2005-04-01T16:57:20Z"
NotOnOrAfter="2005-04-01T21:42:4 3Z">
<sa:AudienceRestrictionCondition>
<sa:Audience>http://wsp.zxidsp.org</></></>
<sa:AuthnStatement
AuthnInstant="2005-04-01T16:57:30.000Z"
SessionIndex="6345789">
<sa:AuthnContext>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</></></>
<sa:AttributeStatement>
<sa:EncryptedAttribute>
<xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element">
mQEMAzRniWkAAAEH9RbzqXdgcX8fpEqSr1v4=</>
<xenc:EncryptedKey>...</></></></>
4125
4126
4127
4128
4129
4130
4131
4132
<wsse:SecurityTokenReference
xmlns:wsse11="..."
wsu:Id="STR1"
wsse11:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#S
<wsse:KeyIdentifier
ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID
A7N123</></>
4133
4134
4135
4136
4137
4138
4139
4140
4141
4142
4143
4144
4145
4146
4147
<ds:Signature>
<ds:SignedInfo>
<ds:Reference URI="#STR1">
<ds:Transform Algorithm="...#STR-Transform">
<wsse:TransformationParameters>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n<ds:Reference URI="#BDY"/></>
...</></></>
<xx:Query/></></>
TAS3 ICT-216287
Page 168 of 211
4148
4149
Note how the <Subject> and the attributes are encrypted such that only the WSP can open them.
This protects against WSC gaining knowledge of the NameID at the WSP.
TAS3 ICT-216287
Page 169 of 211
Annex I: Glossary
Abstract Business Process Abstract business processes are partially specified processes that are
not intended to be executed. An Abstract Process may hide some of the required concrete
operational details. Abstract Processes serve a descriptive role, with more than one possible
use case, including observable behavior and process template.
• Source: Quentin (Quentin.Reul@vub.ac.be)
Accessibility Accessibility means any condition, disease or disability that requires special employment measures or is eligible for positive action.
• Source: Ingo (dahn@uni-koblenz.de)
APL See Accreditation of Prior Learning
Accreditation of Prior Learning
• Source: Dries (dries.pruis@kenteq.nl)
Activity
An activities an agent wishes to undertake in order to fulfill his/her goals.
Action
An operation on a resource.
• Source: David (d.w.chadwick@KENT.AC.UK)
• Reference: PERMIS Glossary
Address An address is the identifier for a specific termination point and is used for routing to this
termination point.
• Reference: ITU-T Y.2091 - Terms and definitions for Next Generation Networks
Affiliation
Membership of learned, professional, civic and recreational organisations.
Agent
A person (or service) entitled to act on behalf of another.
Anonymity Ability to allow anonymous access to services, which avoid tracking of user’s personal
information and user behaviour such as user location, frequency of a service usage, and so on.
• Reference: ITU-T X.1121 (04), 3.2.1
TAS3 ICT-216287
Page 170 of 211
ADPDP See Application Dependent PDP
Application Dependent PDP Application Dependent PDP. Apply specific rules that relate to the
application roles. Typically communicates with ADPEP, but may also proxy requests in relevant
special cases to outside PDPs or gather Information for its decisions from outside, including
from Reputation Providers.
ADPEP See Application Dependent PEP
Application Dependent PEP
municates with ADPDP.
Apply specific rules that relate to the application roles. Typically com-
AIPDP See Application Independent PDP
Application Independent PDP Application Independent PDP, more properly TAS3 Network PDP or
External PDP Aggregator (cf. Architecture: Anatomy of PEP)
AIPEP See Application Independent PEP
Application Independent PEP Application Independent PEP, typically communicates with AIPDP
(cf. Architecture: Anatomy of PEP)
AP See Asserting Party
Asserting Party
*** TBD
Assertion A collection of one or more statements about an entity (e.g. Authentication statement or
Authorisation statement).
• Reference: OMA - The Open Mobile Alliance
Asset
Anything that has value to the organization, its business, its operations and its continuity.
• Reference: ITU-T Y.2701 - Security requirements for NGN release 1
Assurance Level A quantitative expression of Authentication Assurance agreed between a Relying
Party and an Identity Provider.
• Reference: ITU-T Y.IdMsec
TAS3 ICT-216287
Page 171 of 211
Asymmetric Authentication Method
A method of authentication, in which not all authentication
information is shared by both entities.
• Reference: ITU-T Y.IdMsec, X.811
Attribute
A distinct characteristic of an object. An object’s attributes are said to describe the object. Objects’ attributes are often specified in terms of their physical traits, such as size, shape,
weight, and color, etc., for real-world objects. Objects in cyberspace might have attributes describing size, type of encoding, network address, etc.
• Reference: WSIA Glossary - Glossary for the OASIS WebService Interactive Applications
(WSIA/WSRP)
AA See Attribute Authority
Attribute Authority
the SOA.
Trusted authorities, which assign roles to users. Normally this is also done by
AAPML See Attribute Authority Policy Markup Language
Attribute Authority Policy Markup Language AAPML is a XACML profile designed to allow attribute authorities to specify conditions under which information under management may be
used (and possibly modified) by other applications.
• Source: Liberty Alliance Project
• Reference: http://www.oracle.com/technology/tech/standards/idm/igf/pdf/IGF-AAPML-spec
AC See Attribute Certificate
Attribute Certificate Attributes that are certified (digitally signed) by an Attribute Authority as belonging to a particular object. As an analogy, if a PKC corresponds to a passport, an AC corresponds
to a visa.
ACRL See Attribute Certificate Revocation List
Attribute Certificate Revocation List
List of revoked ACs issued by and AA.
TAS3 ICT-216287
Page 172 of 211
Attribute Type
attribute.
That component of an attribute which indicates the class of information given by that
• Reference: ITU-T X.501 - Information technology - Open Systems Interconnection - The
Directory: Models
Attribute Value
A particular instance of the class of information indicated by an attribute type.
Directory: Models
Audit
An independent review and examination of system records and activities in order to test for
adequacy of system controls, to ensure compliance with established policy and operational procedures, to detect breaches in security, and to recommend any indicated changes in control,
policy and procedures.
• Reference: ITU-T X.800 - Security architecture for Open Systems Interconnection for
CCITT applications
Audition Aiming at providing only high quality service to the users, the provider of a directory service
can be interested in testing that the services asking for registration are of "good" quality. For this
purpose, the directory could submit the service under registration to a verification step before
granting the registration. The implementation of such process with respect to the technical
assessment is called Audition (Automatic Model-Based Interface Testing In Open Networks).
• Source: Antonia (antonia.bertolino@isti.cnr.it)
Authenticated Identity
thentication.
A distinguishing identifier of an entity that has been assured through au-
Authn See Authentication
Authentication
The provision of assurance of the claimed identity of an entity.
Authentication Certificate A security certificate that is guaranteed by an authentication authority
and that may be used to assure the identity of an entity.
TAS3 ICT-216287
Page 173 of 211
Authentication Exchange A sequence of one or more transfers of exchange authentication information (AI) for the purposes of performing an authentication.
Authentication Information
Information used to establish the validity of a claimed identity.
Authentication Initiator
The entity that starts an authentication exchange.
Authentication Insurance A measure of confidence that the security features and architecture of
the Identity Management capabilities accurately mediate and enforce the security policies understood between the Relying Party and the Identity Provider.
Authorisation
The granting of rights, which includes the granting of access based on access rights.
Authorization Decision The result of evaluating applicable policy, returned by the PDP to the PEP. A
function that evaluates to "Permit", "Deny", "Indeterminate" or "NotApplicable", and (optionally)
a set of obligations
Authoritative In the context of IdM, the Identity Provider which posses the authority under law, contractual agreement, or customary practice to definitively answer queries concerning a specific
identity for which it is responsible.
Authority Number Agents may receive an authority number from a registered authority to be uniquely
identified within the authority’s jurisdiction or system. Among authority numbers are included:
social security numbers, enrollment numbers, etc. An authority number typically consists of a
name, a scheme and a code.
TAS3 ICT-216287
Page 174 of 211
Authority Provider A provider of authentication numbers, the uniques of numbers and their meaning
are defined by the authority providers jurisdiction or system. Examples are governments, who
can supply social security numbers, driving license numbers etc.
Availability Availability is the goal that assets have to be available to authenticated and authorised
agents when needed.
• Reference: Hafner & Breu, Security Engineeing for Service-Oriented Architectures, Springer,
2009
Behavioural Factors Aspects of feedback used in define a reputation. For example for a helpdesk
one could consider politeness, responsiveness, usefulness of supplied information, etc. These
factors may be combined into the reputation differently depending on the needs of the user.
• Source: Sampo (sampo@symlabs.com)
BTM See Behavioural Trust Management
Behavioural Trust Management Class of trust management systems that use information on past
performance to build trust. RTM and KPITM are examples.
• Source: Jerry (j.d.hartog@tue.nl)
BGP See Breaking-the-glass Policy
Breaking-the-glass Policy A term used to describe an access control policy that allows users who
would not normally have access to a resource, to gain access themselves by "breaking the glass"
in the full knowledge that they will have to answer for their actions later to their management.
BMO See Business Management Ontology
Business Management Ontology The Business Management Ontology (BMO) represents an integrated information model, which helps to better align IT with business. It brings together
business process design, project management, requirements management, and business performance management (in the form of balanced scorecards). As such, it forms the basis for
an integrated, vendor-neutral, Business Management Knowledge Base, from which various artifacts can be generated.
• Reference: Ontology-Based Business Process Management - The Vision Statement
Business Process
TAS3 ICT-216287
*** TBD
Page 175 of 211
Business Process Engine The Business Process Engine orchestrates entities that control how FEs
and SPs work together to achieve the objectives of the business process.
BPEL See Business Process Execution Language
Business Process Execution Language WS-BPEL provides a language for the specification of
Executable and Abstract business processes. By doing so, it extends the Web Services interaction model and enables it to support business transactions. WS-BPEL defines an interoperable
integration model that should facilitate the expansion of automated process integration in both
the intra-corporate and the business-to-business spaces.
• Source: Jutta (muelle@ipd.uka.de)
• Reference: Web Services Business Process Execution Language Version 2.0
BPEL4People See Business Process Execution Language Extension for People
Business Process Execution Language Extension for People BPEL4People addresses human
interactions in BPEL. It defines a new type of basic activity which uses human tasks as an
implementation, and allows specifying tasks local to a process or use tasks defined outside of
the process definition.
• Reference: WS-BPEL Extension for People (BPEL4People), Version 1.0
BPM See Business Process Modelling
Business Process Modelling Using a formal methodology to describe a business process. Such
formal model will usually allow some of the configuration details for implementing the business
model to be automatically derived.
BPMN See Business Process Modeling Notation
Business Process Modeling Notation The Business Process Modeling Notation (BPMN) is a graphical notation that depicts the steps in a business process. BPMN depicts the end to end flow of
a business process. The notation has been specifically designed to coordinate the sequence of
processes and the messages that flow between different process participants in a related set of
activities.
• Reference: http://www.bpmn.org/
BPO See Business Process Ontology
Business Process Ontology
*** TBD
TAS3 ICT-216287
Page 176 of 211
Certificate A set of security-relevant data issued by a security authority or a trusted third party,
together with security information which is used to provide the integrity and data origin authentication services for the data.
CCITT applications
CA See Certification Authority
Certification Authority
Issues digital certificates.
Choreography A choreography description is a multi-party contract that describes from global view
point the external observable behavior across multiple clients (which are generally Web Services
but not exclusively so) in which external observable behavior is defined as the presence or
absence of messages that are exchanged between a Web Service and it’s clients.
• Source: Guglielmo (guglielmo.deangelis@isti.cnr.it)
CoT See Circle of Trust
Circle of Trust
See Trust Network.
Claim
An assertion made by a Claimant of the value or values of one or more Identity Attributes of a
Digital Subject, typically an assertion which is disputed or in doubt.
• Reference: Identity Gang of Identity Commons
Claim Authentication Information
to authenticate an entity.
Information used by a claimant to generate exchange AI needed
Client While general meaning as in "customer" is acknowledged, in protocol contexts "Client" is
taken to mean requester of a service. Thus Client is the counter part of a Service Provider.
Client is a business entity and quite different from a User. A Service Provider can be a Client
towards other entities that it calls.
CARML See Client Attribute Requirements Markup Language
TAS3 ICT-216287
Page 177 of 211
Client Attribute Requirements Markup Language Client Attribute Requirements Markup Language
is a specification that allows applications to define their attribute requirements as it relates to
identity. CARML can be used to automate configuration of identity attribute services and to
expose the set of identity-related data consumed by a specific application or groups of applications.
• Reference: http://www.oracle.com/technology/tech/standards/idm/igf/pdf/IGF-CARML-spec
Competency A competency is a demonstrated ability of a natural person to apply knowledge, skills
and attitudes to achieve observable results.
Confidentiality Confidentiality is the goal that data should be readable to agents with appropriate
permissions.
2009
Context A property that can be associated with a user attribute value to specify information that can
be used to determine the applicability of the value.
Directory: Models
Credential Authentication and Authorization data that can be used to authenticate the claimer is
what it claims to be and authorize the claimer’s access rights. What AA needs from the SOA to
be able to issue ACs.
• Reference: ETSI TS 132 372 V7.0.0
• Comments: CONFLICT:
CTM See Credential based Trust Management
Credential based Trust Management System which builds trust on structural rules which are exchanged in the form of credentials.
Credential Chain A tree (or sequence) of credentials which ensures trustworthiness of the statement
in the root credential. Each node is validated by its children and the leaf credentials are issued
by trusted entities (e.g. AA).
TAS3 ICT-216287
Page 178 of 211
CIS See Credential Issuing Service
Credential Issuing Service The service of issuing a digitally signed attribute assertions provided
by an authoritative source of subject attributes
CVS See Credential Validation Service
Credential Validation Service The service of validating digitally signed attribute assertions and
determining which are trusted and which are not.
Data Origin Authentication
Corroboration that the source of data received is as claimed.
Data Protection
*** TBD
• Source: Joseph (joseph.alhadeff@ORACLE.COM)
DB See Dashboard
Dashboard A web GUI for viewing audit records, work flow status, and/or viewing and manipulating
privacy settings and permissions.
DTM See Decentralised Trust Management
Decentralised Trust Management
DEPRECATED - see CTM
Decision Request
The request by a PEP to a PDP to render an authorization decision
Delegatee
Delegation
The entity receiving a privilege though a delegation.
Conveyance of privilege from one entity that holds such privilege, to another entity.
• Reference: ITU-T X.509 (00), 3.3.46 - Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks
TAS3 ICT-216287
Page 179 of 211
Delegator
The entity that holds and conveys a privilege to another entity though a delegation.
Digital Identity The digital representation of the information known about a specific individual, group
or organization
• Reference: CERIAS - Tech Report 2007-17 - Privacy Preserving Multi-factor Authentication with Biometrics
Digital Identity Provider
An Agent that issues a Digital Identity.
Digital Subject An Entity represented or existing in the digital realm which is being described or
dealt with.
Directed Identity A unifying identity metasystem must support both "omni-directional" identifiers for
public entities and "unidirectional" identifiers for private entities
Discovery
ery.
Finding entities/services/objects matching a set of criteria, e.g. Service Discov-
DNS See Domain Name System
Domain Name System The scheme for attributing alphanumeric, human readable "web addresses".
DNS will map the human readable string to an IP address. Sometimes a /etc/hosts file
replaces the function of the DNS, but this solution, while allowing more local control, is generally
very burdensome to maintain.
Electronic Identity The information about a registered entity, that the Identity Provider has chosen
to represent the Identity of that entity. The eID includes a name or an identifier for the entity that
is unique within the domain of the Identity Provider.
• Reference: TF-AACE - Terena Authentication and Authorisation
Employability
*** TBD
• Source: Dries (dries.pruis@kenteq.nl)
Enrolment
The process of adding a Permission to an Identity.
TAS3 ICT-216287
Page 180 of 211
• Reference: Identity Dictionary
Entity Anything that has separate and distinct existence that can be uniquely identified. In the context
of IdM, examples of entities include subscribers, users, network elements, networks, software
applications, services and devices. An entity may have multiple identifiers.
Executable Business Process Executable business processes model actual behavior of a participant in a business interaction.
XACML See eXtensible Access Control Markup Language
eXtensible Access Control Markup Language The OASIS Extensible Access Control Markup Language (XACML) TC was chartered "to define a core schema and corresponding namespace for
the expression of authorization policies in XML against objects that are themselves identified in
XML. There are many proprietary or application-specific access control policy languages, but
this means policies cannot be shared across different applications, and provides little incentive
to develop good policy composition tools. XACML enables the use of arbitrary attributes in policies, role-based access control, security labels, time/date-based policies, indexable policies,
’deny’ policies, and dynamic policies - all without requiring changes to the applications that use
XACML."
• Source: OASIS
• Reference: http://xml.coverpages.org/xacml.html
Federation A federation is a collection of realms that have established a producer-consumer relationship whereby one realm can provide authorized access to a resource it manages based on
an identity, and possibly associated attributes, that are asserted in another realm. A federation
requires trust such that a Relying Party can make a well-informed access control decision based
on the credibility of identity and attribute data that is vouched for by another realm.
• Reference: FG IdM Use Case WG - ITU-T Focus Group for Identity Management
Federated Identity A single user identity that can be used to access a group of services or applications that are bounded by the ties and conditions of a federation.
FIM See Federated Identity Management
TAS3 ICT-216287
Page 181 of 211
Federated Identity Management The communal services provided by a group of organisations
which have set up trust relationships between themselves, so that they can send each other
digitally signed attribute assertions about their users’ identities in order to grant each others’
users access to their resources.
FE See Front-end
Front-end
In this context, it means web site, i.e. SP
GA See Governing Agreement
Governing Agreement Legal document that every member of Trust Network MUST agree to. This
can be seen as the charter of the Trust Network.
Identification The process of verifying the identity of a user, process, or device, usually as a prerequisite for granting access to resources in an IT system.
• Reference: SP800 - 47 Appendix D - National Institute for Standards and Technology Security Guide for Interconnecting Information Technology Systems
Identifier An identifier is a series of digits, characters and symbols or any other form of data used
to identify subscriber(s), user(s), network element(s), function(s), network entity(ies) providing
services/applications, or other entities (e.g., physical or logical objects).
• Reference: ITU-T Y.2091 - Terms and definitions for Next Generation Networks
Identity An identity is a uniquely identifiable representation of an agent. An agent can have multiple
identities that do not necessarily interrelate.
IAF See Identity Assurance Framework
Identity Assurance Framework
*** TBD
• Reference: http://www.projectliberty.org/content/download/4315/28869/file/liberty-ide
Identity Agent It manages and supports a consistent user experience (and in some cases other
kinds of interactions) with a Service Provider.
TAS3 ICT-216287
Page 182 of 211
Identity Attribute
A property of a Digital Subject that may have zero or more values.
Identity Availability The availability of an identity gives an indication of the how much an agent can
spend on a particular job.
Identity Based Security Policy A security policy based on the identities and/or attributes of users,
a group of users, or entities acting on behalf of the users and the resources/objects being
accessed.
CCITT applications
Identity Context The surrounding environment and circumstances that determine meaning of Digital
Identities and the policies and protocols that govern their interactions.
IGF See Identity Governance Framework
Identity Governance Framework It is an open initiative to address governance of identity related
information across enterprise IT systems. This initiative includes key initial draft specifications
contributed by Oracle to the community. These specifications provide a common framework
for defining usage policies, attribute requirements, and developer APIs pertaining to the use of
identity related information. These enable businesses to ensure full documentation, control, and
auditing regarding the use, storage, and propagation of identity-related data across systems and
applications.
• Reference: http://www.oracle.com/technology/tech/standards/idm/igf/pdf/IGF-Overview-0
Identity Information All the information identifying a user, including trusted (network generated)
and/or untrusted (user generated) addresses. Identity information shall take the form of either a
SIP URI (see RFC 2396) or a "tel" URI (see RFC 3966).
• Reference: ETSI TS 183 007 V1.1.1
TAS3 ICT-216287
Page 183 of 211
Identity Layer An identity layer attempts to develop convergence and interoperability regarding identity, can draw from multiple data stores, selectively exposing, or concealing data and attributes,
according to policy.
IdM See Identity Management
Identity Management The management by trusted providers of trusted attributes of an entity such
as: a subscriber, a device or a provider.
IdMAA See Identity Management, Authentication and Authorisation Infrastructure
Identity Management, Authentication and Authorisation Infrastructure
middleware responsible for authenticating and authorizing entities.
Application independent
Identity Pattern A structured expression derived from the behaviour of an entity that contributes to
the recognition process; this may include the reputation of the entity. Identity patterns may be
uniquely associated with an entity, or a class with which the entity is associated.
IdP See Identity Provider
Identity Provider An entity that specializes in identifying (collecting identity information or PII), and
authenticating users. IdP is usually, and in SAML case especially, charged with the role of
facilitating Single Sign On (SSO). IdP often with the role of facilitating Single Sign On (SSO).
IdP often also conveys PII when authenticating the User. IdP has prime visibility to the usage
patterns of a User and is therefore especially vulnerable or in need of special business or administrative protections. IdP function is often associated with ID Service Discover and Token
Mapping functions. Core of an IdP is a federation database where mappings between several
pseudonymous identities and relationships with the service providers are evident. This database
constitutes a fat target when an identity system is attached.
Identity Registration The process of making a person’s identity known to the (Personal Identity Verification) system, associating a unique identifier with that identity, and collecting and recording
the person’s relevant attributes into the system.
TAS3 ICT-216287
Page 184 of 211
• Reference: FIPS 201 App. F
Inactive Status A service is inactive if it needs to use services that are not yet available according
to the Registry.
Integrity
Integrity is the goal that data and information should not be altered if not explicitly allowed.
2009
IDL See Interface Description Language
Interface Description Language
IDL.
For example within the standards of the family WS*, WSDL is an
Interoperability Interoperability is the ability of two or more systems or components to exchange [?]
information and to use the information that has been exchanged. In particular, it envisages the
ability for loosely-coupled independent systems to be able to collaborate and communicate; the
possibility of use in services outside the direct control of the issuing assigner.
• Reference: Institute of Electrical and Electronics Engineers. IEEE Standard Computer
Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990.
KPI See Key Performance Indicator
Key Performance Indicator Key Performance Indicators are combinations of different Business Performance factors such as Time to deliver, or number of patent application, etc.
KPITM See Key Performance Indicator Trust Management
Key Performance Indicator Trust Management System which builds trust on economical factors
such as performance on delivery times, number of patents filed, etc.
Layer Network A "topological component" that represents the complete set of access groups of the
same type which may be associated for the purpose of transferring information.
• Reference: ITU-T G.805 - Generic functional architecture of transport networks
LoA See Level of Assurance
TAS3 ICT-216287
Page 185 of 211
Level of Assurance A metric which is used to measure the confidence (or assurance) that a relying
party can have, that an authenticated user is really who they say they are. One scale, devised
by the US National Institute of Science and Technology, ranges from 1 to 4, with 4 being the
highest.
LDAP See Lightweight Directory Access Protocol
Lightweight Directory Access Protocol
*** TBD
LTS See Long Tail Service
Long Tail Service It means that half of the volume of the internet use can be in myriad of low use
services (the other half is in few high volume services).
MS See Message Signer
Message Signer
Digitally signs request.
• Source: Danny (decockd@esat.kuleuven.be)
MV See Message Verifier
Message Verifier
Verifies digital signature and other constraints of a request.
NOC See Network Operation Center
Network Operation Center
*** TBD
Non-Repudiation The ability through historical logs and logical analysis to prevent or discourage an
Entity from denying that it had acted as an Identity in a given transaction, especially in a legal
sense.
Object A well-defined piece of information, definition, or specification which requires a name in order
to identify its use in an instance of communication and identity management processing.
• Reference: ITU-T X.680 - Information technology - Abstract Syntax Notation One (ASN.1):
Specification of basic notation
TAS3 ICT-216287
Page 186 of 211
Obligation An operation specified in a policy that should be performed by the PEP in conjunction
with the enforcement of an authorization decision
Offline Testing Testing phase that includes the activities that are performed while no user ("paying
customer) is using the service. Hence, off-line validation of a system implies that it is tested in
one or more artificially evolving environments that simulate possible real interactions.
• Source: Seda (sguerses@ESAT.KULEUVEN.BE)
Online Testing Testing phase that concerns a set of methodologies, techniques, and tools to monitor
a system after its deployment in its real working context.
Ontology an ontology is commonly defined as: "a [?, ?] conceptualization" (Gruber, 1993). More
specifically, an ontology explicitly defines a set of entities (e.g. classes, relations and individuals)
imposing a structure on the domain that is readable by both humans and machines.
• Reference: Gruber, T. R. (1993). Towards principles for the design of ontologies used for
knowledge sharing. In Formal Ontology in Conceptual Analysis and Knowledge Representation, pages 907-928.
Orchestration
action.
The process of coordinating the sequence and data flow during (web) services inter-
Owner
The registered Entity for an Identity.
Panopticon threat A especially pertinent risk in running a Trust Guarantor is that it may gain excessive knowledge to the operations of the Service Provider members or the Users and their
business processes. It can be mitigated by careful division of responsibilities using externally
contracted Trusted Third Parties, each of which operates in its own isolated, regulatory scheme.
Pending Status A service is in a pending status if it is registered to a directory service, but has not
yet been tested by Audition.
Persistent Existing, and able to be used in services outside the direct control of the issuing assigner,
without a stated time limit.
TAS3 ICT-216287
Page 187 of 211
• Reference: ISO Project 26324 - Digital Object Identifier (DOI) system - ISO TC46/SC9
Working Group 7
PCP See Personal Competency Profile
Personal Competency Profile
*** TBD
PDS See Personal Data Store
Personal Data Store
*** TBD
• Source: Luk (luk@synergetics.be)
PII See Personally Identifying Information
Personally Identifying Information
of the User.
Information that may allow identifying a User, or impersonation
PUPPET See Pick UP Performance Evaluation Test-bed
Pick UP Performance Evaluation Test-bed It is an approach for the automatic generation of testbeds to empirically evaluate the QoS characteristics of a Web Service under development.
Specifically, the generation exploits the information about the coordinating scenario, the service
description (WSDL) and the specification of the agreed QoS properties.
Policy A set of rules, an identifier for the rule-combining algorithm and (optionally) a set of obligations. May be a component of a policy set.
PAP See Policy Administration Point
Policy Administration Point
*** TBD
PDP See Policy Decision Point
Policy Decision Point The (application independent) part of an access control system that can
answer access control requests with a granted or denied decision.
PEP See Policy Enforcement Point
TAS3 ICT-216287
Page 188 of 211
Policy Enforcement Point The (application dependent) part of an access control system that is
responsible for enforcing the authorization decisions returned by the PDP.
PIP See Policy Information Point
Policy Information Point
*** TBD
PMS See Policy Management Service
Policy Management Service Handles the management of user policies and ’organization wide’ policies. Moreover it will have a functionality to attach policies to a request respectively a response.
This is an ongoing task in WP8 under the name of ’Aggregating Policies’.
Principal
See Entity.
Privacy
*** TBD
Privacy Policy A set of rules and practices that specify or regulate how a person or organization
collects, processes (uses) and discloses another party’s personal data as a result of an interaction.
• Reference: W3C Glossary and Dictionary
Private Identifier A Claimed Identifier that is intended to be private information used only the context
of the End User’s relationship with one or more specific Relying Parties (typically one or a small
number). The use of Private Identifiers reduces or eliminates the ability of multiple Relying
Parties to do correlation of an End User.
• Reference: OpenID
Privilege A right to carry out a particular permission (act) that is assigned to a role with some
constraints or conditions. A role is (can be) associated with multiple privileges.
TAS3 ICT-216287
Page 189 of 211
PMI See Privilege Management Infrastructure
Privilege Management Infrastructure A highly scalable infrastructure, based on digitally signed attribute assertions, which allows subjects to be authorised to use the resources of relying parties
based on their mutual trust in Attribute Authorities. A component of FIM.
PVS See Privilege Verification Subsystem
Privilege Verification Subsystem
Decision Engine consisting of PEP and PDP.
PMF See Process Modelling Framework
Process Modelling Framework
*** TBD
• Source: Intalio
Provisioning Automatically providing an Identity with access to a role, resource or service, or automatically changing or removing that access, based on the life cycle of events or work requests
or changed attributes.
Pseudonym A fictitious identity that an Entity creates for itself, whereby the Entity can remain
pseudonymous, or perhaps even fully anonymous, in certain contexts.
Pseudonymity
See Pseudonym.
PKC See Public Key Certificate
Public Key Certificate An electronic document that using a digital signature binds together a public
key and an identity. As an analogy, if an AC corresponds to a visa, a PKC corresponds to a
passport.
PKI See Public Key Infrastructure
TAS3 ICT-216287
Page 190 of 211
Public Key Infrastructure A highly scalable infrastructure, based on public key cryptography, which
allows subjects to authenticate to relying parties based on their mutual trust in Public Key Certification Authorities (a type of TTP). A component of FIM.
Public Private Partnership
*** TBD
• Source: Luk (luk@synergetics.be)
QoS See Quality Of Service
Quality Of Service
*** TBD
RTM See Real-Time Trust Management
Real-Time Trust Management
DEPRECATED
Registry
*** TBD
RP See Relying Party
Relying Party A Party that makes known through its Agent one or more alternative sets of Claims
that it desires or requires, and receives through this same Agent a Digital Identity purportedly
including the required Claims from a Digital Identity Provider or other Agent of another Party.
Repository
*** TBD
Repudiation Denial by one of the entities involved in a communication of having participated in all
or part of the communication
• Reference: X.800 (91), 3.3.44
Reputation The reputation of an entity is the view on that entity based on its past performance.
Reputations are computed based on recommendations and on feedback on interaction with the
entity.
RTM See Reputation based Trust Management
Reputation based Trust Management System which builds trust on past performance expressed
in feedback and recommendation.
TAS3 ICT-216287
Page 191 of 211
• Comments: CONFLICT: Same acronym as Real Time Trust
PDP-R See Requester Policy Decision Point
Requester Policy Decision Point
*** TBD
PEP-R See Requester Policy Enforcement Point
Requester Policy Enforcement Point
*** TBD
Resource
Data, service or system component
RS See Response Signer
Response Signer
Digitally signs request
• Comments: CONFLICT: Shouldn’t it be ’response’ instead of ’request’.
RV See Response Verifier
Response Verifier
Verifies digital signature and other constraints of a response.
Risk
A Risk is defined as a triplet consisting of a targeted model element, a related security requirement and a threat that potentially undermines the requirement, including an assessment of its
severity. Moreover, every risk is evaluated in the context of the currently implemented security
controls.
2009
Role Type of attribute that is typically used to signify the position that someone has in an organisation.
RBAC See Role Based Access Control
TAS3 ICT-216287
Page 192 of 211
Role Based Access Control A model for controlling access to resources where permitted actions
on resources are identified with roles rather than with individual subject identities.
S&T See Science and Technology
Science and Technology
*** TBD
SAML See Security Assertion Markup Language
Security Assertion Markup Language It is an XML-based framework for communicating user authentication, entitlement, and attribute information. As its name suggests, SAML allows business
entities to make assertions regarding the identity, attributes, and entitlements of a subject (an
entity that is often a human user) to other entities, such as a partner company or another enterprise application.
• Reference: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
Security Control A Security Control is any managerial, operational, and/or technical measure or
safeguard that has been put in place to mitigate identified risks.
2009
Security Domain A set of elements, a security policy, a security authority and a set of securityrelevant activities in which the elements are managed in accordance with the security policy.
The policy will be administered by the security authority. A given security domain may span
multiple security zones.
Security Domain Authority A security authority that is responsible for the implementation of a security policy for a security domain.
SO See Security Officer
Security Officer A job function or role at Trust Guarantor. Similar function, with the same name,
may also exist at Trusted Third Parties, and Service Providers. Security Officer’s job is to on
continuing basis verify and validate that the members of a Trust Network adhere to the rules.
To do this Security Officer usually operates and monitors automated auditing and systems monitoring tools. If discrepancies are found, or complaints are reported, the Security Officer will
TAS3 ICT-216287
Page 193 of 211
investigate manually in more detail. Security Officer also participates in approving new members to the network and in taking disciplinary action, such as removal from the network, against
the offenders.
Security Objective A Security Objective describes a general security goal to the system. Security
Objectivess in many cases originate in legal requirements and general availability, integrity and
confidentiality requirements.
2009
Security Policies A Security Policy realises a specific Security Objective (or a combination thereof).
A Security Policy is defined as a statement of what is and what is not allowed.
2010
Security Requirement A Security Requirement is a detailed context-dependent explanation of a
Security Objective. It breaks security objectives down in severla more detailed descriptions.
The context of a Seurity Requirement is derived from the model element for which it is defined.
2010
Semantics
*** TBD
SoD See Separation of Duties
Separation of Duties A security procedure whereby a high risk task is split into at least two subtasks which have to be carried out by different people.
Disco See Service discovery
Service discovery Service discovery, sometimes specifically identity enabled service discovery
such as Liberty ID-WSF Discovery Service. Discovery service corresponds to one of the bulletin
boards in Danny’s "snake" diagram.
SOA See Service Oriented Architecture
TAS3 ICT-216287
Page 194 of 211
Service Oriented Architecture A conglomeration of web services, or in a broader sense any kind of
services. SOA paradigm attempts to abstract the services so that they are reusable components
that can be composed in different arrangements at will. Parallel to the orchestration, there is
identity propagation infrastructure and authorization infrastructure, which in its turn relies on
trust infrastructure. Real life SOAs are much less generic and recomposing the components in
any reliable way remains a dream.
SP See Service Provider
Service Provider An entity that provides a kind of electronic service to users. In TAS3 context the
service is foreseen to be provided over a network, usually the Internet.
PDP-P See Service Provider Policy Decision Point
Service Provider Policy Decision Point
*** TBD
PEP-P See Service Provider Policy Enforcement Point
Service Provider Policy Enforcement Point
*** TBD
SPPE See Service Provider Process Engine
Service Provider Process Engine
Controlling logic of the Service Provider.
SRPE See Service Requester Process Engine
Service Requester Process Engine
Controlling logic of the Client.
STM See Session Trust Management
Session Trust Management System which builds trust from session parameters such as authentication parameters used. Establishing a given LoA is an example of STM.
SOAP See Simple Object Access Protocol
TAS3 ICT-216287
Page 195 of 211
Simple Object Access Protocol SOAP is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on Extensible
Markup Language (XML) as its message format, and usually relies on other Application Layer
protocols (most notably Remote Procedure Call (RPC) and HTTP) for message negotiation and
transmission. SOAP can form the foundation layer of a web services protocol stack, providing a
basic messaging framework upon which web services can be built.
• Reference: http://www.w3.org/TR/soap/
SLO See Single Log-Off
Single Log-Off The converse of SSO, whereby a user is simultaneously logged out of all the services
that he is currently logged into via SSO.
SSO See Single Sign-On
Single Sign-On The process whereby a user can sequentially gain access to a number of computer
services by only providing his login credentials once to the first service he contacts.
SoA See Source of Authority
Source of Authority
Root of trust, issues ACs and may have subordinate AAs.
• Comments: CONFLICT: Potential problem with acronyms
StTM See Structural Trust Management
Structural Trust Management Class of trust management systems which use formally expresses
trust facts and relations to establish trust. CTM and STM are examples.
Structural Trust Rules It can be simple trust statements as Provider X is trusted to supply Job
Vacancies and the combinations trust relations for example when the party trusted to issue
credentials is itself determined by trust rules; Provider X is trusted to supply Job Vacancies
if a trusted Accreditation agency certifies them. An Accreditation agency is trusted to certify
Providers if it is registered at a national registry and has a good reputation, etc.
Subcontinent
*** TBD
TAS3 ICT-216287
Page 196 of 211
Subject
An actor who wants to perform an action on a target.
Symmetric Authentication Method A method of authentication in which both entities share common authentication information.
Target
A resource on which a subject tries to perform an action.
TAS3 Trust Network
See Trust Network.
Test Driver
A dedicated software service that is able to run test suites on a service under test.
Test Storage
A dedicated software repository that stores test suites to be used by Audition.
TAXI See Testing by Automatically generated XML Instances
Testing by Automatically generated XML Instances A tool by CNR that generates XML instances
from an XML Schema automatically. The methodology is largely inspired by the Category Partition testing technique.
• Source: Antonia (antonia.bertolino@isti.cnr.it)
Threat A threat is the description of an adverse event that is considered as potentially having a
negative impact. A Threat by itself is not interesting, but becomes relevant when associated
with a targeted model element and a security requirement.
2009
TTL See Time-To-Live
Time-To-Live Parameter that indicates how long a cache entry is valid. Generally a cache entry will
not be re-fetched until TTL expires. This concept is especially used by the DNS.
TLG See Top Level Guarantor
TAS3 ICT-216287
Page 197 of 211
Top Level Guarantor
Trail
See Trust Guarantor.
A "transport entity" which consists of an associated pair of "unidirectional trails" capable of
simultaneously transferring information in opposite directions between their respective inputs
and outputs.
Transmission Media Layer Network A "layer network" which may be media dependent and which
is concerned with the transfer of information between transmission media layer network "access
points" in support of one or more "path layer networks".
Transport
The functional process of transferring information between different locations.
Transport Entity
An architectural component which transfers information between its inputs and
outputs within a layer network.
TLS See Transport Layer Security
Transport Layer Security
*** TBD
Transport Network The functional resources of the network which conveys user information between locations.
Trust
Is used to refer to both the subjective notion of trust, i.e. a perceived likelihood that an
entity/system will behave/perform as required as well as to a formalization of this notion
into a measurable quantity.
TPN See Trust and Privacy Negotiator
Trust and Privacy Negotiator
TAS3 ICT-216287
*** TBD
Page 198 of 211
T&S See Trust and Security
Trust and Security
DEPRECATED
Trust Consortium Convener
Trust Ecosystem
The users, members, suppliers, and stake holders of a Trust Network.
Trust Information Collector A point which gathers feedback information needed to calculate reputations (see also WP2 D2.1 deliverable).
TG See Trust Guarantor
Trust Guarantor Governing entity of a Trust Network. The top level Trusted Third Party that administers the Trust Network.
TM See Trust Management
Trust Management An approach to making decisions about interacting with something or someone we do not completely know. It formalizes the subjective notion of trust into measurable
trust levels by quantifying and combining sources of trust such as credentials expressing trust
statements by entities, recommendations and feedback on performance, etc.
• Reference: Deliverable TAS3D5.1
Trust Negociation The process whereby two entities negotiate a trusting relationship between themselves, by sharing their credentials that were issued to them by TTPs that both of them trust.
• Comments: CONFLICT: Same acronym as Trust Network suggested by David.
TN See Trust Network
Trust Network An online business environment where parties can interact with each other securely.
While the network does not warrant hones behaviour of the members in the network, it does
ensure that everybody adheres to some basic principles especially in non-repudiation, data
security, communications security, and IT security. Thus a Trust Network promotes trust between
its members.
TAS3 ICT-216287
Page 199 of 211
Trust Network Domain
*** TBD
TO See Trust Operator
Trust Operator
T-PDP See Trust Policy Decision Point
Trust Policy Decision Point A Policy Decision Point specialised in evaluating trust policies. Will
answer authorization request with a granted (trusted) or denied (insufficient trust established)
decision by combining different trust management techniques.
Trust Seal A seal awarded by a proprietary company, usually a certification authority, to business
web sites to display in an attempt to boost consumer confidence in the site. Seals are often
awarded when the web sites purchase SSL certificates from the CA. The seals are usually
trademarked or copyrighted to prevent them from being copied illegally.
TAS3 See Trusted Architecture for Securely Shared Services
Trusted Architecture for Securely Shared Services
EU FP7 Project.
Trusted Entity An entity that can violate a security policy, either by performing actions which it is not
supposed to do, or by failing to perform actions which it is supposed to do.
• Comments: Current definition is of an entity that is apparently trusted because it is not
prevented from doing wrong things, i.e. it is an entity that needs to be trusted for the
system to be secure. In a perfect world this would be the same as actually trusted entities
but of course the world is not perfect. I think using this definition is bound to be confusing.
I suggest using Trusted Entity for entities which are actually trusted. Perhaps use a term
such as entrusted entity for the current definition if this term is needed. David?
TTP See Trusted Third Party
Trusted Third Party An entity that is technically trusted by the infrastructure to assure correctness
of some transaction or relationship. TTP is generally subordinate to Trust Operator, the latter
being responsible for the overall oversight.
• Reference: ITU-T Y.IdMsec, X.800, X.810
TAS3 ICT-216287
Page 200 of 211
Trusted Zone From the viewpoint of a NGN provider a security domain where a NGN provider’s network elements and systems reside and never communicate directly with customer equipment.
The common characteristics of NGN network elements in this domain are that they are under
the full control of the related NGN provider, are located in the NGN provider premises (which
provides physical security), and they communicate only with elements in the "trusted" domain
and with elements in the "trusted-but-vulnerable" domain.
Trustworthiness The amount in which an entity is worthy of being trusted. Is used for both the
subjective notion of trust; i.e. is the entity likely to behave as expected and the formalized
notion, i.e. has a sufficiently high trust level been established for the entity.
User
Human that uses the Trust Network. In Liberty and SAML contexts User is synonymous with
Principal.
User Identifier Identifiers that represent users in their interactions with other parties. Users may
present their identifiers verbally, on paper, on plastic cards, or in any other appropriate manner.
Electronic user identifiers are electronically presented over data communication channels by
user-operated computing devices (client devices) such as PCs, laptops, mobile phones, and
smartcards.
• Reference: Onghome
User Identity A code or string uniquely identifying a user across a multi-user, multi-service infrastructure.
Verification The process of confirming a claimed Identity. For example; any one-to-one precise
matching of an identity’s registered credentials, such as in a logon or any non-AFIS process.
Usually performed in real-time, with a yes/no outcome.
Verification Authentication Information Information used by a verifier to verify an identity claimed
through exchange Authentication Information.
TAS3 ICT-216287
Page 201 of 211
Verifier An entity which is or represents the entity requiring an authenticated identity. A verifier
includes the functions necessary for engaging in authentication exchanges.
Vulnerability A Vulnerability is a flaw in a system’s design or its implementation. It is a weakness
that might be exploited to cause a sytem to malfunction, ultimately resulting in some harm or
loss.
2009
X.500
Series of computer networking standards covering electronic directory access. Similar to
LDAP.
X.509
A joint standard by the ITU-T, ISO and IEC which describes both PKI and PMI. X.509 public
key certificates are ubiquitously used on the web for SSL/TLS communications with web servers.
WS See Web Service
Web Service Web Service is SOAP based machine to machine communication. Sometimes specifically Identity enabled web service, e.g. Liberty ID-WSF based WS.
WSC See Web Service Client
Web Service Client
See Service Requester.
WSDL See Web Service Description Language
Web Service Description Language WSDL is an XML format for describing network services as
a set of endpoints operating on messages containing either document-oriented or procedureoriented information. The operations and messages are described abstractly, and then bound to
a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description
of endpoints and their messages regardless of what message formats or network protocols are
used to communicate.
TAS3 ICT-216287
Page 202 of 211
• Reference: http://www.w3.org/TR/wsdl20/
WSP See Web Service Provider
Web Service Provider
*** TBD
Workflow
*** TBD
TAS3 ICT-216287
Page 203 of 211
Bibliography
[AAPML]
Prateek Mishra, ed.:
"AAPML: Attribute Authority Policy Markup Language", Working Draft 08, Nov. 28, 2006, Liberty Alliance / Oracle.
http://www.oracle.com/technology/tech/standards/idm/igf/pdf/IGF-AAPML-spec-08.pdf
[AcctSvc]
"Liberty ID-WSF Accounting Service Specification"
[AdvClient]
"Liberty ID-WSF Advanced Client Technologies Overview", liberty-idwsf-adv-clientv1.0.pdf
[AeGArch07] "D3.1 Access-eGov Platform Architecture", Access-eGov consortium, Feb 12, 2007.
http://www.accessegov.org/acegov/uploadedFiles/webfiles/cffile_4_3_07_3_25_17_PM.pdf,
also http://www.accessegov.org/acegov/web/uk/index.jsp?id=50268
[AMQP06]
"AMQP: A General-Purpose Middleware Standard" (a.k.a Advanced Message Queueing Protocol), 2006.
[Anderson07] Anne Anderson: "Web Services Profile of XACML (WS-XACML) Version 1.0",
Working Draft 10, OASIS XACML Technical Committee, 10 August 2007, available at http://www.oasis-open.org/committees/download.php/24950/xacml-3.0-profilewebservices-v1-wd-10.zip
[CardSpace] InfoCard protocol (aka CardSpace) from Microsoft
[CARML]
Phil Hunt and Prateek Mishra, eds.: "Liberty IGF Client Attribute Requirements
Markup Language (CARML) Specification", Draft 1.0-12, Liberty Alliance, 2008.
http://www.projectliberty.org/liberty/resource_center/specifications/igf_1_0_specs
[Castano07]
Castano, S., Ferrara, A., Montanelli, S., Hess, G. N., and Bruno, S. (2007). State of the
art on ontology coordination and matching. Report FP6-027538, BOEMIE.
[Chadwick08] David Chadwick: "Functional Components of Grid Service Provider Authorisation Service Middleware", Open Grid Forum, 17 September, 2008. (*** AuthzFunc0.7.doc)
[Chadwick09] David W Chadwick. "FileSpace - An Alternative to CardSpace that supports Multiple Token Authorisation and Portability Between Device". Presented at IDtrust 2009,
the 8th Symposium on Identity and Trust on the Internet, NIST, Gaithersberg, April
2009. Available from http://middleware.internet2.edu/idtrust/2009/papers/08-chadwickfilespace.pdf
[ChadwickEA09] David W Chadwick, Sassa Otenko and Tuan Anh Nguyen. "Adding Support to
XACML for Multi-Domain User to User Dynamic Delegation of Authority". International
Journal of Information Security. Volume 8, Number 2 / April, 2009 pp 137-152. DOI
10.1007/s10207-008-0073-y
[CogWalkthruWeb] http://www.cc.gatech.edu/classes/cs3302/documents/cog.walk.html
[CVS-SAML-WS-Trust] David Chadwick and Linying Su: "Use of WS-TRUST and SAML to access a
Credential Validation Service", Open Grid Forum, 2008. (*** WS-TrustProfile0.8.doc)
TAS3 ICT-216287
Page 204 of 211
BIBLIOGRAPHY
[DesignPat]
"Liberty ID-WSF Design Patterns", liberty-idwsf-dp-v1.0.pdf
[Dieng98]
Dieng, R. and Hug, S. (1998). Comparison of "personal ontologies" represented through
conceptual graphs. In Proceedings of the 13th European Conference on Artificial Intelligence (ECAI 98), pages 341-345, Brighton, UK.
[Disco2]
Cahill, ed.: "Liberty ID-WSF Discovery service 2.0", liberty-idwsf-disco-svc-2.0-erratav1.0.pdf from http://projectliberty.org/resource_center/
[Disco12]
Liberty ID-WSF Discovery service 1.1 (liberty-idwsf-disco-svc-v1.2.pdf)
[DST11]
Liberty DST v1.1
[DST21]
Sampo Kellomäki and Jukka Kainulainen,
eds.:
"Liberty Data
vices Template 2.1", Liberty Alliance, 2007. liberty-idwsf-dst-v2.1.pdf
http://projectliberty.org/resource_center/specifications/
[DST20]
Sampo Kellomäki and Jukka Kainulainen, eds.: "Liberty DST v2.0", Liberty Alliance,
2006.
[FF12]
Liberty ID Federation Framework 1.2, Protocols and Schemas
[FMC03]
Frank Keller, Siegfried Wendt: "FMC: An Approach Towards Architecture-Centric System Development", Hasso Plattner Institute for Software Systems Engineering, 2003.
[FMCWeb]
"Fundamental Modeling Concepts" http://fmc-modeling.org/
Serfrom
[HafnerBreu09] Hafner & Breu: "Security Engineering for Service-Oriented Architectures", Springer,
2009.
[IAF]
Russ
Cutler,
ed.:
"Identity
Assurance
Framework",
Liberty
Alliance,
2007.
File:
liberty-identity-assurance-framework-v1.0.pdf
(from
http://projectliberty.org/liberty/resource_center/papers)
[IDDAP]
Sampo Kellomäki, ed.: "Liberty Identity based Directory Access Protocol", Liberty Alliance, 2007.
[IDFF12]
http://www.projectliberty.org/resources/specifications.php
[IDFF12meta] Peted Davis, Ed., "Liberty Metadata Description and Discovery Specification", version
1.1, Liberty Alliance Project, 2004. (liberty-metadata-v1.1.pdf)
[IDPP]
Sampo Kellomäki, ed.: "Liberty Personal Profile specification", Liberty Alliance, 2003.
[IDWSF08]
Conor Cahill et al.: "Liberty Alliance Web Services Framework: A Technical Overview", Liberty Alliance, 2008. File:
idwsf-intro-v1.0.pdf (from
[IDWSF2Overview] "Liberty ID-WSF Architecture Overview", liberty-idwsf-overview-v2.0.pdf from
http://projectliberty.org/resource_center/specifications
[IDWSF2SCR] "Liberty ID-WSF 2.0 Static Conformance Requirements", liberty-idwsf-2.0-scr-1.0errata-v1.0.pdf
TAS3 ICT-216287
Page 205 of 211
BIBLIOGRAPHY
[IDWSFSecPriv] "Liberty ID-WSF Security & Privacy Overview", liberty-idwsf-security-privacyoverview-v1.0.pdf from http://projectliberty.org/resource_center/specifications/
[IGF]
"An Overview of the Identity Governance Framework",
Liberty Alliance,
2007.
File:
overview-id-governance-framework-v1.0.pdf
(from
[Interact2]
"Liberty ID-WSF Interaction Service", liberty-idwsf-interaction-svc-2.0-errata-v1.0.pdf
from http://projectliberty.org/resource_center/specifications/
[Levenshtein66] Levenshtein, V. I. (1966). Binary codes capable of correcting deletions, insertions and
reversals. Soviet Physics Doklady, 10:707+.
[LibertyInterFed] Carolina Canales Valenzuela, Sampo Kellomäki, eds.: "Access to IdentityEnabled Web Services in Cross-Border, Inter-Federation Scenarios", Liberty Alliance,
2007. File: access-to-identity-enabled-services-in-inter-cot-scenarios-v1.0.pdf (from
[LibertyLegal] Victoria Sheckler, ed.:
"Contractual Framework Outline for Circles of
Trust", Liberty Alliance, 2007. File:
Liberty Legal Frameworks.pdf (from
[LibertyXF]
Sampo Kellomäki, ed.: "Cross Operation of Single Sign-On, Federation, and Identity
Web Services Frameworks", Liberty Alliance, 2006.
[Madsen03]
Paul Madsen: "WS-Trust: Interoperable Security for Web Services" Available from
http://www.xml.com/pub/a/ws/2003/06/24/ws-trust.html
[Mbanaso09] U.M.Mbanaso, G.S. Cooper, David Chadwick , Anne Anderson: "Obligations of Trust for
Privacy and Confidentiality in Distributed Transactions", Internet Research. Vol 19 No 2,
2009, pp. 153-173.
[Meier08]
J.D. Meier:
"Threats,
Attacks,
Vulnerabilities,
and Countermeasures",
30.3.2008.
http://shapingsoftware.com/2008/03/30/threats-attacks-vulnerabilitiesand-countermeasures/
[Meier09]
J.D. Meier: "Security Hot Spots", 9.3.2009. http://shapingsoftware.com/2009/03/09/securityhot-spots/
[MS-MWBF]
Microsoft Web Browser Federated Sign-On Protocol Specification, 20080207,
http://msdn2.microsoft.com/en-us/library/cc236471.aspx
[Nagios]
"System, Network, and Application Monitor", the latest incarnation of the Satan and Net
Saint saga, http://www.nagios.org/
[NexofRA09] "Deliverable D6.2 RA Model V2.0", All NEXOF-RA Partners, NESSI Strategic Project
and External Contributors, 2009.
[NIST-SP800-30] Gary Stoneburner, Alice Goguen, and Alexis Feringa: "Risk Management Guide
for Information Technology Systems", Recommendations of the National Institute of
Standards and Technology, NIST, 2002. http://csrc.nist.gov/publications/nistpubs/80030/sp800-30.pdf
TAS3 ICT-216287
Page 206 of 211
BIBLIOGRAPHY
[NIST-SP800-42] John Wack, Miles Tracy and Murugiah Souppaya: "Guideline Network Security",
Recommendations of the National Institute of Standards and Technology, NIST, 2002.
http://csrc.nist.gov/publications/nistpubs/800-30-42/sp800-42.pdf
[OAUTH]
http://oauth.net/
[OpenID]
http://openid.net/
[OWL-S-Web] David Martin, ed.: "OWL-S: Semantic Markup for Web Services", W3C, 22. Nov, 2004.
http://www.w3.org/Submission/OWL-S/
[PCI08]
"Payment Card Industry Data Security Standard",
Version 1.2,
2008, PCI Security Standards Council. Document pci_dss_v1-2.pdf
https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
[Peeters09]
Roel Peeters, Koen Simoens, Danny De Cock, and Bart Preneel: "Cross-Context Delegation through Identity Federation", KUL 2009 (To be published?)
[PeopleSvc]
"Liberty ID-WSF People Service Specification", liberty-idwsf-people-service-1.0-erratav1.0.pdf from http://projectliberty.org/resource_center/specifications/
[PERMIS]
D.W.Chadwick and A. Otenko: "The PERMIS X.509 Role Based Privilege Management
Infrastructure". Future Generation Computer Systems, Vol 19, Issue 2, Feb 2003. pp
277-289
[RFC1157]
J. Case et al.: " A Simple Network Management Protocol (SNMP)", RFC 1157, 1990.
[RFC1950]
P. Deutcsh, J-L. Gailly: "ZLIB Compressed Data Format Specification version 3.3", Aladdin Enterprises, Info-ZIP, May 1996
[RFC1951]
P. Deutcsh: "DEFLATE Compressed Data Format Specification version 1.3", Aladdin
Enterprises, May 1996
[RFC1952]
P. Deutcsh: "GZIP file format specification version 4.3", Aladdin Enterprises, May 1996
[RFC2119]
S. Bradner, ed.: "Key words for use in RFCs to Indicate Requirement Levels", Harvard
University, 1997.
[RFC2138]
C. Rigney et al.: "Remote Authentication Dial In User Service (RADIUS)", RFC 2138,
April 1997.
[RFC2139]
C. Rigney: "RADIUS Accounting", RFC 2139, April 1997.
[RFC2246]
T. Dierks and C. Allen: "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2251]
M. Wahl, T. Howes, S. Kille: "Lightweight Directory Access Protocol (v3)", RFC 2251,
December 1997.
[RFC2256]
Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256,
December 1997.
[RFC2798]
M. Smith: "Definition of the inetOrgPerson LDAP Object Class", Netscape Communications, RFC 2798, April 2000.
TAS3 ICT-216287
Oct
from
Page 207 of 211
BIBLIOGRAPHY
[RFC3548]
S. Josefsson, ed.: "The Base16, Base32, and Base64 Data Encodings", July 2003.
(Section 4 describes Safebase64)
[RFC3588]
P. Calhoun et al.: "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3768]
R. Hinden, ed.: "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, April 2004.
[SAML11core] SAML 1.1 Core, OASIS, 2003
[SAML11bind] "Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML)
V1.1", Oasis Standard, 2.9.2003, oasis-sstc-saml-bindings-1.1
[SAML2core] "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML)
V2.0", Oasis Standard, 15.3.2005, saml-core-2.0-os
[SAML2prof] "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0", Oasis Standard, 15.3.2005, saml-profiles-2.0-os
[SAML2profErrata] OASIS. "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0
- Errata Composite Working Draft", 12 February 2006
[SAML2bind] "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0", Oasis
Standard, 15.3.2005, saml-bindings-2.0-os
[SAML2context] "Authentication Context for the OASIS Security Assertion Markup Language (SAML)
V2.0", Oasis Standard, 15.3.2005, saml-authn-context-2.0-os
[SAML2meta] Cantor, Moreh, Phipott, Maler, eds., "Metadata for the OASIS Security Assertion
Markup Language (SAML) V2.0", Oasis Standard, 15.3.2005, saml-metadata-2.0-os
[SAML2security] "Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0", Oasis Standard, 15.3.2005, saml-sec-consider-2.0-os
[SAML2conf] "Conformance Requirements for the OASIS Security Assertion Markup Language
(SAML) V2.0", Oasis Standard, 15.3.2005, saml-conformance-2.0-os
[SAML2glossary] "Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0", Oasis
Standard, 15.3.2005, saml-glossary-2.0-os
[SAML2SimpleSign] "SAML 2.0 POST Simple Sign Binding", OASIS, 2008.
[Schema1-2] Henry S. Thompson et al. (eds): XML Schema Part 1: Structures, 2nd Ed., WSC Recommendation, 28. Oct. 2004, http://www.w3.org/2002/XMLSchema
[SecMech2]
"Liberty ID-WSF 2.0 Security Mechanisms", liberty-idwsf-security-mechanisms-core2.0-errata-v1.0.pdf from http://projectliberty.org/resource_center/specifications
[Shibboleth]
http://shibboleth.internet2.edu/shibboleth-documents.html
[SOAPAuthn2] "Liberty ID-WSF Authentication,
Single Sign-On,
and Identity
ping Services Specification",
liberty-idwsf-authn-svc-2.0-errata-v1.0.pdf
http://projectliberty.org/resource_center/specifications/
TAS3 ICT-216287
Mapfrom
Page 208 of 211
BIBLIOGRAPHY
[SOAPBinding2] "Liberty ID-WSF SOAP Binding Specification", liberty-idwsf-soap-binding-2.0-erratav1.0.pdf from http://projectliberty.org/resource_center/specifications
[SOX02]
"Sarbanes-Oxley
Act
of
2002",
Public
Law
107-204,
United
States,
2002.
http://frwebgate.access.gpo.gov/cgibin/getdoc.cgi?dbname=107_cong_public_laws&docid=f:publ204.107
[SUBS2]
"Liberty ID-WSF Subscriptions and Notifications Specification", liberty-idwsf-subsv1.0.pdf from http://projectliberty.org/resource_center/specifications/
[SWIG]
Simplified Interface and Wrapper Generator by Dave Beazley. www.swig.org
[TAS3ARCH] Sampo Kellomäki, ed.: "TAS3 Architecture", TAS3 Consortium, 2009. Document: tas3arch-vXX.pdf
[TAS3BIZ]
Luk Vervenne, ed.: "TAS3 Business Model", TAS3 Consortium, 2009.
[TAS3COMPLIANCE] Sampo Kellomäki, ed.: "TAS3 Compliance Requirements", TAS3 Consortium,
2009. Document: tas3-compliance-vXX.pdf
[TAS3CONSOAGMT] "TAS3 Consortium Agreement", TAS3 Consortium, 2008. (Not publicly available.)
[TAS3D12DESIGNRAR] David Chadwick (Kent), Seda Gürses (KUL), eds.:
ments Assesment Report",
TAS3 Consortium,
20090102.
TAS3_D1p2_Requirements_Assesment_Report_1_V1p0.pdf
"RequireDocument:
[TAS3D14DESIGNREQ] Gilles Montagnon (SAP), ed.: "Design Requirements", TAS3 Consortium,
20081221. Document: TAS3_D1p4_Design_Requirements_1_V2p0.pdf
[TAS3D22UPONTO] Quentin Reul (VUB), ed.: "Common Upper Ontologies", TAS3 Consortium, Deliverable D2.2, 7.5.2009. Document: D2.2_ver1.7.pdf
[TAS3D41ID] Sampo Kellomäki, ed.: "Identifier and Discovery Function", TAS3 Deliverable 4.1, 2009.
Document: tas3-disco-v01.pdf
[TAS3D42Repo] David Chadwick, ed.: "Specification of information containers and authentic repositories", TAS3 Deliverable 4.2, 2009.
[TAS3D71IdMAnAz] TAS3 Deliverable 7.1. "Design of Identity Management, Authentication and Authorization Infrastructure" 3 Jan 2009.
[TAS3D81RepoSW] "Software Documentation System: Repository Services", UniKOLD, TAS3 Deliverable 8.1, 2009.
[TAS3D82BackOffice] "Back Office Services with Documentation", TAS3 Consortium, 2009.
[TAS3D83CliSW] "TAS3 Client Software with User Guide", TAS3 Consortium, 2009.
[TAS3D91PilotUC] "Pilot Use Cases", Deliverable D9.1, TAS3 Consortium, 2009.
[TAS3DOW]
"TAS3 Description of Work", TAS3 Consortium, 2008. (Not publicly available.) File:
TAS3_DescriptionOfWork.DoW.technical.annex.final.version.20071030.pdf
TAS3 ICT-216287
Page 209 of 211
BIBLIOGRAPHY
[TAS3GLOS] Quentin Reul (VUB), ed.: "TAS3 Glossary", TAS3 Consortium, 2009. Document: tas3glossary-vXX.pdf
[TAS3PROTO] Sampo Kellomäki, ed.: "TAS3 Protocols and Concrete Architecture", TAS3 Consortium, 2009. Document: tas3-proto-vXX.pdf
[TAS3THREAT] Sampo Kellomäki, ed.: "TAS3 Threat Analysis", TAS3 Consortium, 2009. Document:
tas3-threats-vXX.pdf
[TAS3WP]
"TAS3 Architecture White Paper", TAS3 Consortium, 2009 (as of 20090324 to be published).
[TrustBuilder2] Adam J. Lee, Marianne Winslett and Kenneth J. Perano: "TrustBuilder2: A Reconfigurable Framework for Trust Negotiation", IFIP Trust Management Conference, June
2009.
[UML2]
http://www.sparxsystems.com.au/resources/uml2_tutorial/
[UNDP07]
"e-Government Interoperability Guide", United Nations Development Programme, 2007.
http://www.apdip.net/projects/gif/GIF-Guide.pdf
[VenturiEA08] V. Venturi, et al.: "Use of SAML to retrieve Authorization Credentials", Open Grid Forum,
2008. (*** Attribute PullProfilev1.5.doc; CVS related)
[Wharton94] C. Wharton et al. "The cognitive walkthrough method: a practitioner’s guide" in J.
Nielsen & R. Mack "Usability Inspection Methods" pp. 105-140, Wiley, 1994.
[WSML-Web] "Web Services Modelling Language" http://www.wsmo.org/wsml/
[WSMO05]
D. Roman, U. Keller, H. Lausen, J. de Bruijn, R. Lara, M. Stollberg, A. Polleres, C.
Feier, C. Bussler, and D. Fensel (2005). "Web Service Modeling Ontology". In Applied
Ontology 1, pages 77-106.
[WSMO-Web] "Web Services Modelling Ontology" http://www.wsmo.org/
[WSTrust]
"WS-Trust 1.3", CD 6, OASIS, Sept 2006. (*** WS-Trust, STS, etc.)
[X520]
ITU-T Rec. X.520, "The Directory: Selected Attribute Types", 1996.
[X521]
ITU-T Rec. X.521, "The Directory: Selected Object Classes", 1996.
[XACML2]
"eXtensible
Access
Control
Markup
Language
OASIS
Standard,
February
2005.
From
open.org/committees/tc_home.php?wg_abbrev=xacml
(XACML)"
v2.0,
http://www.oasis-
[XACML2SAML] "SAML 2.0 Profile of XACML, Version 2, Working Draft 5", 19 July 2007, OASIS. (***
instead of "SAML 2.0 profile of XACML v2.0, ERRATA, Working Draft 01, 17 November
2005" which is the version that the profile is currently based on; XACMLContextProfile1.1.doc from Open Grid Forum - OGF)
[XML]
http://www.w3.org/TR/REC-xml
TAS3 ICT-216287
Page 210 of 211
BIBLIOGRAPHY
[XML-C14N] XML Canonicalization (non-exclusive), http://www.w3.org/TR/2001/REC-xml-c14n20010315; J. Boyer: "Canonical XML Version 1.0", W3C Recommendation, 15.3.2001,
http://www.w3.org/TR/xml-c14n, RFC3076
[XML-EXC-C14N] Exclusive XML Canonicalization, http://www.w3.org/TR/xml-exc-c14n/
[XMLDSIG]
"XML-Signature Syntax and Processing", W3C Recommendation,
http://www.w3.org/TR/xmldsig-core, RFC3275
12.2.2002,
[XMLENC]
"XML Encryption Syntax and Processing", W3C Recommendation, 10.12.2002,
http://www.w3.org/TR/xmlenc-core
[XPATH99]
James Clark and Steve DeRose, eds. "XML Path Language (XPath) Version 1.0", W3C
Recommendation 16 November 1999. From: http://www.w3.org/TR/xpath
[ZXIDREADME] Sampo Kellomäki: "README.zxid" file from zxid.org, 2009.
Document ID tas3-deliv-2_1-arch-v15.pdf
URL path https://portal.tas3.eu/arch/review/tas3-deliv-2_1-arch-v15.pdf
TAS3 ICT-216287
Page 211 of 211

Document type Report Title D2.1- TAS Architecture Work Package

Transcription

Similar documents

Presentation

Trans-tasman regulatory findings

maryland division of financial regulation

Blank IDP Outline

chalr p A Talbot - Mid Devon District Council

The 2001 Raoul Wallenberg Lecture - Taubman College

tgs ip phone - TGS Enterprise Networks

Untitled - Caja Rural Granada

Medical Check-up dates for

2016 Audit Engagement Letter – Erdahl Redpath