2024年12月21日土曜日

ついに発売へ。デジタルアイデンティティのすべて

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

週末に家に帰ったら先行して届いていました。12月27日に発売になる「デジタルアイデンティティのすべて」です。
原著と比べると少しだけ大きいですね。


こちらから予約注文できますのでどうぞ。


ついでにSoftware Designの最新号も届いていましたし、年末年始はアイデンティティとパスキーざんまいですね！


1月末には「パスキーのすべて」も発売されますので、体（頭）をあっためておきましょう。

投稿者 時刻: 18:58 0 コメント
ラベル: , ,

2024年12月20日金曜日

モバイル運転免許証に関する用語を見ていきます

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

こちらにも書いた通り、11月にAAMVAからMobile Drivers License Implementation Guidelineの1.4がでました。


読んでいてそういえば一般的じゃない言葉ばっかり使ってるよなぁ、と思うのでまずはTerminologyを見ておきましょう。


そもそも論のAAMVAです。
American Association of Motor Vehicle Administrators

の略ですね。米国自動車管理者協会と訳されるようです。この辺の資料によると。 


EDL。enhanced driver licenseの略ですね。日本語だと強化運転免許証なんて訳されたりしますが、日本にいるとなんじゃそれ、ですがここに解説があります。

Enhanced Drivers Licenses (EDLs) are state-issued enhanced drivers licenses that provide proof of identity and U.S. citizenship when crossing the U.S. border in a vehicle. They are issued in a secure process, and include technology that makes travel easier. EDLs are a low-cost, convenient option for entering the United States from Canada, Mexico or the Caribbean through a land or sea port of entry, in addition to serving as a permit to drive.

強化運転免許証（EDLs）は、自動車で米国国境を越える際に身分証明と米国市民権を証明する州発行の強化運転免許証である。EDLは安全なプロセスで発行され、渡航を容易にする技術も含まれている。EDLは、カナダ、メキシコ、カリブ海諸国から陸路または海路で米国に入国する際に、低コストで便利なオプションであり、運転許可証としての役割も果たす。

使い道としては2025年から施行されるReal ID法（州が発行する運転免許証や身分証明書に対して最低限のセキュリティ基準を定めるもの）に対応したものっぽいです。米国国内で飛行機に乗るときにReal ID法に準拠した身分証明書の提示が必要になる、って話です。（日本人は外国政府発行のパスポートを使うことになると思います）

 

mDL。いわゆるMobile Driver's License、モバイル運転免許証ですね。

こんな解説が書いてあります。

driver’s license or identification card that resides on a mobile device or requires a mobile device as part of the process to gain access to the related information

Note to entry: Adapted from ISO/IEC 18013-5

運転免許証または身分証明書であって、モバイル・デバイス上に存在するもの、または入国時に 関連情報にアクセスするためのプロセスの一部としてモバイル・デバイスを必要とするもの： ISO/IEC 18013-5 からの引用。

まだ18013-7:2024と18013-5:2021の差分をとれていませんが、AAMVAとしては18013-5ベースです。


mDL app。いわゆるWalletに当たるものですね。

software running on an mDL holder’s device; within the context of this document this includes a standalone app as well as a wallet type app

mDL保持者のデバイス上で動作するソフトウェア。本書の文脈では、スタンドアロン型アプリおよびウォレット型アプリを含む。


mdoc。クレデンシャルフォーマットがmdoc、運転免許証として使えばmDLっていう整理でいいのかと思います。

document or application that resides on a mobile device or requires a mobile device as part of the process to gain access to the document or application

モバイル・デバイス上に存在する、または文書やアプリケーションにアクセスするためのプロセスの一部としてモバイル・デバイスを必要とする文書またはアプリケーション


mobile security object。MSOなんて言われたりします。mdocの構造化されたデータセットの話です。中にはデバイスアテステーションなども含まれるのでHolderバインディングの保証をすることが目的とされます。

structured data set that enables an mDL verifier to authenticate (for both accuracy and origin) other mDL data elements received during an mDL transaction

mDLベリファイアが、mDLトランザクション中に受信した他のmDLデータエレメントを（正確さと出所の両方について）認証できるようにする構造化データセット


provisioning。これは特殊用語lじゃないのかな？と思うのはIdentity界隈の人だからなのかもしれません。

initial loading of mDL information into an mDL app

mDLアプリへのmDL情報の初期読み込み

要するにウォレットへのモバイル運転免許証をインストールすることですね。



ということで、まずは用語解説からでした。

概念を理解するためにもこのあたりはちゃんと押さえておきましょう。 

 

 

 

 

 

 

投稿者 時刻: 7:30 0 コメント
ラベル: , , , ,

2024年12月19日木曜日

デジタルIDに関するグローバルの動向

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

