diff --git a/whitepaper.md b/whitepaper.md
new file mode 100644
index 0000000..6f17407
--- /dev/null
+++ b/whitepaper.md
@@ -0,0 +1,371 @@
+# OWND Project Whitepaper （ドラフト）
+
+## 1. イントロダクション
+### 1.1 OWND Project の概要
+
+OWND Projectは個人が主体となるデジタルアイデンティティーの社会実装を目指し、よりトラストできるコミュニケーションを実現するためのプロジェクトです。
+
+ユーザ自身が自らのアイデンティティを管理し、属性情報を他者と相互検証できるようにした上で、特定のサービスに依存しないよう、相互運用性を確保したデータのやりとりや安全なメッセージングを行うことができるようにすることで、コミュニケーションのトラストを向上させることを目指します。
+
+> トラストとは
+> 事実の確認をしない状態で、相手先が期待したとおりに振る舞うと信じる度合い（Trusted Web において定義されている「Trust」を踏襲）
+
+#### 1.1.1 このプロジェクトでやること
+
+* 実現に資するオープンソースソフトウェアの開発
+* トラストを担保するためのガバナンスモデル/ルールの検討
+* ユースケース/ビジネスモデルの検討
+
+#### 1.1.2 このプロジェクトでやらないこと
+
+* プロジェクトとしての営利目的の活動は行わない
+* このプロジェクトの成果物を利用した営利目的の活動は妨げない
+
+### 1.2 この Whitepaper の役割
+
+この Whitepaper は OWND Project のビジョン等を表明し、その役割と方向性を定義づける、プロジェクトのガバナンスの基礎となるものです。
+
+OWND Project は、この Whitepaper に基づいて運営され、OWND Project 参加者は、別途定める [Code of Conduct](https://github.com/OWND-Project/contributing/blob/main/code-of-conduct.md) に従って、会議への参加や開発等によりコントリビュートすることができます。
+
+ガバナンスの詳細は 6. ガバナンス構造 において説明しています。
+
+```mermaid
+
+flowchart TD
+    Doc1{{OWND Project Whitepaper}}
+    Doc2{{Code of Conduct}}
+
+    TW[Trusted Web]
+    OP[OWND Project]
+    Wallet([OWND Wallet])
+    Messenger([OWND Messenger])
+
+    Doc1 -.Refer.-> TW
+    Doc1 --> OP
+    OP --- Doc2
+    Doc2 --Develop--> Wallet
+    Doc2 --Develop--> Messenger
+ 
+```
+
+### 1.3 Trusted Webとの関係
+
+OWND Project は、内閣官房デジタル市場競争本部の推進する["Trusted Web"](https://trustedweb.go.jp/)のユースケース実証事業の一部として誕生しました。
+
+ユースケース名：[ウォレットによるアイデンティティ管理とオンラインコミュニケーション](https://trustedweb.go.jp/news/yqrxm6-b28v)
+
+OWND Project は Trusted Web の概念を継承しますが、独立したプロジェクトであり、Trusted Webに依存しない持続可能なプロジェクトを目指します。
+
+## 2. ビジョン、ミッション、コアバリュー
+
+### 2.1 未来に対するビジョン
+
+個人が主体となるデジタルアイデンティティーの社会実装を目指し、よりトラストできるコミュニケーションを実現する
+
+### 2.2 プロジェクトのミッション
+
+ユーザ自身が自らのアイデンティティを管理し、やるとりされるデータを相互に検証できるようにした上で、特定のサービスに依存しないよう、相互運用性を確保したデータのやりとりや安全なメッセージングを行うことができるようにする
+
+### 2.3 コアバリュー
+
+オープンに議論を行い、成果物を公開することで透明性を確保し、誰でも自由に参加でき、誰も排除せず、弱い立場にある人を取り残さないようにする
+
+## 3. 現状認識と考慮事項
+
+### 3.1 現状のデジタルアイデンティティ、コミュニケーション
+
+#### 3.1.1 プラットフォームへの依存
+
+現状、デジタルアイデンティティの管理は大手プラットフォームに依存、集中しています。例えば、オンラインで提供されるさまざまなサービスを利用する際には、プラットフォームの提供するアカウントを利用して、サインアップを行うことが一般に行われています。
+
+Facebookログイン等のソーシャルログイン機能だけでなく、Gmail等のメールアドレス、Apple ID等のモバイルデバイスを利用するためのアカウントを通じ、大手プラットフォームがデジタルアイデンティティを管理しているため、例えばこれらのプラットフォームからアカウントの停止やBANをされることは、それらのプラットフォームサービスが運営しているサービスが利用できなくなるだけでは無くデジタルアイデンティティが剥奪されることと同義です。
+例えば、GmailからアカウントBANをされてしまうと、Googleの提供するサービスを利用できなくなるだけでなく、Gmailのメールアドレスを利用したその他のサービスのアカウントへのアクセスも制限されることとになり、モバイルデバイスも利用が制限される状況になります。
+
+さらに、年齢や性別、興味関心といった属性情報が要求された際には、ユーザーにはその正確性を保証したり、権利を確実に行使する手段が無く、プラットフォームのポリシーやアルゴリズムによる判断に委ねられ、プラットフォームの提供するビジネス機能（ターゲティング広告等）を通じてそれらの情報を他企業が利用する場合においても、ユーザー側には十分な透明性やコントローラビリティが確保できているとは言えません。また、利用する企業側においても、これらの属性情報の正確性を検証したり、ユーザーから適切に許諾等を得ているかを検証することはできず、プラットフォームに依存するしかない状況になっています。
+
+#### 3.1.2 プライバシー
+
+また、プラットフォームに対して多くの市民および企業が依存することで、プラットフォームには膨大な量の多種多様なデータが蓄積され、また蓄積されたデータを用いて、各個人の詳細なプロファイルを作成することができ、またAIの学習データとして利用されています。
+
+大手プラットフォームは、これらの優位性を利用した個人に対する精細なマイクロターゲティングを可能にし、また第三者がこれらのデータをビジネスに活用できるようなエコシステムを構築することで莫大な収益を生んでいます。
+
+個人が自分に関するどのようなデータが収集・蓄積され、どのようにプロファイリングされているかの実態を把握することは難しく、また、それらのデータが誰に、どのように利用され、利用された結果、自らにどのような影響が及ぶのかを想像することすら難しい状況です。
+
+特に、プラットフォームが提供する識別子（メールアドレスやSNSのID、電話番号など）を用いた認証に依存していることにより、容易に企業を跨いだ名寄せができてしまうことで、ターゲティング広告に用いられるだけでは無く、多くの企業が独自にプロファイリングを行い、ユーザーの意図しない利用方法で用いられることにより、ユーザーの権利利益に大きな影響を及ぼしています。
+
+また、SNSサービスやメッセージングサービスにおいては、利用者の電話帳をアップロードさせる機能により、本人の意思に関わらず、自身の電話番号が第三者によってアップロードされ、登録時に、自動的に友達登録が行われる機能等に利用されており、このネットワーク効果を利用するプラクティスはTelegramやSignalのようなプライバシーを重視すると謳っているサービスでさえも用いています。
+
+#### 3.1.3 コミュニケーションにおける検証可能性
+
+さらに、メールやメッセージングサービス、SNSにおいて、その相手方や相手方の属性情報、メッセージ自体を検証することができないため、スパムメールや詐欺SMS、詐欺広告、有名人の偽アカウント、偽広告などが横行しています。
+例えば、OWND Project のメンバーが、`ota[at]datasign.com` というメールアドレスからメールを受け取ったとすると、OWND Project で事務局をしている株式会社DataSignの代表取締役をしている太田祐一さんからのメールであると勘違いすることは容易に想像ができます。
+実際には `datasign.com` は株式会社DataSignが管理しているドメインでは無いですが、それを確認することは難しく、また逆に `datasign.jp`が本当に株式会社DataSignの管理ドメインなのか、ということを確認することも簡単ではありません。
+
+これは、FacebookやX、LINE等のSNS、メッセージングサービスにおいても同様であり、Facebookで特定の有名人のアカウントであることを表明していたとしても、それが本当にその有名人のアカウントであることは、簡単に検証することができません。
+
+このように、コミュニケーションの相手方や相手方の属性情報が検証できないことにより、SNSにおいては、有名人アカウントを装った詐欺広告が横行し、実際に投資詐欺にあう事例も増えており、取引先のメールアドレスを装った標的型攻撃は甚大な経済的な被害を与えています。
+
+### 3.2 新しいアプローチに対する考慮事項
+
+上記の課題を解決することを期待されているデジタルアイデンティティウォレットを用いたアイデンティティの管理は、一部地域での社会実装が進んでいますが、米国の一部の州におけるモバイルドライバーズライセンス（mDL）の運用状況を観察してみると、課題の一部は解決しているものの、特定のウォレット提供事業者に依存してしまうことで相互運用性が担保されていないケースや、運転免許証発行者に都度問い合わせを行うアーキテクチャを採用してしまうことで、市民の行動が州政府に把握されてしまうような、プライバシーに関する問題が指摘されているケースなどが散見されています。
+
+欧州においては、eIDAS2によりEU各国に義務付けられる予定の European Digital Identity Wallet の実装について、相互運用性を確保し、特定の事業者に依存しないようなトラストフレームワークが構築されつつありますが、採用されている技術的な問題によって、第三者による名寄せが可能になってしまうことについては問題定義がなされています。
+
+また、デジタルアイデンティティウォレットを用いて、アイデンティティの管理を行ったとしても、コミュニケーションの手段として、既存のサービス（大手プラットフォームの提供するメールやメッセージングサービス、SNS）を利用することは、結局プラットフォームの提供するアイデンティティに依存してしまうことになります。
+
+したがって、OWND Project では、標準化されたプロトコルに基づく検証可能なデータのやり取りを実現し、特定の事業者に依存しないアーキテクチャを採用することで、相互運用性を確保し、プライバシーに対する課題についても高度に解決し、個人が主体となるデジタルアイデンティティを用いた、よりトラストできるコミュニケーションのエコシステムの構築を目指す必要があります。
+
+## 4. 課題の解決に向けて
+
+### 4.1 主な課題の特定
+
+#### 4.1.1 不透明なデータの収集と利用
+
+企業は生活者と効率的にコミュニケーションを行うために、生活者のさまざまなデータを収集することはマーケティング活動の一環として、広く普及しており、特に行動の履歴やその識別子として利用されるメールアドレスや電話番号はメールマーケティングやSNSマーケティング等における顧客獲得にも利用されています。
+一方でそれらのデータ収集や利用について、生活者はその実態を把握しているとは言えず、メールアドレスやSNSのID等の事業社を跨いで名寄せができる識別子を簡便に取得できるソーシャルログインや、ソーシャルプラグインなどを利用している事業者から、意図せず自身に関する情報がプラットフォームに集約されることは、生活者の意図しない結果をもたらすことがあることは、ケンブリッジアナリティカ事件やリクナビ内定辞退率問題においても指摘されてきました。
+
+また、収集されたデータが漏洩したり、身に覚えのない第三者への提供が行われることにより、メールやSMSを用いたフィッシングサイトへの誘導や、スパムメール、スパムSMSなどが横行し、生活者は辟易しています。
+
+#### 4.1.2 煩雑なデータのやりとり
+
+オンラインにおいて本人確認を行おうとする場合、運転免許証の画像をアップロードし、カメラに向けて顔を上下左右に動かし、アップロードされた画像や動画を人間が確認して本人の確認を行う、ということは広く行われており、生活者として面倒だと思ったことがある方は多いと思います。
+
+また面倒である、ということだけでなく、例えば必要な情報が「20歳以上」という情報だけだとした場合、運転免許証に記載されている氏名・生年月日・性別・住所・顔写真は必要のない情報になり、不要な情報を渡すリスクや企業側での管理コストの増大にもつながっています。
+
+また、BtoB領域においては現在もメールが企業間におけるオンラインでのコミュニケーションの主流となっていますが、メッセージの内容が通常では暗号化されていないことにより、PPAPと呼ばれるパスワード付きzipファイルを添付しパスワードを別送するという、送り手側も受け手側も面倒で煩雑な、かつ安全性も担保されていない方法が多くの企業でのデータのやりとりで運用されています。
+
+昨今、上記のメールにおける課題を一部解決する法人向けコラボレーションツールなどは普及していますが、各社が、各個別の特定の事業者に依存しており、特に法人を跨ぐメッセージングにおいては、Slack, Teams, Discord, Chatwork等複数のツールを常に確認するという煩雑さだけでなく、担当者が個人レベルで業務に利用してしまうシャドウITも問題になっています。
+
+また、コミュニケーションの相手方を検証できないことにより、現状認識の章でも述べた標的型攻撃には簡単に対処することができず、メールを開かないようにしたり、別途ウイルス対策ソフトでスキャンをするなどの対策が必要です。
+
+#### 4.1.3 NASCAR問題
+
+また、多くのオンラインサービスでは、アカウント登録の方法として、メールアドレスや電話番号での認証に加え、プラットフォームの提供するアカウントの認証情報を利用した登録の方法を導入しています。
+これは一定の利便性を提供しているように見えますが、プラットフォーム各社が同様の機能を提供することにより、オンラインサービスのアカウント登録画面には、複数のプラットフォームのロゴが並ぶ状況になっており、利用者は登録する際にどの方法でアカウントを登録するかを迷わせ、また、登録した後、ログインをする際には、どの方法でアカウントを作ったのかを覚えている必要があるという課題があります。
+
+プラットフォームからアカウントがBANされた場合に、そのサービスにログインできなくなることは、3. 現状認識と考慮事項のセクションで触れたとおりです。
+
+### 4.3 OWND Projectの提案する解決策
+
+オンラインでのコミュニケーションサービスはインフラとして必要とされる一方、これまで述べてきたように多くの課題が指摘されています。OWND Projectでは、これらの課題を解決すべく、`OWND Wallet` と `OWND Messenger` の二種類のシステムを開発します。
+これらのシステムを商用利用も可能なオープンソースコードとして公開することで、誰でもこれらの実装やソースコードを用いたサービス提供ができるようにします。
+OWND Wallet や OWND Messenger 自体が普及することを目指すのではなく、これらのソースコードが多くの人や企業に利用されることで、OWND Wallet、OWND Messengerをベースとした、特定の事業者に依存することない、相互運用可能な、さまざまデジタルアイデンティティウォレットやそのユースケース、メッセージングサービスが創出されることで、現在の社会における課題を解決し、多くの人にその効果が及ぶことを目指します。
+
+#### 4.3.1 OWND Wallet
+
+ユーザが自身のアイデンティティを管理でき、自分の意思で相手先に検証可能なデータを受け渡すことのできる汎用的なデジタルアイデンティティウォレットを国際標準仕様に準拠して開発し、オープンソースプロジェクトとして既存のコミュニティと連携しながら社会実装・普及を目指すことにより、さまざまなユースケースで利用でき、かつ相互運用可能なデータのやりとりの実現し、特定の事業者に依存しない、誰でも開発し利用できるデジタルアイデンティティウォレットの構築を目指します。
+
+* **現時点で予定している開発物**
+    * OpenID for Verifiable Credential Issuance（OID4VCI）の Holder側実装
+    * OpenID for Verifiable Presentations（OID4VP）の Holder側実装
+    * Self-Issued OpenID Provider v2（SIOPv2）の Holder側実装
+
+#### 4.3.2 OWND Messenger
+
+デジタルアイデンティティウォレットにおいて管理するアイデンティティを用いて、自身の検証可能な属性情報を受け渡し、メッセージの相手方の属性の検証も行うことのできる、End-to-End暗号化に対応したメッセージングプロトコルを開発し、オープンソースとしてコードを公開することで、誰もが相互運用可能なメッセージングサーバを構築することができるようにすることで、誰もが安心して利用できるようなメッセージング基盤の構築を目指します。
+
+* **現時点で予定している開発物**
+    * プロトコルには Matrix を採用
+    * サーバーサイドは Synapse にSIOPv2、OID4VPおよび各種証明書へ対応するためのを機能を追加実装
+    * クライアントサイドは Element Web にSIOPv2、OID4VPおよび各種証明書へ対応するためのを機能を追加実装
+
+#### 4.3.3 その他
+
+上記のほか、OWND Walletに格納する証明書とその発行を行うためのコード、OWND Messengerで証明書を受け取るために必要な以下のコードを開発します。
+
+* **現時点で予定している開発物**
+    * Selective Disclosure for JWTs（IETF SD-JWT VC）証明書
+    * mdoc (ISO 18013-5) 証明書
+    * JSON-LD ZKP with BBS+ 証明書
+    * OpenID for Verifiable Credential Issuance（OID4VCI）の Issuer側実装
+    * OpenID for Verifiable Presentations（OID4VP）の Verifier側実装
+    * Self-Issued OpenID Provider v2（SIOPv2）の Verifier側実装
+
+
+## 5. 提供する価値
+
+### 5.1 個人にとっての価値
+
+#### 5.1.1 データ収集の透明化と不正な利用の防止
+
+OWND Walletによってアイデンティティの管理を自身で行うことができるようにすることで、どの情報を誰に提供するかを自分自身で判断できるようになるため、企業による不透明なデータ収集や、プラットフォームによる意図しないデータの収集や利用を防止することが可能になります。また、識別子を提供先毎に変更することにより、名寄せのリスクも低減させることができ、相手先からメッセージを受け取る必要がある場合においても、OWND Messengerを利用することでメールアドレスや電話番号が必要ではなくなることから、それらの情報の漏えいも防ぐことができ、スパムメールや詐欺SMSの被害も低減され、安心して、自分のデータを開示することができるようになります。
+
+#### 5.1.2 データのやりとりにおける利便性
+
+やりとりされるデータを選択的な開示ができる検証可能な証明書にし、OWND Walletに格納することで、「20歳以上である」という情報のみを相手先に渡すことができるようになるため、面倒な作業を行わずに自分の属性を相手先に提示し、簡単に証明することが可能になります。また受け取った相手方も簡単に属性の検証ができるようになることで、データのやり取りがシンプルになります。
+またデータを渡す相手先を検証できるようになることから、フィッシングではないことを確認することも簡単に行うことができるようになります。
+
+また、共通のメッセージングプロトコルを利用することで、メッセージングサービス同士の相互運用性が担保され、各個人が自分の嗜好に応じたサービスを主体的に選択することが可能になります。
+
+#### 5.1.3 NASCAR問題の解消
+
+サービス提供事業者がSIOPv2に対応することで、OWND Walletだけでなく、SIOPv2に対応したデジタルアイデンティティウォレットであれば、なにを用いていたとしても、アカウント登録やログインを行うことができるようになります。認証に使うプラットフォームを選んだり、覚えておく必要もなくなり、プラットフォームからBANされてしまうことにより、オンラインサービスが使えなくなってしまうこともありません。
+
+### 5.2 企業にとっての価値
+
+#### 5.2.1 データの収集と利用目的の明確化
+
+デジタルアイデンティティウォレットから検証可能な属性情報を、利用目的を明確にしたうえで、必要最小限の項目のみ受け取ることは、企業にとってもメリットがあります。本人確認書類の画像や本人の動画を管理し、それを人の目で確認するコストを削減するだけでなく、法令順守の観点からもOECD8原則、特に「目的明確化の原則」「利用制限の原則」「収集制限の原則」に則った運用が簡単になります。また、これらの原則に対応することで生活者の信頼を獲得することにもつながります。
+
+#### 5.2.2 データのやりとりの利便性
+本人確認書類の送付等の面倒な作業を利用者に課すことがなくなるため、利用希望者に対してシームレスにサービスが提供できるようになります。また、属性情報の検証コストが低くなることで、これまで厳密に検証できなかった年齢や性別などの確認についても簡便に行えるようになり、サービスの品質を維持しやすくなります。
+
+また、特にBtoB領域においては、OWND Messengerでは、End-to-End暗号化を有効にすることが可能なため、メッセージや添付ファイルの送付を面倒な作業を行うことなく安全に送信することができます。
+さらに、共通のメッセージングプロトコルを利用することで、メッセージングサービス同士の相互運用性が担保され、各企業が導入をしているサービス間のメッセージングも可能になり、複数のサービスを常に確認するといった煩雑な作業や、シャドウITを防ぐことにもつながります。
+
+#### 5.2.3 NASCAR問題の解消
+メールアドレス・電話番号による認証、各社のプラットフォーム認証など、複数の認証方法に対応する必要がなくなり、UX/UIの観点においても、登録時の選択肢を減らし、ログイン時に迷うことも無くなることは企業にとって大きなメリットです。またプラットフォーム各社の仕様の変更に合わせた開発もなくなり、また企業側がプラットフォームからBANをされてしまうことにより、特定のプラットフォームの認証を用いている利用者を失うこともありません。
+
+### 5.3 競争上の優位性
+
+デジタルアイデンティティウォレットを用いたVCデータモデルのデータのやりとりの利点はこれまで述べてきた通りですが、しばしば従来のサーバ集中型の認証・認可システムでも実現可能であるとの指摘があります。本セクションではそれらのシステムに対するVCデータモデル（OWND Projectの開発技術を利用）の優位性を「18歳以上確認」のケースをもとに説明します。
+
+従来のサーバ集中型の認証・認可システムを用いて18歳以上の確認を行うためには、まず18歳以上の証明を行うサーバを構築し、第三者に向けたAPIを開放する必要があります。そして、18歳以上を確認したい事業者はそのAPIと接続するシステムを構築し、利用者に対する18歳以上の確認を行うたびに、サーバ側へのアクセスを行う必要があります。また、その都度、サーバ側では、国民全員分のデータベースを検索し、結果を返却必要があります。
+
+1. 18歳以上の証明を行うサーバを構築
+    従来型では、18歳以上の確認を行うたびにデータベースへのアクセスが発生するため、効率化のために既存の国民全員分のデータベースに対し、18歳以上を判定するBoolean型のカラムを追加することが必要になりますが、VCデータモデルでは必ずしもその必要はありません。VCデータモデルではVCを発行するときに1回計算すれば良いため、既存の生年月日カラムから都度計算する方法でも効率が悪化するとは考えにくいです。
+1. 第三者に向けたAPIを開放
+    従来型では、18歳以上を確認したい第三者がAPIを利用することになるため、APIを設計しますが、国民全員のデータベースへのアクセスを一般公開することは難しいため、認可された第三者のみがそのAPIを利用できるような、API利用者管理システムを構築する必要があります。また、そのAPI利用者を管理するための運用コストは莫大になり、18歳以上APIを利用する事業者も申請や認可などの手続きを嫌がります。VCデータモデルでは、既存の認証システムに対し、VCを発行する機能のみを追加すれば良く、新たなAPIを第三者に向けて開放する必要はありません。また、18歳以上を確認したい事業者もVCデータモデルのガバナンス上の手続きのみで18歳以上の確認を行うことができます。
+1. 18歳以上を確認したい事業者がそのAPIと接続するシステムを構築
+    従来型では、APIの仕様に合わせた確認側の開発が必要になりますが、VCデータモデルでは、OID4VPの仕様に準拠していれば、18歳以上のVC（VP）を受け取ることができます。一点、18歳以上を表現するためのスキーマ定義は事前に合意する必要はあります。
+1. 確認を行うたびにサーバ側へのアクセスが発生
+    従来型では、確認を行うたびにサーバ側へのアクセスが発生するため、アクセス数に応じたサーバのキャパシティの増強が必要になりますが、VCデータモデルでは、VCを発行するときに1回利用者からアクセスがあるだけのため、既存のキャパシティのままでも対応できると考えられます。（公開鍵へのアクセスが発生することが考えられるが、単純なテキストファイルへのアクセスのため無視できる）
+    また、従来型では誰が、どの事業者によって18歳以上を確認されたか、という情報がサーバ側に蓄積されることにもなります。
+
+このように、VCデータモデルでは、大規模なシステムであるほどシステム構築コスト・運用コストの削減メリットが期待でき、制度運用のための面倒な申請制度も簡略化できることから、社会実装を行う際のハードルが低く、また、利用者に対するプライバシーインパクトも低減することができる方式と言えます。
+
+ただし、VCデータモデルにも課題があります。例えば、証明書の有効性確認は従来型に比べて課題になると考えられます。従来型では、都度、国民の最新情報が保存されているサーバにアクセスすることで常に最新の情報を取得することが可能ですが、VCデータモデルでは上記の優位性を最大限活用しようとする場合に、証明書の有効性確認においてはトレードオフが発生します。「18歳以上」というような、一度発行してしまえば死亡するまでは有効だと考えられる証明書では大きな問題にはなりませんが、更新が必要な資格証明書や、在籍証明書などを運用する際には、考慮が必要となります。
+
+## 6. ガバナンス構造
+
+### 6.1 ガバナンスの考え方
+
+OWND Projectのガバナンスは、OWND Projectの活動、公開するソースコードおよび提供するアプリケーションが、この Whitepaper の内容に沿って運用されていることを担保するために以下の原則に基づいて構築されます。
+
+* **透明性**
+    * 意思決定プロセスと、プロジェクトに関わる文書は公開されることで、透明性が担保されます。
+
+* **多様なステークホルダーによるコンセンサス**
+    * 参加者を排除しないことにより、多様なステークホルダーによるコンセンサスを形成することで意思決定を行います。
+
+OWND Projectのガバナンスは、他のエンティティにおける成果物の利用に関しては、現時点では対象としませんが、その利用がOWND Projectの理念に適合しているかを評価する枠組みを将来的に提供する可能性を残しています。
+
+#### 6.1.1 ガバナンスによって防ぎたいこと
+
+* **Whitepaper**
+    * Whitepaper が、現在の Whitepaper の内容に反して改変が行われる
+    * 関係のないプロジェクトがOWND Projectを標榜する
+
+* **Code of Conduct**
+    * Code of Conduct が Whitepaper の内容に反して改変が行われる
+    * 参加者が Code of Conduct に従わない
+
+* **ソースコード**
+    * 公開したソースコードが準拠を謳っている標準規格に従っていない
+    * マルウェア等がソースコードに紛れ込む
+
+* **アプリケーション**
+    * 公開したソースコードと、提供するアプリケーションの挙動が一致しない
+    * 提供するアプリケーションが Whitepaper の内容に沿って運用されていない
+
+### 6.2 OWND Project のガバナンス
+
+OWND Project におけるガバナンスについて以下に概念図を示しました。ガバナンスを有効に働かせるためのトラストフレームワークは別途、制定するものとします。
+
+OWND Projectのガバナンスは、Trusted Web、OpenID Foundation、Matrix.org Foundationなどの外部コミュニティと連携し、それらのトラストフレームワークに準拠することで、強化されます。
+
+```mermaid
+
+flowchart TD
+
+    subgraph OWND Project Governance
+        Doc1{{OWND Project Whitepaper}}
+        Doc2{{Code of Conduct etc.}}
+
+        
+        OP[OWND Project]
+        WalletCode([OWND Wallet Code])
+        Wallet([OWND Wallet App])
+        MessengerCode([OWND Messenger Code])
+        Messenger([OWND Messenger App])
+
+        Doc1 --1. Establish--> OP
+        OP --2. Enact--> Doc2
+        Doc2 --3. Obey--> WalletCode
+        Doc2 --3. Obey--> MessengerCode
+        WalletCode --4. Build--> Wallet
+        MessengerCode --4. Build--> Messenger
+    end
+
+    subgraph Trusted Web
+        TW{{Trusted Web Whitepaper}}
+    end
+
+    subgraph Matrix.org Foundation
+        Matrix([Matrix Protocol])
+    end
+
+    subgraph OpenID Foundation
+        OIDF([OpenID Conformance Suite])
+    end
+
+    Doc1 -.Refer.-> TW
+    Matrix -.Fork.-> MessengerCode
+    OIDF -.Test.-> Wallet
+
+```
+
+1. Establish
+    OWND Project は OWND Project Whitepaper によって成立するプロジェクトであり、このホワイトペーパーが公開され、OWND Projectの活動自体も公開されることにより、ガバナンスが機能します。
+
+1. Enact
+    OWND Projectへのコントリビューションに際し、Code of Conduct等のルールを制定します。
+    Code of Conduct 等のルールは OWND Project の参加者によって制定、公開されます。
+
+1. Obey
+    参加者は Code of Conduct 等のルールに従って、会議への参加や、コードの開発を行います。
+    ソースコードは当然公開されますが、会議の議事録や技術選定理由等もできる限り公開されることにより、ガバナンスが機能します。
+
+1. Build
+    公開されたソースコードからアプリケーションとしてビルドして提供します。
+    OWND Project により承認された開発者がビルドしシステムを提供していることを証明します。
+
+### 6.3 参加と貢献のためのインセンティブ
+
+## 7. 技術的アーキテクチャ
+
+### 7.1 OWND Wallet のアーキテクチャ
+
+### 7.2 OWND Messengerのアーキテクチャ
+
+### 7.3 Trusted Web アーキテクチャとの関係
+
+## 8. ロードマップとマイルストーン
+
+### 8.1 開発フェーズ
+
+### 8.2 マイルストーンとタイムライン
+
+## 9. ユースケース
+
+### 9.1 年齢確認
+
+
+### 9.2 イベント参加証
+
+### 9.3 デジタル社員証
+
+## 10. ビジネスモデルの検討
+
+### 10.1 有料サービスの提供
+
+### 10.2 秘密鍵管理サービスの提供
+
+### 10.3 Paas、Saasの提供
+
+## 11. 結論と参加への呼びかけ
+
+### 11.1 ホワイトペーパーの要約
+
+### 11.2 プロジェクト参加のためのステップ
+