ラベル OpenBadge の投稿を表示しています。 すべての投稿を表示
ラベル OpenBadge の投稿を表示しています。 すべての投稿を表示

2024年9月20日金曜日

MVPアワードでもらったOpenBadgeを覗いてみる

こんにちは、富士榮です。

MicrosoftからMVP(Most Valuable Professional)というアワードをいただき初めて今年で15年目、という話を前に書きましたが、最近この手のアワードやIT系の資格試験などではOpenBadge形式で資格証明がもらえることがあります。

これまで何度かイベントではOpenBadgeの中身について話をしてきましたが、要するにPNGやSVGファイルの中身(PNGならiTXt領域、SVGならopenbadge属性)へJSON-LDで記述されたクレデンシャルの情報を埋め込んでいます(OpenBadge 2.0、Hosted形式の場合)。

この埋め込み作業のことをBake(ベイク)と言い、こちらに技術仕様が公開されています。

https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/baking/index.html


なお、最近はOpenBadge 3.0がW3C Verifiable Credentials Data Model 2.0を使って定義されようとしています。(Finalizeと言いつつVCDM2.0がFinalにならないのでどうするつもりなんだ、という話もありますが)

OpenBadgeにはHosted型とSigned型の2種類が定義されており、これまでは検証時に発行者のURLへ問い合わせを行うHosted型が中心でしたが、OpenBadge 3.0からはVerifiable Credentialsを利用することでSigned型(バッジ単体で検証ができる)が中心になってくると思われます。


ただ、現状はMVPバッジはCredly社(IT系の資格の受験をするときにお世話になった方も多いであろうピアソン社を数年前に買収した会社で民間の資格証明の最大手ですね)が発行するOpenBadge 2.0、Hosted型のバッジです。

こんな感じでCredlyのバッジポータルでバッジの確認やダウンロードができます。



ちなみに実際のOpenBadgeイメージはこちらから取得できますので、こうやってブログやWebサイトで他の方へ提示(配布)することもできるわけです。




さて、では中身を覗いてみましょう。

先ほど書いた通りiTXt領域にJSON-LD形式で埋め込まれているわけですが、IMS Globalがこちらで検証サイトを公開しているので、こちらを使いましょう。

https://openbadgesvalidator.imsglobal.org/

このサイトを使って取り出したOpenBadgeがこちらです。

{
    "input": {
        "value": "https://www.credly.com/api/v1/obi/v2/badge_assertions/8793fdbf-80a5-4240-977e-12ac45574df3",
        "input_type": "url"
    },
    "graph": [
        {
            "@context": "https://w3id.org/openbadges/v2",
            "type": "Assertion",
            "issuedOn": "2024-09-17T00:00:00.000Z",
            "recipient": {
                "type": "email",
                "identity": "sha256$071281e466032326ffe4c3238545d31970b2b61d75fae181a283ac0aace09264",
                "hashed": true
            },
            "badge": "https://www.credly.com/api/v1/obi/v2/issuers/214390fb-07bc-4575-80f2-f2c325f71c49/badge_classes/2b797f06-fdd4-4ec7-b13c-e8f79915da0c",
            "verification": {
                "type": "HostedBadge"
            },
            "evidence": [],
            "id": "https://www.credly.com/api/v1/obi/v2/badge_assertions/8793fdbf-80a5-4240-977e-12ac45574df3"
        },
        {
            "@context": "https://w3id.org/openbadges/v2",
            "tags": [
                "Community",
                "Leadership",
                "Technology"
            ],
            "name": "2024 Microsoft Most Valuable Professional (MVP)",
            "image": "https://images.credly.com/images/9e9359a4-fe7e-4e02-8eb0-6c2b7947345a/image.png",
            "alignment": [],
            "criteria": {
                "narrative": "Award: Individuals must have deep knowledge and expertise aligned to a Microsoft product or service or related open-source technologies. Through community work, qualifying applicants should be able to demonstrate their technical expertise. https://mvp.microsoft.com/",
                "id": "https://www.credly.com/org/microsoft-student-programs/badge/2024-microsoft-most-valuable-professional-mvp"
            },
            "id": "https://www.credly.com/api/v1/obi/v2/issuers/214390fb-07bc-4575-80f2-f2c325f71c49/badge_classes/2b797f06-fdd4-4ec7-b13c-e8f79915da0c",
            "type": "BadgeClass",
            "description": "The Microsoft MVP Program recognizes outstanding members of technical communities for their community participation and willingness to help others. Above all else, it is a people-powered program, made up of individuals whose passionate commitment to innovation has made its dynamic growth possible.",
            "issuer": "https://www.credly.com/api/v1/obi/v2/issuers/214390fb-07bc-4575-80f2-f2c325f71c49"
        },
        {
            "@context": "https://w3id.org/openbadges/v2",
            "type": "Issuer",
            "id": "https://www.credly.com/api/v1/obi/v2/issuers/214390fb-07bc-4575-80f2-f2c325f71c49",
            "name": "Microsoft MVP and Student Ambassadors Communities",
            "image": "https://images.credly.com/images/8f11d73e-9c33-4788-a602-88c761957c90/blob.png",
            "description": "The Microsoft MVP and Student Ambassadors Programs are communities where student experts, technology professionals or industry leaders transform their passions and skills into globally recognized community leadership.",
            "email": "info@credly.com",
            "url": "https://mvp.microsoft.com/"
        }
    ],
    "report": {
        "valid": true,
        "messages": [],
        "warningCount": 0,
        "validationSubject": "https://www.credly.com/api/v1/obi/v2/badge_assertions/8793fdbf-80a5-4240-977e-12ac45574df3",
        "openBadgesVersion": "2.0",
        "errorCount": 0
    }
}