OpenID FoundationのブログでElizabethが各国のデジタルIDに関する最近のトピックスを取り上げていますので紹介したいと思います。もちろん日本も含まれています。



  1. キプロス
    • デジタル・シチズンとして知られるモバイル・デジタルIDアプリを開始した。
    • このアプリでは、バイオメトリクスIDカード、運転免許証、自動車の路上使用適格性証明書などのデジタル文書をモバイルで保持することができる。また、QRコードを使ってデジタル認証することもできる
    • https://www.biometricupdate.com/202412/cyprus-launches-digital-citizen-mobile-digital-id-app
  2. ガーナ
  3. ニューメキシコ州
    • アップルまたはグーグルのウォレットに読み込むことができるモバイル運転免許証を導入する9番目の州となった。
    • ウォレットはここでの鍵であり、ニューメキシコ州民は運転免許証を携帯し、全米の特定のTSAチェックポイントで使用することができる。QRコードのスキャンによるデジタル認証が可能で、その後、暗号化されたデータがブルートゥース経由で送信される
    • https://www.biometricupdate.com/202412/new-mexico-mdl-goes-live-amid-uneven-state-progress
  4. パプアニューギニア
    • 国家デジタルID政策を発表し、公開協議を行っている。
    • ティモシー・マシウICT大臣によると、この政策は、金融包摂を促進するため、銀行口座開設を主なユースケースとして、SevisPassとして知られる公式デジタルIDシステムを確立するものである
    • https://www.thenational.com.pg/digital-id-policy-released/
  5. スイス
    • Swiyuとして知られるウォレットに保持される国民デジタルIDの技術的実装計画を概説した。
    • 第一段階の実装は2025年第1四半期にテストされる予定で、個々のコンポーネントのソースコードはオープンソースで公開される。第2段階のソリューションには、eIDから個人への追跡を防ぐため、より厳しいプライバシー要件が盛り込まれる予定であり、政府はこれを開発するための研究に110万米ドルを割り当てている
    • https://www.biometricupdate.com/202412/swiss-e-id-has-an-official-name-technical-implementation-plan
  6. ナイジェリア
    • オープンソースの MOSIP プラットフォームに支えられた新しい NIMS 2.0 デジタル ID システムのシステムインテグレーターの調達通知を出した
    • バイオメトリクスもこの通知の一部であり、SIはMOSIPをABISソリューションやバイオメトリクス登録キットと統合するよう求めている。ナイジェリアの現在のIDインフラからのレガシーデータも移行する必要がある
    • https://ted.europa.eu/en/notice/-/detail/753536-2024
  7. エア・カナダ
  8. 英国
    • 国の法執行機関は、最大2000万ポンド相当のライブ顔認証（LFR）システムの入札公告を出した
    • このシステムでは、ライブカメラの映像を監視リストと照合し、要注意人物を特定する。市民権団体や議員の反対にもかかわらず、英国政府は犯罪撲滅の手段としてLFRを警察が使用することを支持し続けている
    • https://www.biometricupdate.com/202412/uk-govt-publishes-25m-tender-for-live-facial-recognition
  9. ブラジル
  10. 日本
  11. パプアニューギニア
    • オーストラリアに続いて「特定のソーシャルメディア・プラットフォーム」の年齢保証を法制化する計画を発表した
    • 政府のデジタルトランスフォーメーション・リーダーであるスティーブン・マタイナホ氏は、「詐欺、違法な商品の流通、人身売買、偽情報、サイバーハラスメントの増加が懸念されている」ため、「有害なコンテンツから子どもを守る」ためだと主張している
    • 大人も「年齢制限のあるコンテンツ」にアクセスする際には、強制的なデジタルID（SevisPassとして知られる）を使用する必要がある
    • https://www.biometricupdate.com/202412/papua-new-guinea-to-ban-social-media-for-youth-require-age-verification-for-adults
  12. フランス
    • 大手携帯電話会社4社（ブイグ・テレコム、フリー、オレンジ、SFR）は、オンラインビジネスのためのデジタルID認証を改善するために手を組んだ。
    • ここでは相互運用性が重要であり、事業者はモバイルネットワーク間の仕様を統一するために2つの新しいAPIを導入している。これらは、Linux Foundationによって開発されたオープンソースプロジェクトであるCAMARA標準に基づいている
    • https://www.biometricupdate.com/202412/frances-mobile-operators-tackle-online-fraud-with-digital-identity-protections
  13. 英国
    • 英国内務省は、英国への入国を申請する外国人を対象に、スマートフォンを使った遠隔および対面での生体指紋採取の試験実施を計画している
    • しかし、パスポートの生体指紋データは現在、拡張アクセス制御（EAC）によって保護されており、EU加盟国の当局しか読み取ることができないことを考えると、この計画の実現性には懸念がある
    • 一方、遠隔地からの指紋採取は、AIを利用した詐欺の影響を受けやすいというセキュリティ上の懸念もある
    • https://www.biometricupdate.com/202412/uk-home-office-to-test-remote-fingerprint-enrolment-via-smartphone-for-entry
  14. ケンブリッジ・オルタナティブ・ファイナンス・センター（CCAF）

他にもイベントのお知らせとしてデジタルIDのための新興APAC市場のナビゲートというWebinarが案内されています。


しかし、本当に動いた一年でしたね。

投稿者 時刻: 7:30 0 コメント
ラベル: ,

2024年12月18日水曜日

FAPI2.0の最終化に向けたPublic Reviewが始まります

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

FAPI2.0のSecurity Profile and Attacker Modelに関する仕様の最終化に関するPublic Review期間が始まっていますね。

https://openid.net/public-review-for-proposed-final-fapi-2-0-specifications/



今後はこんなスケジュールで進むようです。

  • Final Specification public review period: Monday, December 9, 2024 to Friday, February 7, 2025 (60 days)
  • Final Specification vote announcement: Saturday, January 25, 2025
  • Final Specification early voting opens: Saturday, February 1, 2025
  • Final Specification voting period: Saturday, February 8, 2024 to Saturday, February 15, 2025 (7 days)


いよいよFAPIも本格化ですね。

投稿者 時刻: 9:59 0 コメント
ラベル: , ,

2024年12月17日火曜日

Taiwan Digital Identity Wallet International Forumでの登壇内容を紹介します

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

先週はTaiwan Digital Identity Wallet International Forumで登壇してきましたので、キーノートとしてお話した内容をメモしておきたいと思います。
イベントについてはこちら


自己紹介は置いておいて、テーマは相互運用性でした。
As you know, the Digital Identity Wallet has recently become an emerging topic in the digital identity space. For example, the European Committee has started implementing the European Digital Identity Wallet, which allows citizens to bring their own digital identity documents, such as national ID cards or mobile driver's licenses. At the same time, interoperability is essential for adopting these wallets in the real world because we have an existing ecosystem without the digital identity wallet today.
So, today’s my talk is about interoperability between current identity ecosystems and a Digital Identity Wallet.

ご存知のように、デジタルIDウォレットは最近、デジタルID分野で新たなトピックとなっています。例えば、欧州委員会は欧州デジタルIDウォレットの導入を開始しました。これにより、国民は国民IDカードや携帯電話運転免許証などのデジタルID文書を携帯できるようになります。同時に、現実世界でこれらのウォレットを採用するには相互運用性が不可欠です。なぜなら、今日、デジタルIDウォレットのない既存のエコシステムが存在しているからです。

そこで、本日の私の講演では、現在のアイデンティティ・エコシステムとデジタル・アイデンティティ・ウォレット間の相互運用性についてお話します。 


First, let’s think about our current situation when considering the term “interoperability.”
Since the fall of the Tower of Babel, we have been living in a world divided by different languages, different tribes, different cultures, and different social systems.
In other words, we have been living in a world where we have not been able to communicate well for a long time. This continued until the Age of Exploration, when trade between countries worldwide became more active.
For people like me who have lived in Asia, we have lived in a world that is very different from Western languages and cultures, and we are still living behind language barriers.
However, since the spread of the Internet began in the 1990s, the breakdown of regional divisions, including countries, has started. We have finally been freed from the constraints of physical location, and the need to communicate globally has arisen.
So, did a technology break down these barriers to allow us to communicate and trade freely globally?

まず、「相互運用性」という言葉について考える前に、現在の状況について考えてみましょう。

バベルの塔が崩壊して以来、私たちは異なる言語、異なる部族、異なる文化、異なる社会制度によって分断された世界に生きてきました。

つまり、私たちは長い間、うまくコミュニケーションを取ることができない世界に生きてきたのです。この状況は、大航海時代を迎え、世界各国間の貿易が活発になるまで続きました。

私のようにアジアで生活してきた人間にとっては、西洋の言語や文化とはまったく異なる世界で生きてきましたし、今でも言葉の壁に阻まれて生活しています。

しかし、1990年代からインターネットが普及し始め、国を含めた地域的な区分が崩れ始めました。私たちはようやく物理的な場所の制約から解放され、グローバルにコミュニケーションを取る必要性が生じてきたのです。

では、こうした障壁を打破し、世界中で自由にコミュニケーションや取引ができるようになった技術は登場したのでしょうか？



At the moment, the answer is no.
We are currently living in a world divided by silos created by technology.
Even now, to transfer data freely across systems, we have to design and implement interfaces between systems each time, and even when it comes to identity, which is the theme of today's talk, it is still managed on a system-by-system basis. We often have to manage multiple accounts for each systems.

現時点では、答えはノーです。

私たちは現在、テクノロジーによって作られたサイロによって分断された世界に生きています。

今でも、システム間でデータを自由にやりとりするためには、その都度、システム間のインターフェースを設計し実装しなければなりませんし、本日のテーマであるアイデンティティにしても、システムごとに管理されています。 システムごとに複数のアカウントを管理しなければならないこともよくあります。 



We need a way to communicate across countries, jurisdictions, and systems.
And we already know of some examples that have been developed to some extent.
Email can be delivered anywhere in the world without a centralized system, and the telephone system allows us to make calls to people worldwide. In these systems, we can communicate without depending on the email user agent or telephone type.
Also, in the real world, we use passport to identify people on traveling to other countries.
Those of us involved in digital identity need to follow the example of these previous cases and work to create a world where interoperability is guaranteed.
国や管轄区域、システムを越えてコミュニケーションを行う方法が必要です。
そして、ある程度まで開発された例がすでにいくつか存在しています。
電子メールは中央集権的なシステムなしで世界中のどこへでも配信できますし、電話システムは世界中の人々との通話を可能にしています。これらのシステムでは、電子メールユーザーエージェントや電話の種類に依存することなくコミュニケーションを行うことができます。
また現実の世界では、パスポートを使って他国への渡航者の身元確認を行っています。
デジタルアイデンティティに関わる私たちは、これらの過去の事例を手本とし、相互運用性が保証された世界を実現するために取り組む必要があります。



And digital identities are not just for natural persons. There are various things in the real world, such as IoT devices and legal entities, are connected to the internet, and daily business transactions are carried out. Now is the time to design and implement a system so that all digital identities can be mutually operated with minimal friction.

また、デジタルアイデンティティは自然人だけのものではありません。現実世界には、IoTデバイスや法人など、さまざまなものがインターネットに接続され、日常的な商取引が行われています。今こそ、すべてのデジタルアイデンティティが相互に最小限の摩擦で運用できるようなシステムの設計と実装を行うべき時なのです。



 Let's now take a closer look at interoperability. Even though we use the word 'interoperability,' it can be roughly divided into technical and non-technical aspects. When many engineers talk about interoperability, they often only focus on the technical side, but it is also essential to consider the non-technical side.

First, let's look at the technical aspects. We must consider the identifier format, transfer protocol, and data model, including the schema and signature algorithm.

In addition, on the non-technical side, we need to agree on the semantics that expresses what meaning the exchanged data has, the rules and framework within which the data is generated, and the trust framework that ensures the reliability of the entity state, etc.

Let's take a closer look at each of these elements from the next slide.

それでは、相互運用性について詳しく見ていきましょう。相互運用性という言葉を使っていますが、大まかに技術的な側面と技術的ではない側面に分けることができます。多くの技術者が相互運用性について語る場合、技術的な側面のみに焦点を当てがちですが、技術的ではない側面も考慮することが不可欠です。

まず、技術的な側面について見ていきましょう。識別子のフォーマット、転送プロトコル、データモデル（スキーマや署名アルゴリズムを含む）を考慮する必要があります。

さらに、技術面以外の側面では、交換されたデータがどのような意味を持つのか、データが生成されるルールや枠組み、エンティティの状態の信頼性を確保する信頼フレームワークなどを表現するセマンティクスについて合意する必要があります。

それでは、これらの要素について、次のスライドから詳しく見ていきましょう。 



First of all, let's talk about identifiers. An identifier is an attribute identifying a particular entity within a specific set. This attribute can be a single attribute or multiple attributes.

The design of the identifier depends on the size of the set that contains the target entity. For example, designing an identifier within a local set differs significantly from creating one within an international or global set. For example, my family name is Fujie, but there may be no one else in this room with the same family name. In this situation, my family name could function as an identifier. However, when I go home to Japan, my family name does not function as an identifier because, as you know, all of my family members have the family name Fujie.

Finally, it is essential to consider privacy and persistence when considering identifiers. For example, suppose control of an identifier is taken away from you. In that case, there is a possibility that control over the identity information linked to that identifier will also be taken away from you. Also, suppose you are logged in to multiple services using the same identifier. In that case, there is a possibility that the services will collide with each other and merge your attribute information in an unintended way. To deal with such cases, it may be necessary to devise ways to ensure that users use different identifiers.

On the other hand, if users are not allowed to use the same identifier for an extended period, they may not be able to use the service continuously or may not be able to access past data.

From the perspective of interoperability, it is necessary to design systems that can correctly identify entities while considering privacy and persistence, not only in the current but also in a broader set in the future.

Identifiers may seem simple, but they must be designed very carefully.

 まず、識別子についてお話しましょう。識別子とは、特定の集合内の特定のエンティティを識別する属性です。この属性は単一の属性であることも、複数の属性であることもあります。

識別子の設計は、対象のエンティティを含む集合の規模によって異なります。例えば、ローカルな集合内で識別子を設計することは、国際的またはグローバルな集合内で設計することとは大きく異なります。例えば、私の姓は富士榮ですが、この部屋には同じ姓の人は誰もいないかもしれません。このような状況では、私の姓は識別子として機能するでしょう。しかし、私が日本に帰国した場合、ご存知のように私の家族全員が富士榮という姓なので、私の姓は識別子として機能しません。

