the do change end2end trust assurance framework … · the do change end2end trust assurance...

Project # 643735 www.do-change.eu

Throughout this template, all text in italic blue font (like this paragraph itself) is just help text and must be removed. Do not change anything in the header of this page before this text! Then, try to keep the number of empty lines here (before the title) equal to the empty lines after deliverable number (before the table at the bottom) in a way that the whole table at the bottom remains on this page centred at the bottom of the page. If necessary, you can enlarge the width of that table.

The Do Change end2end Trust Assurance Framework

[Deliverable 4.2.1, Revision 1.0]

Key Information from the DoA

Due Date 10-Feb-2016

Type Report

Security Confidential

Description:

WP4 end2end trust assurance – UMA – Governance management

Lead Editor: Sampo Kallomäki (SYN) Internal Reviewer: Mart Wetzels (TUE), Stephen Hope (DOC)

DX.X - Name of Deliverable of 56

Versioning and contribution history Version Date Author Partner Description

0.1 1-feb-2016 Sampo Kellomaki Luk Vervenne

SYN 1ST VERSION

0.2 8-feb-2016 Maciej Machulak SYN COMPLETION

0.3 9-feb-2016 Mart Wetzels TUE CORRECTION

0.4 9-feb-2016 Steve Hope Docobo CORRECTION

0.4 10-feb-2016 Luk Vervenne SYN FINALISED

Statement of originality: This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both.

Disclaimer: This document has not been reviewed or approved by European Commission.

Statement of Originality: This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both.

Legal Notice: All information included in this document is subject to change without notice. The Members of the Do CHANGE 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 Do CHANGE 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.


Table of Contents

The Do Change end2end Trust Assurance Framework ................................................................... 1

1. Part 1: End2end trust assurance ................................................................................ 5

1.1. Introduction ........................................................................................................ 5

1.2. Components of E2ETA Framework ....................................................................... 6

1.2.1. Identity Provider (IdP) 7

1.2.2. Discovery Service (DI) 7

1.2.3. New User Provisioning Service 7

1.2.4. Delegation Service (DS) 8

1.2.5. UMA Authorization Server (AS) 8

1.2.6. Personal Trust Manager iframe (PTM-iframe) 8

1.2.7. Personal Trust Manager Server (PTM) 8

1.2.8. Audit Bus (AB) 8

1.2.9. E2ETA Single Sign-On Connector (Conn-SSO) 8

1.2.10. E2ETA Web Service Client Connector (Conn-WSC) 8

1.2.11. E2ETA Web Service Provider Connector (Conn-WSP) 9

1.2.12. E2ETA Sensor Hub 9

1.2.13. Online Compliance Testing Robot (OCT) 9

1.2.14. New Partner Intake Self Service 9

1.2.15. New Service Registration Self Service 9

1.2.16. Policy Decision Point (PDP) 9

1.3. Implementation of E2ETA Framework ................................................................ 10

1.3.1. Identity Provider (IdP) 11

1.3.2. Discovery Service (DI) 11

1.3.3. New User Provisioning Service 11

1.3.4. Delegation Service (DS) 11

1.3.5. UMA Authorization Service (AS) 11

1.3.6. Personal Trust Manager iframe (PTM-iframe) 11

1.3.7. Personal Trust Manager Server (PTM) 11

1.3.8. Audit Bus (AB) 12

1.3.9. E2ETA Single Sign-On Connector (Conn-SSO) 12

1.3.10. E2ETA Web Service Client Connector (Conn-WSC) 12

1.3.11. E2ETA Web Service Provider Connector (Conn-WSP) 12

1.3.12. E2ETA Sensor Hub 12

1.3.13. Online Compliance Testing Robot (OCT) 12

1.3.14. New Partner Intake Self Service 12

1.3.15. New Service Registration Self Service 12

1.3.16. Policy Decision Point (PDP) 13

1.4. Conclusion: E2ETA scaffolding is in place ............................................................ 13

2. Part 2: Used Management Acces Protocol & Implementation .................................. 15


2.1. Overview of User-Managed Access (UMA) ............................................. 15

2.1.1. Architecture 16

2.1.2. Protocol 18

2.2. Synergetics and User-Managed Access ............................................................... 22

2.3. NuveAM – UMA Authorisation Server ................................................................ 23

2.3.1. NuveAM Characteristics 23

2.3.2. NuveAM Features 24

2.3.3. NuveAM User Interface Interface Examples 24

2.3.4. Policy visualisations 30

2.4. References ........................................................................................................ 32

3. Part 3: End2End Trust Assurance Network Business, Governance & Trust Model ...... 33

3.1. E2ETAN Business Model ..................................................................................... 34

3.1.1. What should constitute a Trust Network? 35

3.2. How many of trust networks should be out there? ............................................. 40

3.3. Should Trust networks interact with each other? ................................................ 41

3.4. Who should run them? ...................................................................................... 41

3.5. How should the governance be organized? ......................................................... 42

3.6. How are Trust Networks financed? ..................................................................... 43

3.7. What form of Trust Guarantor is most suited to operate and manage the Trust Network Infrastructure Services, a centralized or shared trust model? ................ 45

3.8. 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? .......................................................................................... 47

3.8.1. Kinds of Service Providers 47

3.8.2. Kinds of Trust Entities 47

3.8.3. Principles that Trust Network Should Adopt 50

3.8.4. Question a Trust Network Member Has to Answer 50

3.8.5. Privacy Architecture Elements 50

3.9. Governance Framework for an Ecosystem .......................................................... 51

3.9.1. Founding and Governance Agreements and the Charter 52

3.9.2. Association Agreement 53

3.9.3. End User Terms and Conditions, Privacy Policies, Codes of Conduct, etc. 53

3.9.4. Technical and Compliance Rules 54

3.9.5. Agreements 54

3.9.6. Proposed Application: Healthcare Ecosystem (ReLifE / Eindhoven) 55

3.10. Further reading .................................................................................................. 56


1. Part 1: End2end trust assurance

1.1. Introduction

The End to End Trust Assurance Framework (E2ETA) is infrastructure that permits the partners in Do CHANGE to collaborate and communicate with each other in secure and trustworthy way such that privacy and appropriate handling of end user data is ensured, and that end users have appropriate control and transparency to the functioning of the system.

Secure and trustworthy infrastructure is essential to enable ecosystem partners to trust each other, i.e. if there is contract or agreement, it will indeed be respected, and that with appropriate technical solutions are in place to authenticate and identify the transacting parties and end users as well as to create non-repudiable audit trail of the said transactions. These mechanisms will not be credible unless the overall security is credibly handled as well.

The privacy protection, transparency, and appropriate control of end users require a set of technologies such as full pairwise pseudonymisation of user identifiers, encryption in transit and at rest, user viewable audit trail, access control mechanisms, and sticky policies.

Furthermore, users need to be educated to understand how they are protected and how they can control the protection level themselves. The education aspect demands that user experience with regards to transparency and control should be as uniform as possible. It follows that these aspects should have a common implementation rather than ad-hoc implementations at several different parties.

Since the technical solutions required are always necessary, yet nontrivial to implement, it makes sense that they are uniformly handled for all partners of the ecosystem. Hence Do CHANGE adopts End to End Trust Assurance Framework (E2ETA), which is a productized, well debugged, implementation of the fundamental architecture and technical requirements.

The E2ETA is based on FP7 IP TAS3.eu Architecture [TAS3ARCH], which is itself based on Liberty Alliance Identity Web Services Framework [IDWSF08], OASIS SAML2 [SAML2core], and more recent Kantara Initiative User Managed Access [UMA1], OpenID-Connect [OIDC1], and OAUTH2 [OAUTH2] specifications.

UMA, being an important part of the e2eTA proposal, is discussed separately in this document (see part 2). We also provide an overview of the UMA Authorisation Server that implements the UMA protocol.

TAS3 Architecture was developed as European Commission FP7 project in 2008-2012. The e2eta framework uses Synergetics NV e2eta product suite that implements the TAS3 Architecture. Synergetics product is based on the reference implementation of TAS3 developed during that project and has since been used in numerous production deployments.


Figure 1.1: Do CHANGE interconnect pattern

1.2. Components of E2ETA Framework


Figure 2.1: Do CHANGE E2ETA Architecture.

From the architecture, we can discern following components that are relevant for the framework (other components are relevant for the business function and are outside the framework proper).

1.2.1. Identity Provider (IdP)

Its primary responsibility is authenticating end users

IT capable end users are expected to introduce their login credentials

When the end-user is incapable of using IT or authenticating, the IdP authenticates the delegate, while Delegation Service attests the Delegator-Delegate relationship.

Key actor in Single Sign-On and front channel (orange) actions

Also very active in pairwise pseudonym management

Uses data created using new user provisioning (self-service and batch)

Password reset functionality

IdP proxying to use 3rd party IdPs (e.g. Facebook or Google+)

Provided on SaaS (Software as a Service) basis

1.2.2. Discovery Service (DI)

