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

2023年も終盤に近づいてきたということで、今年もDigital Identity技術勉強会 #iddance Advent Calendar 2023に参加しています。

今回のネタはWorldcoinで話題のWorld IDを探っていきたいと思います。

ということでこんな内容でお届けします。

• Worldcoinとは
• World IDの取得と確認
• Identity ProviderとしてのWorld ID
• Incognito Actions（おまけ）

なお、お約束ですが本記事ではWorldcoinを含む特定の仮想通貨の購入や投資などを推奨するものではありません。あくまでDigital Identity関連技術の観点からWorldcoin/IDを見ていきたいと思います。

Worldcoinとは

Worldcoin is an open-source protocol, supported by a global community of developers, individuals, economists and technologists committed to expanding participation in, and access to, the global economy. The Worldcoin Foundation is the steward, and will support and grow the Worldcoin community until it becomes self-sufficient. Tools for Humanity helped launch Worldcoin, and currently serve as advisors to the Foundation and operators of the World App.（原文）

ワールドコインはオープンソースのプロトコルであり、開発者、個人、経済学者、技術者からなるグローバルコミュニティによって支えられている。Worldcoin財団はスチュワードであり、Worldcoinコミュニティが自立するまでサポートし、成長させる。Tools for Humanityはワールドコインの立ち上げを支援し、現在は財団のアドバイザーとワールドアプリの運営者を務めている。（Deeplで機械翻訳） 

Worldcoin was founded with the mission of creating a globally-inclusive identity and financial network, owned by the majority of humanity. If successful, Worldcoin could considerably increase economic opportunity, scale a reliable solution for distinguishing humans from AI online while preserving privacy, enable global democratic processes, and show a potential path to AI-funded UBI.（原文）

Worldcoinは、人類の大多数が所有する、グローバルに包括的なアイデンティティと金融ネットワークを構築することを使命として設立された。成功すれば、ワールドコインは経済機会を大幅に拡大し、プライバシーを守りながらオンライン上で人間とAIを区別するための信頼できるソリューションを拡大し、グローバルな民主的プロセスを可能にし、AIが資金を提供するUBIへの潜在的な道を示すことができる。(Deeplで機械翻訳）

要するに金融包摂の文脈で設立されたデジタルアイデンティティと金融ネットワークで、UBI（ユニバーサル・ベーシック・インカム）を実現することも一つのゴールとして定めている様です。

また、同時にWorldcoinを構成する要素についても以下のように説明が記載されています。

Worldcoin consists of a privacy-preserving digital identity network (World ID) built on proof of personhood and, where laws allow, a digital currency (WLD). Every human is eligible for a share of WLD simply for being human. World ID and WLD are currently complemented by World App, the first frontend to World ID and the Worldcoin Protocol, developed by the contributor team at Tools for Humanity (TFH).（原文）

ワールドコインは、個人であることの証明の上に構築されたプライバシーを保護するデジタルIDネットワーク（ワールドID）と、法律が認めるデジタル通貨（WLD）で構成されている。すべての人間は、人間であるというだけでWLDの分け前を得る資格がある。World IDとWLDは現在、Tools for Humanity (TFH)の貢献者チームによって開発された、World IDとWorldcoinプロトコルの最初のフロントエンドであるWorld Appによって補完されている。（Deeplで機械翻訳） 

なるほど、Worldcoinのサイトのトップに記載されていたWorld ID、WLD、World Appはそれぞれ以下のような関係性だということがわかります。（トップページからリンクされるそれぞれのページの解説文からも補完）

• World ID：デジタルIDネットワーク
• A more human passport for the internet. More powerful. More integrations. More human.（原文）
• インターネットのより人間的なパスポート。よりパワフル。より多くの統合。より人間的に。（Deeplで機械翻訳）
• WLD：デジタル通貨（Worldcoin Token）
• A more human token freely, equally, and globally distributed to unique humans.（原文）
• より人間的なトークンは、自由に、平等に、そしてグローバルに、ユニークな人間に配布される。（Deeplで機械翻訳）
• World App：フロントエンドアプリケーション
• More human access to the global economy with identity and finance for all. Privacy‑first. No fees. 24 hour support.（原文）
• すべての人のためのアイデンティティと金融で、より人間らしいグローバル経済へのアクセスを。プライバシー第一。手数料無料。24時間サポート。（Deeplで機械翻訳）

World IDの取得と確認

では、早速World IDを取得してみたいと思います。

World IDアカウントを作成するのに必要となるのは、以下のものです。

• スマートフォン（iOS/Android）にインストールするWorld App
• SMSの受信できる携帯電話番号（なくてもアカウントは作成できます）

スマホを持っていない人は金融包摂的にどうなるのか？という疑問は抱きつつ、World Appをインストールしセットアップを続けます。

もちろんこの状態でもWorld IDは作成されているのですが、World IDのもう一つの特徴は本当に人（Human）であることをOrbというデバイスを使って確認（物理的にOrbが置いてある場所まで行って対面で確認を行う）を行うことにあります。

まだID確認を行なっていない状態だとアプリの上部にVerify your World IDというリンクが表示されるのでタップすると近所に存在するOrbの場所が表示されますので、場所によっては予約をした上で現地を訪問して存在確認を行います。なお、この際に虹彩登録を行う必要があることから謎のシステムやデバイスに生体情報を提供するのはどうなのか？という議論も存在します。確かに私も渋谷の指定の場所へ行ってOrbでID確認をしてきましたが、かなりカジュアルな感じで登録ができてしまうので、偽Orbを作って生体情報だけを搾取する人たちが出てきても不思議ではありません（Orbを操作してくれる人も、Orbそのものについても登録しようとしている人から見て正当性を確認する手段がない）。この辺りは今後の課題なんだと思います。

なお、ID確認時には法的なアイデンティティ・ドキュメント（免許証などの身分証明書）の提示は求められないので、この辺りは金融包摂のため、という考え方がベースにあるのだと思います。ただ、一人のユーザが複数のWorld IDを取得できないようにするための虹彩情報の突合・重複確認がどこまで本当に実施されているのか？などはよくわかりません。

こんな感じのデバイスが置いてあるのでアプリのQRを読み込ませた後で虹彩登録を行います。登録自体は5分もかからずサクッと終わります。

なお、このID確認を行わないとベーシック・インカムとなるWLDを受け取ったり取引することができません。ちなみにWorld Appをインストールすると定期的（週一回くらい？）にGrantといってベーシック・インカムとしての3〜10程度のWLDが付与されます。現時点で1WLDは日本円で368〜9円程度なので、隔週で1,000円もらえる感じです。実際に利用する際は暗号資産取引所などで日本円へ換金することもできるんじゃないかと思います。（やったことありませんが）※追記：12/18の朝にみたら爆上がりしてました。624円とかになってました。

いずれにしても確認が終わるとVerifiedとして記録がされます。

Identity ProviderとしてのWorld ID

さて、デジタルIDの話なので、あまり仮想通貨の話に行っても仕方がないのでWorld IDの使い方の話をしたいと思います。

非常にざっくりいうと、World IDもOpenID Connectに対応したIdentity Providerとしての機能を持っています。

開発者ポータルへアクセスし、サインアップすると一般のIdentity Providerと同じようにクライアント登録などができる仕組みが提供されています。

ちなみにAuth0（Okta CIC）ではすでにマーケットプレイスにSign in with Worldcoinの機能が提供されていますので、クライアントID/シークレットの登録とRedirectURIを設定すると簡単にWorld IDによるサインインが実装できます。

開発者ポータルでClient ID/Secret/RedirectURIの設定を行います。

こちらはAuth0（Okta CIC）の画面。Social Connectionsとして定義します。

Sign in with Worldcoinを起動するとQRコードが出てくるので、World AppでQRコードを読み込み、サインインします。

World App側でQRコードを読み込むとVerify with World IDの画面が表示される、確認に成功するとサインインされます。

World IDのOpenID Connectの実装に関してはドキュメントが公開されているので、こちらを見ると自作のWebアプリケーションや他のIDaaSへの接続も容易です。（最近World IDのバージョンが2.0に更新され、PKCEのサポートなどが追加されました）

簡単なRelying Partyを書いて実際のid_tokenの中身などを確認していきましょう。細かいコードは省略しますが、結果的にこんなid_tokenが返ってきます。

ポイントはこの辺りです。ドキュメントをみるとhttps://id.worldcoin.org/betaのエレメントはdepricateっぽいですが、verification_levelとしてOrbで確認済みのWorld IDかどうかがわかるような仕組みになっています。

  "https://id.worldcoin.org/beta": {

    "likely_human": "strong",

    "credential_type": "orb"

  },

  "https://id.worldcoin.org/v1": {

    "verification_level": "orb"

  },

ちなみに、Orbで確認を行なっていないWorld IDでもアクセスしてみるとverification_levelがdeviceとなっています。

  "https://id.worldcoin.org/beta": {

    "likely_human": "weak",

    "credential_type": "device"

  },

  "https://id.worldcoin.org/v1": {

    "verification_level": "device"

  },

ところで、Auth0でも簡単なRelying Partyでも実装できたので、ついでにAzure AD B2Cでも実装してみようと思います。Discoveryもサポートしているし、openid-configurationを見るといつもの鬼門のresponse_mode=form_postもサポートしているようなので試してみます。

こんな感じでIDプロバイダーを設定します。

ところが、response_modeをform_postにするとWorld IDのAuthorizationエンドポイントでWorld Appでサインインしたところjsのエラーが出て止まってしまいます。どうもCSPの設定がうまくできていないみたいですね。。。

ということで、response_modeをqueryに変更して再度試してみるとTokenエンドポイントへのアクセスでエラーが出ているようです。

ここは結構ハマったのですが、Postmanなどで順番にアクセスするとちゃんとid_tokenが取得できるので、Azure AD B2CがTokenエンドポイントへアクセスする際に何か変なヘッダがついていたりするんだろうな、、（あるいは逆にUser-Agentがないと返事をしないTokenエンドポイントがいたりするのでそういうケースかも、、）と思いダミーのTokenエンドポイントを作りPostman経由の場合とヘッダを比較。

結果、

expect: '100-continue'

が犯人でした。

PostmanでもexceptヘッダをつけるとWorld IDのTokenエンドポイントがエラーを出しました。どうやらContent-Lengthの事前通知には対応していないようです。

とはいえ、APIクライアントとなるAzure AD B2C側のリクエストをここまで細かいレベルで調整するのはカスタムポリシーを使っても無理っぽいので、現時点では諦めます。（どうしても実装する場合はTokenエンドポイントとの間にゲートウェイモジュールを立ててProxyさせる形になると思います）

Incognito Actions（おまけ）

ここからはおまけですが、World IDにはIncognito Actionsという機能があります。これはユーザがSign in with World IDを含むVerifyをする対象のアプリケーションを簡単に作るための機能です。（例えば、投票などが想定されています）

開発者ポータルからIncognito Actionsメニューから定義体を作っていくことができますが、その際にVerifyの回数の制限などをつけることができます。

例えば、Uniqueだと1つのWorld IDにつき1回しかVerifyができないようなアプリケーションが作れますし、2 Verificationsや3 Verificationsのように2回・3回まで許可する設定やUnlimitedのように制限なしの設定もできます。

本来はIDKitというSDKやAPIを使ってアプリケーションを構築していくことになるのですが、管理者ポータルからテストをするためのKioskモードが用意されているのでこちらから確認していきます。

Enable Kiosk〜Open Kioskでテスト用の画面が開きます。

先ほどのSign in with World IDと同じようにWorld AppでQRコードを読み込みます。今回はUniqueモードを設定したので最初の1回はちゃんとVerifiedとなります。

しかし、再度同じようにKioskを起動して同じWorld IDで確認をするとAlready verifiedとエラーが出ます。

簡単な投票や特典の配布などのアプリを作るのに良さそうですね。

ということで、Worldcoin / World IDを触ってみました。

金融包摂という社会課題への対応をしていくという方向性については共感できるものがありますし、うまく社会に浸透していくことができればベーシック・インカムはおいておいて金融システムからネグレクトされた人々にとっては救いになり得るのかもしれません。

ただ、先に書いた通りOrbの真正性などまだまだ情報の非対称性など粗いところも多く、まだまだポリシーやガバナンス面を含めやるべきことはたくさんあるんじゃないかと思います。Sam Altman氏もOpenAIで得られた知見や利益を、打ち上げ花火だけではなく、うまく実際の社会のために役立てられるといいですね。

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

ここしばらくポスト数が減っていたので、今年は小ネタを中心に色々と書いていこうかと思います。

ということでみなさん大好きなShibbolethです。スペルがずっと覚えられずShobbolethと某所に書いて伝説のワード「しょぼれす」を産んでしまったのは遠い過去の記憶です。

Shibbolethってなんだ？というかなぜShibboleth

A world leader in identity management technology, Shibboleth is an open-source project with a strong community of users. With a dedicated team of developers and vital support from Consortium members, Shibboleth has grown over the years to offer a variety of products alongside its world-renowned Identity Provider.（原文：What is Shibboleth?）

アイデンティティ管理技術の世界的リーダーであるShibbolethは、ユーザーの強力なコミュニティを持つオープンソースプロジェクトです。献身的な開発者チームとコンソーシアムメンバーからの重要なサポートにより、Shibbolethは世界的に有名なIdentity Providerに加え、様々な製品を提供するまでに成長しました。（Deepl翻訳） 

なお、Shibbolethという言葉自体は麦の穂を示す言葉で、アッカド語、ウガリト語、アラム語、古代シリア語、旧南アラブ語、アラビア語あたりが語源みたいです。

Cognate with Akkadian 𒋗𒁍𒌌𒌈 (šubultum, “ear of wheat”), Ugaritic 𐎌𐎁𐎍𐎚 (šblt, “ear of grain”), Aramaic שׁוּבַּלְתָּא/שִׁבַּלְתָּא‎ (šubbaltā/šibbaltā), Classical Syriac ܫܒܠܬܐ‎ (šeb(b)eltāʼ, “ear of grain; flow of a river”), Old South Arabian 𐩪𐩨𐩡𐩩‎ (s¹blt, “ear of grain”), and Arabic سُنْبُلَة‎ (sunbula), سَبَلَة‎ (sabala).

- Wikidisctionary「שיבולת」より

同じくWikipediaによるとこのShibbolethのsh（ʃ）の発音ができる・できないで民族の違いを見極めていたことから「ある社会集団の構成員と非構成員を見分けるための文化的指標を表す用語」になってきたとのことです。

そしてギレアデびとはエフライムに渡るヨルダンの渡し場を押えたので、エフライムの落人が「渡らせてください」と言うとき、ギレアデの人々は「あなたはエフライムびとですか」と問い、その人がもし「そうではありません」と言うならば、 またその人に「では『シボレテ』と言ってごらんなさい」と言い、その人がそれを正しく発音することができないで「セボレテ」と言うときは、その人を捕えて、ヨルダンの渡し場で殺した。その時エフライムびとの倒れたものは四万二千人であった。

多分「しょぼれす」って言ったら瞬殺されてますね・・・

この辺りからセキュリティドメイン（フェデレーション）の境界線を区分するためのゲートキーパーとしての認証システムにShibbolethという名称が用いられているのかな、という推測もあながち間違ってないのかもしれません。また、Shibbolethのロゴマークがグリフィンなのも「黄金を守る」という役目を持つ神話上の生物だから、というところに起源があるのかもしれません。（いずれも真偽は不明）

単一デーモンで複数のIdentity ProviderとFederation

さてさて、そんなShibbolethですがSAMLが喋れるIdentity Provider（IdP）としての役割を持つサーバーとApacheやnginxなどのWebサーバに組み込んでService Provider（SP）として構成するためのモジュールから構成されます。

ということで小ネタですが、単一のデーモン/shibdで動作しているSPがVirtual Directoryの単位で別のIdPとFederationさせたいケースが時たまありますので、どう設定するのが良いのかをちょっとだけ。（なお、セッション管理などSPとなるアプリ側でどう扱うかはアプリ側の設計次第なのでスコープアウトします）

やり方としては単純でRequestMapperに追加のApplicationIdを定義してMetadataProviderの設定をオーバライドしてあげるだけです。

こちらがshibboleth2.xmlの設定。additionalAppというapplicationIdを設定し、SP側のEntityID、HandlerURL、IdPのEntityIDとMetadataを別のものを設定してあげます。

<RequestMapper type="Native">

  <RequestMap applicationId="default">

    <Host name="sp.example.org" authType="shibboleth" requireSession="true" applicationId="additionalApp"/>

  </RequestMap>

</RequestMapper>

<ApplicationOverride id="additionalApp" entityID="https://sp.example.org/additionalApp/shibboleth-sp">

  <Sessions lifetime="28800" timeout="7200" checkAddress="false" handlerURL="/additionalApp/Shibboleth.sso">

    <SSO entityID="https://otheridp.example.jp/idp">

      SAML2

    </SSO>

  </Sessions>

  <MetadataProvider type="XML" validate="true" path="otheridp-metadata.xml"/>

</ApplicationOverride>

その上で、httpd.confのLocationにVirtual Directoryを設定し、ShibRequestSettingで追加したApplicationIdを参照するように指定してあげます。

<Location /additionalLocation>

  AuthType shibboleth

  ShibRequestSetting requireSession 1

  require shib-session

  ShibRequestSetting applicationId additionalApp

</Location>

これでshibdとhttpdを再起動すれば完了です。

従来のパスへのアクセス時はshibboleth2.xmlに元々指定してあったデフォルトのIdPへ、追加したパスへのアクセス時には追加で指定したIdPへリダイレクトされるようになります。

なお、REMOTE_USERはそれぞれのパス単位で別のもの（リダイレクト先のIdPのもの）となりますので、この辺りのハンドリングをアプリ側でコントロールしてあげる必要はあります。

ということで今年もよろしくお願いします。 

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

みなさん大好きなdidメソッドの話です。

結局did:webが結構使われてるけどdid:webって既存のwebサイトの管理方法（DNSとかCA）に依存しちゃうので分散型じゃないよね、という課題（？）をカバーするためにdid:websっていうのをToIP（Trust Over IP） Foundationのdid:webs Method Task Forceで検討して仕様策定している、ということのようです。

ToIP Foundationからのアナウンス

https://trustoverip.org/news/2023/12/15/announcing-public-review-of-the-didwebs-method-specification/

個人的には結局インターネット上でDIDを使うユースケースに限っていえば既存のインターネットの仕組みであるDNSのレジストラやHTTPSのCA局のポリシーやガバナンスを信頼する必要があるはずなので、そこまで分散型に拘る必要性は感じない派なのですが・・・

did:webにおける課題

did:websにおける対応

SAMLの場合

SAML 2.0 core仕様

https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

 こんな感じのリクエストになります。

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

                    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"

                    ForceAuthn="false"

                    ID="a133c62aafc8dcee7a69481de5af763c4ee370494"

                    IssueInstant="2024-01-03T03:28:40Z"

                    Destination="https://idp.example.jp/sso/login"

                    AssertionConsumerServiceURL="https://sp.example.com/acs"

                    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

                    Version="2.0"

                    >

    <saml:Issuer>https://sp.example.com/sp</saml:Issuer>

    <saml:Subject>

        <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">test@example.jp</saml:NameID>

    </saml:Subject>

</samlp:AuthnRequest>

OpenID Connectの場合

HTTP/1.1 302 Found

  Location: https://server.example.com/authorize?

    response_type=code

    &scope=openid%20profile%20email

    &client_id=s6BhdRkqt3

    &state=af0ifjsldkj

    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

    &login_hint=test@example.jp

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

OpenID Providerを自前で実装する際の悩みポイントの一つが認可コード、アクセストークンをサーバ側でどの様に保存するか、という問題です。

どういうことかというと、認可コードを発行するタイミングで通常はユーザの認証を行うわけですが、そのタイミングで認証済みユーザの属性情報を取得しておいて認可コード、アクセストークンと紐づけてテーブルに保存をしておく方が実装は簡単になる一方で、最新のユーザ情報をuserInfoから取得したい場合の対応が結局必要になったり、ユーザの削除の検知のメカニズムの実装が必要になる、という話です。

ちなみに、認可コードやアクセストークンをサーバ側で一定期間保持をし続けるための実装がOpenID Providerの可用性やスケーラビリティを左右する最大のポイントの一つだと思うので、この辺りは各サービス事業者の考え方で分かれるところです。（この辺りは別ポストで詳しくお話しようと思いますが、最後までステートレスにこだわったMicrosoftは認可コードをJWTにして認証済みユーザの属性情報を暗号化して入れることでトークン要求時に認可コードからセッションをLookupしてid_tokenを生成する必要をなくしていたり、VittorioがAuthorのRFC9068/JWT Profile for OAuth 2.0 Access Tokenの様にIntrospectionエンドポイントが無くてもトークンの有効性検証ができる仕組みを実装したり、Hybrid Flowでもないのにフロントで取得できるid_tokenにはほとんど情報を入れず、userInfoやGraph APIへのアクセスをしないとユーザ属性が全く取れなかったり、、、とグローバルスケールの認証基盤を運営する上での苦労が滲み出ていたりします）

横道にそれましたが、一番簡単な実装だと認可エンドポイントへアクセスし認証されたタイミングで以下のレコードを保存しておき、

しかし、この実装のメリットはこのレコードだけで全ての処理が完結するため処理がシンプルになること、そしてid_token発行時とuserInfoアクセス時の間に仮にユーザの属性の更新をされても認証時点のユーザの属性情報をクライアントへ返却できる、という点があります。一方でユーザの最新の属性をuserInfoエンドポイントから返却したいケースやユーザの削除されたことを検知するメカニズムの実装が結局必要になる、など考慮点も存在します。

そのため、実際にはユーザの識別子だけをレコード状には記録しておき、トークンエンドポイントやuserInfoエンドポイントへのアクセス時は対応するユーザの属性をデータベースから取得する、という実装になるはずです。

ということで実際どういう実装になっていそうなのか確認してみます。

Microsoft Entra ID

LINE Login

userInfoにアクセスする前にLINEアプリで名前を「開発用」から変更してみました。

この状態でuserInfoにアクセスすると、、

はい、更新後の値が取得されます。

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

昨日こんなことを書きましたので、ちょっと深掘りしてみようと思います。

この辺りは別ポストで詳しくお話しようと思いますが、最後までステートレスにこだわったMicrosoftは認可コードをJWTにして認証済みユーザの属性情報を暗号化して入れることでトークン要求時に認可コードからセッションをLookupしてid_tokenを生成する必要をなくしていたり、VittorioがAuthorのRFC9068/JWT Profile for OAuth 2.0 Access Tokenの様にIntrospectionエンドポイントが無くてもトークンの有効性検証ができる仕組みを実装したり、Hybrid Flowでもないのにフロントで取得できるid_tokenにはほとんど情報を入れず、userInfoやGraph APIへのアクセスをしないとユーザ属性が全く取れなかったり、、、とグローバルスケールの認証基盤を運営する上での苦労が滲み出ていたりします

要するにEntra IDの話なんですが、良いか悪いかは置いておいてOpenID Providerを作るときにバックエンドにDBをなるべく持たずに認可コード、アクセストークン、IDトークンのやりとりを一貫性を持って実行するための工夫の話です。

そもそも何が課題なのか？

これを実装しようとすると認可エンドポイントへのアクセスとトークンエンドポイントへのアクセスが本当に同一トランザクションの中でのやりとりなのかを確認しないといけませんし、サーバ（OpenID Provider）側としてはトランザクション内での情報の保持をしないといけなくなります。ただHTTPは本来ステートレスな仕組みなので、通常のWebアプリケーションを作る場合と同じ様にサーバ側でのセッション管理をどうするか、しかも認可エンドポイントはユーザエージェントから直接アクセス、トークンエンドポイントはクライアントからのバックエンドアクセスという形なのでcookieで、というわけにも行きません。

通常の実装では何の疑問もなくバックエンドにデータベースを置いてステート管理をサーバ側で実装することになるのですが、グローバルでスケールしている認証サービスの様に極めて高い可用性が必要とされるサービスでその様なインフラを作るのは非常にコストが高い行為といえます。（Entra IDの様に基本無償で提供される様なサービスなら難しい判断になると思います）

そうだ、クライアントにステート情報のハンドリングを任せよう！

そこで考えられたのが全てのやりとりの中で最終的にIDトークンやアクセストークンを発行するのに必要となる情報をもと回れば良いではないか、という考え方だと思われます。（Entra ID以外で見たことはありませんが）

簡単に流れを説明するとこんな感じになっているんだと思います。

認可エンドポイント

1. ユーザを認証する→最終的にIDトークンに含めるユーザの属性情報を取得する
2. nonceやaud（クライアントID）など、同じく最終的にIDトークンに含める属性をクエリパラメータから取得する
3. 1,2で取得した情報を暗号化してJWTにして認可コードとしてクライアントへ戻す

この辺りをミニマムで実装してみるとこんな感じのコードになると思います。（テスト実装なので細かいところは気にしないでください）

const router = require("express").Router();
const jwt = require("jsonwebtoken");

// jwt署名に使う共有シークレット
const jwtSecretForCode = "this_is_a_secret_for_code_signing";
const jwtSecretForToken = "this_is_a_secret_for_token_signing";

// 認可エンドポイント
router.get("/authorization", async (req, res) => {
    // 本来なら実装する処理
    // - ユーザの認証
    // - response_typeによるフローの振り分け
    // - client_idの登録状態の確認
    // - redirect_uriとclient_idが示すクライアントとの対応確認
    // - scopeの確認
    // - 属性送出に関する同意画面の表示

    // codeの生成（本来は暗号化しておく）
    // 最終的にid_tokenに入れる値をDBに保存する代わりに暗号化してcodeに入れておくことでバックエンドを持たずにすませる
    const jwtPayload = {
        iss: "myOpenIDProvider",
        aud: req.query.client_id,
        sub: "authenticatedUserIdentifier",
        email: "test@example.jp",
        given_name: "taro",
        family_name: "test",
        nonce: req.query.nonce
    };
    const jwtOptions = {
        algorithm: "HS256", // 面倒なのでHS256にする
        expiresIn: "30s" // コードの有効期限なので短め
    };
    const code = jwt.sign(jwtPayload, jwtSecretForCode, jwtOptions);
    // redirect_uriへリダイレクト
    res.redirect(req.query.redirect_uri + "?code=" + code + "&state=" + req.query.state);
});

// トークンエンドポイント
router.post("/token", (req, res) => {
    // 本来なら実装する処理
    // - クライアントの認証
    // - grant_typeの検証
    // - codeの検証（有効期限、発行先クライアント、スコープ）
    // - access_tokenの発行
    // - id_tokenの発行
    const code = req.body.code;
    jwt.verify(code, jwtSecretForCode, (err, decoded)=> {
        if(err){
            res.json({
                err: "counld not verify code"
            })
        };
        if(decoded){
            // 本来は検証が終わったらcodeを無効化する
            // codeの中身を取り出してid_tokenを作る
            const jwtPayload = {
                iss: decoded.iss,
                aud: decoded.aud,
                sub: decoded.sub,
                email: decoded.email,
                given_name: decoded.given_name,
                family_name: decoded.family_name,
                nonce: decoded.nonce
            };
            const jwtOptions = {
                algorithm: "HS256", // 面倒なのでHS256
                expiresIn: "10m" // id_tokenの有効期限なので少しだけ長め
            };
            const token = jwt.sign(jwtPayload, jwtSecretForToken, jwtOptions);
            res.json({
                access_token: token, // ちなみにEntra IDの場合はaccess_tokenもid_tokenとほぼ同じものが使われるケースもある。
                token_type: "Bearer",
                expires_in: 3600,
                id_token: token
            });
        }
    });
});

module.exports = router;

http://localhost:3000/oauth2/authorization?client_id=111&redirect_uri=https://localhost:3000/cb&state=hoge

• コールバックへのリダイレクト

https://localhost:3000/cb?code=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJteU9wZW5JRFByb3ZpZGVyIiwiYXVkIjoiMTExIiwic3ViIjoiYXV0aGVudGljYXRlZFVzZXJJZGVudGlmaWVyIiwiZW1haWwiOiJ0ZXN0QGV4YW1wbGUuanAiLCJnaXZlbl9uYW1lIjoidGFybyIsImZhbWlseV9uYW1lIjoidGVzdCIsImlhdCI6MTcwNDQyMDk1MCwiZXhwIjoxNzA0NDIwOTgwfQ.XKi6JLc5IwDNyZG1C7Lrk1UrBiWpOV5EC2NgpqWSXjk&state=hoge

• 認可コードの中身（面倒なので今回は暗号化はしていません）

• トークンエンドポイントへのPOST 

• 取得できたIDトークンの中身

本当にこれでいいのか？

まぁ確かにスケーラビリティを考えると非常にエコなので実装としてはありだと思いますが、色々と割り切りをしないといけません。

例えば、

• 認可コードのサイズが大きくなる
• アクセストークンはJWT形式（内包型トークン）が前提となり、Introspectionエンドポイントの実装はできない

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

OpenID Connectってシンプルなプロトコルだと思いますが、やっぱりOpenID Providerの気持ちにならないと本当のところはわからないよね、ということで「OpenID Providerを作る」シリーズ（デ⚫︎ゴ⚫︎ティーニ風）でもやってみようかと思います。

超絶ベーシックなところまでは前回・前々回のポストを踏まえて2時間くらいで作ってみたのでまずはこちらを解説しつつ実装を一緒に育てていきたいな、と考えています。

とりあえず作ったところまではこちらのレポジトリで公開しています。（前回のポストからの追加部分としては認可コードをJWEにしたところくらいです。詳しくはReadmeを見てください）

https://github.com/fujie/oidc-study-op

ということで、中身は次回から解説しますが現状の実装で何ができるのかの確認を兼ねてOpenID Connectの通信が実際にどうなっているのかを、Azure AD B2Cを使って確認してみようと思います。結構Azure AD B2CとかAuth0を触るときにサービス側が外部IdPにどういう期待をしているのかを知るためにこれまでも簡易IdPを作って通信トレースをとったりしていたのですが、この辺りの試行錯誤がOpenID Connectそのものを知ることにつながりますし、Azure AD B2CやAuth0などのIDaaSについての知識も深められて一石二鳥です。

早速Azure AD B2Cに作ったOpenID ProviderをIDプロバイダとして読み込ませてみます。作ったOpenID Providerはローカルで動かしていますのでngrokを使ってインターネットからアクセスできる様にしています。

ちなみにAzure AD B2Cに限らずMicrosoftのID基盤はresponse_modeとしてform_postをデフォルトにしているのですが、そんなものは作っていないのでqueryに変更してあげる必要があります。

free版のngrokを使っているのでngrokを止めてしまうとURLが変更されてしまうので注意が必要です。（もし止めてしまったら一度IDプロバイダを消して再作成する必要があります）

なお、ngrokを使う利点としてインスペクションができることです。（http://127.0.0.1:4040をブラウザで開くと通信内容がトレースできます）

Azure AD B2CでIDプロバイダの設定をして保存を行うとDiscoveryとjwks_uriへのアクセスがあります。

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

前回のポストではOpenID Connectの認可コードフローの全体像を書きましたので今回から中身について深掘りしていきたいと思います。

ディスカバリとは何をするフェーズなのか？ですが、簡単にいうとOpenID Provider自身に関する情報をRelying Partyに伝えることが目標となります。

もちろんRelying Partyに対してOpenID Providerの構成情報を都度細かく伝えても良いのですが、Relying Partyの数が増えてくるとチリも積もるので設定作業が面倒になってきますし、何よりも何らかの構成変更がOpenID Provider側に発生した場合に変更情報を全Relying Partyに伝え直すのは至難の技です。

この課題を解決するためにOpenID ConnectにはOpenID Connect Discoveryという仕様が定められています。

Discoveryの流れ

大まかな流れとしては、以下の２つのフェーズに分かれます。

1. ユーザの識別子からOpenID ProviderのURLを取得する
2. OpenID Providerの構成情報を取得する

まず最初のフェーズですが、元々はDiscoveryの仕様はWebfingerの仕様に則ってOpenID ProviderのURLを取得することを想定して策定されていました。

こんな流れです。

1. Relying Partyにユーザが自身の識別子（例：test@example.jp）を提供する
2. Relying Partyのユーザの識別子のドメインパート（example.jp）に対応するOpenID Providerを検索する（この部分がWebfinger）

• 具体的には以下のGETリクエストを投げる
• https://example.jp/.well-known/webfinger?
• resource=test@example.jp&
• rel=http://openid.net/specs/connect/1.0/issuer

しかしながら、現実問題としてほとんどのRelying Partyではユーザ自身が利用するOpenID Providerを選択するUXとなっているため、このフェーズが利用されることはほとんどありません。（OpenID Providerが利用者の識別子がOpenID Providerのドメイン名と一致していないケースも多くなってきていることもあるんだと思います）

そのため、本命は２番目のフェーズとなる、Relying PartyがあらかじめOpenID ProviderのURLまでは知っているところからスタートする構成情報の取得となっています。

こちらは{OpenID ProviderのURL}/.well-known/openid-configurationというURLへのGETリクエストを投げ込むことでOpenID Providerの構成情報（エンドポイントやサポートする署名アルゴリズムなど）を取得するという仕組みとなっています。

例えば、LINE Loginであれば「https://access.line.me/.well-known/openid-configuration」をGETすると以下のメタデータが返ってきます。

{

    "issuer": "https://access.line.me",

    "authorization_endpoint": "https://access.line.me/oauth2/v2.1/authorize",

    "token_endpoint": "https://api.line.me/oauth2/v2.1/token",

    "revocation_endpoint": "https://api.line.me/oauth2/v2.1/revoke",

    "userinfo_endpoint": "https://api.line.me/oauth2/v2.1/userinfo",

    "scopes_supported": ["openid", "profile", "email"],

    "jwks_uri": "https://api.line.me/oauth2/v2.1/certs",

    "response_types_supported": ["code"],

    "subject_types_supported": ["pairwise"],

    "id_token_signing_alg_values_supported": ["ES256"],

    "code_challenge_methods_supported": ["S256"]

}

実態として.well-known/openid-configurationも提供していないOpenID Providerも存在しますし、返ってくる情報が当てにならないところもあるのでちゃんとドキュメントは読みましょう、という話にしかならないわけですが・・・（ちなみにLINE LoginもIDトークンの署名アルゴリズム/id_token_signing_alg_values_supportedがES256とありますが、実際の署名としてはRS256となっていたりします）

OpenID Providerの構成情報にはどの様なものがあるのか

仕様の「3.  OpenID Provider Metadata」にOpenID Providerが提供するメタデータに記載されている構成情報について解説されています。

ざっくりこんな感じです。

Discoveryエンドポイントを実装してみる

では実装してみます。非常に単純なエンドポイントなので/.well-known/openid-configurationに対するGETリクエストがあったら必要な情報をJSONで返却するだけです。

githubに公開しているソースのうち、この部分が該当します。

https://github.com/fujie/oidc-study-op/blob/main/endpoints/discovery.js

const router = require("express").Router();

// Discoveryエンドポイント
router.get("/openid-configuration", (req, res) => {
    const baseUrl = 'https://' + req.headers.host;
    const response_types = ["code"];
    const subject_types = ["public"];
    const alg_values = ["RS256"];
    const scopes = ["openid"];
    const auth_methods = ["client_secret_post", "client_secret_basic"];
    const claims =["sub", "name", "given_name", "family_name", "email", "email_verified", "iss", "aud", "exp", "exp", "iat"];
    res.json({
        issuer: baseUrl,
        authorization_endpoint: baseUrl + "/oauth2/authorize",
        token_endpoint: baseUrl + "/oauth2/token",
        userinfo_endpoint: baseUrl + "/userinfo",
        jwks_uri: baseUrl + "/jwks_uri",
        response_types_supported: response_types,
        subject_types_supported: subject_types,
        id_token_signing_alg_values_supported: alg_values,
        scopes_supported: scopes,
        token_endpoint_auth_methods_supported: auth_methods,
        claims_supported: claims
    });
});
module.exports = router;

node.js.+ express routerで実装しているので/.well-knownへのアクセスはこのJSへルーティングされる様にしています。

やっていることは単純で必要な情報をres.jsonで返却しているだけですね。

Relying PartyはOpenID Providerへリクエストをする際にこのエンドポイントにアクセスして最新の構成情報を取得して各種エンドポイントを利用する、という動きをする、ということですね。（パフォーマンスの観点でRelying Party側でメタデータをキャッシュをすることも多いと思います）

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

少し毛色を変えて今日はみんな大好き選択的開示（Selective Disclosure）です。

特にVerifiable Credentialsを使うユースケースの典型的なシナリオに「バーに入る際の年齢証明に免許証を見せる」というものがあります。しかしながら年齢が21歳以上であることを証明したいだけなのに運転免許証を見せてしまうと住所や氏名などの本来不要な情報まで提示することになってしまいます。そこでSelective Disclosureが大事、という話になってきます。

一見簡単そうに見えますが、署名が施されたデータの中身を改竄する（実際は不要なデータを間引く）ことになるのでデジタル署名の目標である真正性の担保という話と相反することになってしまいます。

これまでもBBS+など仕組みは出てきていますが今日はJSON Web Tokenを対象としたSD-JWTの話をしたいと思います。

簡単な仕組み

従来の署名月JWTは対象となるデータ（JSON）をBase64Urlエンコードして署名アルゴリズムなどの情報をヘッダに入れ、署名を施して".（ピリオド）"で連結したものでした。OpenID ConnectにおけるIDトークンもこのフォーマットですね。

例えば、こんなデータを対象としたいと思います。

{

  "iss": "http://server.example.com",

  "sub": "248289761001",

  "aud": "s6BhdRkqt3",

  "nonce": "n-0S6_WzA2Mj",

  "exp": 1311281970,

  "iat": 1311280970,

  "name": "Jane Doe",

  "given_name": "Jane",

  "family_name": "Doe",

  "gender": "female",

  "birthdate": "0000-10-31",

  "email": "janedoe@example.com",

  "picture": "http://example.com/janedoe/me.jpg"

}

これをRS256で署名してJWTとする場合、ヘッダにはアルゴリズムの情報などを入れます。

{

  "kid": "1e9gdk7",

  "alg": "RS256"

}

最後にヘッダ、ペイロードをそれぞれBase64Urlエンコードしてデジタル署名の値を最後に追加します。（ヘッダ・ペイロード・署名の間を"."で連結します）

すると結果、こんな感じになります。

eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogImlzcyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5NzAsCiAibmFtZSI6ICJKYW5lIERvZSIsCiAiZ2l2ZW5fbmFtZSI6ICJKYW5lIiwKICJmYW1pbHlfbmFtZSI6ICJEb2UiLAogImdlbmRlciI6ICJmZW1hbGUiLAogImJpcnRoZGF0ZSI6ICIwMDAwLTEwLTMxIiwKICJlbWFpbCI6ICJqYW5lZG9lQGV4YW1wbGUuY29tIiwKICJwaWN0dXJlIjogImh0dHA6Ly9leGFtcGxlLmNvbS9qYW5lZG9lL21lLmpwZyIKfQ.rHQjEmBqn9Jre0OLykYNnspA10Qql2rvx4FsD00jwlB0Sym4NzpgvPKsDjn_wMkHxcp6CilPcoKrWHcipR2iAjzLvDNAReF97zoJqq880ZD1bwY82JDauCXELVR9O6_B0w3K-E7yM2macAAgNCUwtik6SjoSUZRcf-O5lygIyLENx882p6MtmwaL1hd6qn5RZOQ0TLrOYu0532g9Exxcm-ChymrB4xLykpDj3lUivJt63eEGGN6DH5K6o33TcxkIjNrCD4XB1CKKumZvCedgHHF3IAK4dVEDSUoGlH9z4pP_eWYNXvqQOjGs-rDaQzUHl6cQQWNiDpWOl_lxXjQEvQ

jwt.ioなどのサイトでデコードすると中身がわかります。

そのため、実はSD-JWTで選択的開示をする際はペイロード自体には何の加工もしません（やっぱりペイロードを改竄しちゃうと署名はこわれるので）。その代わりにSD-JWTを作成する際に以下の工夫を施します。

• 選択的開示の対象となる属性のハッシュをペイロードに入れる
• 従来のJWTの最後（署名の後）にDisclosureと言われる各属性に対応する値を追加する（~（チルダ）で連結する）

このDisclosureがあればペイロード内のハッシュ化された値を元に戻せるので開示したくない属性についてはDisclosureを削除してしまうことで受け取り側は値を知ることができなくなる、という仕組みです。

先ほどのJWTのペイロードをSD-JWTにする場合はこんな感じになります。要するに隠す可能性がある属性について"_sd"という要素にハッシュ化した値を入れる感じです。

{

  "iss": "http://server.example.com",

  "aud": "s6BhdRkqt3",

  "nonce": "n-0S6_WzA2Mj",

  "iat": 1516239022,

  "exp": 1735689661,

  "_sd": [

    "5G_krZtMTMPltAWWNMhdDxJMt15SA1KFkd2gIlSvLtQ",

    "5p6bt53D9p4MfkVYQciL4pWXAkIjz0PbLXGD0NHii2w",

    "6Jt5lxreiTK8olTRzyHoHYYPmu0G-ZVvWpacVmYYT8M",

    "Ew-dKRmA2uSgw9EmGwNIfQksPpPIs0qA4OE-86DQ3_Y",

    "Hz-BYPQJmHsFlIfZ_9CJ6IboqisoZNtwzkb0Z3JAlF4",

    "J3P_gNA3LECIzTttBuX62cLVICDFzR-rroiCQkbBbuQ",

    "O2bDUHaELZIsyOXTyutWunAgm37QTkbCTRw73bi55xE",

    "Q4vtraDvprqBkjrPoLW_9FZDetFKKAGcya05rIwq4xg"

  ],

  "_sd_alg": "sha-256"

}

そしてこのペイロードを通常通りデジタル署名付きのJWTにしたものがこちらの文字列です。

eyJhbGciOiJFUzI1NiJ9.eyJpc3MiOiJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwiYXVkIjoiczZCaGRSa3F0MyIsIm5vbmNlIjoibi0wUzZfV3pBMk1qIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE3MzU2ODk2NjEsIl9zZCI6WyI1R19rclp0TVRNUGx0QVdXTk1oZER4Sk10MTVTQTFLRmtkMmdJbFN2THRRIiwiNXA2YnQ1M0Q5cDRNZmtWWVFjaUw0cFdYQWtJanowUGJMWEdEME5IaWkydyIsIjZKdDVseHJlaVRLOG9sVFJ6eUhvSFlZUG11MEctWlZ2V3BhY1ZtWVlUOE0iLCJFdy1kS1JtQTJ1U2d3OUVtR3dOSWZRa3NQcFBJczBxQTRPRS04NkRRM19ZIiwiSHotQllQUUptSHNGbElmWl85Q0o2SWJvcWlzb1pOdHd6a2IwWjNKQWxGNCIsIkozUF9nTkEzTEVDSXpUdHRCdVg2MmNMVklDREZ6Ui1ycm9pQ1FrYkJidVEiLCJPMmJEVUhhRUxaSXN5T1hUeXV0V3VuQWdtMzdRVGtiQ1RSdzczYmk1NXhFIiwiUTR2dHJhRHZwcnFCa2pyUG9MV185RlpEZXRGS0tBR2N5YTA1ckl3cTR4ZyJdLCJfc2RfYWxnIjoic2hhLTI1NiJ9.LAlXQnPK8rOhxBhbg_FU-hiBJJqCX5CYWYTp0YcbbIxnBZPN1ZhRgE_SLh0rEg1L559GxmG1WrpGMyOl1rDoAA

このJWTに"_sd"に入れた各属性に対応するDisclosureを~で連結して追加していきます。赤字の部分が追加したものです。

eyJhbGciOiJFUzI1NiJ9.eyJpc3MiOiJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwiYXVkIjoiczZCaGRSa3F0MyIsIm5vbmNlIjoibi0wUzZfV3pBMk1qIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE3MzU2ODk2NjEsIl9zZCI6WyI1R19rclp0TVRNUGx0QVdXTk1oZER4Sk10MTVTQTFLRmtkMmdJbFN2THRRIiwiNXA2YnQ1M0Q5cDRNZmtWWVFjaUw0cFdYQWtJanowUGJMWEdEME5IaWkydyIsIjZKdDVseHJlaVRLOG9sVFJ6eUhvSFlZUG11MEctWlZ2V3BhY1ZtWVlUOE0iLCJFdy1kS1JtQTJ1U2d3OUVtR3dOSWZRa3NQcFBJczBxQTRPRS04NkRRM19ZIiwiSHotQllQUUptSHNGbElmWl85Q0o2SWJvcWlzb1pOdHd6a2IwWjNKQWxGNCIsIkozUF9nTkEzTEVDSXpUdHRCdVg2MmNMVklDREZ6Ui1ycm9pQ1FrYkJidVEiLCJPMmJEVUhhRUxaSXN5T1hUeXV0V3VuQWdtMzdRVGtiQ1RSdzczYmk1NXhFIiwiUTR2dHJhRHZwcnFCa2pyUG9MV185RlpEZXRGS0tBR2N5YTA1ckl3cTR4ZyJdLCJfc2RfYWxnIjoic2hhLTI1NiJ9.LAlXQnPK8rOhxBhbg_FU-hiBJJqCX5CYWYTp0YcbbIxnBZPN1ZhRgE_SLh0rEg1L559GxmG1WrpGMyOl1rDoAA~WyJ5OWVMRmI3azdXZnd4ZkllQWp5eUt3Iiwic3ViIiwiMjQ4Mjg5NzYxMDAxIl0~WyJUNkVlZzRsaVJyN3VtOUZxOFRYekR3IiwibmFtZSIsIkphbmUgRG9lIl0~WyJUUnRocWdUc29kZzVJbnBBR2ZvNjJnIiwiZ2l2ZW5fbmFtZSIsIkpvbmUiXQ~WyJmRWx5VzFIdlVjX1dYTnFLeUdRcEJ3IiwiZmFtaWx5X25hbWUiLCJEb2UiXQ~WyI1blgwRmZTNHUtVjN3aFNORUpPQndnIiwiZ2VuZGVyIiwiZmVtYWxlIl0~WyJhSzhJYWc2dzB1Mno1WVpxMWlXOC13IiwiYmlydGhkYXRlIiwiMDAwMC0xMC0zMSJd~WyIwR0pLdnN2aDNpbnFkeGlUM3MxbVJRIiwiZW1haWwiLCJqb25lZG9lQGV4YW1wbGUuY29tIl0~WyJXMHpCa1lfLThqUVhNY3JnYTJTak9BIiwicGljdHVyZSIsImh0dHA6Ly9leGFtcGxlLmNvbS9qYW5lZG9lL21lLmpwZyJd

これでSD-JWTが出来上がりました。

これを渡されたVerifierなどはDisclosureの値を使ってペイロード内の"_sd"の値を復号して実際の属性値を取得する、ということをやります。また、開示したくない値があれば対応するDisclosureの値を消した状態でSD-JWTを渡せば良い、という理屈です。

体感してみる

といっても細かい実装の話をするのは疲れるので世の中に出てきているツールを触って体感してみたいと思います。

今回はこのツールを使ってみます。

https://github.com/christianpaquin/sd-jwt

詳細はREADMEに書いてある通りなのですが、取り合えずやってみましょう。

ざっくりこんな手順です。

1. SD-JWTの署名に使う鍵を生成する
2. jwt（Disclose対象じゃない部分）のjsonを用意する
3. sd（Disclose対象としたい部分）のjsonを用意する

まずは鍵を生成します。

npm run generate-issuer-keys -- -k <jwksPath> -p <privatePath> -a <keyAlg>

- jwksPathは公開鍵のファイル名です（なければ作ってくれます）

- privatePathは秘密鍵のファイル名です（同上）

- keyAlgはアルゴリズムです。指定しないとES256になります

鍵の準備ができたらSD-JWTを作ってみます。まずはDisclose対象じゃない部分のJSONを用意します。今回はこんなファイルを用意しました。（先ほどの例の個人属性以外の部分ですね）

  {

    "iss": "http://server.example.com",

    "aud": "s6BhdRkqt3",

    "nonce": "n-0S6_WzA2Mj",

    "iat": 1516239022,

    "exp": 1735689661

  }

そして、Disclose対象の部分のJSONです。（先ほどの例の個人属性部分です）

{

    "sub": "248289761001",

    "name": "Jane Doe",

    "given_name": "Jone",

    "family_name": "Doe",

    "gender": "female",

    "birthdate": "0000-10-31",

    "email": "jonedoe@example.com",

    "picture": "http://example.com/janedoe/me.jpg"

  }

ではSD-JWTを生成してみます。

npm run create-sd-jwt -- -k {作成した秘密鍵} -t {作成したDisclose対象外のJSON} -h sha-256 -c {作成したDisclose対象のJSON} -o {出力したいSD-JWT}

こんな感じの書式です。では実際に生成してみます。

npm run create-sd-jwt -- -k private.jwk -t jwt.json -h sha-256 -c sdClaimsFlat.json -o sd-jwt.json

こちらが実行時の出力です。

出来上がったJWSがsd-jwt.jsonに書き込まれています。

jwt.ioでデコードしてみるとちゃんとSD-JWTになっていることがわかります。

（ちなみにjwt.ioではDisclosure部分は見えません）

次は一部の属性を取り除いた状態で検証できるかどうかの確認です。

出力されたsd-jwt.jsonのDisclosureを一部取り除いてみましょう。なお、Disclosureは上から順番に対象の属性と対応しているので何番目の属性を隠すのかでどのDisclosureを削除すれば良いのかが決まります。

例えば今回７番目の属性がemailなので７番目のDisclosureを削除してみます。ちなみに私はMacのTerminalのviでファイルの編集をしたのですが、保存をするとLine terminator（0a）が行末に追加されてしまうので、awkで削る必要がありました。

awk '{printf("%s", $0)}' sd-jwt.json > user-sd-jwt.json

こんな感じです。

% file user-sd-jwt.json 

user-sd-jwt.json: ASCII text, with very long lines (1260), with no line terminators

fileコマンドで確認するとwith no line terminatorsとなっているのでこれで準備完了です。

早速ですが検証をするためのコマンドを叩きます。

npm run verify-sd-jwt -- -t {インプットとなるSD-JWTファイル} -k {公開鍵} -o {出力されるJWT} -d {開示された属性}

という書式です。

実際に実行するとこんな感じになり、email属性が消えていることがわかります。

ということでみんな大好きなVerifiable CredentialsとSelective Disclosureでした。

認可エンドポイントの役割と処理内容

認可エンドポイントの実装

生成した認可コードとstateをredirect_uriに渡してあげることで認可エンドポイントの役割はおしまいです。

https://localhost:3000/cb?code=eyJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiYWxnIjoiQTI1NktXIiwia2lkIjoiOXBheXlGVzBMdEZ0czkyRDE5VVJCSS15bHc5TGh2ZWI1dFJKYkkxU19vdyJ9.XAMPBCzLxSipsZILlvL9r6qdhL0teaYZkpO17RYgVqirv4btHMsdPQ.2kJJ1PExtsZLhI-nPSpLNQ.Kyxyt6TC2CdV81xbq8_roFaZfERZKSg9vnlInTZHnxS8eb9cVAOW_RESgKFWkt6g9vW6CXgO6qE5w-3Oe2J8jV92gVThUwlz5PcQCKgxZ6xkBr5_cRQv5S22GXeEreYVn746qpJGAcEOACyeB5jEFy-RG0ItrGq3FAMaVVBHcHGfAJc9LCk_TaKdOdm3CvVFk67RpNxE9jVsL7oyWSNJqWkrtAsQIYxDi80ZrgGszOc.lYl0xrOMOHNFROtCHCPtng&state=hoge

ということで今回は認可エンドポイントを雑に（？）作りました。次回はトークンエンドポイントです。 

トークンエンドポイントの役割と処理

  POST /token HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

  grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

トークンエンドポイントの実装

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

OpenID Connectを理解するにはOpenID Providerを作るのが一番、ということで各種エンドポイントを実装してきていますが、一応今回で基本的な部分はおしまいです。

UserInfoエンドポイントの役割と処理

UserInfoエンドポイントの実装

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

前回までで一通り認可コードフロー（code flow）の流れを実装しました。

• まずは全体像から
• まずOpenID Providerの情報をRelying Partyに提供する
• OpenID Providerを作る）認可エンドポイントを作る
• OpenID Providerを作る）トークンエンドポイントを作る
• OpenID Providerを作る）UserInfoエンドポイントを作る

認可エンドポイントの実装を拡張する

ディスカバリエンドポイントの拡張

動作確認

https://jwt.ms/#id_token=eyJ0eXAiOiJqd3QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImpURkZodFR4ZVVsUHFEVlNEQ0dTNVBCOF9HNkpTSjdIS0IxSGFyQU1GMUkifQ.eyJpc3MiOiJodHRwczovL2xvY2FsaG9zdDozMDAwIiwiYXVkIjoiMTExIiwic3ViIjoidGVzdCIsImVtYWlsIjoidGVzdEBleGFtcGxlLmpwIiwibmFtZSI6InRhcm8gdGVzdCIsImdpdmVuX25hbWUiOiJ0YXJvIiwiZmFtaWx5X25hbWUiOiJ0ZXN0IiwiZXhwIjoxNzA1MTM0NjAyLCJpYXQiOjE3MDUxMzQwMDJ9.bSgUeKQBf8cYv2wveFvq5IFTWDpYUu7_s2iVci3dZKyp8tkful3u1Jj9oN4xzS-mn8bz-Ww9a4jIS6KyTKBgeT6HHMlhF-YiMtwMn8_FKqpOY_O94GPFkgUMgwB3Qu1QGTxx5O4fWCzQoZpUFgFF5JW339CAAH4TRtDRcjSJnBR5z7aMU8Ig-UQXIuhLtAAuHDZ01fc3xYyXiOWi4C9Rio6yFDxrO-kVxgAlFWfP7k8qvUEWrX3IlZYIVQQ0GgNtKQSAxGVQZxb9TgShZi2sQvl2EeE-I9DKVSw9W_OI6UOTIdQlc4KNQ5qqLHsuoE74iE1SVf6Oqr_Z67NZYm3GMw&state=hoge

という形でフラグメントにIDトークンが返却され、jwt.msのサイトでデコードされた情報が表示されます。

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

認可コードフロー（code flow）の流れの実装に加えてresponse_typeの実装を行いインプリシットとハイブリッドフローの入り口を実装してきました。

• まずは全体像から
• まずOpenID Providerの情報をRelying Partyに提供する
• OpenID Providerを作る）認可エンドポイントを作る
• OpenID Providerを作る）トークンエンドポイントを作る
• OpenID Providerを作る）UserInfoエンドポイントを作る
• OpenID Providerを作る）response_typeを実装する

認可コードとアクセストークンとIDトークンが同一のトランザクションで発行されていることを確認したいような高いセキュリティレベルが求められるようなケースではハイブリッドフローが用いられることがあります。

• code の ASCII オクテットのハッシュ値を計算する. ハッシュアルゴリズムは, ID Token の JOSE Header に含まれる alg Header Parameter で利用されるものを利用する. 各 alg Header Parameter に対応するハッシュアルゴリズムは JWA [JWA] で定義されている. たとえば, alg が RS256 であれば, 使用されるハッシュアルゴリズムは SHA-256 である.
• ハッシュの左半分を取得し, base64url エンコードする.

同じくアクセストークンのハッシュは以下通り生成する必要があるようです。

• Access Token のハッシュ値. この値は, access_token の ASCII オクテット列のハッシュ値の左半分を base64url エンコードしたものであり, ハッシュアルゴリズムは ID Token の JOSE Header にある alg Header Parameter で用いられるハッシュアルゴリズムと同じものを用いる. 例えば alg が RS256 であれば, access_token の SHA-256 ハッシュ値を計算し, その左半分の128ビットを base64url エンコードする. at_hash は大文字小文字を区別する文字列である.

要するに、それぞれの値の半分に割った左側の値をIDトークンの署名アルゴリズムに沿ってハッシュを取得してBase64Urlエンコードした値をIDトークンの中に含めれば良いと言うことです。

ということで実装していきます。

今回はIDトークンはRS256で署名するのでハッシュはSHA256なので、こんな感じの実装になりそうです。

上記に記載した通り、

1. SHA256でハッシュを取る
2. ハッシュの前半をBase64Urlエンコードする

アクセストークンはこんな感じです。

これらの値（c_hash、at_hash）の値をIDトークンに含めていきます。

これであとはRelying Partyが受け取った認可コードをc_hashで、アクセストークンをat_hashで検証することでトランザクションが同一で合ったことの検証を行います。

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

前回はHybridフローに必要なc_hashやat_hashの実装をしてみました。

• まずは全体像から
• まずOpenID Providerの情報をRelying Partyに提供する
• OpenID Providerを作る）認可エンドポイントを作る
• OpenID Providerを作る）トークンエンドポイントを作る
• OpenID Providerを作る）UserInfoエンドポイントを作る
• OpenID Providerを作る）response_typeを実装する
• OpenID Providerを作る）Hybridフローを実装する

そもそもPairwise識別子とは

しかしながら、主に3rdパーティのRelying Partyとの連携を前提とすると先ほどのThe Laws of Identityの原則に従うと各Relying Party同士が結託しても簡単には属性情報を取得できないようにする必要があるわけです。そこで識別子のタイプに「pairwise」を使用し、以下のような状態を作り上げます。

この状態であれば各Relying Partyは隣のRelying Partyにアクセスしにきているユーザが自分のところにアクセスしてきているユーザと同一のユーザなのかを機械的に判断するのは難しくなります。（なお、識別子をpairwiseにしてもメールアドレスなど他の属性で識別可能になってしまう実装は世の中にたくさんあります。この辺りはユーザに対して提供する利便性とのバランスを含め考えていく必要があると思います）

Pairwise識別子を実装する

• Subject Identifier 値が, OpenID Provider 以外の Party にとって, 可逆であってはならない (MUST NOT).
• 異なる Sector Identifier 値は, 異なる Subject Identifier 値にならなければならない (MUST).
• 同じ入力に対して必ず同じ結果となる決定的アルゴリズムでなければならない (MUST).

• Sector Identifierを, ローカルアカウントIDおよび Provider によって秘密にされているソルト値と連結する. そして連結した文字列を適切なアルゴリズムによってハッシュ化する.
• sub = SHA-256 ( sector_identifier || local_account_id || salt ) を計算する.
• Sector Identifierを, ローカルアカウントIDおよび Provider によって秘密にされているソルト値と連結する. そして連結した文字列を適切なアルゴリズムによって暗号化する.
• sub = AES-128 ( sector_identifier || local_account_id || salt ) を計算する.
• Issuer は, Sector Identifier とローカルアカウントIDのペアに対し, Globally Unique Identifier (GUID) を作成する.
  

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

いよいよ今週末、4年に一度のOpenID Summit Tokyoが渋谷ストリームで開催されます。

見どころなどは明日にでも紹介しようと思いますが、その前に4年前を少しだけ振り返っておきましょう。

前回のテーマは「真のDXを支えるID」でした。時代的にDXというキーワードが出始めていた時期ですし、OpenID Connectの適用先もコンシューマからエンタープライズへ本格的に広がってきつつある時期だったと思います。また、新たなキーワードとして自己主権型アイデンティティという言葉もこの時期から注目を集め始めていた頃です。

こちらが前回のプログラムですが、KYCやFAPI、FIDOなども注目のテーマの一つでしたね。

前回のサミットで思い出深い点が何点かあるのでその点を少しだけ紹介させてください。

コロナ直前のイベントだった

Kim Cameron氏の最後の国際イベント登壇だった

本ブログでの文字起こしと翻訳はこちら

自己主権型アイデンティティからVerifiable Credentialsへ

先にも触れた通り、自己主権型アイデンティティの文脈が今後どうなっていくのか？について議論をする目的もありKim Cameron氏に来日いただいたこともあり、実はイベントの翌週にOpenID Foundation関係者で再度イベント（合宿）を行いました。こちらは残念ながら非公開なのですが、主に企画をOpenID FoundationでeKYC and Identity Assurance WGの共同議長を一緒にやっていたTorsten Lodderstedt氏と私で取り回していました。元々はeKYCの文脈で自己主権型アイデンティティや分散型識別子（DID）、検証可能な資格情報（Verifiable Credentials）をどのように利活用すべきか、という議論を半日かけてKim Cameron氏の考えを伺いながら議論をしました。この再度イベントには後にW3CのVerifiable Credentials Working Groupの共同議長、最近OpenID Foundationに設立されたDigital Credentials Protocol Working Groupの共同議長を務めることになる安田クリスチーナさんも参加していました。その流れもありTorsten Lodderstedt氏と安田クリスチーナさんが現在のOpenID for Verifiable Credentials関連のプロファイルの仕様策定者となっているのは非常に感慨深いものがあります。まさにこのサイドイベントがきっかけとなりデジタルクレデンシャルに関する仕様が産まれて4年が経過し、EUや日本の政府機関でもVerifiable Credentialsに関するプロジェクトが進み、まさに今年OpenID Summitが再び東京で開催されるのは運命的なものを感じます。

本当にこの4年間は世界が大きく変わったといっても過言ではない4年間だったと思います。私たちアイデンティティ・コミュニティもKim Cameron氏に加えてCraig Burton氏、そして昨年はVittorio Bertocci氏などかけがえのない方々を送り出すことになってしまいましたし、もしかすると皆様にとっても大切な人々が旅立ってしまったということもあったかもしれません。

ぜひ皆さんもこの4年間を振り返っていただき、OpenID Summitをお迎えください。皆様にお会いできるのを楽しみにしております。

OpenID Foundation Hybrid Workshop

OpenID Summit Tokyo 2024

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

今日はOpenID Foundation Hybrid Workshopに参加しています。

こちらのポストで紹介したものですね。

崎村さんのご挨拶から始まり、まずは各ワーキンググループからのUpdateが始まりました。全体アジェンダはこんな感じです。

AuthZEN Working Group

まずはAuthZEN WGです。

ということでこのワーキンググループでは組織の内外、コンポーネント間、システム間を繋ぐ認可プロトコルとフォーマットについて、既存の標準や考え方との相互運用性を考慮しながら考えていく感じになるそうです。例えばポリシーベース言語やグラフベースなど、また標準的な認可のパターン（PAP、PDP、PEP、PIP）やNISTのABACのアーキテクチャなども考慮するということですね。

仕様としては、

• 標準的な認可パターン、ユースケース、コミュニケーションパターン、インテグレーションパターンなどを定義する
• 認可リクエストと認可決定を行うためのAPIを定義する
• 認可ポリシーと認可に利用するデータの間でコミュニケーションを行うAPIを定義する

Shared Signals Working Group

認証ばっかり守るんじゃなくて継続的にリスクを検知して緩和してかないとダメでしょ、というのがこの仕様のモチベーションの一つです。

IETFと密にやりとりしていて、OpenID FoundationとしてCAEP、RISC、Shared Signal Frameworkを、IETFではSET（Security Event Token/RFC8417）やベースとなるJWTなどのトークンの仕様を決めている、という役割分担です。

OpenID Foundation 2024 Strategic Initiatives

FAPIやeKYC、OID4VCなどの仕様のUpdateやFinalizeはもちろん、認定プログラムで認定されたサービスやプロダクトがずいぶん増えました。そしてEU ARFやカリフォルニア州のDMVでのOID4VCの採用、GainやSIDI Hubなどのコミュニティーでの活動、NIST SP800-63-4へのコメントなど、とても忙しい一年になったということです。

FAPIなどはすでにインターネットスケールでの展開を行う段階に位置づけられています。

OpenID Connect Working Group

メインのワーキンググループということもありスペックがてんこ盛りです。

（自分の番が終わると力尽きてきた・・・）

eKYC & Identity Assurance Working Group

次はMark HaineによるeKYC & Identity Assurance Working GroupのUpdateです。

分割した理由の一つとしてはClaim SchemaはIDAだけではなくVerifiable Credentialsなどでも使えるよね、というあたりもありました。

MORDNA Working Group

モバイルオペレーターが提供するIdentity Serviceのプロファイルを考えるワーキンググループですね。

Digital Credentials Protocol Working Group

元々はDecentralized Identityの3パーティモデル（Issuer/Holder/Verifier）に関連するプロトコルを策定するために設立されたワーキンググループです。

FAPI Working Group

ざっくりいうと高いセキュリティレベルのプロファイルをOpenID Connect/OAuthの上に作りましょう、というのがFAPIですね。

最初はFAPI1.0から始めてどんどん進化させて行った感じですね。

Certification Program

次はJosephによる認定プログラムの話です。

SIDI Hub

最後はSIDI (Sustainable Interoperable Digital Identity）HubについてGailから紹介です。

日本政府を含む各国政府やOpenID Foundationを含む標準化団体が多数参加していますね。

もうこのスライドに尽きると思います。

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

とうとうやってきました。OpenID Summit Tokyo 2024が開催されましたのでクィックレビューです。

OpenID Summitは約4年に一度、東京で開催されてきたイベントで2011年、2015年、2020年、そして今年2024年は4回目となります。

前回の開催はコロナ禍の直前ということで、本当にこの4年間は色々と世の中が変わってしまいましたが無事に開催に漕ぎ着けられて本当に良かったと思います。

OIDF Strategic Outlook for 2024 and Briefing on the Sustainable Interoperable Digital Identity (SIDI) Summit in Paris

まずはGailのキーノートからです。

OpenIDテクノロジーの利用拡大、ワーキンググループを含む活動、ホワイトペーパーの発行、政府その他とのパートナーシップ、、本当に多くの活動が行われていることがわかります。

また、昨日のWorkshopでも話がありましたが、OpenID Ecosystemを構成する上で、Open DataをAPIなどで接続していく必要がありますが、そのためには通貨におけるクレジットカードのように結節点となる仕組みが必要であると考えられます。

また、セキュリティを考えるとShared Signalsでリスク情報を共有する仕組みなども重要になります。

そして、SIDI Hubの話です。SIDI Hubの目標について「To define what we need to achieve global interoperability for digital identity.」と解説しています。この辺りは当然のことながら先ほどのOpen Dataの接続という文脈とも繋がります。

OpenIDファウンデーション・ジャパン ワーキンググループ活動報告

Panel: Celebrating Ten Years of OpenID Connect

ここから午後のセッションです。

テーマは「Cutting Edge OAuth/OIDC」ということで最新の仕様の一つであるOpenID for Verifiable Credentialsの関係、特にWalletのユースケースについてEUの事例を中心に話がありました。

EU Digital Identity Wallets (eIDAS 2) - status and way forward

まずはTorsten Lodderstedt博士によるEU Digital Walletの話です。

Coreコンセプトとして以下の要素が紹介されました。

• Personal Identity Data（PID）
• Electronic Attestation of Attributes（EAAs）
• Qualified Electronic Attestation of Attributes（QEAA）
• 特にEAAの中でもQTSP（Qualified Trust Service Provider）によって発行されたものを指します。

前述のEU Walletの役割を考えると、全てのWalletは認定されている必要があり、そのための認定の仕組みが重要となります。

そして、eIDAS2で定められているリファレンスアーキテクチャ（ARF/Architecture Reference Framework）の中ではOpenID関連の標準技術を使うことが定められ絵います。

プロトコル

• OpenID for Verifiable Credentials
• ISO 18013-5

クレデンシャルフォーマット

• SD-JWT
• ISO mdoc

※PIDsは両方のフォーマットで発行される必要があります。

また現在ディスカッション中のテーマとしてこれらの事項があるそうです。

• ペイロードとしてW3C JWT VCsを使うかSD-JWT VCsを使うか
• WalletのトラストとWalletのライフサイクル管理
• RPやIssuerのトラスト
• PIDと(Q)EAAsの間のIDマッチングやリンク
• オンラインの仮名での認証

特にVCのペイロードの話でSD-JWT-VCの話は熱い話題でした。ざっくりいうとSD-JWT-VCがシンプルでいいよね、って話でした。

Waiting for the EUDI Wallet: Securing the transition from SAML 2.0 to OpenID Connect

次はAmirさんの話です。Kim Camronアワードを受賞している人ですね。

イタリアでは以下の２つのIDシステムを使っているそうです。

• SPID：Public Digital IdentitySystem（デジタルID）
• CIE id：based on the Electronic Identity Card（物理カード）

そして最近Digital Identity System（SPID）をSAML2.0からOpenID Connectへ移行を始めたそうです。

イタリアのプロファイルの特徴はOpenID Federation 1.0とOpenID Connect iGov Profileを使っているところかもしれません。

特にOpenID Federationを利用している理由として、Dynamic、Scalabe、Transparentを挙げていました。

また、OpenID ConnectのフローとしてはAuthorization Code Flow with PKCEを採用しているそうです。※SAMLからの移行ならImplicitの方が楽だったんじゃ？と思いましたが他国のことなので黙っておきます。

また、EU DIWによるパラダイムの変化について語られましたが、やはりIdP/OPへのリダイレクトモデルからの脱却がポイントになっているようですね。

すでにモバイル運転免許証をはじめとする大規模パイロット運用が始まっているんですね。

Insights into Open Wallet Foundation's initiatives

次はJosephによるOpen Wallet Foundationの活動に関するセッションです。

Linuxファウンデーションの参加ということもあり、OSSの優位性である早くて安いというところを全面に押し出しています。

プロジェクトは多くのスポンサーによって支えられています。

残念あがら日本とのアクティブなやり取りはなさそうですが、この機会に何か協業ができるといいですね。

Open Wallet Foundationの中でも色々なプロジェクトが動いています。様々な言語でWalletの開発ができるのはとても良いことだと思います。

＊＊＊＊＊

次のブロックは「Auth/OIDCによるID/APIエコシステムの推進」というテーマです。

Trusted Webの実現に向けて

まずは内閣官房デジタル市場競争本部事務局次長の成田さんからTrusted Webの取り組みに関する講演です。

いうまでもなくTrusted Webはデジタル空間におけるトラストを構築する取り組みです。

”一握りの巨大企業への過度な依存”でも”監視社会”でもなく、DFFT（Data Free Flow with Trust）を実現するための”第三の道”を模索する取り組みで、ホワイトペーパー（現在第3版）の発行やこれまでに25の事業者による実証実験などにも取り組んできています。

一握りの巨大企業に過度に依存している状態である一番左側の状態と真ん中のすべてを検証する状態（ブロックチェーンの利活用など）のバランスをうまく取りながら検証と信頼のバランスをとる世界観を目指しています。

2022年度に選定されたユースケースは個人属性情報（学習・就業・共助実績）、法人と行政庁との情報のやり取り、サプライチェーンにおける情報のやりとり、の3つにカテゴライズされます。全てのケースにおいてやり取りややり取りされるデータ、そしてやりとりする相手方を検証することで信頼性が高まり、確認コストの削減や不正の削減などに役立てることができるという話です。

アーキテクチャとしてはオーバーレイアプローチを取ります。

アーキテクチャを構成するコンポーネントとしては、

• Verifiable Data：検証可能なデータ
• Verifiable Message：検証可能なメッセージ交換）
• Verifiable Identity：検証可能なアイデンティティ（コミュニティによって裏打ちされる）

が存在します。

そして、アーキテクチャと合わせて

• Trusted Webという考え方自体に関するガバナンス
• Trusted Webの考え方に準拠したトラストフレームワーク提供者に関するガバナンス
• トラストフレームワークに従って構成・運営されるシステムに関するガバナンス

の階層構造のガバナンスも重要となります。

そして、実際に事業者がシステムとして実装する際に参照可能な実装ガイドラインもgithub上で公開されています。エンジニアの方々はぜひ見ていただき積極的に議論に参加してください。

またこのような取り組みはグローバルな取り組みとして推進していく必要があるのでG7群馬高崎デジタル・技術大臣会合においてTrusted Webの取り組みの発表、EUやカナダとの国際連携なども進めようとしています。

今後の活動として

• ユースケースの創出
• 企業・エンジニアによる取り組みのさらなる促進
• 社会実装の加速化
• 国際連携
• 全体として感が主導している他の取り組み（ウラヌス・エコシステムなど）との連携

が予定されています。

OpenID Federation 1.0: The Trust Chain vs The x.509 Certificate Chain

次はVladimirによるOpenID Federationの話ですね。

ざっくりいうとFederationの仕組みの中でTrust Chainを辿っていく仕組みです。

X.509におけるCertificate Chainを構成するものとして、

• issuer, subject
• not-before, not-after
• contrains
• public keys

が挙げられます。

一方でJWTでのTrust Chainを構成するものとして

• iss, sub
• iat, exp
• JWK Set
• trust mark
• contrains
• entity metadata
• metadata policies

が挙げられます。

こちらが比較です。

要するにX.509では公開鍵のアテストしかできない、ポリシーやメタデータで情報を伝えたりすることができないよね、という話です。

2035年にはCertificate ChainからTrust Chainに諸々置き換わってこんな状態が実現するのかもしれません（笑）

Passkeys and Identity Federation

次はエバンジェリストのritouからパスキーとフェデレーションの話です。

パスキーとID連携はどういう関係なのか？というのはよくある質問です。

その辺りをときほぐしていきましょう。

パスキーの課題として「アカウントリカバリ」「クロス・プラットフォーム同期」などが挙げられます。

一方でID連携は、

• 認証方式の一つ
• メールアドレスの確認
• 本人確認済み状態のやりとり

などの用途で使われています。

例えば単純に認証方式として比較するとパスキーの優位点はConditional Mediationとの組み合わせによるUX改善やプライバシーリスクの削減、再認証に使いやすいなどが挙げられます。

そういう意味でID連携の弱点をUXなどの面でパスキーが補強する使い方もありますし、パスキーに対応していない環境をサポートするためのID連携を使う、という補完関係にあると言えます。

OpenID Connectのacr/amrと組み合わせて認証コンテキストや方式を要求する場合にパスキーと組み合わせるということができます。

同様に再認証のユースケースではauth_timeやmax_age、login_hint、id_token_hintを使って確実に再認証させることもできるようになります。

RFC 9470のOAuth2.0 Step Up Authntication Challenge Protocolを使うと例えば決済APIへのアクセスをする際、JWTベースのアクセストークンの中身を保護対象リソース側で見てacr_valuesを指定して追加認証を求めることで安全性を高めるなどもできるようになります。

＊＊＊＊＊

次のトラックは「ビジネスへのOAuth/OIDC活用事例」というトラックです。

ビジネスという意味では2つの側面があると思います。一つはOAuth/OIDCを使ったシステムを使ってどのようにビジネスを推進しているのか、いわゆる事例の話、そして二つ目はビジネスを進める上で必要となるアイデンティティ・エキスパートの育成・チームの組成というテーマです。

まずはブラジルのNuBankの事例からです。

The progress of Nubank and Open Finance in Brazil

NuBankのOpen FinanceのGeneral ManagerのLucianaさんから事例の紹介です。

90M以上の顧客を持つということなので巨大な銀行ですね。

クレジットカード、投資、ローン、などを含め総合的にサービス展開をされているようです。

インハウスでシステム開発を進めることで諸々の意思決定を含むコントロールができる状態を作り出しているんですね、素晴らしいです。

Open FinanceがRegulatoryドリブンなのかマーケットドリブンなのか、ハイブリッドなのかという話は国によって異なりますがブラジルはRegulatoryドリブン、日本と一緒なんですね。日本でももっとOpen FinanceやAPiエコシステムが浸透するといいですね。

ブラジルでは800もの事業者がOpen Financeエコシステムに参加しているとのこと、そうなるとOAuth2.0、OpenID Connect、FAPIが必要になります。そしてブラジルの標準を各仕様のリファインや範囲を限定することで最適化をしているそうです。

Open FinanceはNuBankのミッションである「金融サービスを再発明することにより人々の暮らしをエンパワーするために複雑性と戦う」というテーマにマッチしているということです。

そのために3つの柱を据えて取り組んでいるそうです。

• より良い金融面の意思決定をしてもらえるように人々を支援する
• 金融移管する生活体験を集中化、シンプル化する
• 従来のOpen Financeが提供するものを超えていく

非常に刺激的な事例でした。

事業の成長にどのようにID技術/IDチームが貢献してきたか - SoftBank の取り組み

次は小松さんからSoftBankでどのようにID技術やIDチームの存在が事業成長に繋がったのか、という話です。

まずはSoftBankにおけるID技術がどのように導入されてきたのか、という歴史の話です。

フィーチャーフォンからスマートフォンへのプラットフォームの移行、コンテンツビジネスから決済ビジネスへの拡大などこれまでの歴史について語られます。

その中でスマートフォン向けのサービスが増えていくとAPIアクセス保護の必要性が出てくることでOAuthやOpenID Connectの技術が必要になってきた、ということですね。

しかしながら、スマートフォンに切り替わるにつれて従来のガラケーの回線認証ではなくID/パスワードによる認証が必要となってきてしまい、問い合わせが殺到、スマートフォンでも使える回線認証を導入してきたということです。

一方でリスト型攻撃などの攻撃も激化、キャリア決済の不正利用なども増えてきたことから認証ポリシーの定義と複数要素での認証機能の追加を行ってきました。

その後、グループ企業とのシナジー創出が事業課題となってきた時代も出てきます。

その際もID連携技術が活躍したんですね。

全体を振り返ると「業界標準のOpenIDをありがたく適用させていただくだけで大体の課題を解決できた」とのコメントがありました。素晴らしい。

次のテーマとしてのチーム組成の話はみなさんにとっても大きな課題なんではないでしょうか？

要するに開発者からマネージャへ、という話ですがチームの設計は非常に難しいので小松さんの話はとても参考になります。

事業への貢献、新規ビジネスの創出、そして教育や業界への貢献などバランスをとりながらチーム設計をされています。

組織成長のための鍵としていろいろな観点で語られたのですがその中でも「ID技術のエンジニアである前に事業を支えるエンジニアになってほしい」という言葉は非常に重要だと思います。また、モチベーションとして「IDが好きかどうか」というのは重要な要素であることについても語られました。この辺りはOpenIDファウンデーションジャパンなどの場もうまく活用していっていただきたいと思います。

パネルディスカッション: 組織内に「IDチーム」を確立・拡大するには?

次は柴田さん、工藤さん、菊池さん、渡邊さんによるパネルディスカッションです。小松さんの話に続きチーム組成の話です。

工藤さんの経歴。サンマイクロシステムズ時代はiPlanetとかSun Identity Managerとかをやっていらっしゃいました。とてもお世話になりました。しかしちょうど10年ごとに転職してるんですねw

自身のキャリアとデジタルID分野との関係

• 菊池さん：自分で選んだ。新規事業をやることになりブロックチェーンを使ってデジタル身分証を作る、というプロジェクトがありやりはじめた。地味だけど無くなることはなさそう、というのが選んだ理由。結果的にブロックチェーンは使わなかったが。
• 渡邊さん：どちらかというと流れに任せてIDの世界へ。ECサイトの再構築などをやっているうちにIDのキャリアがある人に結果的になってしまった（笑）
• 柴田さん：同じくどちらかというと流れに身を任せた。前職で事業開発をすることになり、その場に崎村さんがいたのでアイデンティティを使って事業開発をすることになりはや15年、という感じ。

デジタルIDが自身のキャリアにどのように役立っているのか

• 渡邊さん：ECサイトの統合などの求人に対して自身の経験が目に留まることがあり転職につながった
• 柴田さん：コンサルの経験の中で技術の変遷とビジネスの変遷を幅広く知識を得ることができた。このような経験をしている人はID屋さん以外には少なく、希少性があがり転職につながった
• 菊池さん：転職の直接のきっかけ自体がOpenIDファウンデーションジャパンのイベントだった。デジタル庁自体が省庁の中ではスタートアップ的な雰囲気があるので、専門性に加えてスタートアップとしての経験が役に立った。

IDをやることの嬉しさ・辛さ

• 渡邊さん：サービスがたくさんある中でそれぞれに関われることがIDならではだと思う。辛さは絶対に止められない、という辛さ。前職でECサイトのログインサイトを止めて社長にブチギレられた経験も・・。ただ経験として止めてはいけないシステムを運営したのはキャリアとしては非常に貴重
• 柴田さん：ソリューションを提供する側だったので止めるとお客様にご迷惑をおかけする経験は辛いものがある。奥深いところが面白い。分野では法律などへ踏み込むことになるし、技術面でもインフラからアプリケーションのレイヤまで踏み込むことになるでいろいろな経験ができる

IDチームの構成は

• 渡邊さん：プロパーが10名くらい、あとは協力会社。みんながID経験があるわけではなく未経験の中から学んでいく。OpenIDなどの標準が整ってくることで学習効率があがり、育成していく中で何名かはID好きになってくる
• 柴田さん：クライアントの事例だが、個別の担当者ベースでやっているイメージがある。ポリシー変更などがあった場合は根性で対応されていることも多く、効率化するためにアドバイスをすることはある
• 菊池さん：デジタル庁はマトリクス型組織。アイデンティティユニットはPKIとアイデンティティをやっている。その中で法人、個人（マイナンバーカード）、などで担当が別れている。専門家がデジタル庁に集中しすぎ問題と言われるが普通にスカウトメールなど経由も多い。ただ最終面接する段階では誰かの知り合いだった、ということも多い

採用戦略

• 渡邊さん：採用時点ではID経験はとわないようにしている。ID業界は専門用語が多く裾野が広がりにくいと考えているので、なるべく専門用語を使わずに裾野が広いように見せていくことが大切だと思う。トークン、とか
• 柴田さん：同じく採用時点でIDを知っていることはないので育成をしていくことになる。数年単位で人材育成をしていくことになる。教育プログラムを作ったりしていた

IDの難しさとは

• 柴田さん：仕様はオープンだが、その仕様がなぜそうなっているのかが書いていない。なぜそうなっているのかをわからないとインテグレーションができないこともあり、口伝などで情報伝達をしないとうまくいかない
• 渡邊さん：OIDCがわかる本、を読んでもらうだけでは理解できないので自分で読んで解説するところまで必要。開発チームにも自分たちはOIDCに準拠しているのでちゃんと対応してほしい、と明確に伝える、伝え続けることが必要。標準を使うことで新しい人を呼び込むことにもつながる。独自で作るものを学ばされるよりも標準の方がメリットがある。ChatGPTに聴けるのも標準ならでは。
• 菊池さん：デジタル庁の中では国際標準を使うのがデフォルト。社会課題を標準仕様で解く、ということが必要だが存在する実装では実現できないこともあるので、他のチームと連携しながら解いていく必要がある

どうやってIDチームは交流していくのか

• 柴田さん：OpenIDファウンデーションに入ってもらう、イベントに参加してもらう。OpenIDファウンデーションジャパンにも人材育成WGがあるので是非参加してください！
• 渡邊さん：自社のIDチームに人を引き込むためにID業界としてこういうことがあると嬉しい、という観点だと「とっつきやすさ」だと思う
• 菊池さん：技術の専門家とユースケースを知っている人が別々、ということが多い。その交流ができる場があると補完関係になって良い
• 柴田さん：人材育成WGはビジネスサブWGと技術サブWGがあるので是非！

最後に

• 渡邊さん：IDチーム募集しています！とっつきやすいチームを目指しています！
• 菊池さん；IDユニット、引き続き人を募集しています。官民連携を進めたいと思います
• 柴田さん：絶賛採用中！
• 工藤さん：弊社も！（w

ということで最後は採用アピール大会になりましたがとても参考になりました。

＊＊＊＊＊

いよいよ最後のブロックです。

テーマは「日本のID界を盛り上げていきましょう」です。

Your Identity Is Not Self-Sovereign

まずはJustinからです。昨年のEICで彼の話を聞いて、とても面白かったので呼んでもらいました。

「Self」とはなに？というところから始まるわけですが、このセッションは動画で見ないとおお白くないので動画公開をお待ちいただこうと思います（笑）

ヒントは牛丼ですねw

「Soverign」とは？

「Trust」とは？

そういえばNortonさんは米国の皇帝だって名乗っていたことありますねw

まさにSelf Sovereign。

Source of truthはどこに視点を置くかによって変わる、という視点も非常に重要ですね。

※これはUSの標準をありがたく参考にしている日本人は本当に考えないとダメだとおもいますよ・・・

そして最後は「Identity」

これはEntity - Identityモデルの話で自観と他観の話なわけですが、どうやって自分のアイデンティティを表明するのか、という話。

そう考えるとアイデンティティは受け取った側がどう受け取るのかによるわけですよね。これが他観の話。

つまり、自分がどういうアイデンティティを表明したかったとしても相手に受け取られた段階で自分では何のコントロールもできない、ということ。

これが自己主権型アイデンティティだと思っている人はしっかり考え直しましょう。

Closing Keynote

最後は崎村さんによるクロージングです。

テーマは「分散の誤謬」です。

最初にKim Cameron Awardのアナウンスがありました。OpenID Foundationがスポンサーとなっています。

本題です。

Web1.0、Web2.0の流れがあり、OAuthやOpenID ConnectはまさにWeb2.0の申し子なわけです。

OpenIDの基本コンセプトに立ち返ると自分のブログのアドレスを使ってサイトにログインしていく、というようなまさに自己主権型の仕組みでした。

しかしながらOpenID URLを使うと全てのサイトに対して同じ識別子を提供することになってしまうのでPairwise IDが作れないので、認証提供サイトであるOpenID Providerというエンティティが登場するわけです。これがOpenID Authentication 2.0。

しかし必然的に自分のアドレスではなくOPのアドレスを使うことになり、自己主権を犠牲にしているわけです。これは現在EUで起きているEUDIWの議論とも共通します。

XRIとかSXIPなどからOpenID Authentication 2.0への流れを見ていくとこの段階でGAFAは決してプレイヤーだったわけではありません。これを見ていくとWeb2.0が巨大新興企業が率いているという話は間違っていることがわかるわけです。むしろ当時のGAFAは巨人IBMを倒すことで民衆に熱狂を持って受け入れられた革命児だったはずです。

しかし、その流れで生まれてきたWeb2.0は極限まで分散されているにもかかわらず、なぜ巨大企業に支配されているのか？

Googleに売上の推移をみるとわかるとおり、IT産業は収穫低減のモデルなので富の集約は必然っていうことですね。

ではweb3はどうなのか？

「分散」という言葉を語るときに対象を明確化する必要があります。

そして集中と分散はバイナリではなくグラデーションがあるわけです。

そこに分散台帳を当てはめてみると、実は分散台帳は主体が一つの台帳を使うので完全集中だということがわかります。つまり完全集中しているシステムに「分散台帳」という名前をつけるマーケティングセンスは天才的だといえます。

分散型IDやWalletの世界に当てはめるとどうなるか。

Wallet＝IdPという世界観なのでIdPが個人のWalletに分散するという側面で物事が語られるのではないか？ただし個人のデータがWalletに集中することをみると分散ではないと思われます。

 Web2.0の文脈では世界中にIdPが分散していることもありある意味分散型。しかしWalletモデルで見るとIdP提供者よりもWallet提供者の数はずっと少ない状態であり、IdPモデルと比較すると集中していると言えるわけです。

つまり、web3の世界におけるWalletモデルもいずれWalletプロバイダへの集中やプラットフォームベンダへの集約が起きるのは必然となるわけです。

こうなると政策介入しかなくなるわけですが、一部の国がやっているように独立したアプリストアを許可するようにしたとしても本当に使われるのか。そしてさまざまなWalletを許可した場合、本当にそのWalletは信頼できるのか？実際にWalletからの情報流出の事故は発生しているわけです。

こういう形でみんなが分散しようとしても結果として集中が発生してしまう「分散の誤謬」というものが発生しているわけですね。

ということでご参加いただいた皆さん、お疲れ様でした。

動画は追って公開する調整が行われると思いますので残念ながら参加できなかった方も、もう一度見たい方も楽しみにしておいてください。