最後に、識別子を考える際には、プライバシーと永続性について考慮することが不可欠です。例えば、ある識別子の管理が自分から奪われたとします。その場合、その識別子と紐づけられたID情報についても管理が奪われる可能性があります。また、同じ識別子を使って複数のサービスにログインしているとします。その場合、サービス同士が衝突し、意図しない形で属性情報がマージされてしまう可能性がある。このようなケースに対応するためには、ユーザーに異なる識別子を利用させる工夫が必要となる可能性があります。

一方で、長期間にわたって同一の識別子を利用できないと、サービスを継続的に利用できなくなったり、過去のデータにアクセスできなくなったりする可能性があります。

相互運用性の観点では、プライバシーや永続性を考慮しつつ、現在だけでなく将来にわたって、エンティティを正しく識別できる仕組みを設計する必要があります。

識別子は一見単純に見えるが、非常に慎重に設計しなければいけません。


 

Next, we will consider transport protocols. Transport protocols define the methods by which entities communicate with each other. In the context of digital credentials, transport protocols include issuing credentials to wallets, presenting credentials to verifiers, and revoking issued credentials by issuers.
To ensure interoperability, the multiple issuer, wallet, and verifier components must communicate using a method that has been agreed upon in advance.
次に、トランスポートプロトコルについて検討します。トランスポートプロトコルは、エンティティが相互に通信する方法を定義します。デジタルクレデンシャルの文脈では、トランスポートプロトコルには、クレデンシャルをウォレットに発行すること、クレデンシャルをベリファイアに提示すること、発行者によって発行されたクレデンシャルを取り消すことが含まれます。
相互運用性を確保するには、複数の発行者、ウォレット、ベリファイアのコンポーネントが、事前に合意された方法で通信する必要があります。



Let's also consider data models. Schemas need to take into account the types and namespaces of attributes. Generally, gender is expressed using letters such as M and F, but in some cases, it is expressed using numbers such as 0 and 1. In addition, the attribute name family_name is sometimes used to express the family name, and the attribute name surname is sometimes used. In any case, related entities must agree on the names and types of attributes to achieve interoperability.

The algorithm used for digital signatures is also a very important factor. In general, it is necessary to verify digital signatures to verify the authenticity of digital credentials. Still, verification will not be possible if the issuer uses a signature algorithm that differs from what the verifier expects. Agreement on the signature algorithm is significant to avoid this.

データモデルについても検討してみましょう。スキーマでは、属性のタイプと名前空間を考慮する必要があります。一般的に、性別はMやFなどの文字で表現されますが、場合によっては0や1などの数字で表現されることもあります。また、姓を表現する際に、属性名family_nameが使用されることもあれば、surnameという属性名が使用されることもあります。いずれにしても、相互運用性を実現するには、関連するエンティティが属性の名称とタイプについて合意する必要があります。

電子署名に使用されるアルゴリズムも非常に重要な要素です。一般的に、電子証明書の真正性を検証するには、電子署名を検証する必要があります。しかし、発行者が検証者が期待するものと異なる署名アルゴリズムを使用している場合、検証は不可能です。これを回避するには、署名アルゴリズムについて合意することが重要です。 



As we have seen, reaching an agreement on identifiers, transport protocols, and data models is essential to achieve interoperability.

Many standardization organizations are working to develop standard specifications to facilitate this agreement. For example, the W3C has developed a specification called Decentralized Identifiers for identifiers, and the OpenID Foundation has developed a protocol for exchanging credentials called the OpenID for Verifiable Credenitals Issuance and the OpenID for Verifiable Presentations. The W3C and IETF have also formed working groups to create data models.

However, as you can see from this table, the current situation is that multiple standardization bodies are trying to develop their standard specifications. In this situation, no matter how much implementers adopt a standard, achieving interoperability with entities that use a different standard will not be possible.

これまで見てきたように、識別子、通信プロトコル、データモデルについて合意に達することは、相互運用性を実現するために不可欠です。
多くの標準化団体が、この合意を促進するための標準仕様策定に取り組んでいます。例えば、W3Cは識別子としてDecentralized Identifiersと呼ばれる仕様を策定しており、OpenID FoundationはOpenID for Verifiable Credenitals IssuanceおよびOpenID for Verifiable Presentationsと呼ばれる認証情報の交換プロトコルを策定しています。また、W3CやIETFでもデータモデルのワーキンググループが結成されています。
しかし、この表から分かるように、現状では複数の標準化団体が標準仕様を策定しようとしている状況です。このような状況では、実装者がどれだけ標準を採用しても、異なる標準を採用する主体との相互運用性を実現することはできません。



Due to the situation explained in the previous slide, some people are defining and using profiles that combine multiple standards.

It is not realistic to reach agreement on the identifiers, transfer protocols, and data models for each entity. Therefore, we develop profiles that combine specifications for specific identifiers, specific transfer protocols, and specific data models, and the relevant entities agree to use these profiles.

This allows us to reduce the need for individual coordination between entities.

This approach is also used in the European Union, and the OpenID Foundation provides a profile called the High Assurance Interoperability Profile, or HAIP.

前スライドで説明した状況により、複数の標準を組み合わせたプロファイルを定義し使用する人もいます。

各エンティティの識別子、転送プロトコル、データモデルについて合意に達することは現実的ではありません。そのため、特定の識別子、特定の転送プロトコル、特定のデータモデルの仕様を組み合わせたプロファイルを開発し、関連するエンティティがこれらのプロファイルの使用に同意します。

これにより、エンティティ間の個別の調整の必要性を減らすことができます。

このアプローチは欧州連合でも採用されており、OpenIDファウンデーションは、高信頼相互運用性プロファイル（HAIP）と呼ばれるプロファイルを提供しています。 



From this slide, I would like to consider the non-technology elements.

First of all, there is semantics. Suppose you receive a digitally signed credential. If you can only verify the signature, can you trust the information contained in the credential? I think it is difficult.

In other words, a digital signature only proves that the data has not been tampered with by a third party, and does not prove the reliability of the data itself or the reliability of the entity that sent it.

This is where a quality assurance framework is needed. For example, UNESCO has published a quality assurance framework that is intended for global use. This framework defines the levels of degrees at universities, etc., and by having educational institutions in each country issue degrees in accordance with this framework, the recipients of the credentials will be able to understand the meaning of the credentials.

このスライドから、技術以外の要素について考えてみたいと思います。

