Skip to content

Instantly share code, notes, and snippets.

@inabajunmr

inabajunmr/memo.md

Last active August 2, 2020 08:50
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save inabajunmr/a27e3eea8c6e603583a53d0f5a26a13a to your computer and use it in GitHub Desktop.
Save inabajunmr/a27e3eea8c6e603583a53d0f5a26a13a to your computer and use it in GitHub Desktop.
Download ZIP
2020: Self-Sovereign Identity with Self-Issued OpenID Providerを見ながら書いたメモ
Raw
memo.md

https://www.youtube.com/watch?v=b5aaiIaYRNw

2020: Self-Sovereign Identity with Self-Issued OpenID Providerを見ながら書いたメモ

なおIDの知識や英語力の問題でちゃんと正しく理解できている自信はないので以下の内容は部分的もしくは全体的に間違っている可能性がそれなりにある

Self-Sovereign Identityとは

  • 自分が関係する組織と独立して認識される
    • 管理主体が自分、という意味でいいと思う
  • 自分またはサードパーティが保証する値を選択的に開示できる
  • 特定のタイミングでクレームが保証されていることを証明できる

Identity

identity is entityに関連するクレームの組み合わせ 稲葉純（人間）、に対する[年齢、名前、性別]みたいな

誤解されがちなポイント

  • Entity:Identity=1:n
    • 同じ人間が複数サービスのIDを取得できる、みたいな話？
  • IdentityはIdentifierではない
    • 後者はEnittyを特定するためのユニークな値

Self-Sovereign

Sovereign is one that exercises supreme authority within a limited sphere

limited sphere is 'self'

3種類のIdentity

Mydentity

他の組織によって与えられるものではない 基本的に自分でコントロールできる （Mydentity=Self-Sovereign Identityに見えるが、いまいち確信がない）

Ourdentity

誰かに与えられるが、自分で使える Gmailのアドレスとか、雇用主に与えられたID 現代のメインストリームはこれ

Theredentity

自分のデータだが、自分で使えない 自分が顧客、な場合に、販売主のsalesforceに入ってる自分のデータ、みたいなやつ

なぜMydentityを使いたい？

第三者によってIDが削除され、インターネットからIdentityが消えるのを避けたい （多分GoogleのIDをつかってどっかのサービスにログインするケースで、GoogleのIDを消されて連携サービスにもログインできなくなるケース、みたいのがでかいと思う。サービスのアカウント、というよりもIdentity、という軸で見るべき）

どうやって？

mydentityは、IDが表すエンティティが秘密鍵を持つ公開鍵基盤で実現される（IDが本当に自分を表現すること、を担保） それとは別に、エンティティ間の関係を構築するために自分のクレームを送信する必要があるケースがあるが、これもSelf-Sovereign Identityのスコープ

自分に関する「自分自身」とサードパーティが保証する情報の選択的な開示

自分に関連する情報を、すべて自分でコントロールすることはできない 例えば運転免許証で、どのタイプの乗り物を自分が運転できるか？は、自分では決められず、authority（当局）によって決められる

また、コンテキストによって提供するクレームは最小化したい（不要なデータをサービスに渡したくない）

過去の状況、を証明、提示したいケースが有る 何かあって国が消滅した時に、過去その国の国民であったこと、など あるタイミングでのクレームを検証、もSelf-Sovereign Identityのスコープ

SIOPがそれにどう対応するか

SIOP is self issued openid provider oidcのcoreの7章で定義される http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html#SelfIssued

OIDCは選択的にクレームを提供できるプロトコル idトークンには認証に必要なクレーム以外も入れられる、みたいな話

OIDCプロバイダーはサードパーティによって提供されるが、自分自身でローカルだったりクラウドに構築して提供することができる 後者をSIOPという

SIOPの登場人物

  • idの保持者（自分）
  • 自分自身を認証する認証機（スマホ）
    • このなかでIdpが動いている
  • Claims Provider
    • 自分に関する保証されたクレームを提供する人
    • 運転免許でいう、私が免許をもっていますよ、を保証してくれる人
  • RP
    • 自分が提供を受けたいサービス

Two legs

RPとSIOP、Claims providerとSIOP間のやりとりがある

フロー

準備

SIOPをClaims providerに登録

  1. SIOPがCPに認証リクエストをだす
  2. CPがClamsの提供可否を聞いてくるので、OKを出す（多分CPとユーザー間の認証はSIOPとは関係なくあって、必要に応じてCPにログインしたりする）（このログインもSIOPの公開鍵基盤でやるかも）
  3. CPがトークンを発行

利用

  1. Client（サービス）がSIOPに「誰お前」って聞いてくる
  2. SIOPがCPにUserinfoリクエストをなげる
  3. CPはJWT（userinfo）を発行
  4. SIOPはuserinfoを含んだIDトークンをクライアントに投げる

問題点

よくわからん

CPが提供したuserinfoとIDトークンが表現するユーザーが同じ人間であることをどう担保するか、の話だと思うんだけど、よくわからん・・・

クレームのフィルタリング

CPが発行したJWTはJWSでペイロードに対して署名されてるので、SIOPは勝手にクレームを必要な値に絞り込むことができない(Clientが署名検証できなくなる) CPに対してuserinfoの要求を出すタイミングで必要なclaimsのリストをわたせばよいが、現状その仕様はない（OIDCのuserinfoにclaims渡せた気がするけど、それじゃだめな理由がよくわからん）

今後

ワーキンググループとかの話（雑）

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment