180926 ihan webinar 2

How do we make sure that human-driven
approach will revolutionize our use of data?
House rules:
1. Questions to Skype chat
2. Slides will be published
3. Be active
Direction setting

TECHNICAL CONTACT
Jyrki Suokas:
jyrki.suokas@sitra.fi
+358 (294) 618 497
Juhani Luoma-Kyyny:
juhani.luoma-kyyny@sitra.fi
+358 (294) 618 274

Agenda
What is the IHAN ® project on human-driven data economy about?
Jyrki Suokas (15min)
IHAN® blueprint
Jyrki Suokas & Juhani Luoma-Kyyny (60 min)
IHAN Technical Pilot Projects
IHAN Pilot Project approach Juhani Luoma-Kyyny (10 min)
Sandbox of Trust (30 min)
Farmidata (20 min)
Future IHAN® governance model
Jyrki Suokas (15 min)
Questions and Answers
Everybody (25 min)
Next steps
5 min
Webinar ends

What is the IHAN® project on human-driven data
economy about?
Jyrki Suokas (15min)

5 key facts about Sitra
1. A gift from Parliament to the 50-year-old
Finland.
2. An independent foresight agency:
futurologist, researcher, visionary,
developer, experimentalist, partner, trainer,
networker.
3. Funded by returns on endowment capital
and capital investments.
4. Envisages Finland as a successful pioneer in
sustainable well-being.
5. Its vision is supported by three themes, six
focus areas and dozens of projects.
+1
Building our future
together

Data economy entities,
Person Business
Government
P2P B2B
B2P
G2P G2B
G2G
Identity
data flows and foundation

Service
Authorization
to use
my data
End User
Data
Service provider
Requests for data
Data providers
Service
EndUser
Service
Provider
Data
Provider
Data
Value Value
Value flows in Data Economy
Value = Compensation for work

Data economy in the recent past
Data about me is somewhere out there
I have to manage a lot of different accounts
I have to manually copy my data between data providers – if I can
Data about me
Data provider
Data provider
Data provider
Data provider
Data provider
Data provider
Data provider

Data is currently being consolidated
Data companies are hoovering in data about people
As a service provider I have to buy data from data companies – or die
Data companies will control service industries and me
Data
companies
Data about me
Data provider
Data provider
Data provider
Data provider
Data provider
Data provider
Data provider
Data
companies
Service provider
Service provider
How to get data for my services?
€/£/$/¥ €/£/$/¥

Current situation - risk
Data companies will control the whole service industry
There is an unfair cost to get data to service providers
Monopoly will decrease innovation
Extra cost for me?
Data
companiesder
a provider
Data provider
Data provider
D
Data
Dat
Data
companies
Service provider
Service provider
How to get data for my services?
€/£/$/¥ €/£/$/¥

Our vision for the future
Data about me is somewhere out there - I know where and what
My authorization is needed to use my data – I’m empowered
My data can be gathered for my service on fair and reasonable terms
Services will focus on value, quality and need – data is available at my consent
Data about me
Data provider
Data provider
Data provider Data provider
Data provider
Data provider
Data provider
Service provider
Service provider
Log
Authorization
Service discovery
Identifier wallet
APIs
Metadata exchange
Data transfer
Protocol for data requests

Establish key principles, rules & guidelines for human-driven
Data exchange Platform. Build awareness and engage people
across Europe
Test, develop and scale Platform to multiple industries and EU
countries. Ensure interoperability through technology Proof-
of-Concepts [ I H A N ® A P P R O V E D ]
Branding. Develop common Roadmap for fair Data exchange
Method. Build Common Governance Model [ I H A N ® A P P R O V E D ]
IHAN® in nutshell

Benefits for
Individual
- Empowerment for personal
data usage
- Knowledge of use of my
personal data
- Trust for fair data usage
- New services and new service
providers
Benefits for Service and
Data Providers
- Authorization to use data from
other data providers
- No need to beg data from
competitors
- Possibility to create new services
- Possibility for collaboration with
other service providers
- Get compensated for providing
the service
- Get compensated for providing
the data

IHAN® technical specifications
How does IHAN® architecture and technology principles look like?
Jyrki Suokas & Juhani Luoma-Kyyny (60 min)

IHAN® in a nutshell
Service
DataAuthorization
to use
my data
Service provider
Requests for data
Data providers

How does the world look like with
IHAN® services?
End user-
Service
Data
Service provider Data providerEnd user
ServicesIHAN
End User Service Provider Data Provider
Identity
Data
Consent
Services
Log

IHAN® Services components
Identity
Data
Consent
Services
Log
Personal Identity Wallet
Public Service Directory
Personal Service Directory Service Provider Service Directory
Outbound Data AdapterInbound Data Adapter
Service Provider Consent Directory Data Access ControlPersonal Consent Directory
Personal Log Data Provider LogService Provider Log
Data Source

Deployment view: Embedded IHAN® Services
User Interface
Personal Service Directory
Service Provider Service Directory
Outbound Data Adapter
Service Provider Consent Directory
Personal Consent Directory
Personal Log
Data Provider Log
Service Provider Log
End user-
Service
DataService provider Data providerEnd user
ServicesIHAN
“Service Wallet App”
“End user service”
“Data Source 1”
Data Provider Log
“Data Source 2”
Business Logic
Data Logic
User Interface
Business Logic
Data Logic
DataOut
DataIn
DataOut
APIAPI
Inbound Data Adapter
Data Access Control
Data Access Control

IHAN® Blueprint– Document about WHAT,
not HOW
- Contains documentation of all functional and non-
functional requirements for IHAN® service layer
- Architectural diagrams of components and data flows
for reference architecture
- Technical specification of IHAN® service messages
on field level
- IHAN® service documentation and how Business
services will use IHAN® services
- Governance
– Initially created by Sitra project team
– For time being maintained centrally by Sitra project team
– Updated through learnings from IHAN® technical pilots
- Initial version available today - 24.9.2018

Technical context
- Solutions can be developed using
different architectures and
technologies.
- Same component can be implemented
in many ways , but these instances
must be technically compatible to avoid
creating software silos that prevent
open data exchange.
- Software interfaces between
components must be standardized to
ensure interoperability
- All three functionality layers must have
a standard way to support
– metadata exchange,
– consent management and usage and
– actual data exchange.
- A set of standards and/or best practices
will be defined for the mentioned
purposes, especially between Service
Providers and Data Providers.
- The set of used standards and practices
will increase as the solutions mature.

