Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

180926 ihan webinar 2

530 views

Published on

IHAN® Human-Driven Data Economy technical webinar on 26th September

Published in: Data & Analytics
  • Just got my check for $500, Sometimes people don't believe me when I tell them about how much you can make taking paid surveys online... So I took a video of myself actually getting paid $500 for paid surveys to finally set the record straight. I'm not going to leave this video up for long, so check it out now before I take it down! ■■■ http://ishbv.com/surveys6/pdf
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • You can now be your own boss and get yourself a very generous daily income. START FREE... http://ishbv.com/surveys6/pdf
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • A Penis Growth Program With Actual Video Proof That It Works! REAL Growth With Video Proof, You Can't Fake These Enlargement Results...  http://ishbv.com/pebible/pdf
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Discover the secrets to getting a bigger penis naturally with this 100% free. ★★★ https://tinyurl.com/yaygh4xh
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • You can now be your own boss and get yourself a very generous daily income. START FREE...★★★ http://ishbv.com/surveys6/pdf
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

180926 ihan webinar 2

  1. 1. 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
  2. 2. TECHNICAL CONTACT Jyrki Suokas: jyrki.suokas@sitra.fi +358 (294) 618 497 Juhani Luoma-Kyyny: juhani.luoma-kyyny@sitra.fi +358 (294) 618 274
  3. 3. 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
  4. 4. What is the IHAN® project on human-driven data economy about? Jyrki Suokas (15min)
  5. 5. 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
  6. 6. Data economy entities, Person Business Government P2P B2B B2P G2P G2B G2G Identity data flows and foundation
  7. 7. 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
  8. 8. 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
  9. 9. 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? €/£/$/¥ €/£/$/¥
  10. 10. 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? €/£/$/¥ €/£/$/¥
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. IHAN® technical specifications How does IHAN® architecture and technology principles look like? Jyrki Suokas & Juhani Luoma-Kyyny (60 min)
  15. 15. IHAN® in a nutshell Service DataAuthorization to use my data Service provider Requests for data Data providers
  16. 16. 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
  17. 17. IHAN® Services components End User Service Provider Data Provider 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
  18. 18. Deployment view: Embedded IHAN® Services User Interface Public Service Directory Personal Service Directory Service Provider Service Directory Personal Identity Wallet 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” Outbound Data Adapter 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
  19. 19. 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
  20. 20. 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.
  21. 21. 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
  22. 22. 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.
  23. 23. 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.
  24. 24. 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.
  25. 25. 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.
  26. 26. Component view
  27. 27. 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
  28. 28. Personal Identity Wallet (2/3) 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.
  29. 29. Personal Identity Wallet (3/3) 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.
  30. 30. 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.
  31. 31. 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.
  32. 32. 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.
  33. 33. 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
  34. 34. Public Service Directory 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
  35. 35. Service Provider Service Directory Level: Service Provider 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
  36. 36. Service Provider Consent Directory Level: Service Provider 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.
  37. 37. Inbound Data Adapter Level: Service Provider 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.
  38. 38. Service Provider Log Level: Service Provider 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
  39. 39. 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.
  40. 40. Outbound Data Adapter Level: Data Provider 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.
  41. 41. Data Access Control Level: Data Provider 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
  42. 42. Data Provider Log Level: Data Provider 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
  43. 43. 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)
  44. 44. 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
  45. 45. IHAN® technical component documentation End User Service Provider Data Provider 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
  46. 46. Pilot Project 1 creates initial components and services End User Service Provider Data Provider 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
  47. 47. Pilot Project 2 adds new and creates alternative components. More IHAN® services added End User Service Provider Data Provider 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 Personal Identity Wallet Personal Log Data Source
  48. 48. Pilot Project 3 adds yet new components. More services to IHAN® layer End User Service Provider Data Provider 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 DirectoryPersonal Consent Directory Personal Log Data Provider LogService Provider Log Personal Identity Wallet Personal Log Data Access Control Data Access Control Data Source
  49. 49. Pilot Project n adds new and creates alternative components. IHAN® Service layer complete End User Service Provider Data Provider Identity Data Consent Services Log Personal Identity Wallet Public Service Directory Personal Service Directory Service Provider Service Directory End User Data Directory Outbound Data AdapterInbound Data Adapter Service Provider Consent DirectoryPersonal Consent Directory Personal Log Data Provider LogService Provider Log Personal Identity Wallet Personal Log Outbound Data AdapterInbound Data Adapter Data Access Control Data Access Control Data Source
  50. 50. IHAN® architecture implementations Collection of IHAN reference architectures
  51. 51. SANDBOX OF TRUST
  52. 52. SoT implements these IHAN® components End User Service Provider Data Provider 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
  53. 53. 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
  54. 54. 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.
  55. 55. 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
  56. 56. 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)
  57. 57. 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
  58. 58. 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
  59. 59. First pilots 1. International student exchange 2. Immigration of workforce 3. Governmental landing services in Finland
  60. 60. Pilot use case: Edunation foreign student enrolment Pilot I
  61. 61. 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
  62. 62. 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
  63. 63. 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
  64. 64. *Example by ID06 mobile authentication, similar to Sandbox of Trust authentication Authentication example* in physical channels Pilot I
  65. 65. 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
  66. 66. Pilot use case Immigration of workforce in construction and real estate industry from Europe to Finland and Sweden Pilot II
  67. 67. Pilot use case – under preparation Foreigner landing services to Finland Bank Housing Insurance Pilot III
  68. 68. Stage 1, scope and focus in IHAN
  69. 69. Stage 1 (MVP) architecture
  70. 70. 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
  71. 71. 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
  72. 72. 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
  73. 73. 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
  74. 74. IHAN – Sandbox of Trust mapping (draft)
  75. 75. Edunation use case (draft)
  76. 76. 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
  77. 77. 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
  78. 78. FARMIDATA
  79. 79. Farmidata implements these IHAN® components End User Service Provider Data Provider 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
  80. 80. 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.
  81. 81. IBM & Wallmart ”farm-to-fork”
  82. 82. Hyperledger high level architecture
  83. 83. Analysis of the platforms for IHAN technology verification
  84. 84. 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
  85. 85. 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 Account credentials for the service Service provider ID Account credentials for the service
  86. 86. 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
  87. 87. Business networks, IHAN-based POC application UI 1 2 3 4 5 6
  88. 88. Current biz model, difficulties and bottlenecks
  89. 89. Digital identity, certification and distributed ledger impact to the biz processes and networks
  90. 90. FOR IHAN® PILOT PROJECTS WE ARE SEEKING EITHER ALREADY ONGOING PROJECTS OR PROJECTS THAT ARE READY FOR A QUICK LAUNCH.
  91. 91. 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.
  92. 92. 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
  93. 93. MORE INFO: WWW.SITRA.FI/IHAN
  94. 94. Future IHAN Governance model How the permanent governance model will be set up in near future and how can you participate? Jyrki Suokas ( 15min)
  95. 95. 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
  96. 96. 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,
  97. 97. 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,
  98. 98. 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
  99. 99. 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
  100. 100. 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.
  101. 101. 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
  102. 102. ISA WG2 Architecture Terms of reference • ISA WG2 reports to TSG ISA. 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
  103. 103. ISA WG3 Privacy and Security Terms of reference • ISA WG3 reports to TSG ISA. 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
  104. 104. ISA WG4 Maintenance and Billing Terms of reference • ISA WG4 reports to TSG ISA. 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
  105. 105. 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 • The outputs of this steering group will be approved technical specifications for IHAN components and interfaces • Approved mechanisms to transfer data and manage identities
  106. 106. 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.
  107. 107. ICSI WG2 Interworking Terms of reference • ICSI WG2 reports to TSG ICSI. 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.
  108. 108. ICSI WG3 Data Transport Terms of reference • ICSI WG3 reports to TSG ICSI. 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.
  109. 109. ICSI WG4 Identity Management Terms of reference • ICSI WG4 reports to TSG ICSI. 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.
  110. 110. 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 • The outputs of this steering group will be approved technical specifications for IHAN protocols and smart contracts
  111. 111. 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.
  112. 112. 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.
  113. 113. 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.
  114. 114. Questions and Answers Everybody ( 25min)
  115. 115. [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? [26.9.2018 9.05] Vladimir Kuparinen: 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.
  116. 116. [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
  117. 117. [26.9.2018 9.53] Vladimir Kuparinen: 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 [26.9.2018 9.56] Artur Novek (TEHIK, Estonia): Revocation status must be synchronized! [26.9.2018 9.58] Andres Kütt: How do we envision doing the immutability part? [26.9.2018 9.59] Vladimir Kuparinen: By protocolling the logs at DL, like IOTA or blockchain [26.9.2018 10.00] Vladimir Kuparinen: 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? [26.9.2018 10.18] Vladimir Kuparinen: 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 [26.9.2018 10.25] Vladimir Kuparinen: Jaakko Riihinen, two real end-to-end use cases, with diagrams: TagItSmart (TagItWine; Digital Beer, Vaasa) https://www.tagitsmart.eu/usecase
  118. 118. [26.9.2018 10.34] Artur Novek (TEHIK, Estonia): 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ä? [26.9.2018 10.36] Vladimir Kuparinen: 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 [26.9.2018 10.38] Vladimir Kuparinen: 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 [26.9.2018 10.40] Vladimir Kuparinen: 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 [26.9.2018 10.46] Vladimir Kuparinen: 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
  119. 119. [26.9.2018 11.04] Andres Kütt: Sorry for the stupid question, what does DID stand for in this context? [26.9.2018 11.04] Shimono, Akio/下野 暁生: 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) [26.9.2018 11.05] Vladimir Kuparinen: 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? [26.9.2018 11.06] Vladimir Kuparinen: 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
  120. 120. [26.9.2018 11.09] Vladimir Kuparinen: @Juan, video about Finnish solution on Consents: https://www.youtube.com/watch?time_continue=16&v=_bwXwnNaiZ8 [26.9.2018 11.10] Juan V. Durá (IBV - Spain): @Andres, If possible, I would like to see your exercise about consents [26.9.2018 11.10] Juan V. Durá (IBV - Spain): Thanks @Vladimir [26.9.2018 11.10] Vladimir Kuparinen: 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. [26.9.2018 11.14] Vladimir Kuparinen: @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. [26.9.2018 11.16] Shimono, Akio/下野 暁生: Thanks @Vladimir, @Alexey. [26.9.2018 11.17] Juan V. Durá (IBV - Spain): 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. [26.9.2018 11.19] Vladimir Kuparinen: @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. [26.9.2018 11.19] Shimono, Akio/下野 暁生: Same here (present at Mydata2018) ^^) [26.9.2018 11.21] Shimono, Akio/下野 暁生: Yes, DTP is something we probably need to check out. [26.9.2018 11.22] Artur Novek (TEHIK, Estonia): 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.
  121. 121. [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 [26.9.2018 11.39] Vladimir Kuparinen: China had 100+ e-ID (WeChat, AliPay) mobile transactions in 2017. Though they were not GDPR conform. [26.9.2018 11.39] Vladimir Kuparinen: Sorry China: 100+ BILLION e-ID transactions in 2017
  122. 122. Next Steps What will happen next? Jyrki Suokas ( 5min)
  123. 123. 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
  124. 124. 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
  125. 125. Making people’s life easier, smarter and happier!

×