Discovery Service implements the architectural promise to end users that they get to choose their Service Providers in a competitive market, i.e. user gets to choose which provider provides the Personal Data Store service, for example.

Key actor in web service calls and back channel (green) actions

Discovery Service has an intimate relationship with the IdP in pairwise pseudonym management.

The services that the Discovery Service deals in are provisioned by the New Service Registration, below.

1.2.3. New User Provisioning Service

Used to create the users that the IdP authenticates

Several different provisioning flows are possible

Self-service

Self-service followed by official validation

Assisted

Assisted and validated

Batch

In case of IT inexperienced users, the delegation relationship is created at the time of provisioning


1.2.4. Delegation Service (DS)

Can be used to interrogate Delegator-Delegate relationships for purposes of access control

Issuance of identity tokens that express the Delegator-Delegate relationships

Ability to register and delete relationships

1.2.5. UMA Authorization Server (AS)

Handles the Authorization Server role of the UMA protocol

Allows users to control who accesses their data

1.2.6. Personal Trust Manager iframe (PTM-iframe)

Easily accessible mini GUI whose purpose is to increase user’s awareness of how his data is handled

Consent questions

1.2.7. Personal Trust Manager Server (PTM)

Full audit trail viewing GUI

Full policy editing GUI

N.B. The related Personal Data Store (PDS) is not, strictly speaking, part of the E2ETA framework and is not discussed here. We consider PDS to be part of the business function.

1.2.8. Audit Bus (AB)

A facility for collecting and conveying audit trail messages

Non-repudiation service

Monitoring and fraud detection

1.2.9. E2ETA Single Sign-On Connector (Conn-SSO)

The circular red dot in the architecture diagram

Policy Enforcement Point (PEP), handling access control

Handles also audit trail publishing related to Single Sign-On

1.2.10. E2ETA Web Service Client Connector (Conn-WSC)

The red triangle in the architecture diagram

Allows application layer to pass payload and initiate a web service call

Discovers, using DI, where a given service is provided for the user

Obtains the identity tokens representing the pseudonymous identities involved in the call

Packages the payload in a web services envelope and makes the web service call

Handles crypto and digital signatures


Handles also audit trail publishing related to making web service calls


1.2.11. E2ETA Web Service Provider Connector (Conn-WSP)

The red square in the architecture diagram

Receives web service calls and hands the payload to application layer

Verifies pseudonymous identity tokens

Handles crypto and digital signatures


Handles also audit trail publishing related to accepting web service calls

1.2.12. E2ETA Sensor Hub

Supports connection to ecosystem for sensors that can not integrate directly using Conn-WSC

Sensor talks to the hub and the hub talks to the Personal Data Store

In effect the hub contains Conn-WSC and sensor technology dependent application layer

1.2.13. Online Compliance Testing Robot (OCT)

Monitoring and fraud detection

Ongoing process

Both positive and negative testing

1.2.14. New Partner Intake Self Service

Service for creating new partners in the ecosystem

New partner self-provisioning is mainly about potential new partners creating their applications.

New partner legal track is a separate process which will at some point result in approval of new partner

Once approved, the partner can manage his ecosystem partnership parameters through this interface

A batch interface of new partner intake is also planned. The batch interface will be used when there is an external party that will vet a significant number of new partners.

1.2.15. New Service Registration Self Service

Allows registration of a new service by an existing partner (see New Partner Intake, above)

Interacts with the Discovery Service to effectuate the registrations.

While self-service or "app store" may be the principal mode of action, a batch interface is planned as well.

1.2.16. Policy Decision Point (PDP)

A server that evaluates context of an event such as web service call against a set of policies to

produce an authorization decision

The decision making is driven by static policies developed at system level and user-set policies

created during user flows and using PTM

In essence, the policy decision making has been externalized from the applications, which are the Policy Enforcement Points (PEP) to a dedicated server, the PDP.

Typical decision-making criteria include:


o User’s identity Is data about the user? Was data created by the user?

o Delegator’s identity and nature of the delegation relationship (if any) o Roles of user and delegator (if any) o Purpose of data access o Nature of access (read, write) o Application that is accessing the data o The organization responsible for the application o Professional or business context in which the data access is made.

1.3. Implementation of E2ETA Framework

The E2ETA framework is implemented as a combination of infrastructure services, hosted by the ecosystem itself, and software modules deployed by the ecosystem partners. The services hosted by ecosystem are more practically, for the time being, hosted by Synergetics, on Software as a Service (SaaS) basis. Every SaaS service software is available also as software license should the need to run it outside the cloud occur.

The SaaS services are hosted at IaaS providers that satisfy European data protection regulations, or more specifically:

a. Are located in EEA (EU + Iceland, Norway, & Switzerland)

Current situation (2015 and 2016) is that the SaaS services are hosted from DE and NL by companies wholly owned by European investors

b. Are not controlled or dominated through ownership, board membership, or by volume of business by foreign interests.

For comparison, Amazon AWS, despite having datacenters in Europe, is subject to US Patriot Act and can be compelled to disclose information even from its European datacentres (the "Safe Harbour" provision has been ruled ineffective by US and EU Courts) to US authorities and such disclosure may not be very well protected due to incompetence and lax security culture of the US authorities.

c. Do not have agreements to collude with foreign agencies. Collusion with domestic agencies needs to stay within legally required minimum.

Other components need to be deployed at ecosystem partner services or web sites. These include E2ETA single sign-on, web services client, and web services provider capabilities (the "connectors").

When deploying services, the ecosystem partners should take note of the (a) and (b) above. The connectors come in several varieties depending on the deployment scenario. By far the best supported deployment scenario is using Apache httpd, in which case Apache module called mod_relife provides a comprehensive solution. The Web Service Client functionality is provided by libe2eta.so library, which is available with several programming language interfaces, including C, C++, Java, CSharp, php, perl, ruby, and python (the languages available upon request). In addition to the variation by programming language, the connectors support several hardware and Operating System (OS) platforms, including Linux (Debian, Ubuntu, etc. or Redhat, Fedora, CentOS, etc. - if yours is not mentioned, just ask us), Sun OS (Solaris, various versions), FreeBSD (and other *BSD family OS), as well as Windows 2000 Server.


Of the mobile platforms Android is primarily supported. Apple platforms can be supported, but are upon request due to limited demand and expense of testing. Other platforms available upon request: our software is highly portable.

1.3.1. Identity Provider (IdP)

Solution SaaS IdP supplied by Synergetics Current status deployed and available for production use Contact URL (Metadata) https://ssoid.com/idp

1.3.2. Discovery Service (DI)

Solution SaaS supplied by Synergetics Current status deployed and available for production use| Contact URL (Metadata) https://ssoid.com/idp

1.3.3. New User Provisioning Service

Solution SaaS supplied by Synergetics Current status deployed and available for testing Contact URL https://ssoid.com/idpnewuser

1.3.4. Delegation Service (DS)

Solution SaaS supplied by Synergetics Current status deployed and available for testing Contact URL (Metadata) https://ssoid.com/idp

1.3.5. UMA Authorization Service (AS)

Solution SaaS supplied by Synergetics Current status deployed and available for testing Contact URL TBD ***

1.3.6. Personal Trust Manager iframe (PTM-iframe)

Solution Software module supplied by Synergetics Current status deployed and available for testing Download URL https://synersec.eu/15d0c6/

1.3.7. Personal Trust Manager Server (PTM)

Solution SaaS supplied by Synergetics Current status deployed and available for testing Contact URL (Metadata) TBD ***

N.B. The related Personal Data Store (PDS) is not strictly speaking part of the E2ETA framework and is not discussed here.


1.3.8. Audit Bus (AB)


1.3.9. E2ETA Single Sign-On Connector (Conn-SSO)

Solution Software module supplied by Synergetics Current status available for production use Download URL https://synersec.eu/15d0c6/

1.3.10. E2ETA Web Service Client Connector (Conn-WSC)


1.3.11. E2ETA Web Service Provider Connector (Conn-WSP)


1.3.12. E2ETA Sensor Hub

The Sensor Hub is essentially a Web Service Client that uses the Conn-WSC component to talk to Personal Data Store (PDS). Solution Software module supplied by Synergetics Current status available for production use Download URL https://synersec.eu/15d0c6/

1.3.13. Online Compliance Testing Robot (OCT)


1.3.14. New Partner Intake Self Service


1.3.15. New Service Registration Self Service



1.3.16. Policy Decision Point (PDP)


1.4. Conclusion: E2ETA scaffolding is in place

While not all E2ETA framework modules have been deployed yet, the maturity of the framework matches the maturity of the Do CHANGE project as whole and allows meaningful testing with other project partners. The deployment of E2ETA framework ensures that:

A. Single Sign-On is handled in secure and privacy friendly way, benefitting from stable standards (SAML2 has been stable and in production use since 2005) and stable implementation. SYN implementation has been in use since 2005 and participated in interoperability testing events.

B. Web Service calls are handled in secure and privacy friendly way, based on stable protocol specifications (ID-WSF has been stable since 2008) and SYN implementation has supported them since 2009.