Main concept: Identity
- In IHAN world, identity is a unique identifier to a person or individual and it is required
as the first part of IHAN Identifier. An identity needs to be based on a trustworthy
external system where it can be achieved via an interface.
- Identity is role-related and can have an organizational structure – like a family.
- It is notable that an IHAN solution itself does not act as an identity management
solution
- A digital identity means a digital representation of person’s identity which he or she has
decided to use. There can be unlimited amount of different digital identities for one
person, each of which is used for none to many services and data sources. Identities
might be verified by a third party. These digital representations are called as
Identifiers.
- Related to a digital identity or a group of identities there can be Attributes defining
certain features on a digital identity. Attributes might be verified by a third party

Main concept: IHAN Identifier
- This is the fundamental component of IHAN functionality. This unique number is a
combination of an identities of a person or individual and a data set. So, the IHAN
Identifier identifies a connection between a person and a data entity. A consent is linked
to a IHAN Identifier and enables the interchange of data between Service and Data
Providers.
- Different identifiers can be connected to each other by a IHAN Identifier. IHAN
Identifier is created by using identifiers, usually a digital identity’s identifier and data
source Data Access Record. A special case is when different digital identity’s identifiers
are connected to each other creating virtual network identities. There is unlimited
number of virtual identifier networks (Identity Relations) a person can be connected
to.

Main concept: Data Access Record
- Data Access Record is the unique identifier identifying the data by containing access
credentials used to access specific data sources using identity.

Main concept: Consent
- For a Service Provider to be able to provide Services the Service Provider and End User
enter into an agreement between each other – this agreement is the Consent.
- Consent is one of the three IHAN base components (the other two being IHAN Identifier
and Logging) and it is always connected to a IHAN Identifier. A consent is the key
component that implements the authority of the usage of a data element. Without
consent there can be no interchange of data between the Service and Data Providers.

Main concept: Metadata and semantic
interoperability
- Semantic interoperability with using several data sources is on Service Provider’s
responsibility.
- To have this semantic interoperability Data Providers must create an API to get the
Metadata of the data they have.
- In these definitions there might be further links to other definitions like codes,
definitions in detail, vocabularies, nomenclatures, document structures, used standards
etc.
-Creating these definitions are outside of the
scope of the IHAN project.

Personal Identity Wallet (1/3)
Level: End User
Layer: Identity
Responsibility: Personal Identity Wallet stores identities and access to data
Description:
Personal Identity Wallet is a component for storing Identity Records and Data Access
Records, latter of them containing access credentials used to access specific data sources
using identity.
- Identity Record describes the identity – i.e. needed access credentials like username and
password
- Zero or more Data Access Record(s) using the identity with individual access credentials
for each data source. A combination of Identity Record and Data Access Record forms
the IHAN Identifier which is used by Data Provider Access Control to provide data

Description:
IHAN does not depend on any specific Personal Identity Wallet systems implemented as it
manages identity as part of the ecosystem it is working in.
- Identities can be strongly authenticated or even anonymous managed by the user.
However, it is possible to link IHAN wallets to strong electrical identity management
systems and related identifiers, such as social security number, electrical ID number,
passport or any other data. In this case the IHAN wallet can create a link between digital
and real world.
- Identity is separated from Data Access. An Identity can have zero or more Data Access
Records each of which use the Identity combined with Data Source specific credentials
for data access. In order for this to work, the identity needs to be connected to the data
at the Data Source.

Functionality:
- End User can add new identities and modify or delete existing ones. Presentation of an
identity depends on the identity type. Some identities - like electronic passports - render
a representation of the data in a predetermined format that can allow for a document to
be used as an identification mechanism in the real world.
- End User can connect Data Access to an identity by providing valid credentials, so data
access can be tested. If verification is successful, the Data Provider entry in Personal
Service Directory is populated with metadata information provided by Data Access
- Control Management subsystem at Data Provider. A successful verification creates a
Data Access Record– a combination of identity, access credentials and data source
address. The record can be shared with Service Providers, so they can access data at
Data Provider without storing any End User data locally. Data Providers always verify
the Consent that Service Provider is using against the Data Access Record. Access
credentials can be stored in any form and identity wallet does not contain clear text
versions of the credentials.

Personal Service Directory (1/2)
Level: End User
Layer: Service
Responsibility: Personal Service Directory manages End User’s Services
Description:
- Personal Service Directory, containing descriptions of all Service Provider Services that
End User has subscribed to Personal Service Directory is used to grant service providers
access to data providers so service providers can produce the service for the End User.
- Over the course of time the Personal Service Directory will start forming into a “GDPR
dashboard” showing the different service End User has access to and what data is
behind each identity.

Personal Service Directory (2/2)
Functionality:
- User can browse available Services in the Personal Service Directory. If End User is
willing to start using a new service, the Personal Service Directory automatically grants
the needed consents for the Service Provider that are required to access data from all
needed data points. This Information is Stored in Service Provider’s Service Directory.
Service is also stored as activated in End User’s Personal Service Directory
- End User can rank a Service
- Personal Service Directory can also actively propose new services through Service
discovery process, which requires opt-in from the End User for specific and narrow
kinds of services which are available for the End User based on the data sets behind the
overall collection of identities the End User has in his/her Identity Wallet.

Personal Consent Directory
Level: End User
Layer: Consent
Responsibility: Personal Service Directory manages End User’s Consents to Service
Providers to access data at Data Providers
Description:
- Personal Consent Directory contains Consent information for each service that contains
both high level and detailed information of data elements,
- Consent is Service specific authorization to use specific Data Access Records that Service
Provider then uses to fetch data from Data Provider Data Sources.

Personal Log
Level: End User
Layer: Log
Responsibility: Personal Log is the End User’s private log
Description:
Personal Log
- Log events Identity changes
- Log events of Service changes and actual usage
- Log events of data usage
All actions in the Personal Service Wallet are logged

Level: Service Provider
Layer: Service
Responsibility: Public Service Directory contains records of all connected Service
Providers’ Services and Data Provider’s data sources
Description:
- Service Providers can register their services on the Public Service Directory.
- Service Description contains both technical and human-readable documentation of the
service, most importantly describing the needed Data Sources in detail.
- Data Sources list can contain both mandatory and optional data elements and it is
Service Provider’s responsibility to ensure that the Service Description clearly outlines
what value the service provides with mandatory data and what additional value comes
from optional data / data clusters

