Copyright © 2021-2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
この仕様は、MiniAppパッケージの意味論および適合要件、ならびに マニフェストファイル、静的ページテンプレート、スタイルシート、JavaScript文書、メディアファイルおよびその他のリソースを含む、MiniAppのリソースを保持する単一ファイルコンテナーの 構造を定義します。MiniAppパッケージのインスタンスは、MiniAppの配布および ランタイム環境(MiniAppユーザーエージェント)での実行に使用されます。
このセクションは、公開時点におけるこの 文書のステータスを説明します。現在のW3C 公開物の一覧およびこの技術レポートの最新版は、 https://www.w3.org/TR/ にある W3C 技術 レポート索引で確認できます。
この文書は、MiniAppsワーキング グループにより、 勧告トラックを使用して 作業草案として公開されました。
作業草案としての公開は、 W3Cおよびそのメンバーによる承認を意味するものではありません。
これは草案文書であり、いつでも他の文書により更新、置換、または廃止される可能性があります。 この文書を、進行中の作業以外のものとして引用することは不適切です。
この文書は、 W3C 特許 ポリシーの下で活動するグループにより作成されました。 W3Cは、 そのグループの成果物に関連して行われた特許開示の 公開リストを維持しています。 そのページには、特許を開示するための 手順も含まれています。個人が、当該個人が 必須クレーム を含むと考える特許について実際の知識を有する場合、 その情報は、W3C特許ポリシー第6節に従って開示しなければなりません。
この文書は、 2023年11月03日のW3Cプロセス文書により管理されます。
MiniAppは軽量ソフトウェアアプリケーションの概念であり、任意のデジタル手段で 配布でき、Webを通じてアクセスできます。MiniAppは具体的なファイル構造により定義され、そのすべてのリソースは、 MiniAppパッケージ全体を表す単一ファイル内にパッケージ化されます。このパッケージは 処理され、 MiniAppユーザーエージェントによって実行できます。
MiniAppパッケージには、MiniAppのレンダリング、操作、および エンドユーザーとのインタラクションを定義する固有のリソースを保持するディレクトリー構造が含まれます。これには、 静的ページテンプレート、スタイルシート、JavaScript文書、メディアファイル、その他の リソース、およびマニフェストが含まれます。パッケージの中央ディレクトリーに配置されるMiniApp マニフェストは、MiniAppを記述し、ページルーティング、スタイル、その他のMiniAppの操作およびレンダリングの詳細に関する 情報、ならびに人間向けの説明情報を含みます。
セキュリティに関する考慮事項で定義されるように、MiniAppは、パッケージ配信中の パッケージおよび内容の完全性を保証するために、デジタル署名検証をサポートしてもよい。
MiniAppランタイム環境(MiniAppユーザーエージェント)は、 この文書で定義される標準のMiniAppパッケージ形式および特定のMIMEメディア型を通じて MiniAppパッケージファイルを識別します。MiniApp ZIPコンテナーを取得した後、MiniAppユーザーエージェントは、参照解除および処理アルゴリズムに従って、静的ページテンプレート、スタイルシート、 JavaScriptファイル、およびその他のリソースをキャッシュへ読み込みます。これらのMiniAppリソースは次回の更新までキャッシュ内で利用可能なままとなり、 不要なネットワーク取得を回避します。
起動モードに関して、MiniAppはオフライン時でも通常どおり起動できます。MiniAppユーザーエージェントは、パッケージキャッシュパスから指定された開始ページを特定し、MiniApp マニフェストファイルで定められた記述に従ってMiniAppを起動します。
以下の用語はMiniAppに固有のものです。
非規範的と明示されたセクションに加え、この仕様におけるすべての作成ガイドライン、図、例、および注記は 非規範的です。この仕様のそれ以外のすべては規範的です。
この文書におけるキーワードMAY、MUST、MUST NOT、SHALL、SHOULD、およびSHOULD NOTは、 ここに示すようにすべて大文字で現れる場合に限り、 BCP 14 [RFC2119] [RFC8174] に記述されているとおりに解釈されます。
MiniApp Packaging仕様は、アルゴリズムを記述するためにInfra Standard [INFRA]に依存します。適合するMiniAppパッケージは、次の 基準を満たさなければなりません:
pagesサブディレクトリーに基づくファイル構造を持たなければなりません。commonを含んでもよい。i18nを含むべきです。
manifest.jsonという名前の構成ファイルを1つ含まなければなりません。
app.jsという名前のスクリプト文書を1つ含まなければなりません。
app.cssという名前のスタイルシートを1つ含まなければなりません。
MiniAppパッケージは、いくつかの制限ならびに予約済みファイルおよびサブディレクトリーを伴うファイル構造を持ちます。
次の例は、典型的なファイルシステム構造を示します:
/
|___manifest.json
|___app.js
|___app.css
|___pages/
| |___page1.js
| |___page1.html
| |___page1.css
|___common/
| |___componentA.js
| |___componentA.html
| |___componentA.css
| |___example.png
|___i18n/
|___zh-Hans.json
|___en-US.json
MiniAppルートディレクトリーは、MiniAppパッケージファイルシステムの基底 ディレクトリーです。
ルートディレクトリーは、MiniAppパッケージのものであり、 MiniAppのライフサイクル管理に関するグローバルデータおよび情報を含む複数の予約済みファイルを保持します。これには次のものが含まれます:
manifest.jsonapp.cssapp.jspagesディレクトリーには、MiniAppページの表示およびユーザーインタラクションのための一連のファイルが含まれます。
MiniAppページは、一意のファイル名
(例: intro)およびリソース型を定義する特定の拡張子によって識別される、一連のリソースによって定義されます。たとえば、アプリケーションのビジネスロジック
(例: intro.js)、構造およびコンテンツ(例: intro.html)、および
スコープ付きスタイルシート(例: intro.css)です。
開発者は、必要に応じて他の型のリソースを含めても
よい。また、ページに関連するファイル(同じファイル名で識別される)は、各ページ用の特定のサブディレクトリーに整理しても、
pagesディレクトリー直下に保存してもよい。
/
|___manifest.json
|___app.js
|___app.css
|___pages/
|___detail.js
|___detail.html
|___detail.css
|___list.js
|___list.html
|___list.css
/
|___manifest.json
|___app.js
|___app.css
|___pages/
|___detail/
|___detail.js
|___detail.html
|___detail.css
|___list
|___list.js
|___list.html
|___list.css
.htmlリソースは、MiniAppページの構造およびコンテンツを定義します。HTMLに基づき、この型のファイルの構文、構造、およびその他の
要件はHTML
リソースセクションで定義されます。.cssリソースは、MiniAppページのスタイルシートを定義します。この型のリソースの構文、
構造、およびその他の要件はCSSリソースセクションで定義されます。.jsリソースには、アプリケーションの運用に必要な関数、データ、およびその他の構成
要素を含む、MiniAppページのビジネスロジックが含まれます。この型のリソースは、
MiniApp Lifecycle仕様 [MINIAPP-LIFECYCLE]で定義されるように、
MiniAppページの設定およびライフサイクル管理を担います。
これらの型のファイルの構文および形式はスクリプティングリソースセクションで定義されます。
任意のcommonディレクトリーには、MiniApp内のページからアクセス可能な、コンポーネント、マルチメディアリソース、文書、ライブラリーなどのリソースが含まれます。このディレクトリーの内部構造は
柔軟であるため、これらの共通リソースは必要に応じてカスタマイズされた
サブディレクトリー内に、また異なる命名規則を用いて整理してもよい。
任意のi18nディレクトリーは、ルートディレクトリー内の サブディレクトリーであり、MiniAppパッケージのローカライゼーションリソースを含みます。
i18nディレクトリーには、MiniAppコンテンツの
国際化をサポートするための多言語ローカライゼーションリソースが含まれます。このディレクトリー内の各.json文書のファイル名は、
[BCP47]で定義されるLanguage-Tag表記に従い、
その特定の言語に対する具体的な構成を表します。
i18nディレクトリーは、MiniAppがサポートする言語またはロケールの数に応じて、 任意の数のローカライゼーションリソースを含んでもよい。これらのファイルの形式は、 ローカライゼーションリソースセクションで定義されます。
MiniAppパッケージ内のすべてのファイル名およびパス名は、オペレーティングシステムの潜在的な 制限に対応し、プラットフォームおよびファイルシステムの大多数との相互運用性を促進するために、仕様開発者のための国際化ベストプラクティスで指定される 次の制限に従わなければなりません。
同じディレクトリー内のすべてのファイル名は、Unicode正準正規化 [UAX15]の後に完全ケース フォールディング [Unicode]を行った結果として一意でなければなりません。(詳細については、 Unicode正準ケース フォールド正規化ステップ [CHARMOD-NORM]を参照してください。)
MiniAppページは、少なくともHTMLリソースから構成され、任意でCSSリソースおよび/またはスクリプティングリソースを
含みます。これらの関連リソースは、MiniAppページを、ページルートを通じて識別するために、
同じパスおよびファイル名(ファイル拡張子のみを変更)を持たなければなりません。このページルートは、MiniApp
マニフェスト [MINIAPP-MANIFEST]のpagesメンバーで指定される必要があります。
/
|___pages/
|___product/
|___product.html
|___product.css
|___product.js
HTML リソースは、MiniAppページおよびそのユーザーインターフェイスを定義するためのマークアップおよび情報を含む文書であり、 構造、視覚コンポーネント、およびインタラクション要素を含みます。
HTMLリソースは、次のすべての基準を満たさなければなりません:
.htmlを使用するべきです。CSS
リソースは、MiniAppページのレンダリングおよび外観を記述するスタイルシートです。CSSリソースは、MiniApp内のすべてのページに影響するグローバルなもの
(すなわち、ルート
ディレクトリー内のapp.css)であっても、MiniApp内の特定のページのみに影響するローカルスコープのものであってもよいです。
この仕様は、[CSS-SNAPSHOT]で定義されるCSSモジュールをサポートします。
CSSリソースは、次のすべての基準を満たさなければなりません:
app.cssという名前で、ルート
ディレクトリーに保存されなければなりません。
.cssを使用するべきです。スクリプティングリソースは、アプリケーションのビジネスロジックおよび機能を制御し、
インタラクティビティを追加し、MiniAppのライフサイクルを管理するためのスクリプト要素および
データを含む文書です。グローバルなスクリプティング
リソース(すなわち、ルート
ディレクトリー内のapp.js)があり、MiniAppのすべてのページで利用可能なデータおよび関数、ならびに
アプリケーションのライフサイクルを制御する固有のロジックを含みます。各MiniAppページは、具体的なページにスコープが限定された、関連する固有のスクリプティングリソースを持っても
よい。
スクリプティングリソースは、次のすべての基準を満たさなければなりません:
app.jsという名前で、ルート
ディレクトリーに保存されなければなりません。
.jsを使用するべき
です。
MiniAppローカライゼーションリソースは、MiniAppの国際化機構の一部としてローカライズされたコンテンツを含む、MiniAppパッケージの文書です。
多言語MiniAppは、システムロケールまたはユーザーの言語設定に従ってコンテンツをレンダリングするために、ユーザーエージェントによるローカライゼーションプロセス中に使用される複数のローカライゼーションリソースを持っても よい。これらのリソースには、ローカライズ可能な用語または表現の一意の識別子(キー)と、 具体的な言語での表現(値)を含むキー値ペアのJSONオブジェクトが含まれます。
{
"title": "Cool MiniApp",
"about": "About this MiniApp",
"intro-page": {
"title" : "Introduction",
"main" : "This is the body of the page"
}
}
ローカライゼーションリソースは、次のすべての基準を満たさなければ なりません:
.jsonを使用するべきです。このセクションは非規範的です。
MiniApp ZIPコンテナーは、MiniAppの物理的な単一ファイル表現であり、 次のようなさまざまなシナリオで配布に使用できます:
MiniApp ZIPコンテナーは、MiniAppパッケージ構造に従い、MiniAppを構成するすべてのリソースを 単一ファイル内に含みます。この形式は、圧縮機構の使用をサポートします。
MiniApp ZIPコンテナーは、[ZIP]で定義されるZIP形式を使用し、次のようないくつかの特性を含みます:
0、ファイル格納)およびDeflate圧縮(方式0、可逆データ
圧縮)の内容を含まなければなりません。
2.0
(フォルダーおよびDeflate圧縮をサポート)です。MiniApp ZIPコンテナーの構造は次のとおりです:
[ZIPファイルエントリー]
[MiniApp署名ブロック]
[ZIP中央ディレクトリー]
[ZIP中央ディレクトリー終端]
MiniApp ZIPコンテナーは、まずZIP中央ディレクトリーの開始位置を見つけることにより解析されます (ファイル末尾のZIP中央ディレクトリー終端レコードを特定し、その後、そのレコードから中央ディレクトリーの開始オフセットを読み取ります)。すべてのMiniApp署名ブロックは、デジタル署名の存在を識別するために、署名ブロックマジックナンバーブロックを、デジタル署名要件で指定されるように含んでもよい。 「マジックナンバー」ブロックが認識されると、ユーザーエージェントは、デジタル署名を処理できるようになります。署名は、 図 2に示すように、中央ディレクトリーの直前のセクションにある署名ブロックに保存されます。
MiniAppベンダーは、その必要に応じてデジタル署名スキームを採用してもよい。
MiniAppファイルは.maファイル拡張子によって識別されてもよいが、ファイル拡張子の使用は 必須ではありません。
MiniApp ZIPコンテナーは、ソフトウェアの保護された部分に対する変更の検出を助け、 MiniAppの完全性を保証するために、署名を含まない、1つ含む、または複数含んでもよい。
MiniApp署名ブロックは、 MiniAppの一部または全体に影響するデジタル署名に関する特定の情報およびメタデータを含むバイトの集合です。 署名ブロックは、MiniApp ZIPコンテナーにおいて、ブロックが存在する場合に見つけやすくするため、 ZIPコンテナーの中央ディレクトリーの直前に配置されなければなりません。
署名ブロックマジックナンバーブロックは、MiniAppパッケージのデジタル署名機構を識別する一意のフィンガープリントを持つ 16バイトのシーケンスであり、MiniApp ZIPコンテナーの署名ブロック内に保存されます。
この文書は特定のデジタル署名機構(すなわち、ハッシュアルゴリズム、暗号化方式など)を推奨しませんが、 署名ブロックが存在する場合、それは次の基準を満たさなければ なりません:
国際化(i18nと略される)は、任意の文化、地域、または言語のユーザーに 容易に適応できるようにする形で、製品を設計および開発するプロセスです。
ローカライゼーションは、対象言語または 文化的要件を満たすためにコンテンツを適応させるプロセスです。
MiniAppは、予約済みのi18nディレクトリーに配置されたローカライズ文書に基づく機構を使用して、
コンテンツのローカライゼーションを可能にします。この機構により、作成者は、language-range
[BCP47]および.json拡張子に従って命名された
ローカライゼーションリソースを配置できます。すなわち、
ローカライゼーションリソースを持つ文書は、コンテンツのロケールを表す言語タグ [BCP47]で
識別されます。MiniAppユーザーエージェントは、自身のロケールが持つ
言語範囲を適切なロケールファイル名に照合します。
ローカライゼーションリソースの形式は、ローカライゼーションリソースセクションで定義されます。
/
|___i18n/
| |___en-US.json
| |___fr-FR.json
| |___fr.json
| |___ja-JP.json
| |___zh-Hans.json
ユーザーエージェントは、MiniAppパッケージを参照解除、解析、および実行するために、 次のアルゴリズムに従わなければなりません。
URL miniapp_uriが与えられたとき、 MiniAppパッケージを処理するには、次の手順を実行します:
ユーザーエージェントは、さまざまなチャネルを通じてMiniApp ZIPコンテナーを取得してもよい。これには、 ネットワーク経由でのファイル取得(すなわち、HTTPs、WebSocket、FTP、またはその他の特定のTCP/UDPベースのプロトコルの使用)、 ファイルシステムからの取得、またはその他任意の機構の使用が含まれます。
URL miniapp_uriが与えられたとき、 MiniApp ZIPコンテナーを取得するには、次の手順を実行します。これらはMiniApp ZIPコンテナーを返します。
application/miniapp-pkg+zipに等しくない場合、失敗を返します。
ユーザーエージェントは、デジタル署名を検証し暗号機構を適用することにより、 MiniApp ZIPコンテナーおよびその内容の正当性と完全性を保証しても よい。
MiniApp ZIPコンテナー miniapp_zip_fileが与えられたとき、 MiniApp ZIPコンテナーを検証するには、次の手順を実行します:
MiniApp ZIPコンテナーは、1つ以上の署名を含む署名ブロックを含んでもよい。 署名スキームおよび暗号機構は、ユーザーエージェントによる具体的な実装に依存します。
署名スキームは、MiniApp ZIPコンテナーに含まれるマジックナンバーセクションによって識別されます。これは、 ZIPパッケージの中央ディレクトリーの直前に配置された16バイトのシーケンスです。
MiniApp ZIPコンテナー miniapp_zip_fileが与えられたとき、 デジタル署名を処理するには、次の手順を実行します:
0x06054b50(リトルエンディアンとして読み取る)のバイトシーケンスを特定した結果として得られる
バイトシーケンスとします
[ZIP]。
ユーザーエージェントは、MiniAppパッケージ内に配置され、MiniAppに関するグローバルメタデータを 含むMiniApp マニフェストを解析しなければなりません。
MiniAppパッケージ miniapp_packageが与えられたとき、MiniAppマニフェストを処理するには、次の手順を実行します。これらは順序付きマップを返します。
manifest.jsonファイルがパッケージのルートディレクトリーに存在しない場合、失敗を返します。manifest.jsonを渡してバイトからJSONを
解析する結果とします。ユーザーエージェントは、ロジック層とビュー層の両方を含むランタイム環境を
準備するべきです。ロジック層はアプリケーションのロジックおよび制御
(すなわち、app.jsおよびpage.jsファイル)を担います。ビュー
層は、コンポーネントテンプレートやスタイルシートなどのページリソースファイルを含む、視覚環境およびレンダリングを担います。
MiniAppを実行する準備として、ユーザーエージェントは、MiniApp
マニフェストメタデータで指定された構成により環境を設定しなければなりません。
ユーザーエージェントは、次のアルゴリズムに従い、MiniAppのエントリーポイントとして開始ページを識別して読み込まなければなりません。
URL miniapp_uriおよび 順序付きマップ manifestが与えられたとき、プラットフォームランタイムを準備するには、次の手順を実行します。これらはMiniApp開始ページを返します。
app.jsがルート
ディレクトリーに存在しない場合、失敗を返します。app.cssがルート
ディレクトリーに存在しない場合、失敗を返します。ユーザーエージェントは、MiniAppが自分たちと互換性があり、自分たちのプラットフォームで適切に実行できることを 検証しなければなりません。この検証は、MiniAppマニフェストで指定されたメタデータを使用して実行されます。これには、 プラットフォームのサポート対象バージョン、および実行に必要なページとリソースの確認が含まれます。
MiniAppパッケージ miniapp_packageおよび順序付きマップ manifestが与えられたとき、プラットフォーム互換性を検証するには、次の手順を実行します:
既定では、ユーザーエージェントは、MiniAppが起動されるときに、MiniAppマニフェストで示される開始ページをエントリーポイントとして読み込まなければ なりません。次のアルゴリズムで指定されるように、MiniApp URI内に有効なページが指定されている場合、この既定の開始ページは上書きされなければなりません。
MiniAppパッケージ miniapp_package、URL miniapp_uri、 および順序付きマップ manifestが与えられたとき、開始ページを決定するには、次の手順を実行します。これらはURLを返します。
MiniApp URIは、URIのURLパスセグメント文字列として指定される、開始ページに関する情報を含んでもよい。
URL miniapp_uriが与えられたとき、URIから開始ページを抽出するには、次の手順を実行します。これらはURLを返します。
MiniApp
Manifestのpagesメンバー [MINIAPP-MANIFEST]で説明されるように、
MiniAppの開始ページは、pagesリストの最初の項目で指定されます。
順序付きマップ manifestが与えられたとき、マニフェストから開始ページを抽出するには、次の手順を実行します。これらは文字列を返します。
順序付きマップ manifestが与えられたとき、ロケールを抽出するには、 次の手順を実行します。これらは文字列を返します。
このセクションは非規範的です。
この仕様は、MiniAppを論理的および物理的な観点から定義し、その内部ファイル構造と、さまざまなリソースがどのように単一ファイル内に パッケージ化されるかを詳述します。また、この文書には、MiniAppユーザーエージェントがMiniAppコンテナーを取得および処理するためのアルゴリズムも含まれます。
MiniApp Packaging仕様は、ユーザーエージェントがMiniAppコンテナーおよびその内容を処理し、内部
リソース(すなわち、HTML、スタイルシート、スクリプティングなど)および構成(すなわち、マニフェスト、
app.ux)に基づいて、ユーザーインターフェイスと具体的な動作を生成することを要求します。パッケージの取得および処理の後、
ユーザーエージェントは、あらゆる潜在的なシナリオにおいて、知覚可能で操作可能なユーザーインターフェイスおよび
レンダリングされたコンテンツを提供し、スタイルシートを用いてユーザーの要件に合わせて外観を適応できるようにし、
manifest.jsonの一部メンバーで要求されるように、表示オプションならびにウィンドウおよびビューポートの向きを
設定および制御できる可能性を提供することが推奨されます(MiniApp Manifest)。
この文書では指定されていませんが、ユーザーエージェントは、完全なキーボードアクセスを提供することや代替入力デバイスを サポートすること(可能な場合)、ユーザー体験を改善するためにユーザーが設定を保存できるようにすることなど、 ユーザーインタラクションにおけるアクセシビリティ面を保証することが推奨されます。MiniAppユーザーエージェントおよび プラットフォームは、アプリケーションのレンダリングおよびインタラクションのための機構を提供し、支援技術との統合を促進し、 適用可能な仕様および慣行、特にUser Agent Accessibility Guidelines (UAAG) 2.0に 準拠するべきです。
この仕様は、アプリのエントリーポイントおよび異なるルート(すなわち、マニフェストのpages
メンバー)を指定する具体的な構成を通じて、MiniAppをパッケージ化、配布、および読み込むための機構を定義します。ユーザーエージェントは、読み込まれるリソースの種類を制限し、既定で強力な機能へのアクセスをブロックする
サンドボックス化された環境を実装することにより、初期化および読み込みフェーズ中の潜在的な脆弱性を緩和するべき
です。
MiniAppユーザーエージェントは、画像、データソース、スクリプトなどの外部 リソースを取得および処理することにより、具体的にはXSS攻撃に対して脆弱です。したがって、ユーザーエージェントは、 潜在的な攻撃ベクターを調査および制限し、MiniAppが取得または実行できるリソースを制御するために Content Security Policy(CSP)を実装することにより、リスクを緩和するべき です。
MiniAppパッケージは、悪意のあるスクリプトを含め、任意の種類のリソースを 含んでもよい。したがって、MiniAppユーザーエージェントは、 処理されるリソースを厳密に制限し、マニフェストで宣言されておらずコンポーネントから適切に紐づけられていないものを 破棄することで、攻撃対象領域を最小化しなければなりません。したがって、ユーザーエージェントは、マニフェストで指定されたリソース(すなわち、画像および コンポーネントページ)ならびにコンテナー内に含まれる補完ファイル(すなわち、メディアファイル、スクリプト、スタイルシートなど)の 利用可能性を確認し、コンテナー内の残りの要素を破棄しなければなりません。また、ユーザーエージェントは、 サードパーティリソースの使用を可能にするAPIを実装する際の特有のリスクを考慮するべきです。
この文書は、情報を公開する特定の提示方法を要求しません。ただし、MiniAppパッケージには、対象ユーザーエージェントおよび必要な実行環境の一部特性を 記述し得る機能が含まれます。これには、オペレーティングシステムのバージョンおよび基盤となるハードウェア能力 (例: 利用可能なセンサー、デバイスの種類、表示の種類)が含まれます。MiniAppマニフェストで指定されるこれらの プラットフォーム要件は、マニフェスト処理フェーズ中にMiniApp初期化の実行を停止してもよく、アプリ要件との不整合を明らかにします。それでも、ユーザーエージェントは、攻撃対象領域を減らすために、この情報の公開を避けるべき です。
MiniApp Packagingは、基盤プラットフォームに関する情報にアクセスし公開するための特定の機構を指定しません。しかし、 MiniAppユーザーエージェントは、この情報 (例: プラットフォームバージョン、オペレーティングシステム、および利用可能なセンサー)にアクセスするサービス、および ハードウェアやオペレーティングシステムと通信するAPIを実装してもよい。したがって、ユーザーエージェントは、これらの影響を受けやすいサービスをサポートする際の潜在的な リスクを考慮し、強力な機能が意味のあるユーザーの 同意なしに有効化されないことを保証するため、既定で適切な緩和機構を実装するべきです。
MiniAppの配布段階における完全性および信頼性を確保するため、MiniAppパッケージは、1つ以上のデジタル署名によって保護されるべきです。これらの署名は、信頼された機関によって発行された証明書とともに、第三者がMiniAppの著作者 (例: MiniApp開発者)およびソフトウェアの開発または配布に関与するその他の主体(例: MiniApp配布者としてのアプリケーションストア)を 検証するのに役立ちます。
MiniAppにデジタル署名が含まれる一般的なシナリオには、次のものが含まれますが、これらに限定されません:
この仕様では、特定のデジタル署名機構、暗号技術、またはアルゴリズムは推奨されません。 MiniAppベンダーは、そのユースケースに応じてデジタル署名機構を実装してもよい。 実装する場合は、3.3 デジタル署名要件に従わなければなりません。
一部の技術および暗号化方式は、B. 署名スキームで紹介されています。
MiniAppは、以後のアプリ実行のためにユーザーエージェントのサンドボックス化された環境に永続化および保持され得る 個人識別情報を扱ってもよい。ユーザーエージェントは、その情報を保護し、同じアプリケーションのインスタンスのみが データにアクセスできるようにし、公開を避けなければなりません。したがって、 MiniAppユーザーエージェントは、収集されるデータの種類および収集目的について、 エンドユーザーに透明性をもって通知するべきです。
エンドユーザーは、任意のMiniAppインスタンスに対応してユーザーエージェントにより保存された情報を削除するかどうかを 決定しなければなりません。ユーザーエージェントは、保存されたデータを潜在的に機微なものとして扱い、 データ削除時に基盤ストレージから適切に削除されることを保証するべきです。さらに、ユーザーエージェントは、 長期間の非アクティブ後に保存データを自動的に削除するなど、機微情報の漏えいリスクを最小化し、ユーザーのプライバシーを 保護するための機構を実装するべきです。いずれの場合も、ユーザーエージェントは、実装されている具体的な プライバシーポリシーについて、ユーザーに透明性をもって通知するべきです。
セッションは、[MINIAPP-LIFECYCLE]で定義されるように、アプリが起動されたときに開始し、システムからアンロードされたときに終了します。この仕様は
セッション間のデータ永続化のための機構を記述しませんが、MiniAppは、後続のセッションで取得され得るデータをユーザーの
デバイス上に保存してもよい。このシナリオは、ユーザーの認識または制御なしにユーザー追跡が行われる
リスクをもたらします。したがって、MiniAppユーザーエージェントは、
MiniApp実行環境を分離するなど、クライアント側ストレージ機構がユーザーの制御なしに追跡に悪用されないことを保証する
保護を実装しなければなりません。この分離により、マニフェストのapp_idメンバーによって一意に識別される各MiniApp専用のストレージ領域が
可能となり、他のMiniAppからデータへのアクセスを制限します。
ユーザーエージェントは、システム上にアプリをインストールする可能性 (例: ホーム画面ショートカット、デスクトップ上のアイコンなど)を提供してもよい。 このプロセスは透明で可逆的であるべきです。エンドユーザーがアプリをアンインストールしたい場合、 ユーザーエージェントは、関連するすべてのデータが基盤ストレージから適切に削除されることを保証しなければ なりません。
この仕様は、MiniAppパッケージの機密性を保護するための 暗号化機構を推奨しません。ただし、特定の目的のために何らかの暗号化機構を実装することを妨げるものではありません。
このセクションは非規範的です。
このセクションは非規範的です。
すべてのユーザーエージェントは、その必要に応じて独自のデジタル署名スキームを サポートしてもよい。このセクションには、図 4に示すようなデジタル署名実装の例が含まれます。これらは、開発者検証や 配布中のMiniAppの完全性など、特定のシナリオで使用できます。
MiniAppの一実装として、Quick Appsは、MiniAppパッケージの著作者性を検証するため、APK Signature Scheme v2 [APK-SIGNATURE-V2]に類似した、いわゆるRPK (Runnable Package)署名スキームを使用します。この署名スキームは、署名生成においてMiniAppパッケージ内のすべてのバイトを 対象にします。結果として得られる署名ブロックは、 デジタル署名要件に従って作成され、パッケージファイルに挿入されます。
署名ブロックには、署名および署名者の身元に関する情報を持つID-値ペアが含まれます。
RPK署名ブロック内のすべてのデータ値は
リトルエンディアン形式で表され、すべての長さ接頭辞付きフィールドは長さにuint32を使用します。
説明では、次の基本データ型を使用します:
RPK署名ブロックの形式は次のとおりです:
RPK Sig Block 42”(16バイト)不明なIDを持つID-値ペアは、ブロックの解釈時に無視されます。
「ブロックサイズ」値により、ZIPファイル全体における署名ブロックの開始位置を特定できます。
署名は、署名の種類を表す特定の識別子を持つID-値ペアとして保存されます。RPK パッケージに対してサポートされる署名および関連IDは、次の小節で説明されます。
MiniAppパッケージが、ユーザーエージェントが段階的にダウンロードおよび実行してユーザー体験を改善できるよう、 配布プラットフォーム(例: アプリストア)によって複数のサブパッケージに分割される場合があります。そのような場合、 各サブパッケージおよび全体の完全性を保証するために、追加の署名型(したがってID)が必要になります。 詳細は今後の検討事項です。
ID 0x01000101の署名ブロック内のID-値ペアは、ファイル全体のMiniAppパッケージ署名のデータを表します。
IDペアの値にはすべての署名ブロックが含まれ、可変長であり、その構造は次のとおりです:
0x01000101(uint32)配布者の署名は、配布プロセス中のアプリケーションの完全性を保持し、パッケージが信頼された配布者によって検証され、 配布者からの権限制御ポリシー(プロビジョニングプロファイルの形式)が パッケージに対して適用されることを保証します。
配布者署名のプロセス中に、配布者または開発者のいずれかがプロビジョニングプロファイルを追加し、配布者の秘密鍵を使用して 署名します。
プロビジョニングプロファイルは、ID 0x02000201の
署名ブロック内のID-値ペアに保存されます。
IDペアの値にはすべての署名ブロックが含まれ、可変長であり、その構造は次のとおりです:
0x02000201(uint32)0x0101 SHA2-256ダイジェスト、SHA2-256 MGF1、32バイトの
ソルト、トレーラー: 0xbcを使用するRSASSA-PSS0x0102 SHA2-512ダイジェスト、SHA2-512 MGF1、64バイトの
ソルト、トレーラー: 0xbcを使用するRSASSA-PSS0x0103 SHA2-256ダイジェストを使用するRSASSA-PKCS1-v1_5。これは決定的署名を必要とする
ビルドシステム用です。0x0104 SHA2-512ダイジェストを使用するRSASSA-PKCS1-v1_5。これは決定的署名を必要とする
ビルドシステム用です。0x0201 SHA2-256ダイジェストを使用するECDSA0x0202 SHA2-512ダイジェストを使用するECDSA0x0301 SHA2-256ダイジェストを使用するDSA0x01 証明書ダイジェスト
0x02 証明書
0x03 用途:
0x010x020x030x04 マニフェスト
0x05 デバイスID
この署名スキームは、PKCS #7 Cryptographic Message Syntax [rfc2315]に基づいています。これは、 開発者署名および配布者署名を含む、RPK署名スキームで説明されるパッケージ化署名の異なる段階を対象としても よい。
この署名スキームは、MiniAppのプロビジョニングプロファイルおよび 第1段階(開発者署名段階)における開発者署名を含みます。第2段階(配布者署名段階)では、配布者は 開発者署名を自身の署名に置き換えてもよい。RPK署名スキームと同様に、 このアプローチは、デジタル署名要件に従ってパッケージファイルに含められる 署名ブロックを生成します。
PKCS#7署名ブロックは、デジタル署名を持つブロック、ならびに署名および署名者の身元を含むPKCS #7構文を使用して 暗号化されたデータを含むデータコンテナーとして定義されます。
説明では、次の基本データ型を使用します:
PKCS#7署名ブロックの形式は次のとおりです:
MIX Sig Block 42”(16バイト)SignedDataに設定:
MIX Sig Block 42”(16バイト)Block Headの型は、その属性
typeによって識別されます。この属性は、2つの異なる値を取らなければ
なりません:
0: ファイル署名ブロック1: プロビジョニングプロファイル
ブロックtypeの値が0(ファイル署名ブロック)に設定されている場合、ヘッダーは、そのBlock
Head内の
属性tagを使用して、より狭いサブタイプを指定しなければなりません。このサブタイプの値は次のとおりです:
0: 既定1: HASH(ファイル全体のハッシュ)0x80: 1M_HASH_ROOT(1Mブロックハッシュツリー、ルートハッシュ)0x81: 512K_HASH_ROOT(512Kブロックハッシュツリー、ルートハッシュ)0x82: 256K_HASH_ROOT(256Kブロックハッシュツリー、ルートハッシュ)0x83: 128K_HASH_ROOT(128Kブロックハッシュツリー、ルートハッシュ)0x84: 64K_HASH_ROOT(64Kブロックハッシュツリー、ルートハッシュ)0x85: 32K_HASH_ROOT(32Kブロックハッシュツリー、ルートハッシュ)0x86: 16K_HASH_ROOT(16Kブロックハッシュツリー、ルートハッシュ)0x87: 8K_HASH_ROOT(8Kブロックハッシュツリー、ルートハッシュ)0x88: 4K_HASH_ROOT(4Kブロックハッシュツリー、ルートハッシュ)0x90: 1M_HASH_BLOCK(1Mブロックハッシュツリー)0x91: 512K_HASH_BLOCK(512Kブロックハッシュツリー)0x92: 256K_HASH_BLOCK(256Kブロックハッシュツリー)0x93: 128K_HASH_BLOCK(128Kブロックハッシュツリー)0x94: 64K_HASH_BLOCK(64Kブロックハッシュツリー)0x95: 32K_HASH_BLOCK(32Kブロックハッシュツリー)0x96: 16K_HASH_BLOCK(16Kブロックハッシュツリー)0x97: 8K_HASH_BLOCK(8Kブロックハッシュツリー)0x98: 4K_HASH_BLOCK(4Kブロックハッシュツリー)この付録は、BCP 13 [RFC4289]および
W3C仕様のための
インターネットメディア型の登録に適合して、MiniAppパッケージ用のapplication/miniapp-pkg+zipメディア型を登録します。
MiniAppパッケージファイルは、いくつかの変更を含む[ZIP]アーカイブ形式に基づくコンテナー技術です。
applicationminiapp-pkg+zip.maで識別されます。
初期実装のための暫定的な解決策として、application/x-w3c-miniapp-pkg+zipが考えられます。
プロセッサーはパッケージの完全性を確認するべきか(セキュリティに関する考慮事項セクション)?
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: