デジタル公共インフラストラクチャ: アーキテクチャとビルディング ブロック
公共デジタル インフラストラクチャが世界規模で政府サービスをどのように変革しているか: India Stack から eIDAS 2.0、X-Road から GovStack まで、デジタル公共インフラストラクチャを可能にするアーキテクチャ パターン、ビルディング ブロック、API の包括的な技術分析。
デジタル公共インフラとは
La デジタル パブリック インフラストラクチャ (DPI) これは、政府デジタル サービスの設計におけるパラダイム シフトを表しています。 DPI アプローチでは、個別の公共サービスごとにモノリシック ソリューションを構築するのではなく、 共有、モジュール式、相互運用可能なビルディング ブロック パブリックまたはプライベートのあらゆるサービスで、 再利用します。最も効果的な例えは、道路や電力網などの物理的なインフラストラクチャを例にしたものです。 水道橋はさまざまなサービスが構築される共有プラットフォームであり、DPI はその上に「デジタル レール」を提供します。 検証された身元情報、即時支払い、安全なデータ交換が実行されます。
少なくとも2025年には 64か国 DPI タイプのデジタル ID システムを備えており、 97か国 彼らは持っています 相互運用可能なデジタル決済システム 103か国 彼らは構造化されたデータ交換フレームワークを持っています。 PPEはそうではありません 理論的な概念に近いもので、何十億もの人々に関わる運用インフラストラクチャです。
PPE の正式な定義
UNDP と G20 によれば、デジタル公共インフラストラクチャは以下のセットとして定義されています。 共有、オープン、相互運用可能な技術プラットフォーム サービスの提供を可能にする 全国規模でのデジタル化。 DPI コンポーネントは、ソフトウェア コード、プラットフォーム、アプリケーション、および API として設計されています。 これらは本質的にモジュール式であり、組み合わせて完全なテクノロジー スタックを作成できます。
DPI が従来の電子政府と異なる理由
従来の電子政府はサイロを生み出しました。各省は独自のユーザー データベースを備えた独自のシステムを構築し、 独自の認証メカニズム、独自の支払いゲートウェイ。結果は 重複、非互換性 そして指数関数的なコスト。 DPI はこのロジックを覆します。基本的なブロックを一度構築すれば、エコシステム全体が構築されます。 それらを再利用します。
| 待ってます | 従来の電子政府 | PPE のアプローチ |
|---|---|---|
| 建築 | モノリシック、サービス用 | モジュール式、ビルディングブロック |
| 身元 | 機関ごとにデータベースを分ける | 共有アイデンティティ層 |
| 支払い | 独自のゲートウェイ | 相互運用可能な支払いレール |
| データ | ポイントツーポイント交換 | 標準化されたデータ交換層 |
| 限界費用 | 高 (すべてのサーブを最初から) | 低 (ビルディングブロックの再利用) |
| 市場投入までの時間 | Anni | 週/月 |
| ベンダーロックイン | 高い | 削減（オープンスタンダード） |
PPE の 3 つの基本柱
すべての DPI 実装は以下に基づいて構築されています 相互に接続された 3 本の柱 これらが組み合わされてエコシステムが形成されます フルデジタル。これらの柱は独立したものではなく、その力は相乗効果によって生まれます。
1.デジタルアイデンティティ（デジタルアイデンティティ）
最初の柱は、 あなたの身元を一意に確認する すべての国民の、 エコシステム内の企業またはデバイス。堅牢なデジタル ID システムがなければ、他のサービスは利用できません。 安全に動作します。 DPI デジタル ID は次のとおりである必要があります: ユニバーサル (人口全体をカバー)、 検証可能（暗号化証明付き）、最小限（必要なデータのみを共有）、相互運用可能（複数のデータ間で作業可能） さまざまな団体やサービス）。
2. デジタル決済
2 番目の柱がそれを可能にします リアルタイムでの経済価値の交換 任意の俳優ペアの間で 生態系の中で。 DPI ペイメント レールは単なるゲートウェイではなく、オープン インフラストラクチャです。 あらゆる銀行、フィンテック、機関が標準化された API を介して即時支払いを送受信できるようになります。 参照モデルはインドの UPI で、2026 年 1 月に試験運用が開始されました。 217億件のトランザクション 28兆3,300億ルピー以上の価値があります。
3. データ交換
3 番目の柱は、 情報交換のための安全で標準化された層 異なるシステム間では、 ユーザーの同意とプライバシー規制を遵守します。 DPI データ交換フレームワークにより、データが 完全なトレーサビリティとエンドツーエンドの暗号化により、必要なときに必要な場所にフローします。
3つの柱の相乗効果
国民が政府の補助金を申請する場合、次の 3 つの柱が連携して機能します。デジタルアイデンティティ 申請者が誰であるかを確認し、 データ交換 必要なデータ（収入、居住地、家族状況）を取得する 国民が紙の書類を提出する必要なく、さまざまな情報源から情報を入手できます。 デジタル決済 補助金を提供します 現在のアカウントにリアルタイムで直接反映されます。従来は数週間を要していた官僚的な作業が完了します 数秒で。
India Stack: グローバル参照モデル
L’インドスタック これは世界で最も成熟し、研究された PPE の事例です。 2009年から順次発売され、 を超えてサービスを提供するデジタル インフラストラクチャ エコシステムを表す 14億人。その成功により、 G20、国連、数十カ国にこのモデルを再現するよう促しました。 2025年、インドはUPI技術を輸出 25か国以上で。
Aadhaar: 国家規模での生体認証アイデンティティ
アダール これは世界最大のデジタル ID システムであり、13 億件以上の登録が行われています。 各居住者は、生体認証データ (指紋と虹彩スキャン) に関連付けられた固有の 12 桁の番号を受け取ります。 Aadhaar のアーキテクチャは、次の原則に基づいています。 設計によるセキュリティ: 生体認証プロトコルが統合されました in the infrastructure from conception, not added later.
Aadhaar 検証 API は、次の 3 つのモードをサポートする認証エンドポイントを公開します。
# Aadhaar Authentication API - Flusso di Verifica
# 1. Demographic Authentication
POST /api/v2/auth/demographic
Content-Type: application/xml
{
"aadhaar_number": "XXXX-XXXX-XXXX",
"name": "...",
"dob": "YYYY-MM-DD",
"gender": "M|F|T",
"address": {
"house": "...",
"street": "...",
"pincode": "XXXXXX"
}
}
# 2. Biometric Authentication (Fingerprint/Iris)
POST /api/v2/auth/biometric
{
"aadhaar_number": "XXXX-XXXX-XXXX",
"biometric_data": {
"type": "FIR|IIR", # Fingerprint / Iris
"position": "LEFT_INDEX",
"data": "<base64_encoded_biometric>"
},
"device_info": {
"device_id": "...",
"rdsv": "...", # Registered Device Service version
"mi": "...", # Model Info
"mc": "..." # Machine Code (signed)
}
}
# 3. OTP-based Authentication
POST /api/v2/auth/otp/generate
{ "aadhaar_number": "XXXX-XXXX-XXXX" }
POST /api/v2/auth/otp/verify
{
"aadhaar_number": "XXXX-XXXX-XXXX",
"otp": "XXXXXX",
"txn_id": "..."
}
# Response (comune a tutti i metodi)
{
"status": "Y|N",
"auth_token": "...",
"txn_id": "...",
"err_code": null,
"info": {
"auth_type": "DEMO|BIO|OTP",
"timestamp": "2026-03-09T10:30:00Z"
}
}UPI: 相互運用可能な即時支払い
Il 統一決済インターフェース (UPI) NPCI が開発したリアルタイム決済レールです。 (インド国立決済公社)。 UPI アーキテクチャは、 集中スイッチ 相互接続するもの 国内のすべての銀行と決済サービス プロバイダー (PSP) で利用でき、24 時間 365 日、無料で銀行間の即時送金が可能になります。
UPI の階層化アーキテクチャには次のものが含まれます。
- アプリレイヤー: ユーザー アプリケーション (Google Pay、PhonePe、Paytm、BHIM)
- PSP層: 銀行に代わって取引を管理する決済サービスプロバイダー
- NPCI スイッチ: 異なる銀行間の取引をルーティングするインフラストラクチャの中心
- 銀行システム: 参加銀行の中核業務
- 認証層: デバイス バインディング、暗号化 PIN、多要素認証
- 集落層: 複数の毎日のサイクルでの銀行間決済
# Architettura UPI - Flusso di una Transazione
# 1. L'utente inizia il pagamento dall'app
# 2. La richiesta arriva al PSP (Payment Service Provider)
# 3. Il PSP inoltra al NPCI Central Switch
# 4. Il switch identifica la banca destinataria
# 5. La banca destinataria conferma la disponibilità fondi
# 6. Il switch completa la transazione e notifica entrambe le parti
# Flusso tecnico semplificato:
[Payer App] --> [Payer PSP] --> [NPCI UPI Switch] --> [Payee PSP] --> [Payee Bank]
^ | |
| v v
| [Transaction Log] [Credit Account]
| |
+--------- [Response: Success/Failure] <--------+
# API di Collect Request (esempio semplificato)
POST /upi/v2/collect
{
"payer_vpa": "user@bankpsp",
"payee_vpa": "merchant@bankpsp",
"amount": {
"value": "500.00",
"currency": "INR"
},
"txn_note": "Payment for order #12345",
"txn_id": "TXN202603091030ABC",
"device_fingerprint": "...",
"encrypted_pin": "<encrypted_upi_pin>"
}
# Response
{
"status": "SUCCESS",
"txn_id": "TXN202603091030ABC",
"rrn": "631012345678", # Retrieval Reference Number
"approval_number": "ABC123",
"timestamp": "2026-03-09T10:30:05Z",
"payer_vpa": "user@bankpsp",
"payee_vpa": "merchant@bankpsp",
"amount": "500.00"
}DigiLocker と ONDC: データ交換とオープンコマース
デジロッカー インド国民がアーカイブおよび保管できるようにする文書交換プラットフォームです。 公的文書（運転免許証、学校証明書、健康カード）を検証可能なデジタル形式で共有します。 アーキテクチャは、次のモデルに基づいています。 同意に基づく共有: 文書はコピーされません。 ただし、オリジナルへの検証可能なリンクが提供され、一時的な有効性は所有者によって制御されます。
L’オープン ネットワーク フォー デジタル コマース (ONDC) DPI パラダイムを電子商取引に拡張し、 検索/発見プラットフォームをベンダーや物流サービスから分離し、独占を排除するオープン プロトコル 大きな閉じたプラットフォームの。
インドスタックの実際の影響
- アダール: 13 億以上のサインアップ、1,000 億以上の認証が実行されました
- UPI: 217 億取引/月 (2026 年 1 月)、25 か国以上に輸出
- デジロッカー: 2 億人以上のユーザー、発行されたドキュメント数は 60 億件以上
- 貯蓄: 直接送金で 330 億ドル以上を節約 (仲介業者の排除)
- インクルージョン: Jan Dhan Yojana + Aadhaar を通じて 5 億以上の銀行口座が開設されました
ヨーロッパのアプローチ: eIDAS 2.0 と EUDI ウォレット
ヨーロッパはインドとは異なるアプローチで独自の知的財産権を構築しています。インドスタックはここから生まれました。 インフラが限られている国における金融包摂の必要性に対する欧州のアプローチは、以下から始まります。 基本的権利の保護、プライバシーバイデザインとデジタル主権。の eIDAS 2.0 規制 (EU 規則 2024/1183) は、すべての人に義務付ける立法の柱です。 加盟国は、次の方法でデジタル ID ウォレットを国民に提供します。 2026年12月.
EUDI ウォレット: アーキテクチャと原則
L’EU デジタル ID ウォレット (EUDI) とは根本的に異なる原理に従って設計されています。 集中型システム:
- ローカルストレージ: データは中央サーバーではなくユーザーのデバイスに存在します。
- ユーザーコントロール: どの情報を誰と共有するかはユーザーが決定します
- ゼロトラッキング: 攻撃者がユーザーをプロファイリングできないように設計されています
- プライバシーダッシュボード: 情報が誰とどのように共有されるかについての完全な透明性
- 無料: すべての自然人に対する無料の発行、使用、取り消し
# EUDI Wallet - Architettura Semplificata
# Componenti principali:
[Citizen Device]
|
+-- [EUDI Wallet App]
| |
| +-- [Credential Store] # PID, attestazioni, certificati
| +-- [Crypto Engine] # Chiavi private, firma digitale
| +-- [Privacy Dashboard] # Log condivisioni, revoche
| +-- [Consent Manager] # Gestione consensi granulari
|
+-- [Secure Element / TEE] # Hardware-backed key storage
# Flusso di Verifiable Presentation
# 1. Il Relying Party richiede attributi specifici
# 2. Il Wallet mostra all'utente cosa viene richiesto
# 3. L'utente approva/nega selettivamente
# 4. Il Wallet crea una Verifiable Presentation firmata
# 5. Il Relying Party verifica la firma e la validita
# Esempio: Verifica eta senza rivelare la data di nascita
POST /wallet/v1/presentation
{
"verifier_id": "bar-nightclub-001",
"requested_claims": ["age_over_18"],
"purpose": "Age verification for entry",
"nonce": "abc123xyz",
"response_uri": "https://verifier.example.com/callback"
}
# Wallet Response (selective disclosure)
{
"vp_token": "<signed_verifiable_presentation>",
"presentation_submission": {
"descriptor_map": [
{
"id": "age_over_18",
"format": "mso_mdoc",
"path": "$.credentials[0]"
}
]
},
"disclosed_claims": {
"age_over_18": true
# NOTA: la data di nascita NON viene condivisa
}
}eIDAS 2.0 実装タイムライン
| 日付 | マイルストーン | 詳細 |
|---|---|---|
| 2024年5月 | 規制が承認されました | EU 規則 2024/1183 が公式ジャーナルに掲載されました |
| 2024年12月 | 最初の実施法セット | データ形式と国境を越えた相互運用性に関する技術仕様 |
| 2025年7月 | 完全な実装ドキュメント | ウォレットのセキュリティ、信頼性、技術的機能の基準 |
| 2026年12月 | ウォレットが利用可能 | 各加盟国は国民が EUDI ウォレットを利用できるようにする必要があります |
| 2027年12月 | 強制的な受け入れ | 規制対象の民間部門および VLOP による強制的な受け入れ |
EBSI: 欧州ブロックチェーン サービス インフラストラクチャ
L’EBSI ヨーロッパの DPI アーキテクチャにさらなるレイヤーを追加します。許可されたブロックチェーンです。 サービスを提供する 検証可能な資格情報、公証、トレーサビリティおよびタイムスタンプ みんなで共有する とメンバーは述べている。 EBSI は従来のシステムに代わるものではなく、次の保証を追加する補完物です。 国境を越えたプロセスに対する不変性と暗号検証可能性。
GovStack: ビルディング ブロックの標準
政府スタック ITU、GIZ、エストニア、DIAL が主導する国際イニシアチブであり、 オープンな技術仕様 政府のデジタル サービスのビルディング ブロック向け。戦略を持って GovSpecs 2.0 (2025-2027), GovStack はすでに 20 か国以上が採用している枠組みを固めています 独自の DPI アーキテクチャを設計します。 2026 年からは、仕様に AI 対応機能も統合される予定です。
9 つの基本的な構成要素
GovStack の定義 9つの構成要素 あらゆる政府デジタル サービスの基礎を形成します。 各ビルディング ブロックは独立して展開可能で、標準化された RESTful API を公開し、相互に通信します。 明確に定義されたプロトコルを通じて。
| ビルディングブロック | 関数 | 使用例 |
|---|---|---|
| 身元 | デジタルアイデンティティの検証と管理 | 公共サービスへのログイン、KYC、デジタル署名 |
| 支払い | 支払い処理と送金 | 税金、補助金、公務員の給与 |
| 同意 | データ共有のための同意管理 | 健康と税のデータにアクセスする権限 |
| デジタルレジストリ | 信頼できるデータの構造化されたレジスター | 登記所、土地登記簿、商業登記簿 |
| メッセージング | マルチチャネルの通知と通信 | SMS、電子メール、期限のプッシュ通知、アラート |
| 情報仲介者 | システム間の安全なデータ交換 | 省庁間のデータ共有、データベース横断的な検証 |
| 登録 | サービスとプログラムへの登録 | 学校登録、健康登録 |
| スケジューラ | 予約とリソース | ASL の予約、書類の予約 |
| ワークフロー | 複数ステップのプロセスオーケストレーション | 建築確認申請・承認手続き |
# GovStack Building Block - Esempio di Architettura Completa
# Caso d'uso: Richiesta sussidio sociale
# 1. REGISTRATION BB - Il cittadino si registra alla piattaforma
POST /api/v1/registration/applications
{
"program_id": "social-subsidy-2026",
"applicant": {
"identity_ref": "ID-2026-XXXX",
"contact": {
"email": "citizen@email.com",
"phone": "+39XXXXXXXXXX"
}
}
}
# Response: { "application_id": "APP-001", "status": "SUBMITTED" }
# 2. IDENTITY BB - Verifica identità del richiedente
POST /api/v1/identity/verify
{
"identity_ref": "ID-2026-XXXX",
"verification_type": "STRONG",
"purpose": "social-subsidy-eligibility",
"required_loa": "HIGH" # Level of Assurance
}
# Response: { "verified": true, "loa": "HIGH", "method": "eID+biometric" }
# 3. CONSENT BB - Richiesta consenso per accesso dati fiscali
POST /api/v1/consent/requests
{
"subject_id": "ID-2026-XXXX",
"requester": "ministry-of-welfare",
"data_sources": [
{
"provider": "tax-authority",
"data_type": "annual_income",
"period": "2025"
},
{
"provider": "social-security",
"data_type": "employment_status",
"period": "current"
}
],
"purpose": "Verifica requisiti sussidio sociale",
"retention_period": "90d",
"expires_at": "2026-04-09T00:00:00Z"
}
# Response: { "consent_id": "CON-001", "status": "PENDING_APPROVAL" }
# 4. INFORMATION MEDIATOR BB - Recupero dati (post-consenso)
POST /api/v1/mediator/query
{
"consent_id": "CON-001",
"queries": [
{
"source": "tax-authority",
"endpoint": "/citizen/income",
"params": { "year": 2025, "citizen_id": "ID-2026-XXXX" }
},
{
"source": "social-security",
"endpoint": "/citizen/employment",
"params": { "citizen_id": "ID-2026-XXXX" }
}
]
}
# Response: aggregated data from multiple sources
# 5. WORKFLOW BB - Orchestrazione decisione
POST /api/v1/workflow/execute
{
"workflow_id": "subsidy-evaluation",
"application_id": "APP-001",
"input_data": {
"identity_verified": true,
"income_2025": 18500.00,
"employment_status": "unemployed",
"household_size": 3
}
}
# Response: { "decision": "APPROVED", "amount": 600.00, "frequency": "monthly" }
# 6. PAYMENTS BB - Erogazione sussidio
POST /api/v1/payments/disbursements
{
"beneficiary_id": "ID-2026-XXXX",
"amount": 600.00,
"currency": "EUR",
"payment_method": "bank_transfer",
"reference": "APP-001",
"schedule": {
"type": "RECURRING",
"frequency": "MONTHLY",
"start_date": "2026-04-01"
}
}
# Response: { "payment_id": "PAY-001", "status": "SCHEDULED" }
# 7. MESSAGING BB - Notifica al cittadino
POST /api/v1/messaging/send
{
"recipient_id": "ID-2026-XXXX",
"template": "subsidy-approved",
"channels": ["sms", "email", "push"],
"parameters": {
"amount": "600.00 EUR",
"start_date": "1 Aprile 2026",
"reference": "APP-001"
}
}
# Response: { "message_id": "MSG-001", "delivered": ["sms", "email"] }相互運用性フレームワーク: X-Road と DIGIT
X-Road: エストニアのデジタル バックボーン
Xロード は、2001 年にエストニアによって開発され、現在ではエストニアによって採用されている相互運用性フレームワークです。 超えて 25か国。あらゆるシステム間での安全なデータ交換を可能にするコンポーネントです。 情報は政府のネットワークに接続され、次のように発行されます。 オープンソース 2016年からMITライセンスの下で。
X-Road アーキテクチャは、次の 3 つの主要なコンポーネントに基づいています。
- 中央サーバー: メンバー レジストリ、セキュリティ ポリシー、および全体的なネットワーク構成を維持します。
- セキュリティサーバー: 各参加組織にインストールされ、各トランザクションの認証、認可、暗号化、ログ記録を管理します。
- サービスプロバイダー/消費者: X-Road を介してサービスを生成または消費する情報システム
各組織とセキュリティ サーバーの ID は、次の方法で検証されます。 X.509証明書 発行者 信頼できる認証局。各メッセージはデジタル署名され、転送中に暗号化され、不変に記録されます。 コミュニケーションの両側で。
# X-Road - Architettura di Interoperabilità
# Organizzazione A Central Server Organizzazione B
# +----------------+ +-------------------+ +----------------+
# | Information | | - Member Registry | | Information |
# | System A | | - Security Policy | | System B |
# | (Consumer) | | - Config Sync | | (Provider) |
# +-------+--------+ +-------------------+ +-------+--------+
# | |
# +-------+--------+ +-------+--------+
# | Security Server| <--- TLS + Signed SOAP ---> | Security Server|
# | - Auth | | - Auth |
# | - Encryption | | - Encryption |
# | - Logging | | - Logging |
# | - Timestamping | | - Timestamping |
# +----------------+ +----------------+
# Requisiti soddisfatti da X-Road:
# 1. Interoperabilità: funziona tra sistemi eterogenei con API language-agnostic
# 2. Integrita dei dati: nessuna informazione alterata durante il trasferimento
# 3. Privacy: tutti i dati cifrati, protetti da accessi non autorizzati
# 4. Non-repudiabilita: ogni transazione firmata e loggata su entrambi i lati
# Esempio di richiesta X-Road (SOAP/REST)
# Service: popolazione.anagrafe/getCitizenData/v3
{
"client": {
"xRoadInstance": "EE",
"memberClass": "GOV",
"memberCode": "70000001",
"subsystemCode": "welfare-system"
},
"service": {
"xRoadInstance": "EE",
"memberClass": "GOV",
"memberCode": "70000002",
"subsystemCode": "population-registry",
"serviceCode": "getCitizenData",
"serviceVersion": "v3"
},
"id": "REQ-2026-03-09-001",
"protocolVersion": "4.0"
}DIGIT India: データの強化と保護のアーキテクチャ
インド戦線における枠組み DIGIT (ガバナンス、インパクト、変革のためのデジタル インフラストラクチャ) 都市および地方の公共サービスのデジタル化のためのオープンソース プラットフォームを提供します。エックスロードとは違い、 これは純粋な相互運用性レイヤーですが、DIGIT は以下を含むより広範なエコシステムです。 事前構築されたマイクロサービス、分析ダッシュボード、市民参加ツール.
DIGIT を補完するものとして、 DEPA (データの強化と保護のアーキテクチャ) それを国民のデータとして定義します 安全に共有できます アカウントアグリゲーター、規制された信託事業体 ユーザーの明示的な同意を得て金融データの流れを仲介するインド準備銀行による。
政府サービス向けの API 設計
API 設計は DPI の技術的中心です。政府 API は範囲要件を満たす必要がある 商用 API をはるかに超えています。 可用性 99.99%、下位互換性が何年も保証されており、 包括的な監査証跡、多言語サポート、および国内および国際標準への準拠。
政府 API の設計パターン
# API Gateway per Servizi Governativi - Pattern di Riferimento
# Struttura URL standardizzata:
# /{country}/gov/api/{version}/{domain}/{resource}
# Esempi:
# GET /it/gov/api/v2/citizens/CF-XXXXXX/profile
# POST /it/gov/api/v2/welfare/applications
# GET /it/gov/api/v2/tax/declarations?year=2025
# Standard Headers (obbligatori per tutte le API governative):
#
# X-Request-ID: UUID univoco per tracciabilita
# X-Correlation-ID: ID per correlare richieste cross-service
# X-Gov-Client-ID: Identificativo del sistema chiamante
# X-Gov-Consent-Token: Token di consenso dell'utente (dove richiesto)
# X-Gov-Audit-Actor: Identificativo dell'operatore (per audit)
# Accept-Language: Lingua della risposta (it, en, de, fr, ...)
# Versionamento: URI-based per major version, header per minor
# GET /it/gov/api/v2/citizens/...
# X-Api-Version: 2.3.1
# Rate Limiting differenziato per tipo di consumer:
# - Sistemi interni PA: 10.000 req/min
# - Enti accreditati: 1.000 req/min
# - Applicazioni cittadini: 100 req/min
# - Sviluppatori (sandbox): 50 req/min
# Envelope di risposta standard:
{
"meta": {
"request_id": "550e8400-e29b-41d4-a716-446655440000",
"timestamp": "2026-03-09T10:30:00Z",
"api_version": "2.3.1",
"locale": "it-IT"
},
"data": {
# ... payload della risposta
},
"pagination": {
"total": 150,
"page": 1,
"per_page": 20,
"next_cursor": "eyJpZCI6MTIzfQ=="
},
"errors": null,
"warnings": [
{
"code": "DEPRECATED_FIELD",
"message": "Il campo 'codice_fiscale_old' sarà rimosso nella v3",
"target": "data.codice_fiscale_old"
}
]
}
# Error Response standard (RFC 7807 - Problem Details):
{
"type": "https://gov.it/errors/consent-required",
"title": "Consenso richiesto",
"status": 403,
"detail": "L'accesso ai dati fiscali richiede il consenso esplicito del cittadino",
"instance": "/it/gov/api/v2/tax/declarations?year=2025",
"extensions": {
"consent_url": "https://consent.gov.it/request/CON-001",
"required_scopes": ["tax:read:annual_income"],
"expires_in": 3600
}
}同意管理: IPR におけるプライバシーの核心
Il 同意の構成要素 それはおそらく、現代の PPE において最も重要なコンポーネントです。 GDPR が厳しい要件を課しているヨーロッパなどの状況では。同意管理は単純ではない 「承諾/拒否」: 取り消し可能で期限切れの同意を細かく管理する必要がある複雑なシステムです。 タイムラインと完全な監査証跡。
# Consent Management Service - Implementazione di Riferimento
# Modello dati del consenso
{
"consent_id": "CON-2026-03-001",
"version": 1,
"status": "ACTIVE", # PENDING | ACTIVE | REVOKED | EXPIRED
"subject": {
"id": "CITIZEN-ID-XXX",
"type": "NATURAL_PERSON"
},
"controller": {
"id": "MINISTRY-WELFARE",
"name": "Ministero del Lavoro e delle Politiche Sociali",
"dpo_contact": "dpo@lavoro.gov.it"
},
"purpose": {
"code": "SOCIAL_SUBSIDY_EVAL",
"description": "Valutazione requisiti per sussidio sociale",
"legal_basis": "GDPR Art. 6(1)(a) - Consenso esplicito"
},
"data_items": [
{
"source": "agenzia-entrate",
"category": "FINANCIAL",
"specific_data": ["annual_income", "tax_declarations"],
"period": "2024-2025",
"access_type": "READ_ONCE" # READ_ONCE | READ_RECURRING | STREAM
},
{
"source": "inps",
"category": "EMPLOYMENT",
"specific_data": ["employment_status", "contribution_history"],
"period": "current",
"access_type": "READ_RECURRING"
}
],
"constraints": {
"retention_period": "90d",
"geographic_restriction": "EU",
"no_automated_decisions": true,
"no_third_party_sharing": true
},
"lifecycle": {
"created_at": "2026-03-09T10:00:00Z",
"granted_at": "2026-03-09T10:05:23Z",
"expires_at": "2026-06-09T10:05:23Z",
"revoked_at": null,
"last_accessed": "2026-03-09T10:30:00Z",
"access_count": 1
},
"audit_trail": [
{
"action": "CREATED",
"timestamp": "2026-03-09T10:00:00Z",
"actor": "welfare-portal",
"ip": "x.x.x.x"
},
{
"action": "GRANTED",
"timestamp": "2026-03-09T10:05:23Z",
"actor": "citizen-wallet",
"method": "EUDI_WALLET_CONFIRM"
},
{
"action": "DATA_ACCESSED",
"timestamp": "2026-03-09T10:30:00Z",
"actor": "welfare-evaluation-service",
"data_source": "agenzia-entrate"
}
],
"signature": "<digital_signature_of_consent_record>"
}
# API per gestione consenso:
# Creazione richiesta di consenso
POST /api/v1/consent/requests
# Approvazione/rifiuto da parte del cittadino
PUT /api/v1/consent/{consent_id}/grant
PUT /api/v1/consent/{consent_id}/deny
# Revoca consenso (diritto garantito GDPR)
DELETE /api/v1/consent/{consent_id}
# Verifica stato consenso (per i data provider)
GET /api/v1/consent/{consent_id}/verify
# Response: { "valid": true, "scopes": [...], "expires_in": 7776000 }
# Lista consensi attivi per un cittadino
GET /api/v1/consent/subject/{subject_id}
# Response: lista paginata di tutti i consensi attivi/scaduti/revocati
# Audit trail completo
GET /api/v1/consent/{consent_id}/auditPPE の設計によるセキュリティとプライバシー
PPE システムのセキュリティは後付けで考えることはできません。必ず考慮する必要があります。 建築のDNAに組み込まれている 構想以来。世界経済フォーラムでも強調されているように、 設計によるセキュリティの原則は、Aadhaar 生体認証プロトコル、トランザクション フレームワークに組み込まれています。 単一のユーザーが登録される前の UPI およびデータ共有アーキテクチャの変更。
PPE の安全原則
| 原理 | 実装 | Esempio |
|---|---|---|
| ゼロトラスト | すべてのリクエストは認証および承認され、暗黙的な信頼はありません | すべてのマイクロサービスにわたる mTLS、短い期限の JWT |
| データの最小化 | 絶対に必要なデータのみを共有する | EUDI ウォレット: 生年月日を明らかにせずに年齢を確認します |
| どこでも暗号化 | 転送中の暗号化 (TLS 1.3) および保存中の暗号化 (AES-256) | X-Road: すべてのメッセージはエンドツーエンドで署名および暗号化されます |
| 不変の監査 | すべての操作の変更不可能なログ | 同意とアクセスのためのブロックチェーンに基づく監査証跡 |
| 同意優先 | 明示的な検証可能な同意がなければデータにアクセスできません | DEPA Account Aggregator: 署名されたデジタル同意書 |
| フェデレーテッド アーキテクチャ | 単一障害点や単一妥協点がない | X-Road: 分散データ、中央データベースなし |
| ハードウェアセキュリティ | Secure Element または HSM の暗号キー | EUDI ウォレット: デバイスの TEE 内の秘密鍵 |
2025 年 4 月の UPI 障害からの教訓
2025 年 4 月 12 日、UPI は 5 時間以上続く、ここ 3 年間で最大規模の障害を経験しました。分析 NPCIの死後解剖により、原因は 「トランザクションステータスの確認」API のフラッディング: システムにはトランザクション ステータス検証リクエストに制限がありませんでした。この事例は、PPE でも より成熟した企業は、次の原則を厳密に適用する必要があります。 レート制限、サーキット ブレーク、グレースフル デグラデーション 一見セカンダリと思われるエンドポイントも含め、すべての単一エンドポイントで。
DPI のスケーリング: プロトタイプから国家規模まで
PPE を試作段階から人口全体の規模にまで引き上げるのは、工学的な課題の 1 つです テクノロジーの状況はさらに複雑になります。数字が物語っています: UPI はさらに処理を進めます 7億 1日あたりのトランザクション数、Aadhaar は毎月数億件の認証を処理し、エストニアの X-Road は 人口 130 万人の国で年間 10 億を超えるクエリを処理します。
スケーラビリティのためのアーキテクチャ パターン
- イベント駆動型アーキテクチャ: ビルディング ブロックは非同期イベントを介して通信し、プロデューサーとコンシューマーを切り離し、独立したスケーリングを可能にします。
- CQRS (コマンドクエリ責任分離): 書き込み (トランザクション、レコード) 操作と読み取り (クエリ、レポート) 操作を分離し、それぞれに最適化されたデータベースを使用します。
- 地理的シャーディング: 地域/州ごとにデータを分割してレイテンシを削減し、データの常駐要件を満たす
- サーキットブレーカー: ビルディング ブロック間の各統合は、カスケード障害を回避するために回路ブレーカーによって保護されています
- ブルーグリーン展開: ダウンタイムのない更新。中断できないサービスにとって重要です。
- マルチリージョンのアクティブ/アクティブ: RPO がゼロに近い災害復旧のための複数のデータセンターにわたるアクティブ レプリケーション
ケーススタディ: 3 つの PPE モデルの比較
エストニア: e-Residency と世界で最もデジタルな政府
エストニアは、政府の完全なデジタル化の事例として最もよく挙げられています。人口わずか130万人で、 の 公共サービスの99% オンラインで入手できます（唯一の例外は結婚、離婚、 不動産販売では依然として物理的な立ち会いが必要です）。プログラム e-レジデンシー、2014年に発売された、 これにより、世界中の誰もがエストニアのデジタル ID を取得し、同国のビジネス サービスにアクセスできるようになります。
技術の心は、 Xロード、2001 年以来、すべての公共情報システムを相互接続してきました。 行政。各組織は独自のデータを保持します (「1 回限り」原則: データは 1 回だけ記録されます) X-Road は、安全で署名および記録された交換を保証します。
インド: UPI と数十億規模の金融包摂
India Stack は、DPI が前例のない規模で機能できることを証明しました。ルートは次のとおりでした。 アダール (アイデンティティ、2009 年以降) → ジャン・ダン・ヨジャナ (すべての銀行口座、2014 年以降) → UPI (即時支払い、2016年以降) → デジロッカー (資料、2015年のもの) → ONDC （商業オープン、2022年から）。このシーケンスは、として知られています ジャムトリニティ (Jan Dhan + Aadhaar + Mobile) — 5 億人以上の人々を正式なデジタル経済に参加させてきました。
シンガポール: SingPass とスマート国家モデル
シンパス (シンガポールパーソナルアクセス) は、 国民および永住者の97％ 15 歳以上で、約 3億件のトランザクション 個人でも法人でも毎年、 800 以上の公共および民間団体の 2,700 以上のサービスを接続します。 NDI (National Digital Identity) アーキテクチャ シンガポールの特徴は次のとおりです。
- 私の情報: 政府検証データが事前に入力されたデジタルプロファイルにより、データを繰り返し入力する必要がなくなります
- 顔認証：リスクの高い取引に対応した顔生体認証
- Sign: エコシステムに統合された法的に有効なデジタル署名
- 確認する: 物理的な文書を共有せずに、QR コードを介して直接本人確認を行う
| サイズ | エストニア | インド | シンガポール | EU (eIDAS 2.0) |
|---|---|---|---|---|
| サービスを受ける人口 | 130万人以上の電子居住者 | 14億 | 590万 | 4.5億（目標） |
| 創業年 | 2001年（エックスロード） | 2009 (アーダール) | 2003 (シンパス) | 2024 (eIDAS 2.0) |
| 身元 | eIDカード+モバイルID | アダール (生体認証) | シンパス + NRIC | EUDIウォレット |
| データ交換 | X-Road (フェデレーテッド) | DEPA + デジロッカー | マイインフォ + APEX | EBSI + eデリバリー |
| 支払い | SEPA + 電子請求書発行 | UPI (2,170 億トン/月) | PayNow + SGQR | SEPA インスタント + EPI |
| 建築 | フェデレーション、分散化 | 中央スイッチ + API | 一元化、クラウドネイティブ | ウォレットベース、分散型 |
| オープンソース | はい (X-Road MIT) | 部分的 (MOSIP、DIGIT) | 部分的（シンガポール政府技術） | 定義される途中 |
| プライバシーモデル | 1回限りの原則 | 同意に基づく共有 | 一元化されたコントロール | プライバシーバイデザイン、GDPR |
PPE の導入: 学んだ教訓
PPE を成功させるための 7 つの黄金律
- アイデンティティから始める: 堅牢な ID レイヤーがなければ、何も機能しません。それは他のすべての前提条件です。
- オープンスタンダード、必須のオープンソースではない: 仕様はオープンである必要があり、実装は異なる場合があります。 GovStack は、オープン スタンダードによって多様かつ相互運用可能な実装が可能になることを実証しています。
- ゼロからのプライバシー: アーキテクチャには、最初のコミットからのコンセンサス、データの最小化、監査証跡が含まれている必要があります。後から追加すると、コストが飛躍的に高くなります。
- 根本的なモジュール化: 各ビルディング ブロックは、個別に交換、アップグレード、またはスケーリングできる必要があります。支払いシステムを変更するために ID システムを変更する必要がある場合、そのアーキテクチャは間違っています。
- 失敗に備えた設計: 全国規模で見ると、破産は例外ではなく、統計的に確実です。サーキット ブレーカー、指数バックオフによる再試行、およびグレースフル デグラデーションが必須です。
- まずはサンドボックス: 運用に移行する前に、開発者とエンティティが統合をテストできる完全なサンドボックス環境を提供します。導入は開発者の経験に依存します。
- すべてを測定する: 1 秒あたりのトランザクション、P99 レイテンシ、エラー率、採用率、トランザクションあたりのコスト。メトリクスがなければ最適化はできません。
PPE の将来: 2026 年から 2030 年のトレンド
PPE の状況は急速に進化しています。アーキテクチャを再定義するいくつかのトレンドが出現しています 今後数年間での公共デジタルインフラストラクチャの発展:
- ビルディングブロックにおける AI 対応: GovSpecs 2.0 は、2026 年から AI 対応機能をビルディング ブロック仕様に統合し、プロアクティブかつ予測的なサービスを可能にすることを予測しています
- 一般化された検証可能な認証情報: 検証可能な資格情報は、アイデンティティを超えて、教育資格、専門ライセンス、健康証明書、職業資格にまで拡張されます。
- 国境を越えたPPE: EUDI ウォレットと UPI エクスポートを参照モデルとして、各国の PPE 間の相互運用性が標準になるでしょう
- 分散型アイデンティティ (SSI)：中央プロバイダーに依存せずに国民が自分自身のデータを完全に管理する自己主権アイデンティティモデルが注目を集めるだろう
- グリーン PPE：エネルギー効率と環境の持続可能性が設計要件となり、トランザクションごとの二酸化炭素排出量の指標が求められます
結論
デジタル公共インフラは技術プロジェクトではありません。 社会アーキテクチャの選択。 共有され、オープンで相互運用可能なビルディング ブロックを構築することを決定するということは、イノベーションを実現するモデルを選択することを意味します。 分散されており、パブリックまたはプライベートのあらゆるアクターが同じ基盤上にサービスを構築できます。 そして、新しいデジタル サービスの限界費用がゼロになる傾向がある場合。
私たちが分析した 3 つのモデル — 規模のインド スタック、建築の優雅さのエストニア、建築の優雅さのシンガポール 効率性 — IPR を実装する唯一の方法はないが、普遍的な原則があることを実証します。 モジュール性、相互運用性、プライバシーバイデザイン、オープンスタンダード、失敗に備えた設計。 GovStack によるビルディング ブロックの標準化により、eIDAS 2.0 により 4 億 5,000 万人のヨーロッパ人にデジタル ウォレットが提供されます。 インドは UPI を 25 か国以上に輸出しており、私たちは PPE が普及する時代の始まりにいます。 電気やインターネットと同じくらい基本的なインフラストラクチャ。
ソフトウェア開発者やアーキテクトにとって、DPI パターンを理解することは単なる技術的なスキルではありません。 次世代の公共サービスのデジタル インフラストラクチャの構築に参加するための鍵となります。
詳細を学ぶためのリソース
- GovStackの仕様: spec.govstack.global — ビルディング ブロックの完全な技術仕様
- X-Road ドキュメント: x-road.global — エストニアのフレームワークのドキュメントとソース コード
- インドスタック: indiastack.org — インドの PPE エコシステムのドキュメント
- EUDIウォレット: ec.europa.eu/digital-building-blocks — ヨーロッパウォレットの技術仕様
- OECD PPE レポート 2025: OECD 諸国における PPE の比較分析