Service Provider Service Directory
Layer: Service
Responsibility: Service Provider Service Directory contains records of a Service
Provider’s Services in more detail
Description:
- Service can be started
1. When End User requests the Service or
2. End User has granted the Service Provider to start the service based on any combination of
following
– some triggered event,
– schedule or
– Service Provider's own service related process /automated process

Service Provider Consent Directory
Layer: Consent
Responsibility: Service Provider Consent Directory contains records of all current and
valid Consents from all End User using Service Provider’s Services
Description:
- Service Provider Consent Directory contains Consents from End Users. There will be at
two identical version of a Consent – End User’s and Service Providers. Part of this
Consent will be further sent to Data Providers which will also store this part of the
Consent to their Consent Directory.
- There might be a solution when Consents are stored also to trusted 3rd party – either in
same format or as a has created from the original Consent. So both parties have a
possibility to proof the content of the Consent.

Inbound Data Adapter
Layer: Data
Responsibility: Inbound Data Adapter is the inbound data transfer point for Service
Provider’s Service to collect data from Data Providers
Description:
- All data coming into Service Provider must go through a data adapter.
- Inbound Data Adapter is an interface that separates incoming data from Service
Providers operational systems and is a starting point of Service Provider’s incoming data
flow.
- Specifications of a Data Adapter describe the Access Mechanism suitable for a specific
inbound data channel – different adapters for different data.
- Inbound data can be the actual data used to provide services or the control data to
enable all data related operations.

Service Provider Log
Layer: Log
Responsibility: Service Provider Log contains both public and private sections of
Service Provider’s log
Description:
- All changes to services are logged into public sector of the Service Provider Log.
- Invocations of services including usage of Consents and data access are logged.
- Data provided by a Service or data from Data Providers itself is not logged

Data Source
Level: Data Provider
Layer: Service
Responsibility: Data Source is Data Provider’s detailed description of its outbound
interface
Description:
- Data Providers can register their Data Sources on the Public Service Directory.
- Data Source Description contains both technical and human-readable documentation of
the data source.

Layer: Data
Responsibility: Outbound Data Adapter is the outbound data transfer point for Data
Providers to send data to Service Provider
Description:
- Outbound Data Adapter is an interface that separates outgoing data from Service
Providers operational systems and is the end point of Service Provider’s outbound data
flow.
- Specifications of a Data Adapter describe the Access Mechanism suitable for a specific
outbound data channel – different adapters for different data.
- Outbound data can be the actual data used to provide services or the control data to
enable all data related operations.

Data Access Control
Layer: Consent
Responsibility: Data Access Control takes Consent sent by Service Provider to
decipher whose data is to be sent back
Description:
- Data Access Control deciphers the Consent and accesses right end user’s data

Data Provider Log
Layer: Log
Responsibility: Data Provider Log contains both public and private sections of Data
Provider’s log
Description:
- All changes to services are logged into public sector of the Data Provider Log.
- All data access is logged.
- Data contents is not logged

IHAN Technical Pilots
What kind of working methodology, tools and process will be used?
Two example Pilot projects
1. Sandbox of Trust
2. Farmidata
Juhani Luoma-Kyyny & Sandbox of Trust & Farmidata ( 60 min)

Technical pilots
Technical pilots
Sitra IHAN
technical teamRequirements
Clarifications
Technical pilots
IHAN
Components
Guidance
Technical pilots
Technical pilots
Business
service
projects
Documentation
From Technical pilots to Business results

IHAN® technical component documentation
Identity
Data
Consent
Services
Log
Data Source

Pilot Project 1 creates initial components and
services
Identity
Data
Consent
Services
Log
Data Source

Pilot Project 2 adds new and creates alternative
components. More IHAN® services added
Identity
Data
Consent
Services
Log
Personal Log
Data Source

Pilot Project 3 adds yet new components. More
services to IHAN® layer
Identity
Data
Consent
Services
Log
Service Provider Consent DirectoryPersonal Consent Directory
Personal Log
Data Access Control
Data Access Control
Data Source

Pilot Project n adds new and creates alternative
components. IHAN® Service layer complete
Identity
Data
Consent
Services
Log
End User Data Directory Outbound Data AdapterInbound Data Adapter
Service Provider Consent DirectoryPersonal Consent Directory
Personal Log
Data Access Control
Data Access Control
Data Source

IHAN® architecture implementations
Collection of IHAN
reference
architectures

SoT implements these IHAN® components
Identity
Data
Consent
Services
Log
Data Source

Contents
• What is Sandbox of Trust?
• Relevance to IHAN
• Architecture
• Timetable
Sandbox of Trust is
a part of RTECO
Digital Company
Real Time Economy
for Europe

Background of Sandbox of Trust
• The Sandbox of Trust taskforce has been set up under the Realtime Economy program by
Digital Living, Nixu, Suomen Tilaajavastuu, Tieto and Teknologiateollisuus.
• This taskforce has decided to set in motion an open development program for strong
authentication (Stage 1) and authorization (Stage 2) and gives an open invite for any public
or private sector organization to join.
• The main goal of Stage 1 is to solve how to provide a strong identity for global citizens
and thus enable the fair, open and cost-efficient cross-border access to digital services.
• The taskforce is setting up the first MVP version of the Sandbox for the Finnish pilot
stakeholders, due to open in Q3/2018.

Global
• Only minor part of the population can be authenticated in real time online.
• >0,01% of world’s population has a strong identity and access to meaningful digital services
Challenges in Finland
• National trust network is in its current form is a big cost
Private sector > +100M€ in 2018
Government > 8M€ in 2018
• Banks do not have strong incentive to identify foreign customers > Private sector or
the Finnish eGovernment cannot serve them
• Mandate infrastructure is mainly missing
• Finland leads the digital society development yet the digital identities are becoming a bottle
neck for international growth in data economy

Solution - RTECO* Sandbox of Trust
• Free, open and global strong identity for every citizen offered
as an open source digital platform.
• Disruption in cost – no transaction fees for authentication.
• Key factor to speed up the digitalization of Finnish economy.
• The Sandbox consists of key building blocks for the next
generation and international private and public sector
services.
• Open source and open standards based development.
• Built on existing global passport and identity card network.
* Real Time Economy initiative by the Technology Industries of Finland
(Teknologiateollisuus)

Aim of Sandbox of Trust
• Prove that the Wallet of Identifiers and strong authentication solution can be
created with a functioning prototype
• Validate market acceptance and end user requirements for final solution through
pilots and partners
•
Develop open, scalable and future proof architecture and technology stack
•
Validate the enrolment processes for remote user onboarding internationally
•
Establish an open and cost-efficient consortium to develop, market and support the
developed strong authentication solution for the Finnish ecosystem
•
Market as part of the Finnish eGovernment success story, share open source
platform and sell expertise to other countries

In the core of IHAN
Sandbox enables IHAN goals with following features:
• Collects personal data to be shared in IHAN with strong enrolment and by
creating a digital identity, verifiable claims and IHAN number (DID) for the
person
• Creates a Wallet of Identifiers that can be easily used to authenticate the data
owner and to authorize data disclosure to third parties as an identified or
anonymous identity
• Create a solution that is usable today, but that is also future proof
• Validate the IHAN data sharing use case by running real-world pilots
• Creates a pilot environment which is available for other IHAN projects

First pilots
1. International student exchange
2. Immigration of workforce
3. Governmental landing services in
Finland

Pilot use case:
Edunation foreign
student enrolment
Pilot I

Enrolment screen
Facial recognition scan
Accepting the study place and enrolment
Passport scan
Welcome screen
Email address (OTP)
Login
Login with WeChat
Submit and accept
study place
Apply residency permit
Information screen
Congratulations! You have been
granted a study position at
Tampere University, Finland
Continue
To accept the position, you
need to identify yourself.
In case you apply for residency
permit, additional personal
background checks are done
and you need to give
fingerprints in consulate or in
bordercontrol.
Certifications scan
Pilot I

Cross-sell partner company services
Mandatory for
residency permit
Health insurance
offer
Provider: Insurance
company X
More information
Optional, for
easy onboarding
Housing request
Provider: Housing comp.
More information
Finnish Bank Account
Provider: Bank Z
More information
Flights
Provider: Air line Y
More information
Preselected flights
Open a bank account
Create rental agreement
API
Pilot I

Example of using strong authentication
on a web page
Strong authentication required
risto.tetris@foo.bar
Email address
Login
Push
notification
Kela
Risto Tetris
Pilot I

*Example by ID06 mobile authentication, similar to Sandbox of Trust authentication
Authentication example* in physical channels
Pilot I

Governmental
services
Mobility-as-a-
Service
eCommerce,
logistics,
payments etc.
Healthcare
Education,
employment
X-ROAD
People Registry
VRK
Residency database
MIGRI
KOSKI registry
Min. of Education
Kanta registry
KELA
Open Banking and logistics
ecosystems
Mobility as a Service
ecosystems
Payments, accounts, insurance
Banks and insurance providers
Housing providers
Housing
Housing ecosystem
Competence registry
Tilaajavastuu
Logistics systems
Posti
Ticket systems
MaaS operators
The Big Picture –
Exchange students life events
Identification systems
Border Control
Strong
authentication
Pilot I

Pilot use case
Immigration of
workforce in construction
and real estate industry
from Europe to Finland
and Sweden
Pilot II

Pilot use case – under preparation
Foreigner landing services to Finland
Bank
Housing
Insurance
Pilot III

Stage 1, scope and focus in
IHAN

IHAN scope
• Wallet of Identifiers
• Digital identity registration with enrolment service
• Mobile client for iOS and Android
• DKMS compliant Cloud and Edge Agent implementations
• Hyperledger Indy compliant mechanisms for issuing Verifiable Claims
• APIs
• Authorization with OpenID Connect and Verifiable Claims
• Service provider API’s with SDK and integration guide*
• Log system
• Immutable persistent log storage about access to end-user data
* Integration with other IHAN projects is in scope with SDK and integration guide
Integration support work agreed separately per case basis

Wallet of Identifiers
Authentication
- Collaboration with existing authentication
solutions and development work
- Strong authentication
- Two factor authentication
- Dezentralized authentication
- OAuth, OpenID, OpenID Connect
- Distributed Ledger Technology
- FIDO, UAF, U2F
Uniform Resource Indentifier, Uniform
Resource Locator
- IHAN number
- Data
- Credentials
Wallet
• Various authentication mechanism
• Various URI/URL of data
• Credentials
• Combination of an individual and URI of
data = IHAN number?
• Cryptography
• Interfaces, protocols, APIs

Authorization
- Content (via Enrolment, OpenID Connect userinfo and Verifiable Claims)
- Metadata structure and process
- Encryption
- PKI (DPKI)
- IKE (Internet Key Exchange)
- Chained authorization
- Protocols (OpenID Connect and Verifiable Claims)
- APIs
- Log messages

Web communication architecture, Interfaces, APIs
- Registration
- Authorization
- Data requests
- Data send, receive, (REST…)
- Service directory
- Trust domains
- Data management console
- Log (limited to user data access)
- Data transportation
- Wallet of identifiers

IHAN – Sandbox
of Trust mapping
(draft)

Project timeline, first stage 1.9.-28.3.2019
Full prototype stages 1-2, 12 months 1.9.2018-1.9.2019
Preparations:
June
• Partner engagement
& funding
Preparations:
July
• Soft-launch with pilot
cases and partners at
Suomi Areena
Stage 1:
September 2018 -
February 2019
• Build Sandbox
capabilities for strong
onboarding and
authentication
• Pilot with 2 cases
• Build strong
authentication
consortium
Stage 2:
March – August
2019
• Add capabilities for
company enrolment
and authorization
• Pilot with 2 cases
• Consortium formed
for strong
authentication
Scale-upThis pilot project

Sandbox Task Force
• Teknologiateollisuus / RTECO
• Digital Living International Oy
• Suomen Tilaajavastuu Oy
• Nixu Oyj
Contact
Pirkka Frosti
Digital Living int
pirkka.frosti@digitalliving.fi
+35850 524 5730
Joonatan Henriksson
Nixu
joonatan.henriksson@nixu.fi
+358503423472
Sami Sinisalo
Suomen Tilaajavastuu
sami.sinisalo@tilaajavastuu.fi
+358405799468
Markku Örn
Teknologiateollisuus
Markku.orn@teknologiateollisuus.fi
+358505567032

