Recomendados
Mais conteúdo relacionado
Semelhante a MyDataに関連する技術やシステム - OSS PDS Personium紹介を中心に -
Semelhante a MyDataに関連する技術やシステム - OSS PDS Personium紹介を中心に - (20)
MyDataに関連する技術やシステム - OSS PDS Personium紹介を中心に -
- 1. Open Knowledge Japan 下野 暁生 MyDataに関連する技術やシステム - OSS PDS Personium 紹介を中心に -
- 2. MyDataに関連する技術やシステム • PDS (Personal Data Store) • 情報銀行 / 情報信託 • Open ID Connect • UMA (User Managed Access) 参考： PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど) https://www.slideshare.net/tkudo/pds-oauth-openid-connect-uma
- 3. PDS (Personal Data Store) パーソナルデータストア = 人間中心ICTを実現するための個人用データストア 人間中心ICTシステム中心 ICT 病院 自治体 ECサイト 保険会社 私のデータ はバラバラ 保険 会社自治体 EC サイト 病院 これなら管理できる Data Data Data Data PDS 何がどこにあるか 管理できない システムは課題解決等 関心事に作られる 結果、利用者データは バラバラのサイロの中 皆が自分のデータ置き場をもち サービスがここに読み書き 自身の意思でサービスの垣根 を超えてデータを自由に活用 データ格納・本人認証に加え、自己情報コント―ロル・第三者アクセス制御・同意記録等の機能が求められる。
- 5. データ流通のハブとしてのPDS PDSは実名で情報開示する仕掛け。大量の人数の匿名・統計処理されたBig Dataと対比して、PDSが扱うデータ は個人のあらゆる分野横断的データであり、Deep Data と呼ばれる 従来：BigData型のデータ利活用 提供 企業 顧客 データ個人 匿 名 ・ 統 計 加 工 企業 企業 企業 提供 提供 提供 × PDS型のデータ利活用 PDS 個人 企業 企業 企業 企業 企業 企業 顧客 データ 顧客 データ 顧客 データ 返還 匿名であるため データ提供した個人に提供対価を 直接還元できない 情報提供の制御を個人に返すことで ユーザの自己意思で個人を特定して提供できる ⇒個人への直接還元が可能 クーポン・ポイント 特別サービス等の インセンティブ 提供元企業への還元も可能
- 7. GDPR（EU一般データ保護規則） • 2016/4欧州議会で成立、2018/5から施行決定 • データ保護規則改正の主なポイント*1 • 忘れられる権利 a right to be forgotten • より簡易なデータアクセス easier access to one’s data • データポータビリティ a right to data portability • データ漏洩の通知 the right to know when one’s data has been hacked • プロファイリング拒否権 right not to be subject to a measure based on profiling. • 設計＆デフォルトによるデータ保護 data protection by design and by default • より強いルールの強制： Stronger enforcement of the rules • データ保護規則改正の目的 • 市民視点 プライバシー権（自己情報コントロール）の強化と信頼の構築 • gaining control of one‘s personal data、will strengthen citizens' rights and build trust • 経済視点 Digital Single Market の実現 (→€415billion/年の経済効果） • 中小企業(SMEs)を含むEU企業にデジタル市場への参入障壁をなくすことで経済を拡大する 注１） 2015/12/21 Q&A Data protection reform http://europa.eu/rapid/press-release_MEMO-15-6385_en.htm 欧州議会議長（2012～2017/1） マーティン・シュルツ 7 米国パーソナルデータ寡占企業 と戦うための戦略であるとほぼ明言
- 8. Services need to give back user data in a machine readable way. (most probably in the form of Web API) Insight for service providers: Competitors may acquire the collected data via user. But it is the same for competitors, too. GDPR Data portability Roughly speaking, GDPR requires a service to provide its users with • More security • More privacy ServiceService User User Data Upon user’s request, collected user data should be given back to the user or ported to another service 8 rival • Data portability
- 9. Opportunity brought by “Data Portability” Buyma.com Uber w/o Data Portability Facebook Airbnb Your Service Amazon.com PD PD PD PD PD PD Your Customer Customer’s data are enclosed within each service he/she uses. 9 + Use of PDS By putting PDS. his/her machine- readable data from varieties of services can be aggregated and integrated in it. Question is “Who should be the PDS provider?” Facebook Buyma.com Uber Airbnb Amazon.com PD PD PD PD PD PD Your Customer Your Service PDS Customer’s data from all services he/she uses will be available in a machine readable way With it alone, your “non-machine” customer can not enjoy any benefit from it though. w/ Data Portability Facebook Buyma.com Uber Airbnb Amazon.com PD PD PD PD PD PD Your Customer Your Service
- 10. Personiumとは http://personium.io/ 現在富士通で開発、公開、順次改版リリース中。 ただし、中立かつオープンなプロジェクト運営を目指して います。 Ｇithubにて公開中 ライセンスはApache License 2.0 クライアントライブラリ・ＧＵＩ・ツール等もあわせ て公開 Linux OSのマシンにインストールするとPDSサーバになります。 立てたPDSサーバ上には好きなだけPDSを作成してホストすることができます。 https://github.com/personium/ オープンソースの分散(Decentralized) PDSサーバです。
- 11. PDSの基本要件 • PDSとしての機能要請 1. 個人ごとにデータを格納できる 2. データのオーナーが、自由に開示・非開示を設定できる（自己情報コントロール） 仕様を考慮する上の観点 1. データ格納の観点 • データをどう格納するか？（インターフェース、論理構造） • データを読み書きする端末に適したプロトコルや仕組みは？ 2. 自己情報コントロール（アクセス制御）の観点 • データを共有したい他者をPDSにどう定義する？ • 格納したデータごと・開示対象者ごとのアクセス制御をどうやる？ 開示 非開示 PDS データ所有者 家族 友達1.データ格納 2.自己情報コントロール （アクセス制御） 11
- 12. (1)データ格納の要件 • 観点 • データをどう格納するか？（インターフェース、論理構造） • データを読み書きする端末に適したプロトコルや仕組みは？ • 要件 • データ操作：登録・取得・更新・削除、検索ができること • データ形式：用途に依存せず様々なアプリ（食事ログ、カルテ、フォトブックetc…）で共通的に利用可能であること、 アプリ毎に構造を定義できる自由度が必要 • クライアント端末：多様な端末（Windows/Android/iOSなど）から呼び出せること • クライアント・クラウドモデル：アプリケーションのバックエンドとして単独で成立すること ユーザーが利用する端末のアプリ PDS アプリのバックエンドサーバー PDS ユーザーが利用する端末のアプリ 本当に使いやすい？ 複雑では？ 個人のデータを抽出 シンプルな構成が可能 12
- 13. 1) Personium PDSのデータ格納 • REST API • ブラウザ・iOS・Android・Ｗindows … HTTPを話せないプラットフォー ムはない。 • PDSの全機能をREST APIとして提供することで、プラットフォームやアプ リ形態を選ばず、あらゆるところからの読み書きを可能とする。 • 具体的RESTベース標準規格：WebDAV, OData • ディレクトリツリー型ファイルシステム、リレーショナルデータ（テーブル・カラ ム）の両方のデータに対応 13 リレーショナルデータをRESTful に扱うための、OASIS標準イン ターフェース マイクロソフト社が中心となって 標準化されているため、MS系の 技術との相性が良いがあらゆる プラットフォームで利用可能 OData WebDAV ディレクトリ構造を持ったファイ ルシステムをHTTPで操作するため のIETF標準 RFC4918( HTTP Extensions for WebDAV)および3744(WebDAV ACL)で規定
- 14. 1) Personium PDSのデータ格納 14 per App Data Store ユーさ認証 アプリ認証 per App Data Store ・・・ 他のアプリの領域にはユーザ認可 を得ないとアクセスできない。 利用者 ＰＤＳ 正規の アプリ 悪意を 持った アプリ ×誘導 正規の アプリ以外を ブロック 利用者 攻撃者 アプリ認証 悪意のアプリや、アプリの不具合などで、正規アプリのデータが破壊されては困る ■データ破壊をするアプリに対する防衛
- 15. (2)自己情報コントロールの要件 • 観点 • データを共有したい他者を自身のPDS上でどう定義する？ • 格納したデータごと・開示対象者ごとのアクセス制御をどうやる？ • 要件 • 認証：オーナー・ビジター・アプリを適切に認証できること • アクセス制御：オーナーがデータ毎・公開相手毎に適切な権限（Read/Write）を付与できる自由度と、設定の 複雑性爆発回避を両立する工夫が必要 • 設定：上記を設定するためのインターフェースがあること ビジターCNG PDS オーナー ビジターA ビジターB アクセス制御 設定情報 データ取得 アクセス制御 ・写真は、ビジターAだけに公開 ・健康ログは、ビジターCだけに公開 OK NG データ取得 データ取得 … 15
- 16. (2)Personium PDSの自己情報コントロール • 全てのPDSがビジターごとにアカウントを作ると、アカウントの爆発が起こる ⇒自分のPDSで認証して、そこを経由して他のPDSにアクセスするモデルを採用し解決 • オープンなシステムにおいては、悪意のあるアプリへの対策が必須 ⇒アプリケーションを認証し、特定のアプリケーション以外にはデータを渡さない • アクセス制御の複雑性を回避するため ロールベースアクセス制御 • ビジターにもロールを発行する • 相手先との関係（友達、所属組織etc）に応じた、自動ロール発行 PDS オーナー ビジターA ビジターB アクセス制御 ビジターのロール 等 設定情報 データ取得 自分のPDSで認証ロール ・ビジターA:家族 ・ビジターB、C：友達 アクセス制御 ・データは家族だけに公開 OK NG データ取得 データ取得 16
- 17. Personium PDSの機能概要（まとめ） データ格納 REST API：多端末・多アプリで全機能利用可能 アプリ毎データ領域：アプリ間のデータ干渉排除、フィッシングアプリからの保護 ファイルシステム/リレーショナル両モデルに対応した無色なデータ格納機構：アプリケーションの多様性を妨げない自由度を保証 OData：テーブル/カラム型のリレーショナルデータのCRUD操作・検索 WebDAV：ディレクトリツリー型のファイルシステムのCRUD操作 自己情報コントロール 認証： OAuth2.0の認証エンドポイントで、オーナー・ビジター・アプリを認証してトークン発行 ロール発行設定：設定エンドポイント(/__ctl)で、ビジターにどのようなロールを発行するか設定 ロールベースアクセス制御：すべてのデータアクセスと設定のエンドポイントに対して、どのロールにどの操作を許すか設定可能 （WebDAV ACL） 認証 アクセス制御 PDS設定 REST API データ格納 CさんのPDS Personium サーバー AさんのPDS BさんのPDS DさんのPDS 多端末 多アプリケーション （モバイル・システム・Web） HTTP(S) 認証エンドポイン ト 設定エンドポイン ト アプリ毎データ領域 一般利用者 PD保有者 サービス事業者 etc 17
- 18. 実社会での関係性に基づくデータアクセス制御 • 実社会での関係性（ソーシャルグラフ）をPDSの設定として定義し、他者にロールを割当てること で、通常のロールベースアクセス制御(RBAC)にて他者へのデータの開示/秘匿の制御が可能 利用者AのPDS アカウント: A（ロール: 生徒） 外部セル: BのURL（ロール：先生） 利用者BのPDS SAML2 アサーション データ読込/編集 が可能 ロールベースアクセス制御設定 生徒：権限なし 先生：Read・Write権限 Bとして 認証 アカウント: B（ロール: 先生） 外部セル: AのURL（ロール：生徒） ロールベースアクセス制御設定 生徒：Read権限 先生：Read・Write権限 例）他PDSへのアクセス権の付与（教育アプリの成績処理） Aとして 認証 ×データ読込不可 アプリ アプリ ⇒上記の設定では、Aでログインしたユーザ（生徒）はBの情報にアクセスできないが、 Bでログインしたユーザ（先生）はAの情報のRead/Writeが可能 18
- 19. PDSの拡張：データ主体は人だけなのか？ 人や組織、モノ、コトなどに対応するP?DSをクラウド上 に配置し、それをDecentralizdソーシャルグラフで結ぶことで マクロに社会全体を支えるICTになりうる 19 人だけでなく、組織、モノ、コトもデータ主体になり得るならば、それらにもPDSを ＰＤＳをつくりたい ↓ データ主体を中心とした コンピューティングモデルを実現したい Decentralized Network なぜオープンソースなのか？ Web of Data APIをつくりたいから ■受動的データ主体： 幼児・寝たきりの老人など、データ主体でありながら、親や家族にデータ制御権限を移譲 ■組織：冷蔵庫の中身は私のものというよりは家族のもの。法人という言葉もある。
- 20. Personiumの特長(1/2) • 誰でもPDSサーバを立てられる • オープンソースソフトウェアであるため、事業者/自治体/政府/個人等誰でもPDSプロバイダになれる。 • 全機能がREST API • HTTPはどんなプラットフォーム（OS, 開発言語）扱えるため、クライアントのプラットフォームを選ばない。 • データ開示・共有設定は相手PDSのURLを指定（本日デモ予定） • PersoniumのPDSにはみなURLが与えられる。 • 他者(例： 妻、かかりつけ医、勤務先 etc.)へのデータ開示・共有は相手PDSのURLを指定して行う。 他者PDSアクセスには電子署名技術を利用しており、相手は別サーバであってもよい。 • 受動的データ主体：幼児・高齢者などは、親族等に全データの全権限を許可することでPDSの運用移譲が可 能 能動的 データ主体 私のかかり つけ医 私の患者 私の食事ログや 運動ログを先生 にはお見せしよう。 息子 パパ 受動的 データ主体 大きくなるまでは、 私が管理しよう 全データ、全操作を 両親に許可設定 20
- 21. Personiumの特長(2/2) • Web of PDSを構成可能 • データ開示・被開示という関係で結ばれたPDS群は、特定の事業者が胴元（⇒ 一人勝ち）になるのではない中心を持たないDecentralizedなネット ワークを構成 （分散ソーシャルグラフ） • バラバラにたてられたWebサーバにホストされたWebサイトがリンクしあってWWＷができたように、バラバラに立てられたPDSがリンクし合った巨大なWeb of PDSを形成可能。 • オープンなエコシステム形成に必要となるセキュリティも実装 • データ主体（⇒PDSオーナ）を人に限らず、モノ・組織などに拡張可能 • 受動的データ主体を扱う要領でデータ主体をモノや組織などにも拡張可能（例、家族/犬のポチのデータストア） • IoM, IoT, IoE を統合的に扱うモデルを標榜（Cyber-Physical） 21
- 22. Unit PersoniumのAPIアーキテクチャ詳細: 3レイヤーのモデル：Unit/Cell/Box UnitBox Cell Box BoxCell Cell Cell 名称 説明 Typical URL Unit Cell群をホストするサーバ。インストールで得られるもの。 https://pds.example/ Cell PDS。人・モノ・組織のためのデータストア https://pds.example/akio.shimono/ Box Cell内のアプリ毎の空間 https://pds.example/akio.shimono/schedule/ Cell Cell Cell 全機能をREST APIの形式で提供 Cell群はUnitを超えてネットワーク可能.（信頼するUnitとの相互連携） ■ Box はそれぞれのアプリのための専用の隔離された領域を提供 HTTP(S)通信が可能な すべてのプラットフォーム Mastodonみ たいな感じです 22
- 23. Personiumアーキテクチャ詳細: レベル別APIとその用途 • 全通信はSSLで暗号化。認証・認可・アクセス制御でデータを保護 • 3種類のクライアントがそれぞれ対応するレベルのAPIを呼び出す想定 Unit Box BoxCell Box pictures 2016-09- 01.jpg 2016-08- 31.jpg Thumb-svc shared Trip-log settings.json Unit 制御 Cell制御 Unit 管理クライアント サービス提供者 アプリケーションクライアントCell 管理クライアント スーパーユーザアクセス Cellの作成 / 削除 様々なアプリを利用し 自身のデータを保管 自分のデータを 管理 アクセス制御 外部 / 既存の IdP / 認証機構 IdP / 認証 エンドユーザ RESTful なAPI 標準に準拠 WebDAV ファイル系データには リレーショナルデータには アプリ開発で 主に意識するAPI 23
- 25. アプリデモ • デモシナリオ PDSを用いたライフログ（食事履歴）の開示依頼・回答・データ閲覧 • 登場人物 ・PDS運営主体:わかば市情報バンク PDS環境とアプリを市民・事業者へ提供し、仲介する ・PDS利用市民（データオーナー）：たくや PDSにライフログとして食事写真をためている ・PDS利用事業者(データ閲覧依頼者)：リーフモールわかば店 わかば市民の食事が知りたい 25
- 27. デモ解説①：アプリ • Homeアプリ(市民向け、事業者向け) アプリランチャー・AppマーケットなどOS相当：CellレベルAPIの操作 →全てのパーソナルデータの入り口 • わかば市情報バンク(市民向け、事業者向け) • 一般利用者は、事業者からのデータ開示依頼に対して、 許諾や拒否を実施することができる • 事業者は、わかば市情報バンクに登録しているユーザに対してデータ 参照依頼をまとめて送信することができる • カロリースマイル連携アプリ • カロリースマイル（外部のWebサービス）に登録されている、特定の 個人の食事写真データをAPIによって同期するためのアプリ すべてGitHubで公開しています。ご自由にお使いください 27
- 28. コミュニティ概要 • Slack 上で日本語/(英語？)でPersoniumに関する様々な情報交換をします。 • ある程度の人数が集まり、要望があればオフラインのイベント(Personium Meeting)も企画します。 • 参加者を広く募集しています。 公開チャンネル - 議論テーマ デフォルトのチャンネル • #general, #random – 全参加者共通チャンネル。randomは雑談用。 • #hello_ja – 参加者自己紹介。参加したいチャンネルのリクエストはこちらで。 • #github – Personium開発状況のリアルタイム通知 テーマ別チャンネル • #general – PDS関連の技術・制度動向など、共通の話題。 • #infra_ja – Personiumサーバー環境の構築、 導入上の相互支援 • #docs_ja - Personiumドキュメンテーション • #appdev_ja - Personiumのアプリ開発 随時、追加チャンネルの要望を承ります！！ http://personium.io https://personium-io.slack.com https://goo.gl/forms/ODgVX6eMkRDtReLg1 参加フォームはこちら↓ Personium コミュニティ
- 30. 宣伝： 富士通 K5 Personium サービス 30 もしご関心ありましたら富士通のクラウドサービスをお使いいただけると助かります！ 月額10万円弱 100GBのデータ領域と24/365運用つい てます。 だいたい1000名以下程度の実証実験等 にお使いいただく想定。
- 32. APIでPDSを作成する • Personiumと関連ミドルウェア群をサーバにインストール （自動構築スクリプトも公開済み） • 構築すると、PDS一覧管理のためのエンドポイントができる（作成・消去・検索等） • まずは、PDSを生成するエンドポイントに対してリクエストする （サーバ管理者レベルの強いトークンを使用） • http://personium.io/docs/Japanese/docs/ja/rest_api/unit_level/unit_manage/cell_manage/Create.htm personium PDS作成エンドポイント POST AさんのPDS … 201 BさんのPDS CさんのPDS 作成 作成 作成 PDSは、任意の名称で作成可能 1環境に無数に作成可能 PDSには一意URLが与えられる https://example.com/john_doe PDSの各種機能は、配下URLのWebAPIと して提供される HTTP Client 32
- 33. PDS内データのアクセス制御を設定する アクセス制御はロールベースで設定する 予め認証するユーザーアカウント（id/pw）と、その人が持つロールを設定しておく そのロールができる操作権限（ACL）を設定しておく 自分のPDSへアクセス設定 認証→ロール割り当て →割り当てたロールに応じたAPIアクセス許可 • 例：ロール名Ownerを設定→OwnerにAll権限 自分のPDSにアクセスしてくるビジターへのアクセス制御も別途設定（後述） 他人かどうかはトークンを検証することで判別 PDS認証エンドポイントで アクセス者を確認 POST トークン HTTP Client （本人） トークンからユーザとそのロールを確認し、 ロールに割り当てられた権限を確認し、 アクセスが認められていたら、データを返 す w/ トークンGET 個人のデータ 個人のデータ 個人のデータ アプリ毎データ領域 アプリ毎データ領域 アプリ毎データ領域 データ ロールデータ① ② 33
- 34. データの登録 • データの登録 • 格納したいデータ領域に対し、データをPOST • データ登録権限が付与されていれば格納可能 PDS認証エンドポイントで アクセス者を確認 POST トークン HTTP Client （本人） w/ トークンPOST アプリ毎データ領域 アプリ毎データ領域 アプリ毎データ領域 データ ロールデータ① ② ACL ACL ACL 34
- 35. ビジターへのアクセス制御 自分のPDSに、ビジターのロールとアクセス権限を割り当てる 自分以外のPDSのURLを登録。そこにロールを付与 ロールはいくつでも作成でき、ビジターごとに様々なアクセス制御の設定ができる 来訪者のロール設定パターンは3通り 1. ビジター自身のPDSのURLを登録し、ロールを割り当てる 2. 複数のビジターとの関係性をラベルし、関係性ごとにロールを割り当てる（関係性には、複数のPDSの URLを設定可） 3. ビジターPDSにおいて、ある特定のロールを割り当てられたユーザーに対して、ロールを割り当てる PDS認証エンドポイントで アクセス者を確認 POST トークン HTTP Client （本人） トークンからユーザとそのロールを確認し、 ロールに割り当てられた権限を確認し、 アクセスが認められていたら、データを返 す w/ トークンGET 個人のデータ 個人のデータ 個人のデータ アプリ毎データ領域 アプリ毎データ領域 アプリ毎データ領域 データ ロールデータ① ② 35
- 36. 他人のPDSデータの取得方法 予めアクセス許可する権限が設定されていれば、他人のPDS内のデータへのアクセス が可能 来訪先PDS 紹介状トークン受け取り→ロール割り当て→ロールに応じたAPIアクセス許可 PDS(来訪先) 認証エンドポイントで 紹介状をもらう 紹介状 トークン HTTP Client （来訪者） w/ トークンGET 個人のデータ 個人のデータ 個人のデータ アプリ毎データ領域 アプリ毎データ領域 アプリ毎データ領域 データ ロールデータ① ③ 来訪者自身の PDS HTTP トークン ② 紹介状 トークン 認証エンドポイントで 紹介状からロールを特定し トークンを返す ロールにアクセス権が認められていれば、データ を返す 36
- 37. PDSアプリ開発の流れ 37
- 38. Personiumアプリの注意点①：データ • PDSの原則から、人に紐づくデータは個人の持つCellに入れるべき • サーバ側のデータをユーザーサイド／アプリサイドで分ける前提での設計が必要 • アプリに紐づくBoxのデータ構造を定義する「barファイル」を、個人のCellにインストールする という仕組み Server Client My Cell アプリCell Client 私のデータはこっち アプリサイドデータ BoxUser ID1のデータ User ID2のデータ ・・・・ アプリに合った データ領域を展開 一般的なアプリ Personiumを用いたクライアントアプリケーション アプリ共通リソース ・・・ Barファイル （Box定義体） アプリCellに置くもの 1.barファイル 2.アプリ共通リソース(src) 3.アプリアイコン(icon) 4.profile.json 5.launch.json 特に分けて考えない ユーザサイドデータ Personium 38
- 39. Personiumアプリの注意点②：アプリ認証 • パーソナルデータを守るため、フィッシングアプリからの防衛の仕組み • OAuth2.0 のClient認証に準拠したフロー 正規の アプリ 悪意を 持った アプリ ×誘導 正規の アプリ以外を ブロック 利用者 ・新しいバージョンのアプリが出ましたよ。 ・このアプリを使うと便利ですよ。 攻撃者 アプリCell 認証したトークン アプリCellで 認証してないトークン My CellBox 39 アプリCell
- 40. アプリ開発の流れ • 前提 ・自由に使えるUnitをもち、Personiumの管理権限（UnitAdmin/UnitUser）が使用できること →ローカルでも可。UnitManager、CellCreatorなどのツールを使うと楽（GitHubで公開中） • 流れ 1. barファイルを作る ・Box、アプリCellのデータ構造（Collection）を設計 ・必要であれば、サーバサイドスクリプト（Engine）を作成 ・各リソースへのACLを設計。アクセス主体の種類（Role他）と権限を定義 2. profile.json, launch.json, iconを作成 （詳しくはドキュメント参照） 3. アプリCell作成、リソース配置 アプリCellのAccount、Passwordを設定（アプリ認証用） 4. Homeアプリなどからbarインストールし、アプリを立ち上げる 以下のリンク先に順次整備予定： https://personium.github.io/ja/app-developer/index.html 参考：アプリセルテンプレート https://github.com/personium/template-app-cell My Cell アプリCell アプリサイドデータ Box アプリに合った データ領域を展開 Barファイル （Box定義体） ユーザサイドデータ Personium アプリCellに置くもの 1.barファイル 2.アプリ共通リソース(src) 3.アプリアイコン(icon) 4.profile.json 5.launch.json 40
- 41. ご参考）各オープン仕様の特長 様々な形態のアプリケーション （Web/デスクトップ/モバイル） から、保護されたWebAPIを利用 するための標準認可プロセス OAuth2.0 SAML2 Assertion 認証結果や属性情報を電子署名に よって担保しサーバを跨って伝え るためのXML仕様のOASIS標準 主にシングルサインオンで用いら れ、PersoniumでもOAuth2.0と 組み合わせてユーザ単位データ領 域間での認証連携に活用 41
- 43. Unit Cell HomeApp MyBoard i-am-here … Calorie Smile Sync Minimal App Wakaba User Wakaba Business Cell Manager Unit Manager PCUI For demo only: Minimal App, Wakaba Business, & Wakaba User contain incomplete feature Cell Creator PDS事業者向け アプリ開発者向 け launch launch アプ リ PDS事業者 向け アプ リ アプリ開発 者向け アプ リ 一般ユー ザー向け 一般ユーザー向 け
- 44. PDS事業者向け 名前 機能説明 備考 Unit Manager Personiumユニット配下の全てのセルを管理す るツール（Cell Managerと同居）。 全部のセルの内部コンポーネント、データ及び セルの設定を管理できる。 ユニットセルにログイン する場合、自動的に Unit Managerに切り替 える。 Cell Creator（Wizardも含む） 直感的に利用者セルを払い出すツール。 下記componentを自動で生成する。 - profile.json（cell種別を追記） - Adminアカウント - Appセルの場合、App userアカウント - Appセル以外はHomeApp Usability向上 - 誤入力と誤操作を 防ぐ機能 - QR codeで HomeAppのログイ ン画面に移動 - 長いURL文字列に 対応するcopy to clipboardボタン
- 45. App開発者向け（2/3） 名前 機能説明 備考 Cell Manager Personiumの利用者セルを直感的に管理するツー ル（Unit Managerと同居）。 利用者セルの内部コンポーネント、データ及びセル の詳細設定を管理できる。 利用者セルにロ グインする場合、 自動的にCell Managerに切り替 える。 PCUI Personiumの利用者セルの管理ツール。 Cell Manager並み のcommand line 版 MinimalApp Personium Appの雛形。 アプリの適用手順も記載される。 Personiumの HelloWorld
- 46. App開発者向け（3/3） 名前 機能説明 備考 Wakaba User データ参照依頼や開示可否操作を実施する Personium App。 事業者からのデータ開示依頼に対して、許諾や拒 否を実施することができる。 デモアプリ Wakaba Business データ参照依頼や開示可否操作を実施する Personium App。 登録しているユーザーに対してデータ参照依頼をま とめて送信することができる。 デモアプリ js-client JavaScript App開発者向けjsライブラリ。 personium-js-lib-common JavaScript App開発者向けjsライブラリ。 共通API/和英メッセージ・ラベルを提供する。 OData WebDAV ODataとWebDAVのREST APIの紹介。 デモsite REST API使用方法 上記のREST APIの実装部分
- 47. 一般ユーザー向け（2/2） 名前 機能説明 備考 HomeApp ユーザーが自分のPersoniumセルを管理・操作する Personium App。 • セルの一般設定を管理する。 • PDS事業者から提供したアプリで保存されたデー タを操作する。 Cell種別によって 自動的にfor Biz版 に切り替える MyBoard 使用者の情報をPDSに保存するPersonium App。 データ参照依頼や開示可否操作を実施する。 Textのみ i-am-here 福祉系App。 写真と位置をPDSに保存するPersonium App。 データ参照依頼や開示可否操作を実施する。 画像とtext Calorie Smile Sync Webサービスに登録されている情報（食事写真 データ）をPDSに同期するPersonium App。 データ参照依頼や開示可否操作を実施する。 限定web service 必要
Notas do Editor
- PDSとしてのGUIはサンプル配布するが誰でも改造可能。（⇒PDS運営者ブランドで見せられる）
- さて、このようなビジョンを掲げるpersoniumのアーキテクチャについてみてみましょう。 第1に私たちは全ての機能をRESTfulなAPIとして提供することを原則としています。 これは、あらゆるプラットフォーム、あらゆるアプリ形態からもデータの出し入れできることを保証するためです。 そしてHTTP上で表現される3階層のオブジェクト。大きい順に並べていますが、Unit, Cell, Boxこれが基本となります。 まずは、中央にあるCell 。これがデータストアであり、まさにpersoniumです。 名前の不一致がありますが、先ほどお話したようにこのCellは人のデータをホストするとは限らないですし、また他のストアと有機的に結びついて ネットワークをつくることを目指しているからこういう名前にしています。1音節だというのも理由ですね ユニットはCellを沢山ホストできるサーバです。ソフトウェアをインストールしてできるのがこのUnitです UnitにはFQDNを一つ割り当てるのが基本としています。自分のCellと息子のCellと妻のCellをつくるのにわざわざ３つサーバを用意するのは手間ですからね。 というのは冗談で、このソフトウェアを使う、サービスプロバイダは、何十万人、という人々のCellをまとめてホストしたいでしょうからね。 そして、Unitの最大の特徴は、Unitを超えてネットワークが構築できることです。 世界50億人の人々にデータストアを用意するには、一つのユニットで足りるわけがないからです。 そして、私の所属しているFujitsuという日本の会社だけでサポートしきれるわけがないからです。 そしてBoxこれは、アプリケーション毎のデータストアです。私たちはこのCellをプラットフォームとしてとらえています。Cellには様々なアプリケーションが データをやりとりします。万が一にも、私が遊んでいたゲームのバグが原因で私の健康記録が消えるようなことがあっては困ります。 右に典型的なＵＲＬが書いてあります。Personimuはこのような3階層の構造で前述のビジョンを実現しようとしています。
- もう少し具体的詳細を見てみましょう。 当然アクセス制御、セキュリティがあります。 Cellを作ったり消したりするUnit Ctl API Cellの中にBoxを作ったり消したりするCell Ctrl APIがありますが、 一つ特徴的なのは、 Cellはそれ自身がそれぞれ認証APIを持っているのに対して、 Unitは自身に認証ＡＰＩを持っておらず、外部の認証局と連携するように つくってあります。これは、事業発展型PDSをやるうえでの重要な特性です。 Cellの認証機構は、現状では ID/PW認証に加えてGoogleのOpen ID Connectには対応済みですが、 拡張しやすい設計にしており、様々な認証手段に対応できるように してゆきたいと思っています。 Personiumは様々なアプリケーションのデータを格納できなくてはなりません。 ゲームのスコアでも、設計図でも、カルテでも契約書でも・・・ そのため、アプリ毎の領域は全く業務・業種の色を持つわけにはいきません。 設計図・契約書・カルテなど、大抵のデータはファイルとして表せます。 ですので、Boxは、このように、WebDAVの空間となっており、 いわばファイルシステムのように使うことができます。アクセス制御は WebDAV ACLです。 しかし、1分刻みのｇｐｓの座標情報を保存するのにファイルでよいでしょうか？ ファイルで保存することもできるでしょうが、それでは活用ができません。 2年後に私が、「そういえば、あのヘルシンキいったのはいつだったっけ？」と思いだしたいときに、 60*24*365*2＝??の膨大な数のファイルを一つ一つみるのではなく、座標で 検索がしたくなるでしょう。 WebDAVのコレクション拡張を用いて、特殊な2つのコレクションを格納できます。 ひとつが、OData、もうひとつが任意のJavaScriptを配置できるEngine Serviceです。 リレーショナルデータ、ファイルが使えれば、たいがいのアプリケーションのデータは格納することができます。
- 41