C. Access control is handled in a systematic way through out the ecosystem, based on stable protocols such as XACML.

D. Audit is handled thoroughly and systematically at all layers E. Parts play together in meaningful way, as described in TAS3 architecture (stable since 2011).

By using existing SYN software solutions, the connectors, most Do CHANGE ecosystem partners merely need to deploy software rather than develop these necessary advanced functions themselves, thus saving time and money and resulting in more bug free and stable system.

Of course the E2ETA framework does not solve all problems. First, it must be deployed in proper legal and contractual environment. The audit trail can show if a contract breach has happened, but it is no use if there is no enforceable contract or no meaningful avenue of redress. Second, the framework does run on servers in mostly public internet. It is paramount that physical security, network security, and secure system administration practices are deployed as well.

The E2ETA framework encourages a model where service providers need to be accepted to join the ecosystem (technically the acceptance criteria could be set so low that everybody could join automatically, but we do not encourage that). Thus there is an expectation that the partners are vetted for honesty and suitability to join the ecosystem. Similarly, the personnel working for the partners, as well as the framework infrastructure supplier (SYN and its data centre partners in this case), must be vetted, if they are to come in position where they could access personal data.

Bibliography

[TAS3ARCH] Sampo Kellomäki (EIfEL), ed.: "TAS3 Architecture", TAS3 Consortium, 2009. Docu-

ment: tas3-arch-vXX.pdf

[IDWSF08] Conor Cahill et al.: "Liberty Alliance Web Services Framework:

A Technical Overview", Liberty Alliance, 2008. File: idwsf-intro-v1.0.pdf (from http://projectliberty.org/liberty/resource_center/papers)

[SAML2core] "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML)

V2.0", Oasis Standard, 15.3.2005, saml-core-2.0-os


[UMA1] UMA 1.0 spec, Kantara Initiative

[OIDC1] OpenID-Connect spec, OpenID Foundation

[OAUTH2] OAUTH2 spec, IETF


2. Part 2: Used Management Acces Protocol & Implementation

Abstract

In this part of the document, we briefly introduce the User-Managed Access (UMA) approach for access control to online data. UMA is an access management solution that consists of an architecture and a new access control delegation protocol. UMA provides a method for users to control third-party application access to their protected resources, residing on any number of host sites, through a centralised authorisation server that makes access decisions based on user instructions.

The UMA proposal consists of a dedicated service for authorising data sharing and service access. The user is capable of imposing demands on any Web application that wishes to access a user's data. Moreover, the user is able to monitor, change, and stop access relationships between online services from one location. With a specialised component being in charge of relationships, the user does not have to manually provision copies of data to requesting services, nor define access control policies at multiple host applications. Instead, the user may point requesters to authoritative sources from which they can request such data directly in a secure and efficient way. The user can also apply policies across multiple hosts and resources using a single and central application.

We also provide overview of the Synergetics implementation of UMA called NuveAM. NuveAM provides a solution to access control and audit for distributed data and Web APIs. With NuveAM, organisations and individuals can manage their security policies centrally with an intuitive dashboard. NuveAM also provides advanced real-time analytics and monitoring to support compliance.

2.1. Overview of User-Managed Access (UMA)

In this section, we briefly introduce the User-Managed Access (UMA) approach for access control to online data. Our introduction covers only specific aspects of the UMA protocol and should not be considered as a full explanation of the UMA proposal. We refer the reader to the official UMA protocol


specification and other sources for a complete information of UMA, including information on the UMA architecture as well as the UMA protocol itself. UMA is an access management solution that consists of an architecture and a new access control delegation protocol. UMA provides a method for users to control third-party application access to their protected resources, residing on any number of host sites, through a centralised authorisation server that makes access decisions based on user instructions. The UMA proposal consists of a dedicated service for authorising data sharing and service access. The user is capable of imposing demands on any Web application that wishes to access a user's data. Moreover, the user is able to monitor, change, and stop access relationships between online services from one location. With a specialised component being in charge of relationships, the user does not have to manually provision copies of data to requesting services, nor define access control policies at multiple host applications. Instead, the user may point requesters to authoritative sources from which they can request such data directly in a secure and efficient way. The user can also apply policies across multiple hosts and resources using a single and central application. UMA has been researched by the User-Managed Access Work Group (UMA WG) at Kantara Initiative, which includes researchers and professionals from industry and academia. Kantara Initiative has published the following recommendations with regards to UMA:

1. User-Managed Access (UMA) Profile of OAuth 2.0 Version 1.0 – published 4 Apr 2015 2. OAuth 2.0 Resource Set Registration Version 1.0 – published 4 Apr 2015 3. User-Managed Access (UMA) Profile of OAuth 2.0 Version 1.0.1 – published 28 Dec 2015 4. OAuth 2.0 Resource Set Registration Version 1.0.1 – published 28 Dec 2015

Our overview of UMA in this section refers to version 1.0 of the UMA proposal. This is due to the fact that the very recent version, i.e. 1.0.1 has just been published. Importantly, differences between these two versions of the UMA proposal relate mainly to the protocol itself and do not affect the entire proposal. Therefore, our overview of UMA can be considered sufficient for understanding this new user-centric access management concept.

2.1.1. Architecture

UMA is based on five main entities: Resource Owner, Authorisation Server, Resource Server, Client, and Requesting Party. We discuss each of those entities in this section. We depict these entities in the below figure.


Overview of the User-Managed Access Architecture We explain each UMA entity below. We refer the reader to the UMA protocol specification for detailed information on each UMA entity. Brief description of UMA entities:

1. Resource Owner - A Resource Owner delegates access control from their chosen Resource Servers to an UMA-compliant Authorisation Server. Such a user may be also responsible for configuring policies at an Authorisation Server which makes access decisions when a Client attempts to access a Protected Resource at a Resource Server. A user, therefore, serves as their own policy administrator.

2. Authorisation Server - An Authorisation Server (AS) acts on behalf of a Resource Owner. It

evaluates access requests made by a Client against applicable policies, issuing access tokens necessary to make authorised access requests to Protected Resources at a Resource Server. An Authorisation Server may also evaluate such tokens on demand in case a Resource Server chooses not to evaluate them locally. Therefore, an Authorisation Server acts as a Policy Administration Point (PAP) and a Policy Decision Point (PDP) by exposing a Protection API for Resource Server applications. Authorisation Server also plays the conceptual role of a Security Token Service by exposing an Authorisation API for Client applications.

3. Resource Server - A Resource Server is a Web application that is used by a Resource Owner to

store and manage Protected Resources and to share access to these resources with specific Clients. Resource Server delegates access control to an Authorisation Server following configuration by a Resource Owner. A Resource Server is then concerned with enforcing access control decisions issued by an Authorisation Server. Therefore, such application acts as a Policy Enforcement Point (PEP).

4. Client - A Client is an application that interacts with a Resource Server in order to get access

to a Protected Resource, which can be accomplished after it interacts with an Authorisation Server to obtain an access token. A Client is controlled by a person or a company (Requesting Party) that uses such an application to seek protected resource access on their own behalf.

5. Requesting Party - A Requesting Party is a web user, or a corporation or other legal person,

that uses a client application to seek access to an UMA-protected resource stored on a


Resource Server. If the requesting party is a natural person, it may or may not be the same person as the resource owner.

For example, in UMA a Web user (Resource Owner) can arrange to authorise an online service to gain one-time or ongoing access to a set of personal data including his home address stored at a personal data service (Resource Server). A user can achieve that by instructing the host to check with his authorisation decision-making service (Authorisation Server).

2.1.2. Protocol

The User-Managed Access protocol describes interactions between all of the previously defined entities. This protocol consists of the following steps:

1. User introduces resource server to AS; 2. User registers resources at AS; 3. User defines access control policies at AS (not a part of the core UMA protocol); 4. Client gets access token from AM; 5. Client wields access token at resource server to gain access.

We provide a very brief overview of each step of the UMA protocol individually in subsequent sections. We refer the reader to the UMA protocol specification for detailed information on each step of the protocol. Importantly, step 3 is not a part of the UMA protocol per se. UMA does not impose any constraints on how the policy setting step should be performed but we present it for the purpose of completeness of our brief discussion. For example, NuveAM, offering from Synergetics, provides a User Interface that allows users to setup access control policies for their protected resources stored on different hosts.

2.1.2.1. Resource owner introduces resource server to AS In order for an application to act as a Resource Server and to delegate access control to an Authorisation Server, it has to be able to interact with the user’s chosen AS. In this phase of the UMA protocol, the user, acting as the Resource Owner, authorises the Resource Server for Authorisation Server. Importantly, this phase of the UMA protocol is done using OAuth 2.0 Authorisation Code Grant flow. The resource server acts in the role of an OAuth client during this flow. During this phase, the RS completes the following two steps before it can use the UMA Authorisation Server:

1. Resource Server obtains initial authorisation in form of a short-lived code; 2. Resource Server exchanges the code for an access token for AM.

Resource Server, after being authorised by the Resource Owner, is provisioned with an access token, called Protection API Token (PAT), which can be used to interact with the UMA AS’s Protection API. In particular, it allows the Resource Server to:

1. register resources for protection at the UMA AS; 2. register permissions; 3. validate access requests made by client applications to protected resources.

2.1.2.2. Resource owner registers resources at AS

In UMA, the user can store and manage resources on resource server applications as usual (i.e. the protocol does not impose any constraints on this process but only interferes with the access control functionality). The way access control is exposed to this user depends on the application. However,


before resources can be protected on the RS by the UMA AS, the RS has to register information about these resources with the AS. UMA defines a resource registration protocol for the purpose of informing UMA AS about resources that require protection. During this phase of the UMA protocol, RS simply informs the UMA AS which resources it should protect and for which resources access control policies can be defined at this AS. Registration of resource sets is currently done using the resource registration protocol proposed by UMA (called OAuth 2.0 Resource Set Registration Protocol). This protocol allows the resource server to define a resource set that needs UMA protection in a resource set description encoded in JSON form. The resource server registers the description and manages its lifecycle at the UMA AS through the UMA AS's Resource Registration Endpoint (part of the Protection API). Requests to this API are accompanied by the PAT token. Successful registration of a resource set at AM results in the resource server being provisioned with the identifier of the resource set at AM. This identifier has to be stored at a RS in case the application decides to update or delete the set at any time. We refer the reader to specification for further description regarding registration of resource sets. The RS can be optionally provisioned with the information regarding the policy for this set. Since such policy has not yet been set by the user, then this URI can point to an empty policy. Its presence simplifies further interactions of the user with the RS. Once a resource set is registered at AM, the RS must use UMA mechanisms to limit access to any resources corresponding to this resource set, relying on the UMA AS to supply currently valid permissions for authorised access.

2.1.2.3. Resource owner defines access control policies at AS

This phase is not the part of the UMA protocol per se. However, we briefly discuss it in this section for the purpose of completeness. During this phase, the Resource Owner is able to define access control policies for protected resources, which have been registered by the RS at the UMA AS. The UMA protocol does not impose any constraints on how access control policies are composed by a user or how a policy is linked with a resource, since policy provisioning and decision-making take place solely within the UMA AS and this information is not conveyed to other UMA entities. The AS, however, is meant to provide a consistent user experience by allowing resource owners to manage their policies for distributed Web resources with a single user interface. Different UMA AS may provide different management tools with different user interfaces and underlying policy types and policy engines. UMA purposely does not constrain the policy composition process in order to support a variety of data sharing scenarios on the Web. A user may compose policies identifying suitable subjects and their access rights to a user's resources. More importantly, the UMA protocol supports the policy-driven ability of an UMA AS to demand "claims" from clients before authorisation is granted. A policy may also require a consent to be collected from the resource owner in real time. As far as linking a policy to a resource is concerned, a user may perform this in a variety of ways. For example, the resource server may offer a typical security-related user interface (e.g. a simple "Sharing Settings" link). When a user clicks on such a link then they are redirected to the configured UMA AS to associate a resource with an existing access control policy or create a new policy. Similarly, a user may decide to log in to an UMA AS and manually link a policy with a resource or configure existing policy using provided management tools.


At the end of this phase, a set of resources is successfully associated with one or more access control policies defined by a user at the UMA AS. This AS evaluates access requests, which are issued by client applications to protected resources, against these policies.

2.1.2.4. Client gets access token from AS

The client application, instructed by the requesting party, can access protected resources on resource servers. The UMA proposal does not define how the client learns the location of a protected resource. Such location, in form of a Web accessible URI, can be freely advertised by the resource owner for requesting parties. Importantly, the client needs to know the required syntax and semantics for accessing resources using Web Service calls. HTTP access requests (i.e. Web Service calls) to protected resources need to be accompanied by an access token called Requesting Party Token (RPT). This token is necessary for the access control process to be initiated at the resource server. As of version 1.0 of the UMA protocol specification, the resource server can respond to the requester's access request in one of several ways depending on the circumstances of the access request. This depends on the presence as well as validity of the RPT included in the request to the RS. Based on the response, the client initiates different UMA protocol flows. There are 3 different flows that depend on the following:

1. Access request did not contain an RPT; 2. Access request contained an invalid RPT; 3. Access request contained a valid RPT.

Initially, if RPT is missing in the request issued by a client application then a resource server informs the client that a resource is protected and an authorisation is needed from an UMA AS. The client uses this information to talk to the UMA AS and obtain such authorisation using the UMA AS's RPT endpoint and Authorisation Request Endpoint. In order to interact with these endpoints, the client has to be first authorised by the requesting party to use a particular UMA AM. Such authorisation is similar to the authorisation that resource servers have to go through. However, client applications are authorised to use UMA AS Authorisation API (and not Protection API) and it is the requesting party (and not resource owner) that authorises these applications to use UMA AS. Client, after being authorised by the Requesting Party, is provisioned with an access token, called Authorisation API Token (AAT), which can be used to interact with the UMA AS’s Authorization API. In particular, it allows the Client to:

1. obtain new and empty RPTs for specific resource servers; 2. associate existing RPTs with new permissions.

Once a client is in possession of AAT, it can interact with the UMA AS RPT endpoint and obtain an empty RPT. It then has to use this empty RPT and try to access a protected resource on the RS. Initially, the RPT is not associated with any permissions. Therefore, if the requester uses this token to access a protected resource then such access will simply fail. However, for every request that is accompanied with an RPT that is not valid, the RS registers the necessary permissions at AS. UMA requires that empty RPTs are issued initially to clients and only then these RPTs are associated with permissions during further stages of the protocol. This design choice is dictated by the fact that the UMA AS does not know which permissions should be associated with an RPT for a particular access request and it requires this information to be registered at AS by the RS. Importantly, permissions are


associated with the RPT only if the relevant access control policy (or policies) is met. When the client obtains the RPT, it can use this token to access a protected resource but such access will simply fail, since no permissions have been associated with the RPT. In such case, the RS registers the necessary permissions that would be required for such access to succeed. The RS uses the Permission Registration endpoint of the UMA AS Protection API. This registration requires providing the identifier of the resource being accessed as well as the set of actions, which need to be authorised for the client. This information is used in further phases of policy evaluation. When the permission is successfully registered, the client is provisioned with the permission ticket by RS and can interact with the Authorisation Request endpoint provided by the AS. The purpose of this endpoint is to allow the client to obtain the authorisation for a specific resource set. This endpoint requires an RPT as well as the RS-issued permission ticket to be present in the request. The UMA protocol does not define how the AS performs evaluation of access requests. The AS may, for example, use simple rules or a more sophisticated policy engine to evaluate access requests against applicable policies. Once the AM decides whether the access request is valid or not, it may respond to a requester in one of three ways:

1. a successful access response; 2. an unsuccessful access response; 3. a claims-requested document.

Firstly, the AS may decide that a client is definitively not authorised to access a particular resource according to a user's policy and it then responds with an unsuccessful access response. Secondly, if the AS has all the required information concerning this particular access request then it may respond with a successful access response. For example, the issued RPT is already associated with the necessary permissions. Such a response contains a new or upgraded RPT with associated permissions, that can be used by a client on a resource server. The third case is where a user's policy specifies requested claims that must be conveyed from a requesting party before an authorisation is granted, such as self- or third-party-asserted identification, or a promise to adhere to access licensing terms. Based on the user defined policy, the AS may engage the client in the "claims-gathering flow". For example, the AS responds with a claims-requested response containing a list of all requested claims. The client has to provide claims on behalf of the requesting party, which can be used by the AS to evaluate whether access to a protected resource on RS should be granted or not. Upon subsequently receiving claims from the client, the AS performs the access request evaluation process and decides whether authorisation can be granted or not. It may then respond with a successful or unsuccessful access token response, or with yet another claims-requested response if more claims are needed. At the end of this step, a client is in a possession of RPT issued by an AS for a specific access type to an UMA-protected resource on a resource server.

2.1.2.5. Client wield access token at recourse server to gain access


This step of the UMA protocol happens when a client has acquired an RPT from UMA AS and such RPT is likely to be valid on a resource server. A client presents this token when attempting to access a protected resource on RS. A resource server can either choose to evaluate the access token locally or may use the AS for the evaluation process. In the first case, it is the RS that decides whether to grant access to a resource or not, though this must be based on the received access token (such token must be self-contained for the RS to make a meaningful decision). If the token is valid then access to a resource is granted. In case the RPT is invalid then a host registers the necessary set of permissions at UMA AS and it requires from the client to associate these permissions with its RPT token. In case a resource server decides to use the AS for the validation process, it then sends the received RPT to the AS Token Status endpoint. UMA specifies this phase of the protocol as a requirement for bearer tokens, which are opaque to the RS. The request for validation is accompanied by RS own PAT token. Additionally, RS can send information regarding the resource on which access is being attempted by the client, i.e. the resource set identifier. The UMA AS replies with a status of the RPT token message. If valid, this status contains permissions that his RPT carries. It is the RS responsibility to check if the permissions are sufficient to access a protected resource. After this step of the protocol, a client gains authorised access to a protected resource or is denied access if the presented RPT is invalid. In the latter case, a client is free to seek further authorisation at AS, as we discussed.

