Soumettre la recherche
Mettre en ligne
今なら間に合う分散型IDとEntra Verified ID
•
7 j'aime
•
11,957 vues
Naohiro Fujie
Suivre
6/30のOffice365勉強会のEntra Verified ID特集の資料です。 分散型ID、Entra Verified IDの解説をしています。
Lire moins
Lire la suite
Technologie
Signaler
Partager
Signaler
Partager
1 sur 71
Télécharger maintenant
Télécharger pour lire hors ligne
Recommandé
分散型IDと検証可能なアイデンティティ技術概要
分散型IDと検証可能なアイデンティティ技術概要
Naohiro Fujie
SSIとDIDで何を解決したいのか?(β版)
SSIとDIDで何を解決したいのか?(β版)
Naohiro Fujie
自己主権型IDと分散型ID
自己主権型IDと分散型ID
Naohiro Fujie
MicrosoftのDID/VC実装概要
MicrosoftのDID/VC実装概要
Naohiro Fujie
Azure AD B2CにIdPを色々と繋いでみる
Azure AD B2CにIdPを色々と繋いでみる
Naohiro Fujie
Keycloakのステップアップ認証について
Keycloakのステップアップ認証について
Hitachi, Ltd. OSS Solution Center.
S13_レガシー ID 管理者でも分かる Verifiable Credentials のセッション [Microsoft Japan Digital D...
S13_レガシー ID 管理者でも分かる Verifiable Credentials のセッション [Microsoft Japan Digital D...
日本マイクロソフト株式会社
FIDO認証によるパスワードレスログイン実装入門
FIDO認証によるパスワードレスログイン実装入門
Yahoo!デベロッパーネットワーク
Recommandé
分散型IDと検証可能なアイデンティティ技術概要
分散型IDと検証可能なアイデンティティ技術概要
Naohiro Fujie
SSIとDIDで何を解決したいのか?(β版)
SSIとDIDで何を解決したいのか?(β版)
Naohiro Fujie
自己主権型IDと分散型ID
自己主権型IDと分散型ID
Naohiro Fujie
MicrosoftのDID/VC実装概要
MicrosoftのDID/VC実装概要
Naohiro Fujie
Azure AD B2CにIdPを色々と繋いでみる
Azure AD B2CにIdPを色々と繋いでみる
Naohiro Fujie
Keycloakのステップアップ認証について
Keycloakのステップアップ認証について
Hitachi, Ltd. OSS Solution Center.
S13_レガシー ID 管理者でも分かる Verifiable Credentials のセッション [Microsoft Japan Digital D...
S13_レガシー ID 管理者でも分かる Verifiable Credentials のセッション [Microsoft Japan Digital D...
日本マイクロソフト株式会社
FIDO認証によるパスワードレスログイン実装入門
FIDO認証によるパスワードレスログイン実装入門
Yahoo!デベロッパーネットワーク
プロトコルから見るID連携
プロトコルから見るID連携
Naohiro Fujie
Keycloak拡張入門
Keycloak拡張入門
Hiroyuki Wada
OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜
OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜
Masaru Kurahayashi
次世代 IDaaS のポイントは本人確認 NIST と、サプライチェーンセキュリティと、みなしご ID - OpenID Summit 2020
次世代 IDaaS のポイントは本人確認 NIST と、サプライチェーンセキュリティと、みなしご ID - OpenID Summit 2020
OpenID Foundation Japan
Modern Authentication -- FIDO2 Web Authentication (WebAuthn) を学ぶ --
Modern Authentication -- FIDO2 Web Authentication (WebAuthn) を学ぶ --
Jun Kurihara
BigQuery で 150万円 使ったときの話
BigQuery で 150万円 使ったときの話
itkr
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Hiroshi Tokumaru
Keycloak & midPoint の紹介
Keycloak & midPoint の紹介
Hiroyuki Wada
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
Nov Matake
実装して理解するLINE LoginとOpenID Connect入門
実装して理解するLINE LoginとOpenID Connect入門
Naohiro Fujie
なぜOpenID Connectが必要となったのか、その歴史的背景
なぜOpenID Connectが必要となったのか、その歴史的背景
Tatsuo Kudo
KeycloakでAPI認可に入門する
KeycloakでAPI認可に入門する
Hitachi, Ltd. OSS Solution Center.
IDA,VC,DID関連仕様 最新情報 - OpenID BizDay #15
IDA,VC,DID関連仕様 最新情報 - OpenID BizDay #15
OpenID Foundation Japan
FIDOのキホン
FIDOのキホン
Yahoo!デベロッパーネットワーク
認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜
Masaru Kurahayashi
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
OpenID ConnectとAndroidアプリのログインサイクル
OpenID ConnectとAndroidアプリのログインサイクル
Masaru Kurahayashi
Keycloak入門
Keycloak入門
Hiroyuki Wada
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
Shota Shinogi
FIDO2 ~ パスワードのいらない世界へ
FIDO2 ~ パスワードのいらない世界へ
FIDO Alliance
OpenIDファウンデーション・ジャパンKYC WGの活動報告 - OpenID Summit 2020
OpenIDファウンデーション・ジャパンKYC WGの活動報告 - OpenID Summit 2020
OpenID Foundation Japan
SSI DIDs VCs 入門資料
SSI DIDs VCs 入門資料
KAYATO SAITO
Contenu connexe
Tendances
プロトコルから見るID連携
プロトコルから見るID連携
Naohiro Fujie
Keycloak拡張入門
Keycloak拡張入門
Hiroyuki Wada
OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜
OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜
Masaru Kurahayashi
次世代 IDaaS のポイントは本人確認 NIST と、サプライチェーンセキュリティと、みなしご ID - OpenID Summit 2020
次世代 IDaaS のポイントは本人確認 NIST と、サプライチェーンセキュリティと、みなしご ID - OpenID Summit 2020
OpenID Foundation Japan
Modern Authentication -- FIDO2 Web Authentication (WebAuthn) を学ぶ --
Modern Authentication -- FIDO2 Web Authentication (WebAuthn) を学ぶ --
Jun Kurihara
BigQuery で 150万円 使ったときの話
BigQuery で 150万円 使ったときの話
itkr
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Hiroshi Tokumaru
Keycloak & midPoint の紹介
Keycloak & midPoint の紹介
Hiroyuki Wada
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
Nov Matake
実装して理解するLINE LoginとOpenID Connect入門
実装して理解するLINE LoginとOpenID Connect入門
Naohiro Fujie
なぜOpenID Connectが必要となったのか、その歴史的背景
なぜOpenID Connectが必要となったのか、その歴史的背景
Tatsuo Kudo
KeycloakでAPI認可に入門する
KeycloakでAPI認可に入門する
Hitachi, Ltd. OSS Solution Center.
IDA,VC,DID関連仕様 最新情報 - OpenID BizDay #15
IDA,VC,DID関連仕様 最新情報 - OpenID BizDay #15
OpenID Foundation Japan
FIDOのキホン
FIDOのキホン
Yahoo!デベロッパーネットワーク
認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜
Masaru Kurahayashi
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
OpenID ConnectとAndroidアプリのログインサイクル
OpenID ConnectとAndroidアプリのログインサイクル
Masaru Kurahayashi
Keycloak入門
Keycloak入門
Hiroyuki Wada
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
Shota Shinogi
FIDO2 ~ パスワードのいらない世界へ
FIDO2 ~ パスワードのいらない世界へ
FIDO Alliance
Tendances
(20)
プロトコルから見るID連携
プロトコルから見るID連携
Keycloak拡張入門
Keycloak拡張入門
OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜
OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜
次世代 IDaaS のポイントは本人確認 NIST と、サプライチェーンセキュリティと、みなしご ID - OpenID Summit 2020
次世代 IDaaS のポイントは本人確認 NIST と、サプライチェーンセキュリティと、みなしご ID - OpenID Summit 2020
Modern Authentication -- FIDO2 Web Authentication (WebAuthn) を学ぶ --
Modern Authentication -- FIDO2 Web Authentication (WebAuthn) を学ぶ --
BigQuery で 150万円 使ったときの話
BigQuery で 150万円 使ったときの話
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Keycloak & midPoint の紹介
Keycloak & midPoint の紹介
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
実装して理解するLINE LoginとOpenID Connect入門
実装して理解するLINE LoginとOpenID Connect入門
なぜOpenID Connectが必要となったのか、その歴史的背景
なぜOpenID Connectが必要となったのか、その歴史的背景
KeycloakでAPI認可に入門する
KeycloakでAPI認可に入門する
IDA,VC,DID関連仕様 最新情報 - OpenID BizDay #15
IDA,VC,DID関連仕様 最新情報 - OpenID BizDay #15
FIDOのキホン
FIDOのキホン
認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
OpenID ConnectとAndroidアプリのログインサイクル
OpenID ConnectとAndroidアプリのログインサイクル
Keycloak入門
Keycloak入門
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
FIDO2 ~ パスワードのいらない世界へ
FIDO2 ~ パスワードのいらない世界へ
Similaire à 今なら間に合う分散型IDとEntra Verified ID
OpenIDファウンデーション・ジャパンKYC WGの活動報告 - OpenID Summit 2020
OpenIDファウンデーション・ジャパンKYC WGの活動報告 - OpenID Summit 2020
OpenID Foundation Japan
SSI DIDs VCs 入門資料
SSI DIDs VCs 入門資料
KAYATO SAITO
ブロックチェーンを用いた自己主権型デジタルID管理
ブロックチェーンを用いた自己主権型デジタルID管理
Hyperleger Tokyo Meetup
OpenID ConnectとSCIMのエンタープライズ利用ガイドライン
OpenID ConnectとSCIMのエンタープライズ利用ガイドライン
Takashi Yahata
Azure ADとWindows 10によるドメイン環境の拡張
Azure ADとWindows 10によるドメイン環境の拡張
Naohiro Fujie
PID:the Protocol for Programmable Identity.pdf
PID:the Protocol for Programmable Identity.pdf
KAYATO SAITO
組織におけるアイデンティティ管理の基本的な考え方
組織におけるアイデンティティ管理の基本的な考え方
Naohiro Fujie
クラウドにおける Windows Azure Active Directory の役割
クラウドにおける Windows Azure Active Directory の役割
junichi anno
Auth0 node fest2017-workshop
Auth0 node fest2017-workshop
Hideya Furuta
認証技術、デジタルアイデンティティ技術の最新動向
認証技術、デジタルアイデンティティ技術の最新動向
Tatsuo Kudo
既存RailsアプリをSSO化して、本番環境で活用した話【WESEEK Tech Conf #12】
既存RailsアプリをSSO化して、本番環境で活用した話【WESEEK Tech Conf #12】
WESEEKWESEEK
クラウド過渡期、Identityに注目だ! idit2014
クラウド過渡期、Identityに注目だ! idit2014
Egawa Junichi
IDaaSにSign in with Appleをつないでみた
IDaaSにSign in with Appleをつないでみた
Naohiro Fujie
ID Management
ID Management
Kohei MATSUOKA
Idcon gomi-052715-pub
Idcon gomi-052715-pub
Hidehito Gomi
テレワーク本格導入におけるID認証考察
テレワーク本格導入におけるID認証考察
FIDO Alliance
認証/メッセージング領域へのモバイル/ソーシャルネットワークIDの活用
認証/メッセージング領域へのモバイル/ソーシャルネットワークIDの活用
Naohiro Fujie
指紋認証と「FIDO」について
指紋認証と「FIDO」について
Device WebAPI Consortium
OpenID Connect のビジネスチャンス
OpenID Connect のビジネスチャンス
OpenID Foundation Japan
「Windows Phone アプリ と 認証」のまとめ
「Windows Phone アプリ と 認証」のまとめ
junichi anno
Similaire à 今なら間に合う分散型IDとEntra Verified ID
(20)
OpenIDファウンデーション・ジャパンKYC WGの活動報告 - OpenID Summit 2020
OpenIDファウンデーション・ジャパンKYC WGの活動報告 - OpenID Summit 2020
SSI DIDs VCs 入門資料
SSI DIDs VCs 入門資料
ブロックチェーンを用いた自己主権型デジタルID管理
ブロックチェーンを用いた自己主権型デジタルID管理
OpenID ConnectとSCIMのエンタープライズ利用ガイドライン
OpenID ConnectとSCIMのエンタープライズ利用ガイドライン
Azure ADとWindows 10によるドメイン環境の拡張
Azure ADとWindows 10によるドメイン環境の拡張
PID:the Protocol for Programmable Identity.pdf
PID:the Protocol for Programmable Identity.pdf
組織におけるアイデンティティ管理の基本的な考え方
組織におけるアイデンティティ管理の基本的な考え方
クラウドにおける Windows Azure Active Directory の役割
クラウドにおける Windows Azure Active Directory の役割
Auth0 node fest2017-workshop
Auth0 node fest2017-workshop
認証技術、デジタルアイデンティティ技術の最新動向
認証技術、デジタルアイデンティティ技術の最新動向
既存RailsアプリをSSO化して、本番環境で活用した話【WESEEK Tech Conf #12】
既存RailsアプリをSSO化して、本番環境で活用した話【WESEEK Tech Conf #12】
クラウド過渡期、Identityに注目だ! idit2014
クラウド過渡期、Identityに注目だ! idit2014
IDaaSにSign in with Appleをつないでみた
IDaaSにSign in with Appleをつないでみた
ID Management
ID Management
Idcon gomi-052715-pub
Idcon gomi-052715-pub
テレワーク本格導入におけるID認証考察
テレワーク本格導入におけるID認証考察
認証/メッセージング領域へのモバイル/ソーシャルネットワークIDの活用
認証/メッセージング領域へのモバイル/ソーシャルネットワークIDの活用
指紋認証と「FIDO」について
指紋認証と「FIDO」について
OpenID Connect のビジネスチャンス
OpenID Connect のビジネスチャンス
「Windows Phone アプリ と 認証」のまとめ
「Windows Phone アプリ と 認証」のまとめ
Plus de Naohiro Fujie
LINE Login総復習
LINE Login総復習
Naohiro Fujie
LINEログインの最新アップデートとアプリ連携ウォークスルー
LINEログインの最新アップデートとアプリ連携ウォークスルー
Naohiro Fujie
ざっくり解説 LINE ログイン
ざっくり解説 LINE ログイン
Naohiro Fujie
Azure AD x LINE x Auth0
Azure AD x LINE x Auth0
Naohiro Fujie
LINE Payも取り組んでいるKYCってなんだろう?KYCの基本と最近の動向
LINE Payも取り組んでいるKYCってなんだろう?KYCの基本と最近の動向
Naohiro Fujie
LIFFとの連携でさらに強力に。こんなに使えるLINEログイン
LIFFとの連携でさらに強力に。こんなに使えるLINEログイン
Naohiro Fujie
Azure ADの外部コラボレーションとBYOID
Azure ADの外部コラボレーションとBYOID
Naohiro Fujie
祝!公式サポート Auth0 + LINE Login
祝!公式サポート Auth0 + LINE Login
Naohiro Fujie
次世代KYCと自己主権型アイデンティティの動向
次世代KYCと自己主権型アイデンティティの動向
Naohiro Fujie
これからの KYC と Identity on Blockchain の動向
これからの KYC と Identity on Blockchain の動向
Naohiro Fujie
教育機関におけるBYOIDとKYC
教育機関におけるBYOIDとKYC
Naohiro Fujie
コンシューマIDのエンタープライズ領域での活用
コンシューマIDのエンタープライズ領域での活用
Naohiro Fujie
大学等におけるAzure AD B2Cを使用したSNS認証の活用
大学等におけるAzure AD B2Cを使用したSNS認証の活用
Naohiro Fujie
Azure AD B2C + LINE 学校や企業における次世代 ID/ メッセージ基盤
Azure AD B2C + LINE 学校や企業における次世代 ID/ メッセージ基盤
Naohiro Fujie
Azure ADとLINE連携により実現する学校や企業における次世代ID/メッセージ基盤
Azure ADとLINE連携により実現する学校や企業における次世代ID/メッセージ基盤
Naohiro Fujie
大学等におけるAzure AD B2Cを使用したSNS認証の活用
大学等におけるAzure AD B2Cを使用したSNS認証の活用
Naohiro Fujie
アイデンティティ API とデータ統合プラットフォームの活用
アイデンティティ API とデータ統合プラットフォームの活用
Naohiro Fujie
Office365のID基盤活用とセキュリティ上の注意点
Office365のID基盤活用とセキュリティ上の注意点
Naohiro Fujie
OAuth2.0によるWeb APIの保護
OAuth2.0によるWeb APIの保護
Naohiro Fujie
ID管理/認証システム導入の理想と現実
ID管理/認証システム導入の理想と現実
Naohiro Fujie
Plus de Naohiro Fujie
(20)
LINE Login総復習
LINE Login総復習
LINEログインの最新アップデートとアプリ連携ウォークスルー
LINEログインの最新アップデートとアプリ連携ウォークスルー
ざっくり解説 LINE ログイン
ざっくり解説 LINE ログイン
Azure AD x LINE x Auth0
Azure AD x LINE x Auth0
LINE Payも取り組んでいるKYCってなんだろう?KYCの基本と最近の動向
LINE Payも取り組んでいるKYCってなんだろう?KYCの基本と最近の動向
LIFFとの連携でさらに強力に。こんなに使えるLINEログイン
LIFFとの連携でさらに強力に。こんなに使えるLINEログイン
Azure ADの外部コラボレーションとBYOID
Azure ADの外部コラボレーションとBYOID
祝!公式サポート Auth0 + LINE Login
祝!公式サポート Auth0 + LINE Login
次世代KYCと自己主権型アイデンティティの動向
次世代KYCと自己主権型アイデンティティの動向
これからの KYC と Identity on Blockchain の動向
これからの KYC と Identity on Blockchain の動向
教育機関におけるBYOIDとKYC
教育機関におけるBYOIDとKYC
コンシューマIDのエンタープライズ領域での活用
コンシューマIDのエンタープライズ領域での活用
大学等におけるAzure AD B2Cを使用したSNS認証の活用
大学等におけるAzure AD B2Cを使用したSNS認証の活用
Azure AD B2C + LINE 学校や企業における次世代 ID/ メッセージ基盤
Azure AD B2C + LINE 学校や企業における次世代 ID/ メッセージ基盤
Azure ADとLINE連携により実現する学校や企業における次世代ID/メッセージ基盤
Azure ADとLINE連携により実現する学校や企業における次世代ID/メッセージ基盤
大学等におけるAzure AD B2Cを使用したSNS認証の活用
大学等におけるAzure AD B2Cを使用したSNS認証の活用
アイデンティティ API とデータ統合プラットフォームの活用
アイデンティティ API とデータ統合プラットフォームの活用
Office365のID基盤活用とセキュリティ上の注意点
Office365のID基盤活用とセキュリティ上の注意点
OAuth2.0によるWeb APIの保護
OAuth2.0によるWeb APIの保護
ID管理/認証システム導入の理想と現実
ID管理/認証システム導入の理想と現実
Dernier
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
Yuki Kikuchi
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
博三 太田
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
Hiroshi Tomioka
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
FumieNakayama
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NTT DATA Technology & Innovation
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
akihisamiyanaga1
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
UEHARA, Tetsutaro
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
FumieNakayama
Dernier
(8)
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
今なら間に合う分散型IDとEntra Verified ID
1.
今なら間に合う 分散型ID & Entra
Verified ID 2022/06/30 富⼠榮 尚寛 @phr_eidentity
2.
自己紹介 役割/活動 • OpenIDファウンデーション・ジャパン代表理事、KYC WG設立 •
米国OpenID Foundation eKYC and Identity Assurance WG, co-chair • 色々と委員(ISO、某官房、某研究所など) • 某SIerでビジネス開発 書き物など • Blog:IdM実験室(https://idmlab.eidentity.jp) • 監訳 : クラウド時代の認証基盤 Azure Active Directory 完全解説 • 共著 : クラウド環境におけるアイデンティティ管理ガイドライン その他活動 • 日本ネットワークセキュリティ協会アイデンティティ管理WG • Microsoft MVP for Enterprise Mobility(Jan 2010 -) • LINE API Expert (Feb 2018 -) • Auth0 Ambassador(Sep 2018 -)
3.
本日のネタ • 分散型IDとは? • なんで必要? •
コンセプトは? • 何ができる? • 何に使える? • Entra Verified IDとは? • どんなもの? • 使い方は? ※なるべく深いところまで掘り下げず、まんべんなく語るよう努力!
4.
インターネットにおける根本課題 新しい信頼モデルを作れないか? 新しい信頼モデルをベースとした新しい 経済圏を作れないか?
5.
ID領域における未解決問題 • アイデンティティ保証 • 誰がその属性を発行・保証しているのか? •
発行主体が無くなったらどうするのか? • 否認/アカウント停止(中央集権からのネグレクト) • なりすまし防止 • O2O Binding(本人確認)、安全なID連携 • プライバシー保護 • IDを握った企業が行動履歴を掌握 • 事業者間の名寄せによるプライバシー侵害
6.
ID領域における未解決問題 • アイデンティティ保証 • 誰がその属性を発行・保証しているのか? •
発行主体が無くなったらどうするのか? • 否認/アカウント停止(中央集権からのネグレクト) • なりすまし防止 • O2O Binding(本人確認)、安全なID連携 • プライバシー保護 • IDを握った企業が行動履歴を掌握 • 事業者間の名寄せによるプライバシー侵害 属性発行元が無くなっても 真正性を証明する方法 ID情報を 安全に伝える方法 IDプロバイダに行動履歴を 把握されない方法
7.
必要な要素と分散型IDにかかる技術要素 属性発行元が無くなっても 真正性を証明する方法 ID情報を 安全に伝える方法 IDプロバイダに行動履歴を 把握されない方法 自己主権型アイデンティティ (Self Sovereign Identity
– SSI) 分散型識別子 (Decentralized Identifiers – DID) 検証可能な属性情報 (Verifiable Credentials – VC) 技術要素 コンセプト
8.
分散型ID – 関連キーワードの整理 ž
自己主権型アイデンティティ(Self Sovereign Identity) ž 分散型識別子(Decentralized Identifiers) ž 検証可能な属性情報(Verifiable Credentials)
9.
自己主権型アイデンティティ(SSI) https://blog.goodaudience.com/how-blockchain-could-become-the-onramp-towards-self-sovereign-identity-dd234a0ea2a3
10.
自己主権型アイデンティティ(SSI) ž Sovrin foundationの定義 ž
自己主権型アイデンティティ(SSI)とは「個人は、管理主体が介在することなく、自身のア イデンティティを所有しコントロールできるべきである」、と考えるデジタル・ムーブメン トを表す言葉である。SSIを使うと、人々は現実世界で彼らが行っているのと同じ自由度と信 頼性をもってデジタル世界でも活動することが出来る。(https://sovrin.org/faq/what-is-self- sovereign-identity/) ž インテンション・エコノミー(Doc Searls / 2012) ž 顧客の意思に基づく経済(VRM)の実現 ž 企業が顧客の関心(アテンション)を中心に行う経済活動(CRM)と対局 ž 顧客が企業に自分自身の意思を持ってアイデンティティ情報を提供することで、 ž 企業がBig Dataをもとに推測したリコメンド・広告表示による気持ち悪さからの脱却 ž 企業が大量データを収集・分析を行うためのコストの削減 いつの間にか「アイデンティティの所有」の話になってきている??
11.
ž アテンション・エコノミー:顧客の関心が中心の経済 ž インテンション・エコノミー:顧客の意思が中心の経済 アテンション・エコノミーからインテンション・エコノミー
12.
ž 物理世界におけるお財布モデル 実現したいこと レンタル ビデオ店 コンビニ 会社 病院 利用者が自身で 選択して提示 発行元を信頼 発行元への問い 合わせは不要 IDの発行
13.
ž 物理世界におけるお財布モデル 提示されたID情報の信頼性の担保 レンタル ビデオ店 コンビニ 会社 病院 利用者が自身で 選択して提示 発行元を信頼 発行元への問い 合わせは不要 IDの発行 どうやって提示されたID情報の 真正性を発行元に問い合わせを せずに確認・検証するか
14.
ž 物理世界におけるお財布モデル 公開鍵基盤の利用 レンタル ビデオ店 コンビニ 会社 病院 利用者が自身で 選択して提示 発行元を信頼 IDの発行 公開鍵基盤
15.
ž 物理世界におけるお財布モデル 課題①:誰が公開鍵基盤を運営するか? レンタル ビデオ店 コンビニ 会社 病院 利用者が自身で 選択して提示 発行元を信頼 IDの発行 誰が公開鍵基盤を運営するか? 公開鍵基盤
16.
ž 物理世界におけるお財布モデル 課題②:そこに悪意はないのか? レンタル ビデオ店 コンビニ 会社 病院 利用者が自身で 選択して提示 発行元を信頼 IDの発行 IDの発行元、公開鍵基盤運営側 による改竄や否認はないのか? 公開鍵基盤
17.
ž 物理世界におけるお財布モデル 分散台帳の利用 レンタル ビデオ店 コンビニ 会社 病院 利用者が自身で 選択して提示 発行元を信頼 IDの発行 公開鍵基盤 on 分散台帳 財布の登録 +IDとの紐づけ
18.
19.
自分の意思を持ってアイデンティティ情報を提供 ž 利用者目線で必要なこと→ポータブルであること ž 事業者になるべく依存せず(例:IdPが落ちていたり、IdPによってBANされることなく)自 身の属性情報をサービス提供者へ選択的に開示 ž
一方でサービス事業者目線では→高度な信頼 ž 提供された属性情報を信頼できること(事業者の介在なく提供された情報への信頼) ž 「No trust, more truth」に通じる?「Trust, but verify(信じよ、されど確認せよ)」 ※信頼とは? 事実の確認をしない状態で、相手先が期待したとおりに振る舞うと信じる度合い (内閣官房/Trusted Web推進協議会の定義より)
20.
信頼のDXの要が「DID、VC」 ポータブル ⾼度な信頼 従来のデジタルID 物理世界のID 分散型ID (DID/VC) ポイント 利⽤者の意思で、 • いつでも使える • 使い分けができる (持ち運べること) •
スマホ、NFCチップ等に IDを⼊れて持ち運ぶ • 提⽰属性の選択・使い分 けができる 中⼼となる技術要素 • 分散台帳上で管理される分散型識別⼦(Decentralized Identifiers / DID) • 分散型識別⼦と関連付けされた公開鍵で検証可能な属性情報(Verifiable Credentials / VC) • 財布に⼊れて免許証、社 員証などを持ち運ぶ • 使い分けができる • IDシステム状態に依存す る(システム停⽌、アカ ウント停⽌等) • 提⽰情報の使い分けは難 しい(利⽤者の意思は反 映されにくい) 受取った側が、 • 真贋判別が出来る (検証可能であること) • 分散台帳上の公開鍵を使 い、ID発⾏元への問い合 わせせずに検証可能(永 続性の担保、事業者依存 からの脱却) • IDシステムでユーザ認証 して検証する(認証強度 によりID漏洩の危険性) • IDシステム状態に依存す る(システム停⽌等) • 対⾯で表情などを含め総 合的に判断 • 勘と経験で免許証の真贋 を判断 ID漏洩、プライバシ問題 対⾯前提、勘と経験 真のDXの要として注⽬
21.
分散型識別子(DID/Decentralized Identifiers) ž 特定の事業者に依存しない識別子(Identifier) ž
Identity(属性の集合)ではなく、Identifier(識別子) ž W3Cにより標準化(did:method:xxxx) ž DIDと紐づく鍵ペアを生成、秘密鍵へのアクセス=「所有」 ž 識別子に紐づくDID Documentが分散台帳上等で公開される ž DIDに紐づく秘密鍵で署名したデータをDID Document上の公開鍵で検証する ことでDIDの「持ち主」が発行したデータであることを検証できる(VCはこ の仕組みを利用) ž 事業者の都合(倒産やアカBANなど)で公開鍵の取り消しや改竄ができない ため、自己主権っぽく見える(そのためにはPermissionlessなチェーンが望ま しいが実態は・・・)
22.
何が分散 ž 系の分散:特定の系への依存度を下げる(ソーシャルログオンと同レベル) ž 系の中でのノード分散:系を運営する事業者への依存度を下げる(本質) 基盤レイヤ データレイヤ APIレイヤ sovrin
bitcoin ethereum ION(sidetree) N N … N N N … N N N … N ・・・ did:sov:xxx did:btcr:xxx did:ion:xxx did:eth:xxx ・・・ Discovery Service(Universal resolver等) driver driver driver driver ・・・
23.
ざっくり言うと ž 各エンティティがメソッド単位で鍵ペアに紐づくDIDを取得する ž メソッド(ionとかbtcrとかethrとか)ごとのノードの運営が特定事業者に限定されないので、 少なくとも識別子の単位で勝手に消されたり、公開されるDID
Documentが改ざんされる恐れ は少ない=分散、事業者非依存、SSIというキーワードへ繋がっている ž よくある質問 ž メソッドを跨いでDIDを引っ越すことはできる? ž できません。SSIと言いつつメソッドの系への依存はします。 ž DID Documentを分散台帳へ記録するためのコストは誰が負担するの? ž 系によってまちまちです。Sovrin foundationだとFoundationへの参加した組織だけが書き込めて、トランザクショ ンごとに費用が発生していたはず。 ž 鍵のローテーションはどうする? ž DID Documentの更新(公開鍵の追加)を行います。過去の秘密鍵で署名されたVCは過去の公開鍵で検証ができる ので、少なくとも当該のDIDを管理しているエンティティにより署名された過去があることはわかります。
24.
検証可能な属性情報(VC/Verifiable Credentials) ž 検証可能なデータモデル ž
発行者(Issuer)のDIDに紐づく秘密鍵によりデジタル署名される ž 発行者のDID Documentに含まれる公開鍵を使って検証可能 ž エンティティ間でのトランスポートはW3C定義外。ここはOIDC4VCやDIDCommの範囲 分散台帳(DID Documentを配置) ⾏政/キャリア/企業 など 個⼈のID Wallet アプリケーション VP: Verifiable Presentation VCを複数束ねたもの
25.
メリット ž Issuerの事業継続性を気にする必要がない(OIDCとの対比で言うと、IdPがなく てもRPがid_tokenの検証ができる)⇒過去のVCを検証可能、疎結合でOK ž 複数Issuerから発行されたVCをまとめて提示可能 分散台帳(公開鍵基盤) 個⼈のID
Wallet アプリケーション
26.
ざっくり言うと ž 関連エンティティ ž VC発行者(Issuer)、利用者(Holder)、VC消費アプリ(Verifier) ž
単なるJSON/JSON-LDであるVCやVPへ、DIDに紐づく秘密鍵で署名をする ž OIDCと対比し、RP(Verifier)目線で言うとこんな感じ。 ž よくある質問 ž VCの発行元(VC内のIssuerとして指定されているDIDの持ち主)は誰か?をどうやって判 別・信頼するのか? ž DNSにバインド。DID Document内のLinked Domainに記載のあるドメイン配下に/.well-known/did- configuration.jsonを配置。受け取ったら検証 → よく考えると結局疎結合になりきれない・・・ 取得元 Verify用の公開鍵 含めることのできる属性 何を信じるか Id_token IdP Jwks_uriから取得 IdPが発行したもの (Aggregatedだと元CPの署名検証は不 可) IdP VP Holder DID Documentから取得 複数のVCをVPに含めることで複数の発 行元から検証可能な状態で取得可能 DID Documentが格納され る分散台帳の系
27.
実は最も重要なこと)DIDとVCを切り離す ž VCはあくまでデジタル署名されたデータセット ž id_tokenとほぼ変わらない ž
iss/subにDIDを用いる必要はない ž 実際、ワクチン接種証明はVerifiable Credentials ž スキーマ:FHIR ž Issuer:https://vc.vrs.digital.go.jp/issuer ž 署名:デジタル庁の自己証明書書 ž 参考) ž https://idmlab.eidentity.jp/2021/12/verifiable-credentials.html ž DIDと組み合わせることで得られるのは疎結合 ž 署名検証を行う際にIssuerの公開鍵を取得する方法の違い ž jwks_uriエンドポイントへのアクセスによる取得 → DID Documentから取得 ž DID Documentが分散台帳上にあることでIdP(Issuer)とRP(Verifier)の直接通信は不要となる
28.
分散型IDは自己主権型IDを実現するのか? ž 「IDの所有」と呼ぶにはあまりにも限定的 ž 確かに事業者の都合で署名済みのVC=デジタルIDが使えなくなるリスクは低減できる ž
WalletにVCを入れればポータビリティっぽく見える ž 真の価値は「IDプロバイダへの依存度を下げる」ことではないか? ž ユーザ目線では、「IdPが落ちていてもサービスが継続して利用できる」 ž 事業者目線では、「IdPの可用性要件を下げられる」「継続的なID管理が不要となる」 ž こう考えるとユースケースが見えてくる ž 情報管理はしたくないが、ID発行事業者として身元保証はしたい ž ID発行事業者に知られることなくサービスを利用したい ž IdPとサービスが連携できないスケールのサービス ž 例)大学における卒業生の管理、資格証明(資格試験、所属等)、スマートシティ、etc
29.
ID基盤のパラダイム変化 従来のID基盤 分散型IDによる変化 ü ID管理は最低限
→ ID管理は利⽤者側へシフト ü 本⼈確認(eKYC等)によるIDリカバリが重要 ü 提供するIDサービス(認証等)も最低限 → 影響度低 ü サービスとID基盤が疎結合 → スケールしやすい ü 利⽤者のIDの維持が重要 ü 滅多にログインしないユーザでもID維持が必要 ü 利⽤者へIDサービス(認証等)を提供 → 可⽤性が⼤切 ü サービスとID基盤が密結合 → スケールしにくい ID基盤 サービス ID管理 管理者 利⽤者 利⽤者 頻度低 攻撃者 ID搾取 ID連携(密結合) なりす まし サービス 利⽤ 認証 滅多に使わない⼈の IDも維持・管理が必要 (ライセンス費⽤増) 滅多に使わない⼈の 認証情報は漏洩しても 気が付きにくい (リスク増) ID基盤 サービス ID管理 管理者 利⽤者 利⽤者 頻度低 ID情報 ID連携不要(疎結合) サービス 利⽤ 最低限のID管理で⼗分 (ライセンス最適化、 リスク低減) ID情報を個⼈に持たせ る=ロストした場合の リカバリが必要 (本⼈確認) ID発⾏ /取消 ID情報 本⼈確認 〜リカバリ
30.
ID基盤のパラダイム変化 従来のID基盤 分散型IDによる変化 ü ID管理は最低限
→ ID管理は利⽤者側へシフト ü 本⼈確認(eKYC等)によるIDリカバリが重要 ü 提供するIDサービス(認証等)も最低限 → 影響度低 ü サービスとID基盤が疎結合 → スケールしやすい ü 利⽤者のIDの維持が重要 ü 滅多にログインしないユーザでもID維持が必要 ü 利⽤者へIDサービス(認証等)を提供 → 可⽤性が⼤切 ü サービスとID基盤が密結合 → スケールしにくい ID基盤 サービス ID管理 管理者 利⽤者 利⽤者 頻度低 攻撃者 ID搾取 ID連携(密結合) なりす まし サービス 利⽤ 認証 滅多に使わない⼈の IDも維持・管理が必要 (ライセンス費⽤増) 滅多に使わない⼈の 認証情報は漏洩しても 気が付きにくい (リスク増) ID基盤 サービス ID管理 管理者 利⽤者 利⽤者 頻度低 ID情報 ID連携不要(疎結合) サービス 利⽤ 最低限のID管理で⼗分 (ライセンス最適化、 リスク低減) ID情報を個⼈に持たせ る=ロストした場合の リカバリが必要 (本⼈確認) ID発⾏ /取消 ID情報 本⼈確認 〜リカバリ 卒業⽣、研究者のID管理シナリオ • 過去に在籍したことの証明 • 卒業・離籍後も⼤学に残した研究データへ継続的にアクセス許可 サプライチェーンのID管理シナリオ • 企業への所属証明、アクセス権限の証明 • OEM企業側でのID管理・パスワード管理の⼿間を⼤幅に削減 顧客、⾃治体における個⼈ID管理シナリオ • SNSを使った簡易ID登録と⾝元保証の両⽴、事業者への依存度低減 • 年齢等の⾝元確認(公的な⾝分証明の電⼦化) 従業員、学⽣のID管理シナリオ • ⼊社、⼊学時の⾝元確認(公的な⾝分証明の電⼦化) • パスワードレス、オンラインでのアカウント払い出し
31.
Microsoft Entra
32.
Microsoft Entra 3つのコンポーネントをまとめてリブランド ž Azure
Active Directory ž Permissions Management(旧CloudKnox Permissions Management) ž Verified ID(旧Azure AD Verifiable Credentials) https://news.microsoft.com/ja-jp/2022/06/01/220601-secure-access-for-a-connected-worldmeet-microsoft-entra/
33.
新ポータル:https://entra.microsoft.com
34.
新ポータル:https://entra.microsoft.com 本日の主役 Entra Verified ID 8月にGAらしい https://www.microsoft.com/security/blog/2022/05/31/secure-access-for-a-connected-worldmeet-microsoft-entra/
35.
キーワードの整理 先に紹介したキーワード ž 分散型ID(Decentralized Identifiers) ž
検証可能な資格情報(Verifiable Credentials) Microsoft Entraにおけるキーワード ž 検証済みID(Verified ID) 読み解けること • 分散型ID(DID)とは切り離して考え、本質的な検証可能な資格情報(VC)にフォーカス • 資格情報(Credentials)だけではなくもっと幅広くIdentity(属性の集合)を扱う • 検証可能/検証済みの差についてはIdentity Proofing(KYC)とのセットで考えている
36.
想定されているシナリオ群 ž リモートオンボーディング ž アクセスのセキュリティ強化 ž
アカウント回復 ž その他 https://www.microsoft.com/ja-jp/security/business/identity-access/microsoft-entra-verified-id
37.
本人確認プロバイダーとの提携 ž 公的身分証明書(免許、パスポート、マイナンバーカードなど)を 使った本人確認(Identity Proofing/KYC)サービスを提供している 事業者との連携による本人確認済みIDを発行 https://www.microsoft.com/ja-jp/security/business/identity-access/microsoft-entra-verified-id
38.
ユースケース ž 日本においても慶應義塾が初期ユーザとなっている https://www.microsoft.com/ja-jp/security/business/identity-access/microsoft-entra-verified-id
39.
パートナープログラム ž まだまだ少ない。現状アジア圏ではCTCが唯一。 https://www.microsoft.com/ja-jp/security/business/identity-access/microsoft-entra-verified-id
40.
Entra Verified IDの歩き方 ž
組織IDの設定 ž 要するにIssuer設定 ž 資格情報 ž 要するにVerifiable Credentialsの設定 ž 発行と検証 ž Verifiable Credentialsの発行と検証 ž 発行済みVCの取り消し
41.
準備 ž 最低限必要なもの ž キーコンテナ(Key
Vault) ž Azure Key VaultじゃなくてKey Vault ž ストレージアカウント(Blob) ž Verifiable Credentialsに表示するロゴファイル ž 定義体(Rules、Display)※Managedを使う場合は不要 ž Webサーバー ž Static Web AppでもOK(.well-knownというパスを作るのでStorageじゃダメ) ž DNSベースでIssuerを信頼するためのファイルを公開 ž did:web(既定)を使う場合はdid documentも公開 ž 合わせてデプロイ元となるGithubアカウントとレポジトリ ž API実行用のアプリ登録 ž Azure ADへのアプリ(client)登録とAPIアクセス許可 ž Preview時代に必要だったAzure AD Premium P2は不要になった
42.
Key Vault設定 ž Entra
Verified IDの設定を行 う管理ユーザへ[署名]権限の 付与(アクセスポリシー) ž Entra Verified IDの管理APIが Application Permissionでは なくDelegated Permissionで 動作するため管理ユーザに 権限付与が必要
43.
Storageアカウント設定 ž Blobにロゴファイルを置く場合は匿名アクセスを許可 (AuthenticatorからInternet経由でアクセスされるため)
44.
Webサーバ設定 ž Entra Verified
ID(Issuer)の所有権確認を行う ž /.well-known/did-configuration.jsonファイルの配置 ž DIFのWell Known DID Configuration仕様に従った実装 ž DIDがどの組織のものなのかを確認するため、DID Document内のLinked Domainとして設定 されたドメイン直下の.well-known/did-configuration.jsonにIssuerのDIDに関連するデータを 配置する ž VCを受け取ったエンティティ(HolderやVerifier)はVCのIssuerのDIDからDID Documentを取 得、Linked Domainに指定されたドメインからdid-configuration.jsonを取得、正しい発行者の DIDであることを検証する(DNSのガバナンスに依拠している) ž Webサーバはなんでも良いが、.well-knownというパスを作れる必要があるのでStorageだと ダメ([.]始まりがNG) ž どっちにしろ後でIssuerのプログラムを配置することになるので、Web Appとかで良い
45.
Entra Verified ID設定:組織IDの設定(Issuer設定) ž
組織名 ž Issuerの組織名 ž ドメイン ž IssuerのDIDにリンクされるドメイン名 ž DID Document内のLinked Domainの値 ž キーコンテナ ž Issuer DIDに紐づく鍵ペアの管理 ž 代替信頼システム ž DIDメソッド(did:webかdid:ion) ž 既定はdid:web
46.
DIDメソッドの選択について ž did:web(既定) ž did:web:{リンクされたドメイン名}という形式。例)did:web:pharaoh.entraid.xyz ž
DID Documentはhttps://{リンクされたドメイン名}/.well-known/did.jsonに配置される ž つまり、厳密には分散型IDではない ž did:ion ž did:ion:{内部識別子}という形式。例) did:ion:EiDBUQo0aGP1tSnp2….Wm13In19 ž Bitcoin上に構成されたSidetreeプロトコルであるION(Identity Overlay Network)を利用 ž DID/DPKIをサポートするため、Bitcoin上にLayer2を構成、多数のオペレーションを直接 Bitcoinネットワークへ流さないことで省エネ、省コストを実現 ž トランザクションがある程度溜まるまではIPFS上で管理(この間はlong-formの識別子を利用) ž 一定数溜まったらBitcoinへ書き込み(書き込み終わったらshort-formの識別子を利用)※現状のMicrosoftの実装で は書き込んでいない
47.
ドメインの検証 ž did-configuration.jsonを 配置して所有権を検証 ž did:webの場合はdid.json (DID
Documentそのも の)も配置する必要あり ž did:ionの場合はIONネッ トワーク上にDID Documentが浸透するま では検証できないのでし ばらく待ち(ion explorer で確認可) ION Explorer https://identity.foundation/ion/explorer
48.
Universal ResolverでDID Documentを確認 https://dev.uniresolver.io/
49.
資格情報 ž Verifiable Credentialsの定義を作成する
50.
資格情報の定義 ž 資格情報名 ž 表示の定義(Display) ž
Authenticator上に表示される資格情報 ž ロゴ、色、文言 ž ルールの定義(Rules) ž 発行方法 ž 属性のマッピング
51.
表示の定義 ž locale:表示言語 ž card:資格情報(カード表記) ž
backgroudColor:背景色(RGB) ž description:説明 ž issuedBy:発行者 ž textColor:テキスト色(RGB) ž title:タイトル ž logo:URL、description ž consent:同意に関する表記 ž claims:属性の表記 https://docs.microsoft.com/ja-jp/azure/active-directory/verifiable-credentials/credential-design
52.
表示の定義(例) { "locale": "en-US", "card": { "backgroundColor":
"#000000", "description": "Entra Seminar Attendee's Proof", "issuedBy": "M365 Study Group", "textColor": "#ffffff", "title": "Entra Seminar", "logo": { "description": "Mokudai-san", "uri": "https://entrapharaohguitar.blob.core.windows.net/logo/ mokudai.jpeg" } }, "consent": { "instructions": "M365勉強会に参加した証です。", "title": "発行します。同意してね" }, "claims": [ { "claim": "vc.credentialSubject.firstName", "label": "Name", "type": "String" }, { "claim": "vc.credentialSubject.lastName", "label": "Surname", "type": "String" } ] }
53.
ルールの定義 ž attestations:発行する資格情報のもととなる属性取得元 ž IdTokenAttestation: ž
Authenticator内で外部IdP(OpenID Connect)で認証しid_tokenを取得 ž IdTokenHintAttestation: ž 事前にIssuer側で外部IdPで認証、発行リクエスト内に属性を指定(id_token_hint) ž verifiablePresentaionAttestation ž 別の資格情報から属性を取得 ž selfIssuedAttestation ž Authenticator内で属性値を自分で入力させ取得 ž mappings:発行元の属性と資格情報内の属性のマッピング ž validityInterval:資格情報の有効期間 ž vc/type:資格情報のタイプ https://docs.microsoft.com/ja-jp/azure/active-directory/verifiable-credentials/credential-design
54.
ルールの定義(例) { "attestations": { "selfIssued": { "mapping":
[ { "outputClaim": "firstName", "required": true, "inputClaim": "firstName", "indexed": false }, { "outputClaim": "lasttName", "required": true, "inputClaim": "lastName", "indexed": true } ], "required": false } }, "validityInterval": 2592001, "vc": { "type": [ "VerifiedCredentialExpert" ] } }
55.
資格情報の定義 ž 作成するとマニフェストが生成される(表示・ルールの定義) ž 例)https://beta.did.msidentity.com/v1.0/0fd7c1d1-82e9-42f6-9bd4- 8ea45e372d11/verifiableCredential/contracts/Entra%20Seminar%2020220630
56.
資格情報の発行 ž 2通りの発行方法 ž Issuance
APIを実行する ž Azure ADに登録したアプリケーションの権限で実行する(client_credentialsで取得したaccess_tokenを使用) ž Issuance APIを使う発行用のWebアプリケーションの開発が必要 ž 一般コンシューマ向けの資格情報発行シナリオ ž OpenID for Verifiable Credential Issuanceの仕様に則ったやりとり ž https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html ž 組織に登録されたAuthenticatorへプッシュ通知を送る ž Azure ADのグループ単位でプッシュ ž 従業員向けの資格情報(社員証、学生証など)発行シナリオ ž 現状はIssuance APIを利用する方法のみ利用可能
57.
資格情報の発行 ž 呼び出すAPIエンドポイントとRequest Bodyのテンプレート ž
値を置き換えて利用 ž Callback ž Authority ž Registration ž Issuance ž 通常はアプリ内でAPI を呼び出すがPostmanで テストする
58.
資格情報の発行 ž client_credentialsでaccess_tokenを取得しAuthorizationヘッダへ設定
59.
資格情報の発行 ž エンドポイントとBodyをセットしてPOST
60.
資格情報の発行 ž Callbackには発行状態に関する 情報がPOSTされてくるのでテ スト時はローカルにエンドポイ ントを立てて、ngrok等でイン ターネットへ公開
61.
資格情報の発行 ž リクエストが成功するとurlが返ってくるので、QRコード化して Authenticatorで読み込む QRコード生成は適当なサイトで 例)https://www.cman.jp/QRcode/
62.
資格情報の発行 ちなみにWalletはMS Authenticatorだけでなく、自作 してもOK(SDK利用、もしくはAPIを素で叩く)
63.
資格情報の検証 ž Presentation APIを実行する ž
基本的な考え方はIssuance APIと一緒 ž エンドポイントも同じ ž Request BodyのIssuance部分をPresentationに変えるだけ "presentation": { "includeReceipt": true, "requestedCredentials": [ { "type": "VerifiedCredentialExpert", "purpose": "the purpose why the verifier asks for a VC", "acceptedIssuers": [ "did:ion:pQy1oU0ZVblRfkhqZ2Y5bjFOamJUQnZ1Wm13In19" ] }] }
64.
資格情報の検証 ž callbackに指定したURLへ提示されたVCの情報が送られてくる ž OpenID
for Verifiable Presentationに則ったやりとり ž https://openid.net/specs/openid-4-verifiable-presentations-1_0.html ž Body ž id_token ž Subject ž Audience ž VP(Verifiable Presentation)に関するメタデータ ž vp_token ž 提示されたVCを含むトークン
65.
資格情報の検証 ž 結構深いネストでJWTが構成されているが解いていくと属性発見
66.
発行済みVCの取り消し ž VCのライフサイクル ž 有効期限:VC発行時に設定(Verify時に期限切れとわかる) ž
明示的な取り消し:管理ポータルから取り消し(現状APIは未提供) ž 明示的な取り消し ž Index属性をベースに取り消し(ルール定義でIndexed: trueにした属性)
67.
まとめ+α
68.
再掲)ID基盤のパラダイム変化 従来のID基盤 分散型IDによる変化 ü ID管理は最低限
→ ID管理は利⽤者側へシフト ü 本⼈確認(eKYC等)によるIDリカバリが重要 ü 提供するIDサービス(認証等)も最低限 → 影響度低 ü サービスとID基盤が疎結合 → スケールしやすい ü 利⽤者のIDの維持が重要 ü 滅多にログインしないユーザでもID維持が必要 ü 利⽤者へIDサービス(認証等)を提供 → 可⽤性が⼤切 ü サービスとID基盤が密結合 → スケールしにくい ID基盤 サービス ID管理 管理者 利⽤者 利⽤者 頻度低 攻撃者 ID搾取 ID連携(密結合) なりす まし サービス 利⽤ 認証 滅多に使わない⼈の IDも維持・管理が必要 (ライセンス費⽤増) 滅多に使わない⼈の 認証情報は漏洩しても 気が付きにくい (リスク増) ID基盤 サービス ID管理 管理者 利⽤者 利⽤者 頻度低 ID情報 ID連携不要(疎結合) サービス 利⽤ 最低限のID管理で⼗分 (ライセンス最適化、 リスク低減) ID情報を個⼈に持たせ る=ロストした場合の リカバリが必要 (本⼈確認) ID発⾏ /取消 ID情報 本⼈確認 〜リカバリ
69.
再掲)ID基盤のパラダイム変化 従来のID基盤 分散型IDによる変化 ü ID管理は最低限
→ ID管理は利⽤者側へシフト ü 本⼈確認(eKYC等)によるIDリカバリが重要 ü 提供するIDサービス(認証等)も最低限 → 影響度低 ü サービスとID基盤が疎結合 → スケールしやすい ü 利⽤者のIDの維持が重要 ü 滅多にログインしないユーザでもID維持が必要 ü 利⽤者へIDサービス(認証等)を提供 → 可⽤性が⼤切 ü サービスとID基盤が密結合 → スケールしにくい ID基盤 サービス ID管理 管理者 利⽤者 利⽤者 頻度低 攻撃者 ID搾取 ID連携(密結合) なりす まし サービス 利⽤ 認証 滅多に使わない⼈の IDも維持・管理が必要 (ライセンス費⽤増) 滅多に使わない⼈の 認証情報は漏洩しても 気が付きにくい (リスク増) ID基盤 サービス ID管理 管理者 利⽤者 利⽤者 頻度低 ID情報 ID連携不要(疎結合) サービス 利⽤ 最低限のID管理で⼗分 (ライセンス最適化、 リスク低減) ID情報を個⼈に持たせ る=ロストした場合の リカバリが必要 (本⼈確認) ID発⾏ /取消 ID情報 本⼈確認 〜リカバリ 卒業⽣、研究者のID管理シナリオ • 過去に在籍したことの証明 • 卒業・離籍後も⼤学に残した研究データへ継続的にアクセス許可 サプライチェーンのID管理シナリオ • 企業への所属証明、アクセス権限の証明 • OEM企業側でのID管理・パスワード管理の⼿間を⼤幅に削減 顧客、⾃治体における個⼈ID管理シナリオ • SNSを使った簡易ID登録と⾝元保証の両⽴、事業者への依存度低減 • 年齢等の⾝元確認(公的な⾝分証明の電⼦化) 従業員、学⽣のID管理シナリオ • ⼊社、⼊学時の⾝元確認(公的な⾝分証明の電⼦化) • パスワードレス、オンラインでのアカウント払い出し
70.
再掲)想定されているシナリオ群 ž リモートオンボーディング ž アクセスのセキュリティ強化 ž
アカウント回復 ž その他 https://www.microsoft.com/ja-jp/security/business/identity-access/microsoft-entra-verified-id
71.
DID/VC開発者向けコミュニティを立ち上げます Japan DID Developer
Community ž DID/VCに興味がある人が集まる場 ž Discordチャネル開設しました ž https://discord.gg/nn53BRRz ž これからのコミュニティなので一緒に盛り 上げていってもらいたいです!
Télécharger maintenant