このとおり、IssuerはCredly社となっており、マイクロソフトが直接発行しているわけではないことがわかります。
また、OpenBadgeの特徴としてあくまで資格情報を表現するものとなっていることが挙げられます。何を言っているかというとバッジを提示する人とバッジが指し示す人が一致していることは表現していないということです。(私が他人のバッジを保持して提示することも可能。まぁ単なる画像ファイルですから当然ですね)
そのため、Verifyをする際にバッジを提示する主体とバッジが指し示す主体が一致していることを検証サイト側で行うことが必要となります。

具体的な方法としては、recipientのidentity要素に入っている値(バッジが指し示す主体)が提示してくる主体と同じことを確認することになりますので、提示する際に利用者にメールアドレス(type: emailの場合)を入力させ、
  1. 到達性確認を行うことで提示者が当該メールアドレスに対してアクセスが可能な状態であることを確認する
  2. 到達性確認ができたメールアドレスとバッジを検証URL(発行元。今回のケースだとCredly)へ投げ込む
  3. 検証URL側は自身が管理するsalt値を使って送られてきたメールアドレスの値をSHA256(もしくはMD5)でハッシュ化する
  4. バッジの中にはいっているidentityの値と生成したハッシュ値が同一であることを確認する(提示者はバッジの中を見てもメールアドレスの値がハッシュ化されているため、誰のバッジかわからない。持ち主だけがバッジ発行時のRecipient情報として設定したメールアドレスを知っているので発行対象の主体とバッジの指し示す主体が一致しているであろうことを推測する)
この部分)
            "recipient": {
                "type": "email",
                "identity": "sha256$071281e466032326ffe4c3238545d31970b2b61d75fae181a283ac0aace09264",
                "hashed": true
            },


非常に簡易的な仕組みですが、身分証明に使うわけではありませんしこのくらいのゆるさでもOKってことでしょう。

しかしVCにもVC2.0があったり、SD-JWTがあったりと複雑ですが、こういう形で教育業界でもOpenBadgeのバージョンやアーキテクチャ(Hosted/Signedなど)の混在による混乱もありそうですね。

引き続き見ていきたいと思います。


2024年6月12日水曜日

Verifiable Credentials改めReusable Identity?何をどこまで検証すべきなのか

こんにちは、富士榮です。

先日のIdentiverseやEuropean Identity & Cloud Conferenceで目についたのが「Reusable Identity」というキーワード。

どうも話の流れを聞いていると、一般名詞としてのVerifiable Credentials(mDocやSD-JWT-VCやW3C VCDM、anonCredまで含む)の中でIdentity Verificationに使うものをReusable IdentityとかDecentralized Reusable Identityと呼ぶことに(誰かが)したらしいです。

openart.aiに描かせてみたら、なんだか資源ごみみたいになってしまった。

ちょっと検索してみると、identity.comの人のこんな記事が見つかりました。

What Is a Reusable Identity?

Reusable identity is a single set of identity credentials that allows individuals to access multiple platforms without repetitive verification. Unlike traditional centralized systems, which demand separate identity verifications for each service or platform, a reusable identity streamlines the user experience. This approach reduces the burden of multiple verifications and addresses inefficiencies and security risks linked to the repeated sharing of personal information.

再利用可能な ID とは?

再利用可能な ID とは、個人に複数のプラットフォームへのアクセスを許可する、1 セットの ID 認証情報です。従来の中央集権型システムとは異なり、各サービスやプラットフォームごとに個別の ID 認証を要求するシステムとは異なり、再利用可能な ID はユーザーエクスペリエンスを合理化します。このアプローチは、複数の認証の負担を軽減し、個人情報の繰り返し共有に伴う非効率性とセキュリティリスクに対処します。(Deeplによる機械翻訳) 

https://www.identity.com/what-is-reusable-identity/


この話とWalletのセキュリティの話がかなり密接に結びついて分類が始まってきているように思えているので、今日はその辺りの話を整理し始めようかと思います。

WalletとHolderの違い

そもそもWalletとHolderが同じものとして扱われてしまうことが多いのですが、EICのパネルでも少し話題に登った通り、IssuerはクレデンシャルをWalletに対して発行するのではなく、Holderに対して発行するんですよね。

W3C VCDM1.1のいつもの図を見てもそのように記載されています。

どうもこのHolder=Walletというイメージが先行し過ぎてしまっていることが混乱を招く一因になってしまっていると思います。


WalletとHolderとクレデンシャルのバインディング

ここでは3つの話があります。

  1. Holder-クレデンシャルのバインディング
  2. Wallet-クレデンシャルのバインディング
  3. Holder-Walletのバインディング


まずHolder-クレデンシャスのバインディングです。

発行されたクレデンシャルがHolderとちゃんと紐づいているか(バインディング。要するにちゃんと対象者に対して発行されているか)はVerifierの視点からすると大切な点です。

例えば、特定の資格情報をVerifierが受け取った時に、提示してきた人(Holder)が他人のクレデンシャルを渡してきていたら問題になるケースも多いはずです。(もちろん全てのケースではない。これはVerifierのシナリオに依存する。このVerifier側の都合である、という点は非常に重要)

Verifiable Credentialsの場合、通常はVerifiable Presentationの発行者となるHolderのデジタル署名と、発行者の識別子とVerifiable Credential内のCredential Subjectの識別子が一致していることを持ってHolderとクレデンシャル発行対象が同一のエンティティであることを確認するわけです。


次に、Wallet-クレデンシャルのバインディングです。

前述のHolder-クレデンシャルのバインディングの前提はWalletが悪さをしない、ということになるので、特に国が発行する身分証明書などについては特定の基準を満たした(例えば鍵の管理がしっかりしているなど)Wallet出ないと困るわけです。こうなるとWalletとクレデンシャルの紐付け(バインディング)も検証する必要が出てきます。

このためにはWalletプロバイダが発行するWallet自体を証明するクレデンシャルと、Issuerから発行されるクレデンシャルを紐付けてデジタル署名を施す、という方法が取られたり、Secure Element等にプロビジョニングされた「管理された」鍵を使ってHolder署名をすることによりWallet自体が管理されたものであることを検証可能にする、という方法が取られたりします。


最後に、Holder-Walletのバインディングです。

要するに、他人がWalletを勝手に使っていないか?という話です。一般にWalletを起動する時にFace IDなどのOSの生体認証機能を使ってアンロックする方法が取られます。


Verifierは何をどこまで、どうやって検証するべきなのか

先に挙げたバインディングを含め全て検証をすれば確かに固い仕組みが出来上がると思います。ただし、Verifierは全ての資格情報の種別に対してそれらの検証をしたいわけではないことに注意しないといけないと思います。

例えば、単にお店の会員カードのような資格情報だった場合に持参人(Holder)とCredential Subjectが異なっても大きな問題にならないでしょうし、ビジネス機会を考えるとある程度のクレデンシャル共有は許容すべきとの意見もあると思います。

また、全てのWalletがSecure Elementに鍵を持ち、確実にIssuer等によって管理された状態となるのは非常に難しいですしToo Muchと言えます。(現実的にSecure Elementが使える端末は限定されますし、そのためにSIMを使うのか、またはマイナンバーカードやNational IDカードのICチップやクラウドHSMなどを使うのか?など非常に無理がある話です)


こうなると、Verifierの視点で何をどこまで検証すべきなのか?についてはシナリオと資格情報の種別によって変わってきそうです。
  • シナリオは、対面なのかリモートなのか
  • 資格情報の種別は、身元確認(Identity Verification)に使うものなのか単なる資格確認なのか
こんな視点で分類ができると思います。

また、「検証」という言葉についても何を?という話があります。NIST SP800-63A-3的に言うと、
  • Validation:エビデンスの真正性の確認
  • Verification:持参人がエビデンスが指し示すエンティティと同一であることの確認
だと思います。(NIST SP800-63の中でもValidationとVerificationの使い分けは混乱が見られるので全体にこの定義が当てはまるわけではありませんが)

これらの視点で考えると、Verifierは対面(デジタル)でもリモートでも
  • 受け取ったクレデンシャルのValidationは行いたい
  • 持参人の検証はシナリオによる
ということが言えると思います。

また、対面かリモートかによって、Verificationの方法は若干変わります。
  • 対面ならValidateされたクレデンシャル内の顔写真などと持参人を比較(Verify)する
  • リモートならValidateされたクレデンシャルが指し示すエンティティと同一であることを別途本人確認(例えばeKYCを含む)した結果と比較する

おそらく、Reusable Identityの文脈においてはこのリモートにおけるVerificationも一つのクレデンシャルの中で閉じて実施する必要があるので、先に挙げた3つのバインディングにかなり気を使うことになります。(要するにパスキーのように一回の動作で多要素認証と同等のことを行う)
しかしながら、単なる資格確認であればVerificationについては他のオプション(eKYCなど)と組み合わせることで実現が可能な話なので、Walletの作り方を含めそこまで気にし過ぎなくても良いのではないか、と思います。(現に、OpenBadgeなどではバッジと持参人の紐付けの確認は検証側の仕事として整理されています)

ちょっとダラダラと書きましたが、Walletのエコシステムを拡充させるためにはApple Walletがマイナンバーカードを格納できるようになった!万歳!で思考停止せずにちゃんと考える必要がありそうです。