Farmidata implements these IHAN® components
Identity
Data
Consent
Services
Log
Data Source

High Level Concept • Automating/digitalizing
traditionally manual transactions
secure way.
• Business network participants are
farmer, smart fuel tank and fuel
delivery company.
• Each participants has secure
digital identity.
• Each participant create
transactions to ledger (block in
blockchain) – also smart, IoT
enabled devices create
transactions.

IBM & Wallmart ”farm-to-fork”

Hyperledger high level architecture

Analysis of the platforms for IHAN technology verification

IHAN concept in Distributed Ledger model
DataProvider
1
EndUser 2EndUser 4
DataProvider
3
Distributed
Ledger Client
Membership
service
EndUser 5
DataProvider
6
Service
provide
r
Service
provide
r
1. Peer
1
2. Peer
2
3. Peer
3
4. Peer
4
5. Peer
5
6. …
Ordering service &
Smart contracts
(Chaincode)
Transactio
n
Transactio
n
Distributed Ledger Network
Channel 1 Channel 2 Channel N
Distributed ledger
1 2
Update
Query

Public • IHAN is a digital certificate, fully
compatible with X.509 standard,
containing user name, public key,
issuer identity, validity information
and other technical details.
Compatibility with X.509 makes
IHAN compatible with Hyperledger
platform.
• Private key used for signing data
and for encryption of documents.
• Ledgers are transactions chains for
the different business networks.
• Digital IDs Wallet is a list of service
providers IDs, together with
account credentials for the service.
Digital identity entities
IHAN
Service provider IDs Wallet
Service provider ID
Account credentials for the
service
Private
Ledgers
Private key
Service provider ID
service
Service provider ID
service

Client application
IHAN and Business networks web
service
Generate IHAN and Keys
High level architecture of the IHAN-based service
Create business network
Join business network
Get list of available networks
Get list of own networks
Get proposals, endorse of
deny
Client application
IHAN
Secret key
Validate peer’s IHAN
IHAN
Secret key
Client application
IHAN
Secret key
Communication over
HTTP protocol

Business networks, IHAN-based POC application UI
1 2 3
4 5 6

Current biz model, difficulties and bottlenecks

Digital identity, certification and distributed ledger impact to the biz
processes and networks

FOR IHAN® PILOT PROJECTS WE
ARE SEEKING EITHER ALREADY
ONGOING PROJECTS OR
PROJECTS THAT ARE
READY FOR A QUICK LAUNCH.

Pilot project criteria
1. Applicants: we are particularly seeking the kind of
applicants operating in co-operation networks that
involve various actors.
2. Implementation phase of the project: we are
looking for applicants belonging to already existing
ecosystems, with whom we can advance quickly.
3. User-oriented approach: the clear aim of the pilot
project is to improve people’s everyday lives and
opportunities for the management of their own
information.
4. Technical solution: the pilot project needs to solve
technical software component issues related to
IHAN® principles, specified more closely in the
application form.
5. Effectiveness: the pilot project aims to replace the
current operating model, where an individual’s
information is dispersed in the depths of various data
storages owned by different systems and companies,
with a human-oriented and fair exchange of data.
6. Visionary approach: the pilot project is aimed at
the future and has a “novelty value”.
7. Feasibility: the applicant must have sufficient
competence and, if necessary, a functioning
subcontractor network for the development, launch
and establishment of a feasible and economically
sound solution.
8. Repeatability: the lessons learned from the pilot
project and feasible solutions should also be able to be
used in other sectors and scaled up.
9. Continuity: the application demonstrates the
applicant’s strong commitment, resources and plans
for the continuation of the operations after the project
is over.
10. Transfer of intellectual property rights: the
applicant is prepared to transfer intellectual property
rights to the extent required by the pilot project, for
example, in connection with the EU-wide workshops.
11. Other criteria: in addition to the criteria listed
above, the pilot project meets the technical and other
similar criteria to be specified in the application form.

Pilot project criteria – change in emphasis
After these first months we have "sharpened" the focus
- The criteria is the same
- It is required to implement at least one of IHAN core components
- We prefer good business cases and a client needing the overall solution

Future IHAN Governance model
How the permanent governance model will be set up in near future and how
can you participate?
Jyrki Suokas ( 15min)

Standardisation and documentation are closely
related
• If a system deploys standards in a multi participant ecosystem, standardisation will be
required to describe the system functionality
• The selected standardisation mechanism defines the structure and nature of the
documentation
• Main options
1. Regulated standardisation - using learnings from 3GPP work
2. Non – regulated standardisation – Internet standards
3. Non – regulated ICT system description e.g. SOA architecture
• Chosen direction: Regulated standardisation approach gives the most suitable starting
point for IHAN documentation structure

IHAN ecosystem Documentation description 1/2
1. Services and features
descriptions
• Verbal narratives from different
stakeholder perspectives (service
providers, data providers, end users)
• Verbal system service and system feature
descriptions with simple diagrams,
• Authorisation descriptions
• State diagrams for (smart) contracts,
• Verbal and numerical requirements for
service operation and capabilities
2. Architecture specifications
• Core reference architecture picture
(blueprint),
• Verbal component definitions,
• Message definitions
• Interface descriptions (UML or other),
• Sequence chart work flows,
• Message flow charts between Components
(scenario pictures),
• Full system stack picture,
• Interworking requirements,

IHAN ecosystem Documentation types 2/2
3. Technical specifications
• Detailed component verbal
descriptions,
• Functional requirements for the blocks
(black box),
• Protocol descriptions with message
descriptions (UML or other),
• Interworking descriptions.
4. Security specifications
• Whole architecture security and privacy
requirements,
• Security and encryption architectures,
• Algorithm definitions,
5. Testing and conformance
specifications
• Test specifications for Components,
• Performance and load testing
specifications,
• Testbed setup description,

IHAN standardisation / documentation WG’s
BSG IHAN
IHAN Business Models
TSG ISA
IHAN Services & System Aspects
TSG ICSI
IHAN Core System & Internetworking
TSG IAM
IHAN Access Mechanism
ISA WG1
Services and features
ICSI WG1
Technical specifications per component
IAM WG1
Protocols
ISA WG2
Architecture including component
definitions as a part of the architecture
ICSI WG2
Interworking with external systems
IAM WG2
Smart contracts
ISA WG3
Privacy and Security
ICSI WG3
Data transport and routing
IAM WG3
Performance and Conformance aspects and
testing
ISA WG4
Maintenance and Billing
ICSI WG4
Identity management