まず、意味論があります。 デジタル署名された資格証明書を受け取ったとします。 署名の検証しかできない場合、その資格証明書に記載されている情報を信頼できるでしょうか？ 難しいと思います。

つまり、デジタル署名は、第三者がデータを改ざんしていないことを証明するだけであり、データ自体の信頼性や、送信元の信頼性を証明するものではありません。

そこで必要になるのが、品質保証の枠組みです。例えば、ユネスコは世界的に利用できる品質保証の枠組みを公表しています。この枠組みは、大学などの学位のレベルを定義するもので、各国の教育機関がこの枠組みに沿って学位を発行することで、資格取得者はその資格の意味を理解できるようになります。


 

Next, let's consider the trust framework. Let's ask the same question as on the previous page. Just because you have verified the digital signature on the credential you have received, does that mean you can trust the issuer of that credential? For example, if you have obtained the digital data of a graduation certificate with a digital signature, how can you confirm that the university that issued the certificate exists?

This is where a system called a trust framework comes into play. There are various types of trust frameworks, but general laws and regulations are also a type of trust framework. For example, the recipient of a certificate of qualification may believe that the issuer is operating under the country's laws and regulations that control the bank and that the government regularly audits the bank. In this case, the verifier believes in the laws and regulations of the country, so there is no need to visit the bank to confirm that the individual issuer is an actual bank. In this way, it is possible to reduce the cost of individual verification by designing and operating a system that includes certification and auditing.

次に、トラストフレームワークについて考えてみましょう。前ページと同じ質問をしてみましょう。受け取ったクレデンシャルに付与された電子署名を検証したからといって、そのクレデンシャルの発行者を信頼できるのでしょうか？例えば、電子署名の付与された卒業証明書の電子データを受け取った場合、その証明書を発行した大学が実在していることをどのように確認できるのでしょうか？

そこで登場するのが「トラストフレームワーク」と呼ばれる仕組みです。トラストフレームワークにはさまざまな種類がありますが、一般的な法律や規則もトラストフレームワークの一種です。例えば、資格証明書の受領者は、発行者が銀行を管理する国の法律や規則に従って運営されており、政府が定期的に銀行を監査していると考えるかもしれません。この場合、検証者はその国の法律や規制を信頼しているため、個々の発行者が実際に銀行であることを確認するために銀行を訪問する必要はありません。このように、認証と監査を含むシステムを設計・運用することで、個々の検証にかかるコストを削減することが可能となります。 



In a few previous pages, we discussed the need for profiles. At that time, we focused on the technical aspects but also learned about the importance of trust frameworks on the previous page. That's right, profiles can include not only technological elements but also agreements on trust frameworks.

Because so many factors are involved in ensuring interoperability, using profiles that organize and correctly combine technical and non-technical aspects is efficient and effective.

数ページ前に、プロファイルの必要性について述べました。その際には技術的な側面に焦点を当てましたが、前ページでは信頼フレームワークの重要性についても学びました。その通り、プロファイルには技術的な要素だけでなく、信頼フレームワークに関する合意事項も含めることができます。
相互運用性を確保するには多くの要因が関わっているため、技術的および非技術的な側面を整理し、正しく組み合わせたプロファイルを使用することが効率的かつ効果的です。



As system architectures change daily, it is clear that systems based on multiple approaches will coexist. In the real world, we must consider interoperability between these systems.

In this slide, I want to explain the recent paradigm shift in digital identity systems.

This diagram shows how the identity paradigm has changed from a centralized world to a decentralized one.

In the centralized identity system, as I mentioned earlier, it is crucial to manage identity information in the centralized database. However, there are various side effects, such as the need to keep a non-active user account in the database, making license costs expensive. It may cause identity theft attack because nonactive user cannot be aware their identities were stolen since they are not using their accounts.

Also, a centralized authentication system is quite helpful in gathering sign-in logs. Still, the system's availability is quite crucial because if the system fails, all users cannot log in to all applications.

On the other hand, in the decentralized identity world, users' identity data is stored in the user's wallet, which is typically installed on smartphones. So, users can bring their identity and authenticate it through their purse, and there is no effect on other users if the user’s wallet is offline.

In addition, users can aggregate attributes from multiple data sources in a single wallet, aggregate them, and present them to the application. The application can get various attributes from the user’s wallet and determine access permission.

システムアーキテクチャは日々変化しており、複数のアプローチに基づくシステムが共存することは明らかです。現実の世界では、これらのシステム間の相互運用性を考慮する必要があります。
このスライドでは、デジタルIDシステムにおける最近のパラダイムシフトについて説明したいと思います。
この図は、IDのパラダイムが中央集権型から分散型へとどのように変化したかを示しています。
集中型のIDシステムでは、先ほど申し上げたように、ID情報を集中データベースで管理することが重要です。しかし、さまざまな副作用があります。例えば、データベースに非アクティブなユーザーアカウントを維持する必要があるため、ライセンスコストが高額になることがあります。また、非アクティブなユーザーはアカウントを使用していないため、自分のIDが盗まれたことに気づくことができません。そのため、ID盗難の被害に遭う可能性があります。
また、中央集権型の認証システムはサインインログの収集に非常に役立ちます。しかし、システムが故障した場合、すべてのユーザーがすべてのアプリケーションにログインできなくなるため、システムの可用性は非常に重要です。
一方、分散型のアイデンティティの世界では、ユーザーのアイデンティティデータは、通常スマートフォンにインストールされているユーザーの財布に保存されます。そのため、ユーザーは自分のアイデンティティを持ち歩き、財布を通して認証することができます。また、ユーザーの財布がオフラインの状態でも、他のユーザーには影響がありません。
さらに、ユーザーは複数のデータソースから属性を収集し、それを集約してアプリケーションに提示することができます。アプリケーションはユーザーの財布からさまざまな属性を取得し、アクセス許可を決定することができます。



We at the OpenID Foundation support the SIDI Hub, a community established to ensure interoperability in global digital identity. The SIDI Hub is considering ensuring interoperability in a world where various system architectures coexist from multiple perspectives, including systems and governance.

We have defined three types of system architecture: federated, wallet-based, and API-based, and we are considering what methods might be used to connect systems that use each of these architectures. For example, we are researching the possibility of building a proxy module between an API-based identity provider and a federated relying party.

私たちOpenIDファウンデーションは、グローバルなデジタルアイデンティティの相互運用性を確保するために設立されたコミュニティであるSIDI Hubを支援しています。SIDI Hubでは、システムやガバナンスなど、さまざまな観点から、さまざまなシステムアーキテクチャが共存する世界における相互運用性の確保について検討しています。