2.2. Synergetics and User-Managed Access

Synergetics NV has been at the core of User-Managed Access and Privacy of Personal Data. It is now the mother company of Cloud Identity Limited in UK. Cloud Identity Limited has done IAM projects in Europe, Asia, and USA and has been targeting various sectors: governmental, health care, higher education, industry with end-to-end project management. Cloud Identity has been shortlisted by EuroCloud UK in 2014 in two startup categories: “Most Innovative” and “Best Business Potential” based on its User-Managed Access solutions which we discuss in this document. Synergetics NV co-authors User-Managed Access that has been named Best Innovation/Standard in Information Security (EIC 2014, Germany). Notably, Synergetics NV co authors the following specifications: UMA V1.0 and associated specification (OAuth 2.0 Resource Set Registration) released April 2015 and UMA V1.0.1 and associated specification (OAuth 2.0 Resource Set Registration) released December 2015. Through its personnel, Synergetics NV also holds leadership positions in the Kantara Initiative User-Managed Access Work Group (including Vice-Chair, Implementation Coordinator). Synergetics personnel also co-authors RFC 7591 and RFC 7592 specifications: RFC 7591 – OAuth 2.0 Dynamic Client Registration Protocol (July 2015), RFC 7592 – OAuth 2.0 Dynamic Client Registration Management Protocol (July 2015). Personnel is also committers to Apache Oltu, that is the official OAuth 2.0 implementation at the Apache Software Foundation and is used in various software all around the world. Synergetics NV team member (while still at Newcastle University) has won the prestigious Kantara Initiative Identity Deployment of the Year (IDDY) award in 2011 for innovative UMA software (San Francisco, CA, USA). Also, the MIT Tech Review Innovators Under 35 award was given to Dr Maciej Machulak in recognition for the work on UMA and Privacy (this included invitation to European


Parliament in September 2015). Dr Maciej Machulak also has a User-Managed Access masterclass planned at prestigious Cloud Identity Summit in April 2016 – New Orleans, LA, USA. Synergetics has been implementing UMA in its two products NuveLogin and NuveAM (collectively known as Nuve User-Managed Access). Both products integrate with the core e2eTA framework. In particular, NuveAM provides the functionality of an UMA Authorisation Server as well as a Personal Trust Manager, presented in this document. Therefore, we introduce the NuveAM implementation in this further sections of this document.

2.3. NuveAM – UMA Authorisation Server

NuveAM provides a solution to access control and audit for distributed data and Web APIs. With NuveAM, organisations and individuals can manage their security policies centrally with an intuitive dashboard. NuveAM also provides advanced real-time analytics and monitoring to support compliance.

NuveAM is a User-Managed Access (UMA) Authorisation Server (AS) that provides:

Access control to online data and APIs

User-defined access policies

Real-time monitoring and audit

Solves such use cases: Securing Personal Data Services (PDS); Security of Private Health Data; Managing access to online APIs;

Uses open standards, including: UMA, OAuth 2.0, and (via NuveLogin) OpenID Connect, SAML 2.0, and others;

Can be integrated with easy-to-use client frameworks;

Integrates with e2eTA.

2.3.1. NuveAM Characteristics

Main characteristics of the NuveAM system are listed below:

Advanced access control and sharing functionality for any Web-based resource.

Easy management of internal and external SOAP-based and RESTful Web APIs.

Compliant with User-Managed Access (UMA) v1.0.1 – an innovative and open protocol.

Advanced analytics and monitoring tools to support compliance.


Figure. Overview of NuveAM architecture.

2.3.2. NuveAM Features

NuveAM features are listed below:

Unified User Experience - Control access to online data using a single and intuitive dashboard with easy-to-use functionalities;

Access Control for Online Data - Apply access control and sharing functionality across existing in-house and Cloud-based applications. Protect your online resources easily and securely;

Access Control for APIs - Allow administrators to efficiently manage access to internal and external Web APIs from a central location;

Real-Time Analytics and Monitoring - Analytics and monitoring functionality that can support compliance with existing security policies within organisations;

On-Demand Access Control - Allows access control policies to be established on “as needed” basis for flexible control to Cloud resources;

Contact and Application Management - Manage contacts and applications that can access your distributed Cloud data and services using a single location (applications are managed through NuveLogin).

2.3.3. NuveAM User Interface Interface Examples

As discussed in this document, the UMA Authorisation Server as well as the PTM provide the point allowing individual users to manage policies for their online data. As such, it is crucial that user interfaces are designed properly and tailored towards management of various types of data. In this section, we provide example screenshots that relate to data for which security is managed via implemented NuveAM Authorisation Server.


Figure. Exemplar login page for NuveAM system.

Figure. List of resources registered for protection by Resource Servers owned by a particular individual.


Figure. Resource metadata registered at Authorisation Server by the Resource Server

Figure. Requesting parties screen.


Figure. Client applications screen.

Figure. Myself policy for a resource.


Figure. Others policy for a resource.

Figure. Adding new “myself”-type policy.


Figure. Resource audit log.

Figure. Audit log.


Figure. Application audit log.

2.3.4. Policy visualisations

Because end users will need to handle security for vast amount of data, Synergetics NV has been working on new policy visualisations concepts. This includes presentation of a policy as a network. We provide exemplar screenshots below.

Figure. Exemplar policy – screen 1.


Figure. Policy visualization.

2.4. References

When writing this part of the document, we referred to (or we used text from) a number of available sources, including, among others:

1. https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0.html 2. https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html 3. https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0.html 4. https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html 5. http://kantarainitiative.org/confluence/display/uma/ 6. http://www.cloudidentity.co.uk/products/nuveam 7. http://www.cloudidentity.co.uk/products/nuvelogin

https://kantarainitiative.org/confluence/display/uma/Case+Study%3A+Access+Management+2.0+for+the+Enterprise

https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0.html

https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html

https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0.html

https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html

http://kantarainitiative.org/confluence/display/uma/

http://www.cloudidentity.co.uk/products/nuveam

http://www.cloudidentity.co.uk/products/nuvelogin




3. Part 3: End2End Trust Assurance Network Business, Governance & Trust Model

This document explores the Business Governance & Trust Models for end2end Trust Assurance Networks. We acknowledge that there will be multiple Trust Networks and that a given Service Provider may belong to more than one. We explore the role a Trust Guarantor plays in the network and how is this related to the concept of Trusted Third Parties.

In general it is recognized that Trusted Third Parties will be needed to achieve confidence in “trust-ability” of the network. Trust Guarantor’s role is to overall coordinate the operation of the Trust Network and ensure all Trusted Third Parties as well as the Service Providers are performing their obligations.

Governance aspects and stakeholders of a Trust Network are examined. Some acute privacy threats are examined. Costs and sources of revenue of personal data ecosystems for Health or Human Capital are identified. Some recommendations for government policy are highlighted.


3.1. E2ETAN Business Model

e2eTA (end2end Trusted Assurance) Network, provides a secure and effective means for individuals, end-users, to participate in online commerce, eGovernment (including health), and civil society (including social networking) while monitoring and controlling their personal information online, as it is produced and used or requested by service providers.