IHAN Business Steering Group (BSG BM)
Terms of reference
• BSG Business Models is the overall governing body.
Responsibilities
• Specification of business models
Scope
• Business models and earning log for all IHAN ecosystems
Outputs
• The outputs of this working group will be Business
requirements, or changes to these. Once approved, they
shall form the basis for the work for the whole of IHAN

Technical Steering Group IHAN Services &
System Aspects (TSG ISA)
Terms of reference
• TSG ISA reports to BSG BM
Responsibilities
• Approval of features and service specification
Scope
• • IHAN services and features high level documentation
Outputs
• The outputs of this steering group will be approved
functional and non-functional requirements for IHAN
services and features.

ISA WG1 Services
Terms of reference
• ISA WG1 reports to TSG ISA.
Responsibilities
• Specification of features.
• Specification of services
• Specification of service capabilities
• Identification of requirements to support service operation.
• Identification of requirements for service interworking.
• Identification of requirements for service interoperability
between networks.
• Billing and accounting requirements
Scope
• Service and feature requirements applicable to IHAN ecosystem for:
– Data unit connected to identity
– Access rights related to data unit - consents
– Management of these access rights
– Internal messaging and logging
– Data management
– Interworking with other systems
Outputs
• The outputs of this working group will be Technical Specifications and
Reports, or changes to these, which are all submitted to TSG ISA for
approval. Once approved, they shall form the basis for the work for the
whole of IHAN

ISA WG2 Architecture
Terms of reference
Responsibilities
• Based on the services requirements elaborated by ISA WG1,
ISA WG2 Architecture identifies the main functions and
components of the system, how these components are linked
to each other and the information they exchange
Scope
• To have a system-wide view, and decides on how new
functions integrate with the existing system components
• Definition, evolution and maintenance of the overall
architecture including the assignment of functions to
particular subsystems and associated high level functional
interactions
• In co-operation with the other TSGs, define required
services, service capabilities and bearers capabilities offered
by the different subsystems, including Quality of Service
requirements
• In addition the Architecture Working Group will consider
how to carry out the technical co-ordination and overview
role with the other TSGs
Outputs
• The output of ISA WG2 is used as architectural input by
ICSI and IAM working groups

ISA WG3 Privacy and Security
Terms of reference
Responsibilities
• ISA WG3 is responsible for security and privacy in IHAN
ecosystems, determining the security and privacy
requirements, and specifying the security architectures and
protocols.
• The WG also ensures the availability of cryptographic
algorithms which need to be part of the specifications.
Scope
• The WG will perform analysis of potential threats to IHAN
ecosystem, sub-systems and building blocks.
• Based on the threat analysis, the WG will determine the
security and privacy requirements for IHAN ecosystems, and
specify the security architectures and protocols.
• The WG will ensure the availability of any cryptographic
algorithms which need to be part of the specifications.
• The WG will accommodate, as far as is practicable, any
regional regulatory variations in security objectives and
priorities
• The WG will further accommodate, as far as is practicable,
regional regulatory requirements that are related to the
processing of personal data and privacy.
Outputs
• The output of ISA WG3 is used as security and privacy
requirement input by ICSI and IAM working groups

ISA WG4 Maintenance and Billing
Terms of reference
Responsibilities
• Defining IHAN Network management and
maintenance solutions
• Defining the Billing solutions and principles in
IHAN Network
Scope
• Specifying the requirements, architecture,
solutions and protocols for IHAN ecosystem
Maintenance, Management, and
Upgrading/Updating
• Specifying the principles, architecture, servers
and protocols for creating the IHAN ecosystem
billing solutions.
Outputs
• The output of ISA WG4 is used as requirement
input by ICSI and IAM working groups

Technical Steering Group IHAN Core
System & Internetworking (TSG ICSI)
Terms of reference
• TSG ICSI reports to BSG BM
Responsibilities
• Approval of technical specifications for IHAN components
• Approval of technical specifications for external interfaces
between IHAN and Business Service layers
• Coordination of specification work to allow Data transfer from
Data Providers to Service Providers
• Coordination of specification work within Identity management
domain
Scope
• IHAN components
• IHAN interfaces
• Data transfer from Data Providers to Service Providers
• Identity management
Outputs
technical specifications for IHAN components and
interfaces
• Approved mechanisms to transfer data and manage
identities

ICSI WG1 Component Technical
Specifications
Terms of reference
• ICSI WG1 reports to TSG ICSI.
Responsibilities
• Responsible for the IHAN specifications and
requirements that define the IHAN ecosystem modules
in details as described and identified by ISA WG2.
Scope
• Functional descriptions and requirements of all IHAN
components and modules e.g. data wallet, adapter
nodes, servers, logging subsystems etc.
• Specification of Interfaces and API’s that modules make
available to interact and interface with IHAN ecosystem
Outputs
• The output of ICSI WG1 is used to implement and
develop functional IHAN ecosystem components. IAM
WG3 creates test specifications based on ICSI WG1
deliverables.

ICSI WG2 Interworking
Terms of reference
Responsibilities
• Specifies the capabilities and scope for data
services, and the necessary interworking
functions between IHAN ecosystem and any
external network identified by ISA WG2.
Scope
• Service interworking specifications e.g. between
different IHAN ecosystem implementations.
• Gateway specifications and functionalities to
connect external networks
• QoS specifications for Interworked networks
Outputs
• The output of ICSI WG2 are used to implement
and develop the IHAN Interworking gateways
and servers.

ICSI WG3 Data Transport
Terms of reference
Responsibilities
• Specifies requirements for transferring End
Users’ Data from Data Providers to Service
Providers
Scope
• Specifications for linking data routing
information to IHAN components.
• IHAN ecosystem requirements for User Data
transport from different Data Providers to
Service Providers
• Data transport related IHAN messaging
specifications
Outputs
• The output of ICSI WG3 is used by the Data
Providers and Service Providers to establish
data transport and transfer gateways, interfaces
and tunnels and link that to IHAN Ecosystem
components and messaging.