私たちは、システムアーキテクチャをフェデレーション型、ウォレット型、API型の3つに定義し、それぞれのアーキテクチャを使用するシステムを接続する方法について検討しています。例えば、API型アイデンティティプロバイダーとフェデレーション型依存者の間にプロキシモジュールを構築する可能性について研究しています。



Let's take a brief look at federation-type identity systems.

This type of architecture is the mainstream of current identity systems; for example, Apple, Google, Microsoft, and LINE also use this method.

In this system, applications are configured in a way that relies on external identity systems, and by clicking on buttons such as “Sign in with Apple” or “Sign in with Google,” users are redirected to the Apple or Google identity system. After that, the results of the user being authenticated by Apple or Google are presented to the application, and the login is complete.

This system is very well standardized, and protocols such as SAML and OpenID Connect are the mainstream and are adopted worldwide.

フェデレーション型のIDシステムについて簡単に説明します。

このタイプのアーキテクチャは、現在のIDシステムの主流であり、例えばApple、Google、Microsoft、LINEなどもこの方式を採用しています。

このシステムでは、アプリケーションは外部のIDシステムに依存する形で構成され、「Appleでサインイン」や「Googleでサインイン」などのボタンをクリックすると、ユーザーはAppleやGoogleのIDシステムにリダイレクトされます。その後、Apple または Google によるユーザー認証の結果がアプリケーションに表示され、ログインが完了します。

このシステムは非常に標準化されており、SAML や OpenID Connect などのプロトコルが主流となっており、世界中で採用されています。


 

In the wallet-based model, users store their own identities in software called a wallet and carry it with them.

This model is sometimes called the Issuer-Holder-Verifier (IHV) model, as it contains three components: the Issuer, which issues credentials; the Holder, which holds credentials; and the Verifier, which verifies credentials.

As I mentioned in the previous slide about paradigm shifts, this model is expected to support new use cases. For example, because Holders do not need to contact Issuers when presenting credentials to Verifiers, it will be possible to support new use cases, such as offline cases.

However, there are many competing standards, and the IETF, ISO, OIDF, W3C, and other organizations are all actively working to develop their specifications.

ウォレット型モデルでは、ユーザーは自身のIDを「ウォレット」と呼ばれるソフトウェアに保存し、持ち歩くことになります。

このモデルは、3つのコンポーネント、すなわち、クレデンシャルを発行する「発行者」、クレデンシャルを保持する「保持者」、クレデンシャルを検証する「検証者」を含むことから、発行者-保持者-検証者（IHV）モデルと呼ばれることもあります。

前回のスライドでパラダイムシフトについて述べたように、このモデルは新しいユースケースをサポートすることが期待されています。例えば、ホルダーがベリファイアにクレデンシャルを提示する際に、イシュアーに連絡する必要がないため、オフラインでのケースなど、新しいユースケースをサポートすることが可能になります。

しかし、多くの競合する標準規格が存在し、IETF、ISO、OIDF、W3C、その他の組織が、それぞれ仕様策定に積極的に取り組んでいます。 



The last model is the API type. Unlike the previous two, this one is often a system that was introduced without a specific standard specification. It can remain in a closed environment.

最後のモデルはAPIタイプです。前の2つとは異なり、このモデルは特定の標準仕様なしに導入されたシステムであることが多いです。クローズドな環境のままでも構いません。


 

It is very challenging to interconnect systems of different architectures introduced so far. This is because it is often difficult to modify already working systems. Therefore, we sometimes take the approach of placing components called proxies or brokers between systems. The proxy absorbs and converts differences in protocols and data models.

While this approach is often a temporary solution, it tends to create problems in the overall trust model because of the need to trust the proxy.

For example, it is structured like this diagram. There is a wallet-based system in the center. However, because modifying the existing IdP to enable direct communication with the wallet is impossible, the Issuer component is developed as a proxy, and a federation relationship is established with the IdP. Similarly, the Verifier component is developed as a proxy because it is difficult to modify the existing Relying Party to present credentials from the wallet. It behaves as an Identity Provider from the Relying Party's point of view.

これまで紹介してきた異なるアーキテクチャのシステムを相互接続することは非常に困難です。すでに稼働しているシステムを変更することが難しい場合が多いためです。そのため、プロキシやブローカーと呼ばれるコンポーネントをシステム間に配置するアプローチを取ることもあります。プロキシはプロトコルやデータモデルの違いを吸収し、変換します。

このアプローチは一時的な解決策であることが多い一方で、プロキシを信頼する必要があるため、全体的な信頼モデルに問題が生じがちです。

例えば、次のような構成です。中心にウォレットベースのシステムがあります。しかし、既存のIdPを変更してウォレットとの直接通信を可能にすることは不可能であるため、発行者コンポーネントをプロキシとして開発し、IdPとフェデレーション関係を確立します。同様に、既存の依拠当事者（Relying Party）を変更してウォレットからのクレデンシャルを提示することは困難であるため、検証者コンポーネントもプロキシとして開発します。依拠当事者から見ると、このコンポーネントはアイデンティティプロバイダーとして動作します。



I want to introduce one actual use case.

This is a project by the National Institute of Informatics to digitize learner credentials. In this project, learning records issued from existing learning management systems are issued to wallets, and the credentials are used to verify qualifications when submitting papers, etc.

The challenge in implementing the project was that many academic systems, not just in Japan, use the SAML protocol, and in Japan, too, many SAML-based identity systems operate within the ecosystem of the academic federation known as GakuNin. In addition, the learning management system in question was developed based on a middleware called Moodle, and it was necessary to implement a unique API to issue credentials.

実際の利用事例を一つ紹介したいと思います。

これは国立情報学研究所の学習歴証明の電子化プロジェクトです。このプロジェクトでは、既存の学習管理システムから発行される学習記録をウォレットに発行し、その資格情報を論文投稿時などの資格証明に利用します。

このプロジェクトを実施するにあたっての課題は、日本に限らず多くの学術システムがSAMLプロトコルを使用しており、日本でも学認という学術フェデレーションのエコシステム内で多くのSAMLベースのIDシステムが稼働していることでした。また、対象の学習管理システムはMoodleというミドルウェアをベースに開発されており、独自のAPIを実装してクレデンシャルを発行する必要がありました。



This diagram shows an overview of the GakuNin ecosystem that we explained earlier.