The overarching business model is that of federated independent parties / service providers collaborating and adding value to a network, while also benefitting from economies of scale provided by the network effect created by pooling their user bases. The network is a facilitator that lowers transaction costs and adds convenience, security, and trust to all parties, including the end-user. The end-users, in particular, will derive benefit from privacy by design and more equitable and level playing field where they are in control of their data.

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 (TN) information exchange and transactions are supported by guarantees in terms of both quality and the various trust and security components (authentication, authorization, 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.

Central to the operation of the network based trust infrastructure is the use of specific Trusted Third Parties (TTPs) for mechanical and 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.

The Trust Guarantor’s role is to provide overall coordination of the operation of the Trust Network and to ensure that all Trusted Third Parties as well as the Service Providers are performing to their obligations. This leads to a-priori assumption that it is basically safe to transact with any member of the network, promoting trust in the whole network, leading to its acceptance and widespread use.

This brings down costs of doing business, reduces fraud and abuse of information, and ultimately leads to new innovative ways of transacting. It is envisaged that cross Trust Network communication will be enabled by co-operation between Trust Guarantors. This eventually will result in merger of ecosystems, enabling a bottom up approach to deploying Trust Networks.

Figure 2: Main Components of a Trust Network

Technically the top level Trust Guarantor has a fundamental role in (i) introducing, (ii) monitoring, and (iii) auditing the end2end assurance of trust between the transacting parties.


1. All parties in the Trust Network (i.e. (i) end-users, (ii) service providers and requesters, including (ii) 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 and nature of the trust network and has to fulfil both technical and legal audit roles in the trust network.

2. All parties including end-users, service providers/requesters of application specific services (e.g. eHealth tools) and service providers/requesters of TTP services (i.e. authentication) will be monitored by the overall end2end Trust Assurance 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 and monitored by the Trust Guarantor.

3. Any breaches of terms or failures of the Trust Network are ultimately 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 (i) via reduction of trust ranking of specific services, (ii) by legal action on the basis of the e2eTAN 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 are addressed in the following.

3.1.1. What should constitute a Trust Network?

Trust Network needs to address:

Business requirements

Technical requirements

Policy requirements

Legal requirements.

The parties covered by the e2eTAN architecture fall into four 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 (e.g. employability or eHealth related services)

End-users (individuals)

Network beneficiaries that receive value from end-user’s interaction with the Service Providers, e.g. employer benefits from employees using training services provided by Service Provider even if the employer does not actively participate in the network.

All parties should consider the technical, policy and legal requirements to be the minimum requirements of the architecture.

In the case of technology requirements, there may be limited flexibility in some implementation parameters to ensure interoperability.

In the case of policies, they can be used in 2 ways. Participants to the e2eTAN consortium can 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 e2eTAN can be used to create policies or are to use existing possible legacy policies and map onto the e2eTAN 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.


Lastly, the legal requirements are reduced into contracts tailored to the role that each participant is playing, so they must be completed and adhered to. When registering to the Trust Network, the contract terms will bind organisations to technical and policy requirements, both in terms of those ex- pressed at the intra- and inter-organizational level as well as in terms of using the appropriate trust technologies to honour the preferences and choices of users as to use and sharing of personal information.

Trust verification and assurance are essential elements of the e2eTAN 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.

End2end Trust Assurance Networks are monitored & trust assured by (1) an independent Trust Guarantor supported by one of more (2) e2eTAN 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 Trust Guarantor 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.

An end2end Trust Assurance 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 Noord-Brabant province in the Netherlands, such PPP is currently in the making for a regional employability platform. It involves representatives of the employers, 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 labour unions, industry sector federations, government, grass roots user groups, In essence this boils down to "organising the communality"

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 user-centric data and services and the trust this requires.

The end2end Trust Assurance Network Governance Agreement as monitored and audited by the Trust Guarantor therefore has the following tasks:

Monitor the governance structure of the Trust Network

Register, certify, oversee and audit of the TTPs active in the Trust Network.

Register, certify, oversee and audit the Service Providers

The certified Trusted Third Parties, working in framework set by the Trust Net- work as executed by the Trust Guarantor will typically be existing actors possibly performing the following functions:

Identity Providers (IdPs), to be certified by the TG


Discovery and registries, to be certified by the TG

Reputation Providers, to be certified by the TG

PKI (q.b.) to be certified by the TG

Authentic attribute sources, to be certified by the TG

... Etc?

Service Providers, may participate in multiple TNs (having a non-exclusive relationship), and choose their TTPs from available choice within each TN.

Service Providers that act as data requestors

Service Providers that act as data providers (running trusted repositories)

Service Providers that act as data originators

End-Users can expect the following services from the Trust Network:

Certification and audit procedures

Branding (might/should be reputation based on live tangible metrics. Problem with brand is that 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 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:

The TG does not have all the skills needed

There are already players in the market like:

Certification Authorities

Issuing certificates

Credit check operators

Providing reputation

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.

3.1.1.1. Public vs. Private networks


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, e2eTAN 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 Net- works) 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 e2eTAN 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 e2eTAN Governance model or direct oversight. Thus e2eTAN 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.

…”A Governance Agreement to which all parties agree governs each Trust Network”….

N.B. In implementing the end2end Trust Assurance Network (e2eTAN) requirements, two equally valid models may be used simultaneously. Some players may wish to adopt whatever criteria are created by e2eTAN where others may map their existing criteria toe2eTAN to demonstrate equivalent compliance and interoperability. As we work on the development and pilots of e2eTAN 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 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).

3.1.1.2. Branding and reputation

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 e2eTAN type of Trust Net- works 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 e2eTAN - 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. e2eTAN 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.

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-the-shelf. However in an early innovator market, such as e2eTAN 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.

3.1.1.3. Users trust perception

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 e2eTAN that when users present their personal information to a e2eTAN 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.

The ultimate guarantee that the data will not be misused is. The trusted guarantor who effectively takes on the liability for their respective trust networks assures this. 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?

Beyond the brand perception of a e2eTAN 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.

3.1.1.4. Quality of trust

A key business opportunity in e2eTAN is the concept of user trust perception. As users present their data to e2eTAN 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 e2eTAN networks allowing application invocation and presentation of results when done.

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

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 e2eTAN. It is likely that the GUI to e2eTAN 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 e2eTAN interfaces whilst others may use e2eTAN 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.

3.2. How many of trust networks should be out there?

First of all we like to restate that an important goal of the e2eTAN project is to create documentation and software so that Trust Networks will be easy to setup, whatever their application domain. Further, by adopting common architecture and technology, it will be possible to merge existing Trust Networks in a bottom up fashion.

As argued above, we expect e2eTAN 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).

N.B. 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.

Conclusion: Initiated from a need for trusted sharing of personal information, e2eTAN’s arise from two angles:

With the user as the ONLY ’lifelong’ continuum within Trust Networks, the variety and scope of 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: o Regional development, interests & communality o Domain/industry sector specific interests.

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 rollouts, where different trust networks can be interlinked into Trust Ecosystems. In fact the Trust Ecosystem level could be the goal of the e2eTAN 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.

3.3. Should Trust networks interact with each other?

As e2eTAN services mature, the focus will shift towards building efficient larger trust ecosystems, which means connecting different context networks and avoid- ing overlapping functions. Again e2eTAN is built 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 e2eTAN project however considers the Trust Ecosystem level to be outside of the scope of the project and of its demonstrators.

We are presuming sectorial/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 e2eTAN 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.

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.

3.4. 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.


Figure 3: Crossing the Chasm

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.

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 Net- work 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:

Public-Private partnership with a user community impact

New for profit company founded for the purpose (needs to build reputation)

New non-profit foundation or association created for the purpose (needs to build reputation)

Existing non-profit foundation or association

Certification Authority

Other major (consumer) player

Government institution

Government

EU

Charity

Bank (they run your money, why not you personal data?)

Insurance Brokers (you honest broker represents users)

United Nations 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, labour union, ...etc. Outreach to privacy and consumer organisations would be recommended.

3.5. 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 on-board.

a. On the one hand will e2eTAN 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:


i. A clear win-win for their members and constituency (why) ii. Adhere to e2eTAN compliance and its common rules of engagement (how)

iii. 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, and 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:

Governance structure, such as advisory and audit boards

Criteria to join and stay on the network, including certification and audits

Process for removal from the network

Process for complaints

Commercial liability and its fair appropriation

Liability due to negligence in criminal cases and its fair appropriation

Privacy protection, including redress for users (Req. D1.2-6.10-Redress)

Minimal mandatory security practices (Req. D1.2-6.11-Confid)

Acceptable use for Service Providers

Acceptable use for Users

Licensing of Trusted Third Parties, and their liability

3.6. How are Trust Networks financed?

a. An end2end Trust Assurance 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 centre, new, and innovative user-centred services will be developed, which did not exist in the old service economy.

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:

Compared to the scattered service provider centric services, how much money does using a user-centric online trust network save?

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 costs 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 on-board to found the Trust Network.

By now it is clear that Trust Networks will have operational costs:

Procurement and maintenance of technical infrastructure

Member acquisition costs

Member management costs

User acquisition costs

User management costs

Trust branding costs (marketing)

Audit costs

Legal costs

Liability and insurance costs

General management costs

Trust Network can be financed in a variety of ways

Initial capital injection for o Procurement of technical infrastructure o Procurement of legal contract framework o Initial trust branding costs (marketing) o Initial member acquisition o General set up

Fees from Service Providers: there is a need to accommodate many types of Service Providers: o Fixed yearly fee o Per transaction o Per number of Users o Per yearly business volume o Revenue share o Member management fees o Audit fees

Fees from Trusted Third Parties o Trusted Third Parties are allowed to have a fee structure of their own o Need to accommodate many types of TTPs; for

Fees from Users: o Fixed yearly fee o Usage fees from Users. (The tricky part is to collect them) o Per transaction o Per number of Users o Per yearly business volume o Revenue share o Member management fees o Audit fees

Advertisement o Placement of advertisement in authentication steps


o Right to place advertisements in Service Providers o Revenue share from Service Provider advertising revenue

Proceeds from foundation grant investment portfolio

Government subsidy, research funding, taxes in a fair way. Perhaps a model where bill for broadband

Internet connection includes some fee.

The e2eTAN architecture should enable all of the above forms of raising revenue, or at least not block any of them.

3.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 e2eTAN specification. This includes: a. Operate or outsource the certification program for software products to be used in the Trust

Network. b. Operate or outsource the certification program for deployments, i.e. the participating Service

Providers, and possibly others like IdPs. c. Operate or outsource an audit programme for the deployments d. Process complaints and arrange for arbitration or disciplinary action e. Market the network to

both Service Providers and Users e. Maintain government compliance & endorsement as "The Trust Network" f. Guarantee minimal cost participation for non-profits

2. Operate necessary technical infrastructure. Depending on how the Trust Guarantor organizes (1) its business and (2) the Trust Network this may include:

a. Execute an IdP function or arrange for others to operate IdPs in the network b. Authentication providers, in as far as this is not integrated into IdP.

b. Discovery and registry functions c. Dashboard and audit results publication portal d. 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. e. Network level PDP


f. Reputation system, or arrange for someone to run the reputation system. g. 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. h. Where interaction between networks happens, the Trust Guarantor may operate a gateway

that mediates.

3. Managing liability

a. 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.

b. 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.

c. 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. Outsourcing the 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

4. The Trust Guarantor monetary streams are:

Trusted Third Parties contracted on case-by-case basis. o Most of these will involve cash outflow o Some cases cash inflows may be possible. Never-the-less, to be negotiated.

Government Service Providers pay a yearly fee, to be negotiated

Commercial Service Providers pay as negotiated, but preferred basis is revenue share or per transaction

Small Service Providers pay small o Yearly fee o An one-off Service Provider setup fee o Support fees once initial support package has been exhausted

Value added telephone & (first/second level) helpdesk support for users

Advertising in authentication process where feasible

Licensing fees or Revenue Sharing from Trusted Third Parties

Insurance against liability

In the above listing, there are many charter requirements to guarantee that the Trust Guarantor will operate ’within reason’. Since e2eTAN 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.


3.8. 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?

3.8.1. Kinds of Service Providers

a. All business actors, other than end-users, are modelled as Service Providers. Obviously there are different types of Service Providers with different legal requirements. As such 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.

b. 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.

c. 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.

d. 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.

e. 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.

3.8.2. Kinds of Trust Entities

Trust entities will fall out of the e2eTAN 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:

1. PKI Certification Authorities (CAs)

Issue SSL and signing certs to system entities

Potentially issue certs to users as well (we should avoid this if at all possible)

Handle certificate revocation and online status checks (OCSP)

No particular conflict of interest seen. TG could well be CA.

However, established players exist on market, so it makes sense to lever- age them. 2. User registration authorities.

(PS: Sometimes IdPs perform the user registration function as well, but this need not necessarily be so)

3. Identity Providers (IdPs)

Authentication

SSO


Possibly some initial attributes

Possibly a discovery and/or token issuance service bootstrap Main problems with IdPs are

Visibility to federation relationships

Traffic analysis, know who is who’s customer and how often

Potential visibility to authentication credentials

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

Who provides what service to whom

Where do users keep their data

Indirection layer in providing end point URLs

Credential mapping, from original to specific use

Problems are similar to IdP. Further technical reasons usually dictate that that Discovery is operated by same entity as IdP.

5. Relationship Service

Who has invited whom to have sharing relationships

Group

Delegation use case

Almost certainly should be distinct from IdP to avoid accumulating too much information in one place

Technically easy to have multiple PS 6. Organizational PDPs

Local to organizations operating the SPs

Authorizations must be trusted blindly

The PDP gets to see quite a lot of traffic analysis info 7. e2eTAN network-wide PDP

Enforces the network wide rules

Authorizations must be trusted blindly

The PDP gets to see quite a lot of traffic analysis inf 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.

Multiple instances encouraged to avoid accumulation of too much info of this nature in one place

9. Authorative data sources

Sometimes known as Policy Information Points (PIPs)

PDPs and reputation scoring can rely on authorative attribute data, thus supplier of this data has to be trusted

The way the data was collected in the first place has to be trusted 10. Policy Authorities

Where do the policies that drive various PDPs come from?

Are they dynamic or field upgradeable?

Many e2eTAN components are driven by business models, so whoever pro- grams these and has ability to update the installed base, has a lot of power


Dynamic BPM where the actual model itself can change and be propagated instantaneously to the consumers of the model

11. Ontology authorities

When trying to compare apples to apples, e.g. to make authorization decision, the authority that defines the equivalence classes of terminology can control the outcome.

Field upgradeable or dynamic ontologies are likely to be used, thus it matters what authority lies behind them.

This threat is similar to the process model one 12. 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.


3.8.3. Principles that Trust Network Should Adopt

Personal Data should only be collected and/or processed for fair and legitimate business purposes.

The purpose(s) for collection must be clearly specified.

The collection related to those purposes must be relevant and non-excessive.

Personal data must be accurate and, where needed, up-to-date.

Use, and subsequent use, of personal data cannot be incompatible with the purposes specified and should be with the consent of the data subject

Appropriate security (technical and organizational) measures against

Unauthorized/unlawful/accidental access; modification, disclosure, de- struction, loss or damage to personal data must be in place.

Controllers and processors have duties to maintain confidentiality of information.

Sensitive data may be subject to greater restrictions

Data subjects have the right to know what types of data are being maintained and have the right to access and correct personal data.

It should be noted that consent often bears important adjectives of clear, un- ambiguous or explicit. From a technical point of view, this requires that the user "opt in" to the collection of personal information.

3.8.4. Question a Trust Network Member Has to Answer

1. Are you collecting/using PII as part of the service? 2. Do you have a privacy policy that you are bound to follow? 3. Do you use PII for any purpose other than providing the service?

4. Do you get my consent or let me opt out before my information is used for other purposes than providing the specific service?

5. Do you share my information beyond your company or family of companies? 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? 7. Do you allow me to manage these preferences over time and change my options?

3.8.5. Privacy Architecture Elements

1. Identify why information is needed 2. Provide appropriate notice and obtain consent for use of information 3. Limit information collected to that which is required for the legitimate business need 4. Limit access to information to those that need it for the business function 5. Retain information only as long as reasonably needed to complete the business function and

securely delete it (or possibly anonymise it). 6. Secure information as required in a manner proportionate to its nature and sensitivity 7. Maintain the integrity and accuracy of the information 8. Provide access and possibility of correction


3.9. Governance Framework for an Ecosystem

While many variations of governance structure are possible, we suggest here a governance framework for an ecosystem. In this model, the Trust Network that enables the ecosystem is assumed to be a not-for-profit company or association, perhaps a Public Private Partnership (PPP) or a Joint Venture.

The stakeholders and members of the ecosystem will come in several varieties:

A. Sponsoring Members (generally have right to Board seat and contribute significant financing, labour, or expertise). These are typically the promoters and organizers of the ecosystem, though they could also be significant Service Providers and beneficiaries of the ecosystem as well.

B. Regular Members. These are typically Service Providers and beneficiaries that need less expensive way to join the ecosystem, but wish to have their voice heard in the governance of the Trust Network.

C. Associate Members. These are typically Service Providers (SPs) that want to join at minimal cost. Associate Members do not have voting powers and join the ecosystem by signing Association Agreement (Board or an officer authorized by the Board signs on behalf of the Trust Network) rather than the Governance Agreement. In some ecosystems, these might be the majority of the SPs. Associate Members may (or may not, depending on Charter) have their voice heard through special Board Member or Advisory Board Member.

D. End Users. Most human end users do not explicitly join the Trust Network, they just use it and in so doing are bound by the Terms and Conditions and other policies directed towards them. End users may (or may not, depending on Charter) have their voice heard through special Board Member or Advisory Board Member. However, it is highly advisable to have End Users represented in some way.

E. It should be understood that a Member of Trust Network (TN) does not necessarily need to run a service in the TN (they could be member in order to sponsor the network and to make sure their voice is heard in the governance) and that one member may also run several services.

The governance is based on following documents and bodies, in decreasing order of precedence:

I. Governance Agreement (private, long term), signed by Sponsor and Regular Members II. Charter (public, long term), all members are bound by the Charter

III. Binding Agreements with Suppliers IV. Founding Agreement (private, signed by founders) V. Association Agreements, signed by Associate Members

VI. General Assembly, as limited by (I) and/or (II) VII. Board of Directors ("Board"), as limited by (I) and/or (II)

VIII. Auditor (financial, external) IX. General Manager and other officers appointed by the Board X. Advisory Board (if any)

XI. End User Terms and Conditions, Privacy Policies, Codes of Conduct, etc. XII. Technical and Compliance Rules


3.9.1. Founding and Governance Agreements and the Charter

The purpose and governance structure are laid out in the Governance Agreement and Charter of the Trust Network. The Charter is a public document, sometimes known as articles of association, articles of incorporation, bylaws, or statutes. The Charter is generally required by law for the Trust Network to become a separate legal entity.

However, there are aspects of the Trust Network and its governance, such as special privileges and Board seat allocations, that are not required by law to be public and the founders may wish to keep confidential. These matters are addressed in the private Governance Agreement (analogous to shareholder’s agreement in corporate world). Confidential initial dispositions, including funding and in-kind contributions, are best addressed in private Founding Agreement.

Charter, Governance Agreement, and Founding Agreement - taken together - should address at least the following issues:

1. Purpose of the Trust Network a. Not-for-profit nature b. Fair and privacy respecting nature (details of how these are implemented can come later in

documents, such as Technical and Compliance Rules, approved by the Board) 2. Ability to own companies and participate in associations d. Jurisdiction and official language

a. Specification of types of Members and their special rights b. Founding disposition: initial members (with addresses) and their type c. Founding disposition: initial funding and in-kind contribution provided by the founders d. Governance structure e. Division of powers between General Assembly and Board, including limitations on powers of

Board if different from law. f. Vetoes in General Assembly and matters requiring qualified majority (and specification of the

majority). Specifically, the alteration of Charter and Founding Agreement should be addressed. g. Quorum and convocation of General Assemblies

3. Board composition, including reserved board seats 4. Board vetoes or matters requiring qualified majority of the Board (and specification of the

majority) 5. Quorum and convocation of the Board g. Signing rules 6. Powers and composition of Advisory Board, if any 7. Founding disposition: initial composition of the Board (and Advisory Board, if any) 8. Founding disposition: initial set of General Assembly decisions made by simple majority (i.e. not

part of the Charter) 9. Founding disposition: initial set of Board decisions, such as

a. Nomination of officers and their powers and proxies b. Establishing banking relations b. Taking out insurance, e.g. general liability and director’s liability d. Association Agreement

template 10. End User Terms and Conditions, Privacy Policies, Codes of Conduct, etc. 11. Initial set of agreements with suppliers.

N.B. The main purpose of this founding disposition is to avoid bloating the Charter, especially clause 4.e, with matters that are normally within powers of the Board, but that form an essential component of the founding deal of the Trust Network. In particular, it should be understood that initial agreements with suppliers are binding to the Trust Network and the board cannot unilaterally renounce them (i.e. they can only be terminated according to clauses of those agreements, typically due to breach or expiration).

12. Distribution of Liability


13. Member obligations, such as membership dues, or a mention that the Board shall decide these. Also member’s obligations to comply with Technical and Compliance Rules if member provides a service in the Trust Network.

14. Procedure for adopting new members 15. Procedure for a member to terminate its membership. Some obligations of agreements may

persist beyond end of membership. Partial return of member’s contribution to funding may be appropriate.

16. Procedure for dealing with breaches and involuntary termination of membership. 17. Transfer of membership and loss of control of a member. Generally first right of refusal type rule

would apply. Also Drag Along and Tag Along may be included if it is possible to sell the membership. 18. Eventuality (unlikely we hope) of sale or dissolution of the Trust Network. 19. How the Trust Network will finance itself and terms and conditions of any (emergency) financing

that the members may provide. Also limits on terms of external financing (e.g. maximum interest rate and amount the Board may contract without convening General Assembly).

20. Rules of IPR contribution, including IPR brought in, IPR excluded, and IPR that may be co-exploited. 21. Founding disposition: list of IPR brought in - may also appear in (4) 22. Confidentiality 23. Non-compete and non-solicit (if desired)

3.9.2. Association Agreement

The Association Agreement is intended for Associate Members (type C). The intent is that Associate Members need not know the content of the confidential Founding Agreement, but are still bound to the Charter and Technical and Compliance Rules. Associate Members are also bound to act in a way consistent with the promises made in the End User Terms and Conditions. Association Agreements are signed by the Board or an officer appointed by the Board, on behalf of the Trust Network.

Association Agreement should address at least:

1. Identification of associate (including nature and address) 2. Make Charter (especially purpose part), Technical and Compliance Rules, and End User Terms

and Conditions, Privacy Policies, Codes of Conduct, etc. part of the agreement. 3. More or less automatic adoption of future versions of Association Agreement and documents

mentioned in (2). 4. Statement of the type of membership and resultant (lack of) rights and obligations, including

dues, if any 5. Warranties and representations 6. Distribution of Liability 7. Voluntary and involuntary termination as well as breach 8. Limited confidentiality

It should be understood that for a member to provide services in the trust network, they must have (i) signed an association (or founding) agreement, (ii) passed financial vetting, and (iii) passed technical vetting. In case criteria for (ii) or (iii) later ceases to be satisfied, the service may be blocked out of the Trust Network, but the business entity that signed, will stay as Associate Member and may remedy the breaches of (ii) and (iii) to return to provide services.

3.9.3. End User Terms and Conditions, Privacy Policies, Codes of Conduct, etc.

This treatise does not pretend to be exhaustive in this regard, but typically these address


1. Introduction to features of Trust Network and the fact that Service Providers are distinct entities and that each entity (user, SP, or TN) bears responsibility for its own actions.

2. Obligation to guard authentication credentials and responsibility for any and all use of the credentials.

3. Acceptable use (code of conduct), both from user and SP perspective 4. Privacy Policy 5. Guarantees and Warranties, or lack of them 6. Distribution of Liability 7. Reasonable consent to handing of data 8. Acknowledgement of risks (and comparison how Trust Network reduces them viz. wild Internet) 9. Contact address for the Trust Network governance and redress path

3.9.4. Technical and Compliance Rules

This treatise does not pretend to be exhaustive in this regard, but typically these address

1. Obligation to guard authentication credentials and responsibility for any and all use of the credentials.

2. Acceptable use, both from user and SP perspective, with reference to End User 3. Terms and Conditions, Privacy Policies, Codes of Conduct, etc. 4. Guarantees and Warranties, or lack of them 5. Distribution of Liability 6. Acknowledgement of risks (and comparison how Trust Network reduces them viz. wild Internet) 7. Contact address for the Trust Network governance and redress path 8. Reference to Technical Specifications, including e2eTAN architecture and e2eTAN protocol

documents. 9. Financial vetting form 10. Technical vetting form

3.9.5. Agreements

I. Governance Agreement (private) 1. All members but one qualified majority to change contract 2. Sponsors have board seat and veto on important decisions (TBD)

II. Charter (public) 1. Not-for-profit 2. Fair and privacy respecting 3. Can own companies and participate in associations 4. Dutch jurisdiction and language, with English as secondary language e. Associate members do not

have voting rights, except for their board 5. Member’s election. Minimal information rights. 6. 7 to 11 member board *** The board should be smaller to be efficient 7. Each founding member has a seat 8. 1 seat for end-user representative (outside director) 9. 1 seat for associate member representative (outside director) 10. Possibly 4 additional outside directors elected at General Assembly 11. Paid managing director and secretary 12. Advisory board to be composed of distinguished academics, privacy and consumer advocates, and

labour market participants. No real power except to force Board to publicly pronounce on any question posed by the Advisory Board


13. Advisory board to be invited by the Board 14. 90% of voting members qualified majority to change charter k. 90% of members qualified majority

to change charter 15. Double signature or single signature with proxy or appropriate board decision to oblige the Trust

Network 16. New Sponsor Member procedure (needs to sign Governance Agreement) 17. New Regular Member procedure (needs to sign Governance Agreement) 18. Can terminate membership with 180 days notice and no compensation for investment 19. Breach and involuntary termination clause TBN (To Be Negotiated) 20. No transfers allowed without board consent and with first right of refusal, membership is not

sellable 21. Sale of network requires 90% of voting members qualified majority and implies drag-along and

tag-along. 22. Loans to trust network practise 5% interest and no conversion or col- lateral 23. Trust Network will not own IPR. Any IPR created belongs to creator, but non-exclusive royalty free

license must be provided to the Trust Network. 24. Confidentiality, but no non-compete or non-solicit v. Distribution of liability (TBD)

III Binding Agreements with Suppliers

1. Synergetics Trust Network Operator as Service contract b. Synergetics software licenses 2. Synergetics maintenance contracts d. Synergetics PDS as a SaaS contract e. Helpdesk partner

contract 3. New Partner Vetting and Certification service contract

IV Founding Agreement (private)

1. Financial and in-kind contributions of each founding member (see "Sponsors", above) 2. Initial board composition (and compensation if any) - see Sponsors in previous section 3. Initial board decisions

a. Binding agreements with suppliers (see below b. Nomination of General Manager and Secretary, and their remuneration c. Association Agreement Template d. End User T&Cs e. Technical and Compliance Rules

4. Initial nomination of Advisory Board 5. List of initial IPR

V Association Agreements

a. New versions adopted with 30 days notice and right to leave membership on voluntary (non-breach) basis.

b. Distribution of liability (TBD) c. Limited Confidentiality, but no non-compete or non-solicit

3.9.6. Proposed Application: Healthcare Ecosystem (ReLifE / Eindhoven)

To Be Written, but similar to 2.5.


3.10. Further reading

To further understand e2eTAN Trust Networks, you should read (in roughly this order):

a. The Governance Agreement of the network you plan to participate in (this depends on the network, no single answer exists)

b. The Compliance Requirements [e2eTANCOMPLIANCE] c. The e2eTAN high level architecture [e2eTANARCH] d. The e2eTAN protocol and concrete architecture [e2eTANPROTO] e. Any architecture and compliance documents of your Trust Network

**************

the do change end2end trust assurance framework … · the do change end2end trust assurance...

Documents