ICSI WG4 Identity Management
Terms of reference
Responsibilities
• Responsible for development and maintenance
of specifications for Identity Management
inside IHAN ecosystem.
Scope
• Specifying different Identity Profiles inside
IHAN ecosystem
• Linking IHAN ecosystem identities to National,
third party or personal identities
• Specifying Identity management practices
inside IHAN ecosystem e.g. restoring lost access
to IHAN Service Wallet.
Outputs
• The output of ICSI WG4 is used to implement
Identity structure and hierarchy in IHAN
ecosystem and to link external Identity
Management systems to IHAN identities.

Technical Steering Group IHAN Access
Mechanism (TSG IAM)
Terms of reference
• TSG IAM reports to BSG BM
Responsibilities
• Approval of technical specifications for IHAN protocols and
smart contracts
• Approval of testing
Scope
• IHAN protocols
• IHAN smart contracts
• Performance and Conformance aspects and testing of whole
IHAN ecosystem
Outputs
technical specifications for IHAN protocols and smart
contracts

IAM WG1 Protocols
Terms of reference
• IAM WG1 reports to IHAN TSG IAM.
Responsibilities
• Responsible of the IHAN ecosystem Core protocols
selection, definition and development that also provide
scalability and security of the system.
Scope
• Specifications of protocols implementing Identity
management profiles as defined by ICSI WG4
• Specifications of permission control and logging
protocols.
• Specifications of IHAN ecosystem Messaging and
Metadata routing protocols.
• Specifations Smart Contract protocols as defined by
IAM WG2
• Other relevant protocol specifications
Outputs
• The output of IAM WG1 is used to create SW that will be
deployed while developing IHAN ecosystem
components.

IAM WG2 Smart Contracts
Terms of reference
• IAM WG2 reports to TSG IAM.
Responsibilities
• Responsible of specifying the Contract
Structures that define the Data Processing
permission states within IHAN ecosystem
Scope
• Specification of roles of individuals and Service
/ Data providers in IHAN ecosystem.
• Specification of permission statuses relating to
data processing rights in IHAN ecosystem.
• Linking the roles and permission statuses to
specify flow chart descriptions of state diagrams
of different allowed contractual situations in
IHAN ecosystem.
Outputs
• The output of IAM WG2 is used as a
requirement input by other ICSI and IAM
working groups.

IAM WG3 Performance, Conformance and
Testing
Terms of reference
• IAM WG3 reports to TSG IAM.
Responsibilities
• Responsible of creating Performance and Conformance
testing specifications.
• Responsible of creating Test System definitions and
specifications.
Scope
• Conformance test case and setup descriptions and
specifications for IHAN ecosystem and components and
modules
• Performance test case and setup descriptions and
specifications for IHAN ecosystem and components and
modules.
• Specifications describing Test Network parameters and
configuration that can be run parallel without
interfering the main IHAN ecosystem.
Outputs
• The output of ISA WG3 is used to create a test
environment for IHAN ecosystem components
development and new IHAN ecosystem features testing
and development before entering the main IHAN
ecosystem environment.

Questions and Answers
Everybody ( 25min)

[26.9.2018 9.01] Vladimir Kuparinen:
Often Services can be used without Identification of User.
Example: payment for transportation of a person from point A to point B, Service provider: HSL.
Could IHAN be applied to Authentication of Right-to-Service instead of Identification of User?
The service that my startup develops is distribution of (IHAN) access to each household, with incentives - for mass engagement. Is it in scope of IHAN project,
may I apply?
[26.9.2018 9.21] Andres Kütt:
What are the ambitions of IHAN in terms of establishing standards for interoperability of the data sharing ecosystem?
[26.9.2018 9.28] Andres Kütt:
What is the relationship between IHAN and an underlying transport layer? For example, X-Road already provides logging and participant identity
(the latter is missing from the setup depicted AFAICS)
[26.9.2018 9.35] Aapo Rista (Forum Virium):
Someone should implement IHAN API validators, so service and data providers can ensure their API implementations fit the specification.
[26.9.2018 9.40] Hyyrönmäki Jyrki:
Aapo, that should be built in to the technical ecosystem. Then service providers don't need to worry about it. This is how we have seen it.
[26.9.2018 9.42] Andres Kütt:
Who takes care of the service provider and data provider identities?
[26.9.2018 9.42] Hyyrönmäki Jyrki:
There need to be a service in the ecosystem which offers identities.

[26.9.2018 9.43] Artur Novek (TEHIK, Estonia):
Certification authorities?
[26.9.2018 9.45] Janek Metsallik (TTÜ):
@Artur. Businesses or services registry should come first, then certification for digital authentity. Like Business Reg or State Information System Reg in EE.
[26.9.2018 9.46] Andres Kütt:
@Janek if this is to be global, we need a better idea
[26.9.2018 9.45] Andres Kütt:
What if the Data Source specific credentials are hardware- or cryptography-based?
[26.9.2018 9.47] Shimono, Akio/下野暁生:
DID (Decentralized Identity) can be a candidate for starndardized universal identifier.
[26.9.2018 9.48] Janek Metsallik (TTÜ):
One can trust multiple registries. Exactly.
[26.9.2018 9.48] Andres Kütt:
@Janek @Artur: having personal service directory a separate entity from the Consent Provider is a good idea
[26.9.2018 9.48] Andres Kütt:
In our heads, it lived within the CP
[26.9.2018 9.50] Jenni Krohn:
Global GS1 system can be used to identify providers
[26.9.2018 9.51] Andres Kütt:
In that case we must set requirements towards the transport layer as to the extent to which the endpoints are tied to their GS1 identities

Shimono, Akio, DID and also maybe Right-to-Service Authenticators (not IDentificator, i.e. for anonymous Users) can serve to mark the Services Access Acts
Revocation status must be synchronized!
[26.9.2018 9.58] Andres Kütt:
How do we envision doing the immutability part?
By protocolling the logs at DL, like IOTA or blockchain
DL=Distributed Ledger (immutable by design)
[26.9.2018 10.01] Andres Kütt:
Well, DL does provide a very specific set of immutability guarantees.
[26.9.2018 10.01] Juuso:
Can data flow also between Service Providers (SP)? If e.g. SP 1 produces enriched data, that would be useful for SP 2?
[26.9.2018 10.09] Jaakko Riihinen:
At this point, is there any end-to-end use cases and corresponding sequence diagrams showing the system behavior?
There's a real case similar to IBM (shown at previous slide), by UpCode, Vaasa, Finland/VTT, Finland/TagItSmart:
TagItWine, from Montenegro to China/ Digital beer in Vaasa https://bit.ly/2DEZ5Cq
Jaakko Riihinen, two real end-to-end use cases, with diagrams: TagItSmart (TagItWine; Digital Beer, Vaasa)
https://www.tagitsmart.eu/usecase