The National Institute of Informatics provides the trust framework, and certified universities and research institutions' identity providers and certified applications such as learning management systems and research databases are deployed as relying parties within the ecosystem.

By being authenticated by the university or institution's identity provider, students and researchers can securely single sign-on to many applications, creating a very convenient and secure environment.

この図は、先に説明した学認エコシステムの概要を示しています。
国立情報学研究所がトラストフレームワークを提供し、認定を受けた大学や研究機関のアイデンティティプロバイダーと、学習管理システムや研究データベースなどの認定済みアプリケーションが、エコシステム内の依拠当事者として展開されています。
学生や研究者は、大学や機関のアイデンティティプロバイダーによって認証されることで、多くのアプリケーションに安全にシングルサインオンでき、非常に便利で安全な環境を実現できます。

 


 

We decided to introduce a wallet-based system into this federated environment.

For this reason, we took these approaches to the challenge of interoperability.

First, we embedded the OpenBadge credential the Learning Management System issued using its own API into the Verifiable Credential. We placed a gateway service between Moodle and the wallet and constructed it as an issuer that issues verifiable credentials based on the OpenBadge issued by Moodle. In other words, from the wallet's point of view, the gateway service appears as an Issuer.

Secondly, the Verifiable Credential presented by the wallet was embedded inside the SAML assertion. Since the existing Relying Party supports the SAML protocol, it was impossible to show the Verifiable Credential directly. Therefore, the OpenBadge extracted from the Verifiable Credential was embedded as one of the attributes inside the SAML assertion, and the credential was presented to the Relying Party. To achieve this, we developed a Wallet to SP Connector component. We configured it to appear as a Verifier to the Wallet and an Identity Provider to the Relying Party.

Of course, the Relying Party still needs to implement the appropriate logic to extract the OpenBadge from the SAML assertion, verify it, and use it. Still, there was no need to modify to support new protocols such as OpenID for Verifiable Presentation.

この統合環境にウォレットベースのシステムを導入することを決定しました。

そのため、相互運用性の課題に対して、以下のアプローチをとりました。

まず、LMSが独自のAPIを利用して発行するOpenBadgeクレデンシャルを、検証可能なクレデンシャルに埋め込みました。Moodleとウォレットの間にゲートウェイサービスを配置し、Moodleが発行するOpenBadgeに基づいて検証可能なクレデンシャルを発行する発行者として構築しました。つまり、ウォレットから見ると、ゲートウェイサービスは発行者として表示されます。

次に、ウォレットが提示した検証可能なクレデンシャルはSAMLアサーション内に埋め込まれました。既存のリライングパーティはSAMLプロトコルをサポートしているため、検証可能なクレデンシャルを直接提示することはできません。そのため、検証可能なクレデンシャルから抽出したOpenBadgeをSAMLアサーション内の属性の1つとして埋め込み、リライングパーティにクレデンシャルを提示しました。これを実現するために、私たちは Wallet to SP Connector コンポーネントを開発しました。 Wallet に対してはベリファイアとして、また、リライングパーティに対してはアイデンティティプロバイダーとして表示されるように構成しました。

もちろん、リライングパーティは、SAML アサーションから OpenBadge を抽出し、それを検証し、使用するための適切なロジックを実装する必要があります。それでも、OpenID for Verifiable Presentation などの新しいプロトコルをサポートするために修正する必要はありませんでした。 



This is an overview of the system.

First, the user issues a badge using the Learning Management System. At this point, the user is authenticated using the existing Identity Provider.

Next, the badge is issued to the user's wallet. When the user accesses the gateway, the gateway is also federated with the same Identity Provider as the Learning Management System, and the user is prompted for authentication. This way, the user is granted the appropriate permissions to execute the Moodle API. The gateway service then performs the Moodle API to obtain the issued badge and generate a verifiable credential. The gateway then issues the verifiable credential to the user's wallet as the issuer.

The issuance is now complete.

Finally, let's look at the presentation. In this case, we want to present the credential to the Gakunin RDM research database, but Gakunin RDM only supports the SAML protocol so we will use the Wallet to SP Connector. When the user accesses a specific page on Gakunin RDM, Gakunin RDM uses the SAML protocol to start the Wallet to SP Connector. This is the same operation as a standard SAML-based federation, so it is very easy to implement. When the Wallet to SP Connector is started, it requests the user's wallet to present a verifiable credential per the OpenID for Verifiable Presentation protocol. When the user presents the credential in their purse, the Wallet to SP Connector verifies the signature of the credential, extracts the embedded badge information from the credential, and configures it as a SAML assertion, then sends it to Gakunin RDM using the SAML protocol.

This allows Gakunin RDM to obtain the desired learning credential information, which can then be used to perform access control and other processing.

以下にシステムの概要を示します。

まず、ユーザーは学習管理システムを使用してバッジを発行します。この時点で、ユーザーは既存のアイデンティティプロバイダを使用して認証されます。

次に、バッジがユーザーのウォレットに発行されます。ユーザーがゲートウェイにアクセスすると、ゲートウェイも学習管理システムと同じアイデンティティプロバイダとフェデレーションされており、ユーザーに認証が求められます。これにより、ユーザーにはMoodle APIを実行する適切な権限が付与されます。次に、ゲートウェイサービスがMoodle APIを実行して発行済みのバッジを取得し、検証可能な資格情報を生成します。次に、ゲートウェイが発行者として、検証可能な資格情報をユーザーのウォレットに発行します。

これで発行は完了です。

最後に、プレゼンテーションについて見てみましょう。このケースでは、学認RDM研究用データベースにクレデンシャルを提示したいのですが、学認RDMはSAMLプロトコルしかサポートしていないので、Wallet to SP Connectorを使用します。ユーザーが学認RDM上の特定のページにアクセスすると、学認RDMはSAMLプロトコルを使用してWallet to SP Connectorを開始します。これは標準的なSAMLベースのフェデレーションと同じ操作なので、実装は非常に簡単です。Wallet to SP Connectorが起動すると、OpenID for Verifiable Presentationプロトコルに従って、ユーザーのウォレットに検証可能なクレデンシャルの提示を要求します。ユーザーが財布内のクレデンシャルを提示すると、Wallet to SP Connectorはクレデンシャルの署名を検証し、クレデンシャルから埋め込みのバッジ情報を抽出し、それをSAMLアサーションとして構成し、SAMLプロトコルを使用して学認RDMに送信します。

これにより、学認RDMは必要な学習クレデンシャル情報を取得でき、アクセス制御やその他の処理に使用できるようになります。 

 



We will also introduce activities that address other non-technical considerations.

Open Identity Exchange is working to map the trust frameworks of each country and identify differences.

For example, this will enable the EU to understand what rules were used to issue the credentials issued by Japan and to determine whether additional measures are necessary.

また、技術以外の考慮事項に対処する活動についても紹介します。

Open Identity Exchangeは、各国の信頼フレームワークをマッピングし、相違点を特定する作業を行っています。

例えば、これによりEUは、日本が発行したクレデンシャルを発行する際にどのような規則が用いられたかを理解し、追加の措置が必要かどうかを判断することができます。



There are also activities in the academic world to map frameworks related to qualification levels.

In the academic world, there are two main types of credentials: micro-credentials, mainly learning records, and macro-credentials, which are qualifications such as degrees and credits.

While micro-credentials are becoming increasingly digitized, as in the case of the NII example mentioned earlier, OpenBadge, it is tough to standardize the difficulty of skills. I think this will continue to be a challenge. On the other hand, about macro-credentials, UNESCO has established standards for skill levels so that each country can define levels based on these standards.

学術界でも、資格レベルに関連する枠組みをマッピングする活動があります。

学術界では、主に学習記録であるマイクロ資格と、学位や単位などの資格であるマクロ資格の2つの主要な資格があります。

マイクロ・クレデンシャルは、先ほど例に挙げたNIIのOpenBadgeのように、どんどんデジタル化が進んでいますが、スキルの難易度をどう標準化するかは難しい。これは今後も課題になっていくと思います。一方、マクロ・クレデンシャルについては、ユネスコが技能レベルの基準を定めており、各国がそれをベースにレベルを定義できるようになっています。


 

This is the approach to global standards and mapping as defined by UNESCO.

In this example, the EQF developed by Europe based on UNESCO standards is mapped to the frameworks of other countries.

For example, EQF Level 4 is mapped to Country X Level 5 and Country Y Level 3.

これは、ユネスコが定義するグローバルスタンダードとマッピングへのアプローチです。

この例では、ユネスコの基準に基づいてヨーロッパが開発したEQFが、他の国のフレームワークにマッピングされています。

例えば、EQFレベル4は、国Xのレベル5および国Yのレベル3にマッピングされています。



 In addition, we will introduce some of the activities that have been taking place in Japan recently.

Trusted Web has been underway since 2020, and research into digital identity wallets is being carried out. In addition, the introduction of national ID cards and mobile driver's licenses is already being planned. Starting next March, it will be possible to issue permits for smartphones. In addition, various studies are underway to enable the interoperability of academic credentials with other countries, so I hope that in the future, studies on interoperability with Taiwan and other countries will progress

さらに、最近日本で起こっている活動の一部をご紹介したいと思います。

2020年からTrusted Webが動き出しており、デジタルIDウォレットの研究が進められています。また、国民IDカードやモバイル運転免許証の導入もすでに計画されています。来年3月からは、スマートフォンでの許可証発行が可能になります。また、学歴の相互運用性についても諸外国との間でさまざまな研究が進められており、今後は台湾などとの相互運用性についての研究が進むことを期待しています


Let me finish by summarizing.

First, interoperability is a technical issue and a non-technical consideration, such as rules and frameworks. It is essential to reach agreement on technical matters such as identifiers, transport protocols, and data models. I also explained that semantics and trust frameworks are necessary from a non-technical perspective.

I also explained that we need to respond to the recent paradigm changes of identity systems. To introduce a wallet-based system into a federation-type system that has been used in the past, it is thought that it will be necessary to use components such as proxies and gateways temporarily. I also mentioned that by comparing trust frameworks, it will be possible to clarify what additional processing the systems require to be connected.

In the future, we will need to connect many systems to overcome the silo-based society that has continued since the fall of the Tower of Babel. I hope that we can continue to have discussions like this with everyone.

Thank you.

最後にまとめます。
まず、相互運用性は技術的な問題と、ルールやフレームワークなどの技術的でない考慮事項の両方を含んでいます。識別子、通信プロトコル、データモデルなどの技術的な事項について合意に達することが不可欠です。また、技術的でない観点からは、セマンティクスや信頼フレームワークが必要であることを説明しました。
また、アイデンティティシステムの最近のパラダイム変化に対応する必要があることを説明しました。これまで使われてきたフェデレーション型システムに、ウォレット型システムを導入するには、プロキシやゲートウェイなどのコンポーネントを一時的に使用する必要があると考えられます。また、信頼フレームワークを比較することで、システムを接続するためにどのような追加処理が必要かを明確にできることを述べました。
今後は、バベルの塔の崩壊以来続いてきた縦割り社会を乗り越えるためにも、多くのシステムを接続していく必要があります。今後も皆さんとこのような議論を続けていければと思います。
ありがとうございました。



プロンプターが欲しかったプレゼンでした・・・ 

ちなみに始まる前にオープンニングトークをしてくれた台湾のデジタル副大臣（私の左側）と登壇者全員で記念写真を撮りました。なんかセレモニーみたいでいいですね。






投稿者 時刻: 7:30 0 コメント
ラベル: , , ,

2024年12月16日月曜日

年明けはデジタルアイデンティティ人材育成推進WG：活動報告会から

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


年明け1/14はデジタルアイデンティティ人材育成推進WGの活動報告会があります。

https://openid.connpass.com/event/339259/



例の本が年末に販売されることもあり、翻訳を担当したメンバーから苦労話など聞ける良い機会になると思いますのでぜひご来場ください。

投稿者 時刻: 7:30 0 コメント

2024年12月15日日曜日

今年もKim Cameronアワードのノミネートが始まっています

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

これまで何度かポストした、Kim CameronアワードやVittorio Bertocciアワードですが、今年もKim Cameronアワードのノミネートが始まりました。

https://digitalidadvancement.org/awards-and-grants/kim/2025-kca/




今後のスケジュールはこんな感じなので、我こそは！という方は申請してみてはいかがでしょうか？

  • December 11: Call for Applications Opens
  • January 21: Call for Applications Closes
  • January 31: Awardees Notified
  • February 7: Awardee Confirmation of Acceptance Due
  • 30 Days Post-Event: Awardee Receipts for Reimbursement Due
  • 30 Days Post-Event: Awardee Reflections Due

投稿者 時刻: 7:30 0 コメント
ラベル: , ,
登録: 投稿 (Atom)