How in this implementation the physical person real world identity is connected to digital identity? Can I take the certificate on the name of Juha Sipilä?
Imo the "physical person real world identity" doesn't exist yet globally, only local nation countries use local ID's. And these local ID's can be authenticated,
tokenized as DID's
I mean that physical passports are not assigned with digital ID's globally. Yet
[26.9.2018 10.38] Alexey Razin:
Atrur, you may, of course. Bring your Juha Sipilä passport to Certified Authority, and they will give you digital identity that you are Juha Sipilä .
[26.9.2018 10.39] Andres Kütt:
eIDAS does this at least within EU - you can get a digitally confirmed identifier for citizens of most EU countries
Alexey, Artur wishes to identify Juha without Juha's previous action, I presume. Otherwise Andres is right: eIDAS in EU
[26.9.2018 10.44] Teemu Karvonen:
eIDAS has its challenges too and needs a solution like IHAN to harmonize identities
I am more interested in Authentications of Right-to-Service for a certain person, i.e. not in IDentification. IDentification will be solved by IHAN partners soon.
But more interesting is to invite people to use Right-to-Service without IDentification (that is vulnerable / danger for privacy)
[26.9.2018 10.48] Andres Kütt:
This is the same consent problem this project seeks to solve. I can authorise my computer to access my data similarly to how I can authorise a startup to
access the same data

[26.9.2018 11.04] Andres Kütt:
Sorry for the stupid question, what does DID stand for in this context?
Isn't this related to Sovrin ? It looks like an decentralized identity attempt based on Hyperledger Indy, which reminds me of Sovrin https://sovrin.org/
[26.9.2018 11.05] Alexey Razin:
Digital ID (DID). Refer to the Hyperledger terminology (Hyperledger.org)
Yes, he told about TrustNet, and Sovrin is part of it
[26.9.2018 11.05] Andres Kütt:
Thanks, Alexey
[26.9.2018 11.06] Juan V. Durá (IBV - Spain):
Have you defined a structure/formats for the consent directory?
DID means Decentralised Identities, see Sovrin/TrustNet for more info
[26.9.2018 11.07] Andres Kütt:
@Juan, I have done an exercise on this

@Juan, video about Finnish solution on Consents: https://www.youtube.com/watch?time_continue=16&v=_bwXwnNaiZ8
@Andres, If possible, I would like to see your exercise about consents
Thanks @Vladimir
Finnish Solution I meant Kantara (at this youtube)
[26.9.2018 11.12] Sami Sinisalo:
MyData pilot with Trafi: https://www.muntiedot.fi/en
[26.9.2018 11.12] Andres Kütt:
Juan, please drop me an e-mail at andres@kytt.org, will share
[26.9.2018 11.14] Antti Kettunen (Tieto):
DIDs are a soon-to-be W3C specification: https://w3c-ccg.github.io/did-spec/
Even though it's spearheaded by Hyperledger Indy/Sovrin, it's also used by UPort, VeresOne and other similar DLT-solutions.
However, it is not restricted to Decentralized systems, but can be used by centralized ones as well.
@Juan, there is more info about MyData solutions (for Consents also) shown at August MyData2018 conference https://mydata2018.org/presentations/
We saved this conversation. You'll see it soon in the Conversations tab in Skype for Business and in the Conversation History folder in Outlook.
Thanks @Vladimir, @Alexey.
Thanks @Vladimir. I was present in Mydata2018. But the presentations are about concepts. Highl level. I am looking for more datails and practical exaamples.
[26.9.2018 11.19] Andres Kütt:
Same here @Juan. Get in touch, let’s talk details.
@Juan, more about real cases Consents: https://mydata2018.org/sessions/consent-in-action/
We saved this conversation. You'll see it soon in the Conversations tab in Skype for Business and in the Conversation History folder in Outlook.
Same here (present at Mydata2018) ^^)
Yes, DTP is something we probably need to check out.
Current collected user data is connected to already existing identifiers of a person. Probably we need more the secure way how to connect those existing identifiers than a new identifier.

[26.9.2018 11.29] Andres Kütt:
Consent Provider
[26.9.2018 11.30] Andres Kütt:
We have had previous discussions with Janek and Artur, sorry for not being transparent onthis
[[26.9.2018 11.31] Andres Kütt:
Thank you, will be looking forward to participating in some of the WGs
[26.9.2018 11.36] Bo Harald:
We had 100,9 million e-ID transaction in Finnish public-private space last year. With the upgrades being worked on this will be the first step into Sovrin-like global to
China had 100+ e-ID (WeChat, AliPay) mobile transactions in 2017. Though they were not GDPR conform.
Sorry China: 100+ BILLION e-ID transactions in 2017

Next Steps
What will happen next?
Jyrki Suokas ( 5min)

CEN-CENELEC Workshop
- Sitra will host together with Finland Standard Association SFS a workshop during 2019
- A face-to-face kick-off meeting will be held on the 21st of January 2019 in Helsinki in
Sitra's facilities
- The kick-off meeting and further meetings in the workshop will be open for all
participants who accept the general terms and conditions by CEN-CENELEC
- The workshop will concentrate on three work sreams:
– Work stream 1: Data identifiers
– Work stream 2: Consent management
– Work stream 3: Distributed log system
- The final output of the workshop is a CWA document (CEN-CENELEC Workshop
Agreement) which is a public document and will be published in the CEN-CENELEC
website

Timeline
10/2018 11/2018 12/2018 01/2019 02/2019
Standardization
kickoff 21.1
Farmidata pilot
readyIHAN Webinar 3
SoT first
components
IHAN
permanent
governance
model in place

Making
people’s life
easier, smarter
and happier!

180926 ihan webinar 2

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a 180926 ihan webinar 2

Semelhante a 180926 ihan webinar 2 (20)

Mais de Sitra the Finnish Innovation Fund

Mais de Sitra the Finnish Innovation Fund (20)

Último

Último (20)

180926 ihan webinar 2