MiniApp パッケージング

W3C 作業草案

この文書の詳細
このバージョン:
https://www.w3.org/TR/2025/WD-miniapp-packaging-20250128/
最新公開バージョン:
https://www.w3.org/TR/miniapp-packaging/
最新の編集者草案:
https://w3c.github.io/miniapp-packaging/
履歴:
https://www.w3.org/standards/history/miniapp-packaging/
コミット履歴
編集者:
Martin Alvarez-Espinar (Huawei)
Qing An (Alibaba)
Tengyuan Zhang (Baidu, Inc)
Yongjing Zhang (Huawei)
Dan Zhou (Baidu, Inc)
以前の編集者:
Shouren Lan (Huawei)
Zhiqiang Yu (Huawei)
Qian Liu (Baidu, Inc)
Shuo Wang (Baidu, Inc)
フィードバック:
GitHub w3c/miniapp-packaging (プルリクエスト, 新しい課題, 未解決の課題)

概要

この仕様は、MiniAppパッケージの意味論および適合要件、ならびに マニフェストファイル、静的ページテンプレート、スタイルシート、JavaScript文書、メディアファイルおよびその他のリソースを含む、MiniAppのリソースを保持する単一ファイルコンテナーの 構造を定義します。MiniAppパッケージのインスタンスは、MiniAppの配布および ランタイム環境(MiniAppユーザーエージェント)での実行に使用されます。

この文書のステータス

このセクションは、公開時点におけるこの 文書のステータスを説明します。現在のW3C 公開物の一覧およびこの技術レポートの最新版は、 https://www.w3.org/TR/ にある W3C 技術 レポート索引で確認できます。

この文書は、MiniAppsワーキング グループにより、 勧告トラックを使用して 作業草案として公開されました。

作業草案としての公開は、 W3Cおよびそのメンバーによる承認を意味するものではありません。

これは草案文書であり、いつでも他の文書により更新、置換、または廃止される可能性があります。 この文書を、進行中の作業以外のものとして引用することは不適切です。

この文書は、 W3C 特許 ポリシーの下で活動するグループにより作成されました。 W3Cは、 そのグループの成果物に関連して行われた特許開示の 公開リストを維持しています。 そのページには、特許を開示するための 手順も含まれています。個人が、当該個人が 必須クレーム を含むと考える特許について実際の知識を有する場合、 その情報は、W3C特許ポリシー第6節に従って開示しなければなりません。

この文書は、 2023年11月03日のW3Cプロセス文書により管理されます。

1. 導入

1.1 概要

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を起動します。

1.2 用語

以下の用語はMiniAppに固有のものです。

デジタル署名
リソースの真正性を証明するための暗号機構およびハッシュ技術。デジタル署名は、リソースおよびMiniAppパッケージの出所、時刻、 身元、および状態を示すことができます。
MiniApp
任意のデジタル手段で配布でき、Webを通じてアクセスできる軽量ソフトウェアアプリケーション。MiniAppは具体的なファイル構造により定義され、 MiniApp ZIPコンテナーという単一ファイル内に配布されます。このコンテナーは、MiniAppパッケージ全体を表し、MiniAppユーザーエージェントによって処理および実行できます。
MiniAppパッケージ
MiniApp ZIPコンテナー内にパッケージ化された一連のリソースで構成される論理文書実体。
MiniApp リソース
MiniAppのビューまたはロジックの一部である論理文書。リソースは物理的にMiniAppパッケージに含まれます。
MiniAppページ
特定のMiniAppのスコープ内で、MiniAppユーザーエージェントに 表示される情報の集合。
MiniAppユーザーエージェント
MiniAppパッケージを取得、処理、レンダリングし、 MiniAppの実行およびエンドユーザーとのインタラクションを可能にするソフトウェアアプリケーション。
MiniApp ZIPコンテナー
MiniApp ZIPコンテナーセクションで定義される、MiniAppのZIPベースのパッケージ化および配布形式。
MiniAppウィジェット
MiniAppページの特殊な型であり、アシスタントやデバイス検索ページなどのホスト環境で スタンドアロン表示され、特定のシナリオにおいてMiniAppサービスを接続します。
MiniApp開始ページ
MiniAppのエントリーポイント。アプリケーション起動時にMiniAppユーザーエージェントによって読み込まれ、レンダリングされるリソース。

1.3 適合性

非規範的と明示されたセクションに加え、この仕様におけるすべての作成ガイドライン、図、例、および注記は 非規範的です。この仕様のそれ以外のすべては規範的です。

この文書におけるキーワードMAYMUSTMUST NOTSHALLSHOULD、およびSHOULD NOTは、 ここに示すようにすべて大文字で現れる場合に限り、 BCP 14 [RFC2119] [RFC8174] に記述されているとおりに解釈されます。

MiniApp Packaging仕様は、アルゴリズムを記述するためにInfra Standard [INFRA]に依存します。

2. パッケージの適合性

適合するMiniAppパッケージは、次の 基準を満たさなければなりません:

2.1 ディレクトリーおよびファイルシステム 構造

MiniAppパッケージは、いくつかの制限ならびに予約済みファイルおよびサブディレクトリーを伴うファイル構造を持ちます。

次の例は、典型的なファイルシステム構造を示します:

1: ファイルシステム構造
/
|___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

2.1.1 ルートディレクトリー

MiniAppルートディレクトリーは、MiniAppパッケージファイルシステムの基底 ディレクトリーです。

ルートディレクトリーは、MiniAppパッケージのものであり、 MiniAppのライフサイクル管理に関するグローバルデータおよび情報を含む複数の予約済みファイルを保持します。これには次のものが含まれます:

manifest.json
MiniAppマニフェストは、MiniAppのグローバル構成を担うJSON文書です。マニフェストファイルには、 MiniApp Manifest仕様 [MINIAPP-MANIFEST]に従って、ページのルートおよびパス、 MiniAppのウィンドウ構成(例: ナビゲーションバーのスタイル、背景画像、 背景色、ページタイトルなど)を含むMiniAppの設定を示す必須および任意の 属性の集合が含まれます。
app.css
このファイルはアプリケーションのメインスタイルシートであり、開発者がMiniApp内のページの共通スタイルおよび ルックアンドフィールの側面を定義する場所です。これは空であってもよい
app.js
このスクリプト文書にはMiniAppの基本サービスロジックがあり、MiniApp Lifecycle [MINIAPP-LIFECYCLE]における、MiniAppの起動、表示、非表示のための イベント管理を含む、MiniAppライフサイクルの基本的な構成および制御が含まれます。

2.1.2 pagesディレクトリー

pagesディレクトリーには、MiniAppページの表示およびユーザーインタラクションのための一連のファイルが含まれます。

MiniAppページは、一意のファイル名 (例: intro)およびリソース型を定義する特定の拡張子によって識別される、一連のリソースによって定義されます。たとえば、アプリケーションのビジネスロジック (例: intro.js)、構造およびコンテンツ(例: intro.html)、および スコープ付きスタイルシート(例: intro.css)です。

開発者は、必要に応じて他の型のリソースを含めても よい。また、ページに関連するファイル(同じファイル名で識別される)は、各ページ用の特定のサブディレクトリーに整理しても、 pagesディレクトリー直下に保存してもよい

2: pages ディレクトリー直下のページリソース
/
|___manifest.json
|___app.js
|___app.css
|___pages/
        |___detail.js
        |___detail.html
        |___detail.css
        |___list.js
        |___list.html
        |___list.css
3: サブディレクトリー内に整理されたページリソース
/
|___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ページの設定およびライフサイクル管理を担います。 これらの型のファイルの構文および形式はスクリプティングリソースセクションで定義されます。

2.1.3 commonディレクトリー

任意のcommonディレクトリーには、MiniApp内のページからアクセス可能な、コンポーネント、マルチメディアリソース、文書、ライブラリーなどのリソースが含まれます。このディレクトリーの内部構造は 柔軟であるため、これらの共通リソースは必要に応じてカスタマイズされた サブディレクトリー内に、また異なる命名規則を用いて整理してもよい

2.1.4 i18nディレクトリー

任意のi18nディレクトリーは、ルートディレクトリー内の サブディレクトリーであり、MiniAppパッケージローカライゼーションリソースを含みます。

i18nディレクトリーには、MiniAppコンテンツの 国際化をサポートするための多言語ローカライゼーションリソースが含まれます。このディレクトリー内の各.json文書のファイル名は、 [BCP47]で定義されるLanguage-Tag表記に従い、 その特定の言語に対する具体的な構成を表します。

i18nディレクトリーは、MiniAppがサポートする言語またはロケールの数に応じて、 任意の数のローカライゼーションリソースを含んでもよい。これらのファイルの形式は、 ローカライゼーションリソースセクションで定義されます。

2.1.5 ファイル名およびパス名

MiniAppパッケージ内のすべてのファイル名およびパス名は、オペレーティングシステムの潜在的な 制限に対応し、プラットフォームおよびファイルシステムの大多数との相互運用性を促進するために、仕様開発者のための国際化ベストプラクティスで指定される 次の制限に従わなければなりません

  • ファイル名およびファイルパスは大文字と小文字を区別します。
  • ファイル名およびファイルパスはUTF-8 [Unicode]で符号化されなければなりません
  • ファイル名は長さが255バイトを超えるべきではありません
  • パス名は長さが65535バイトを超えるべきではありません
  • ファイル名およびパス名は、次の[Unicode]ポイントを使用してはなりません:
    • " [U+0022 QUOTATION MARK]
    • * [U+002A ASTERISK]
    • / [U+002F SOLIDUS]
    • : [U+003A COLON]
    • < [U+003C LESS-THAN SIGN]
    • > [U+003E GREATER-THAN SIGN]
    • \ [U+005C REVERSE SOLIDUS]
    • | [U+007C VERTICAL LINE]
    • U+007F DEL
    • U+E0001 LANGUAGE TAG
    • U+E007F CANCEL TAG
    • 次の範囲のコードポイント:
      • C0 Controls [U+0000...U+001F]
      • C1 Controls [U+0080...U+009F]
      • Private Use [U+E000...U+F8FF]
      • Specials [U+FFF0...U+FFFF]
      • Supplementary Private Use [U+F0000...U+FFFFF]
      • Supplementary Private Use [U+100000...U+10FFFF]
    • . [U+002E FULL STOP]
    • すべてのUnicode非文字コードポイント、具体的には:
      • 基本多言語面内の32個の連続する文字(U+FDD0 … U+FDEF)
      • 基本多言語面の最後の2つのコードポイント(U+FFFEおよびU+FFFF)
      • 補助面の末尾にある最後の2つのコードポイント(U+1FFFE、 U+1FFFF … U+EFFFE、U+EFFFF)

同じディレクトリー内のすべてのファイル名は、Unicode正準正規化 [UAX15]の後に完全ケース フォールディング [Unicode]を行った結果として一意でなければなりません。(詳細については、 Unicode正準ケース フォールド正規化ステップ [CHARMOD-NORM]を参照してください。)

注記: ファイル名の長さの制限
MiniAppベンダーがパス名およびファイル名に長さ制限を課す場合、UTF-8のようなマルチバイト 符号化ではバイトと文字の違いがあるため、文字の途中で切り詰められることを避けることが重要です。詳細については、 テキスト切り詰めのベスト プラクティスを参照してください。

2.2 MiniAppリソース

MiniAppページは、少なくともHTMLリソースから構成され、任意でCSSリソースおよび/またはスクリプティングリソースを 含みます。これらの関連リソースは、MiniAppページを、ページルートを通じて識別するために、 同じパスおよびファイル名(ファイル拡張子のみを変更)を持たなければなりません。このページルートは、MiniApp マニフェスト [MINIAPP-MANIFEST]のpagesメンバーで指定される必要があります。

4: ページルート「pages/product/product」に対応する ページリソースの構成
/
|___pages/
        |___product/
                |___product.html
                |___product.css
                |___product.js

2.2.1 HTMLリソース

HTML リソースは、MiniAppページおよびそのユーザーインターフェイスを定義するためのマークアップおよび情報を含む文書であり、 構造、視覚コンポーネント、およびインタラクション要素を含みます。

HTMLリソースは、次のすべての基準を満たさなければなりません:

構文および内容
HTMLリソースは、 [HTML]で定義されるHTML構文を使用しなければ なりません
ファイル名
HTMLリソースは、単一のMiniAppページを識別し、存在する場合はそのページに対応するCSSリソースおよびスクリプティング リソースと一致する、一意のファイル名を持つべきです
ファイル拡張子
HTMLリソースは、 ファイル拡張子.htmlを使用するべきです
編集者 注記
MiniAppコンテンツ文書のHTMLプロファイルを定義すること。

2.2.2 CSSリソース

CSS リソースは、MiniAppページのレンダリングおよび外観を記述するスタイルシートです。CSSリソースは、MiniApp内のすべてのページに影響するグローバルなもの (すなわち、ルート ディレクトリー内のapp.css)であっても、MiniApp内の特定のページのみに影響するローカルスコープのものであってもよいです。

この仕様は、[CSS-SNAPSHOT]で定義されるCSSモジュールをサポートします。

CSSリソースは、次のすべての基準を満たさなければなりません:

構文および内容
CSSリソースは、 [CSS-SNAPSHOT]で記述されるCSSの構文および定義を用いて記述されたものに従わなければ なりません
ファイル名
MiniApp内のすべてのページに影響するグローバルCSSリソースは、app.cssという名前で、ルート ディレクトリーに保存されなければなりません
ページに関連付けられたローカルCSSリソースは、MiniAppページを識別し、存在する場合は対応するHTMLリソースおよびスクリプティング リソースと一致する、一意のファイル名を持つべきです
ファイル拡張子
CSSリソースのファイル名は、 ファイル拡張子.cssを使用するべきです

2.2.3 スクリプティングリソース

スクリプティングリソースは、アプリケーションのビジネスロジックおよび機能を制御し、 インタラクティビティを追加し、MiniAppのライフサイクルを管理するためのスクリプト要素および データを含む文書です。グローバルなスクリプティング リソース(すなわち、ルート ディレクトリー内のapp.js)があり、MiniAppのすべてのページで利用可能なデータおよび関数、ならびに アプリケーションのライフサイクルを制御する固有のロジックを含みます。各MiniAppページは、具体的なページにスコープが限定された、関連する固有のスクリプティングリソースを持っても よい

スクリプティングリソースは、次のすべての基準を満たさなければなりません:

構文および内容
スクリプティングリソースは、ECMAScript仕様 [ECMA-262]の要件に適合しなければ なりません
グローバルスクリプティングリソースは、app.jsという名前で、ルート ディレクトリーに保存されなければなりません
ページに関連付けられたローカルスクリプティングリソースは、MiniAppページを識別し、存在する場合は対応するHTMLリソースおよびCSS リソースと一致する、一意のファイル名を持つべきです
ファイル拡張子
スクリプティングリソースのファイル名は、ファイル拡張子.jsを使用するべき です

2.2.4 ローカライゼーションリソース

MiniAppローカライゼーションリソースは、MiniAppの国際化機構の一部としてローカライズされたコンテンツを含む、MiniAppパッケージの文書です。

多言語MiniAppは、システムロケールまたはユーザーの言語設定に従ってコンテンツをレンダリングするために、ユーザーエージェントによるローカライゼーションプロセス中に使用される複数のローカライゼーションリソースを持っても よい。これらのリソースには、ローカライズ可能な用語または表現の一意の識別子(キー)と、 具体的な言語での表現(値)を含むキー値ペアのJSONオブジェクトが含まれます。

5: ローカライゼーションリソース
{
    "title": "Cool MiniApp",
    "about": "About this MiniApp",
    "intro-page": {
        "title" : "Introduction",
        "main" : "This is the body of the page"
    }
}

ローカライゼーションリソースは、次のすべての基準を満たさなければ なりません:

ファイル拡張子
ローカライゼーションリソースのファイル名は、 ファイル拡張子.jsonを使用するべきです
形式
ローカライゼーションリソースは、有効なJSON文書 [JSON]でなければ なりません
構造
ローカライゼーションリソースは、 キー値ペアで構成されなければなりません。各キーは、ローカライズ可能な各文字列(値)の一意の識別子を表します。

3. MiniApp ZIPコンテナー

3.1 導入

このセクションは非規範的です。

MiniApp ZIPコンテナーは、MiniAppの物理的な単一ファイル表現であり、 次のようなさまざまなシナリオで配布に使用できます:

MiniApp ZIPコンテナーは、MiniAppパッケージ構造に従い、MiniAppを構成するすべてのリソースを 単一ファイル内に含みます。この形式は、圧縮機構の使用をサポートします。

3.2 ZIPファイル要件

MiniApp ZIPコンテナーは、[ZIP]で定義されるZIP形式を使用し、次のようないくつかの特性を含みます:

MiniApp ZIPコンテナーの構造は次のとおりです:

[ZIPファイルエントリー]
[MiniApp署名ブロック]    
[ZIP中央ディレクトリー]
[ZIP中央ディレクトリー終端]
標準ZIPパッケージと、中央に署名ブロックを持つMiniAppパッケージの構造
1 ZIPパッケージおよび任意の署名ブロックを持つMiniAppパッケージ

MiniApp ZIPコンテナーは、まずZIP中央ディレクトリーの開始位置を見つけることにより解析されます (ファイル末尾のZIP中央ディレクトリー終端レコードを特定し、その後、そのレコードから中央ディレクトリーの開始オフセットを読み取ります)。すべてのMiniApp署名ブロックは、デジタル署名の存在を識別するために、署名ブロックマジックナンバーブロックを、デジタル署名要件で指定されるように含んでもよい。 「マジックナンバー」ブロックが認識されると、ユーザーエージェントは、デジタル署名を処理できるようになります。署名は、 2に示すように、中央ディレクトリーの直前のセクションにある署名ブロックに保存されます。

標準ZIPパッケージと、中央に署名ブロックを持ち、パッケージの各ブロックへの参照を伴うMiniAppパッケージの構造
2 相対オフセットアドレス指定を使用した、各ブロックへの参照を伴うZIPおよびMiniAppパッケージ

MiniAppベンダーは、その必要に応じてデジタル署名スキームを採用してもよい

編集者 注記: 拡張子を追加すること

MiniAppファイルは.maファイル拡張子によって識別されてもよいが、ファイル拡張子の使用は 必須ではありません。

3.3 デジタル署名要件

MiniApp ZIPコンテナーは、ソフトウェアの保護された部分に対する変更の検出を助け、 MiniAppの完全性を保証するために、署名を含まない、1つ含む、または複数含んでもよい

MiniApp署名ブロックは、 MiniAppの一部または全体に影響するデジタル署名に関する特定の情報およびメタデータを含むバイトの集合です。 署名ブロックは、MiniApp ZIPコンテナーにおいて、ブロックが存在する場合に見つけやすくするため、 ZIPコンテナーの中央ディレクトリーの直前に配置されなければなりません

署名ブロックマジックナンバーブロックは、MiniAppパッケージのデジタル署名機構を識別する一意のフィンガープリントを持つ 16バイトのシーケンスであり、MiniApp ZIPコンテナーの署名ブロック内に保存されます。

この文書は特定のデジタル署名機構(すなわち、ハッシュアルゴリズム、暗号化方式など)を推奨しませんが、 署名ブロックが存在する場合、それは次の基準を満たさなければ なりません:

署名ブロックマジックナンバー
署名ブロックは、含まれるデジタル署名の型を一意に識別するため、 中央ディレクトリーの直前のブロックとして署名ブロックマジックナンバーを含まなければ なりません

4. 国際化

国際化i18nと略される)は、任意の文化、地域、または言語のユーザーに 容易に適応できるようにする形で、製品を設計および開発するプロセスです。

ローカライゼーションは、対象言語または 文化的要件を満たすためにコンテンツを適応させるプロセスです。

MiniAppは、予約済みのi18nディレクトリーに配置されたローカライズ文書に基づく機構を使用して、 コンテンツのローカライゼーションを可能にします。この機構により、作成者は、language-range [BCP47]および.json拡張子に従って命名された ローカライゼーションリソースを配置できます。すなわち、 ローカライゼーションリソースを持つ文書は、コンテンツのロケールを表す言語タグ [BCP47]で 識別されます。MiniAppユーザーエージェントは、自身のロケールが持つ 言語範囲を適切なロケールファイル名に照合します。

ローカライゼーションリソースの形式は、ローカライゼーションリソースセクションで定義されます。

6: i18n ディレクトリー内の言語タグに基づくファイル名
/
|___i18n/
|     |___en-US.json
|     |___fr-FR.json
|     |___fr.json            
|     |___ja-JP.json
|     |___zh-Hans.json

5. MiniAppパッケージ処理

ユーザーエージェントは、MiniAppパッケージを参照解除、解析、および実行するために、 次のアルゴリズムに従わなければなりません

URL miniapp_uriが与えられたとき、 MiniAppパッケージを処理するには、次の手順を実行します:

  1. miniapp_zip_fileを、 miniapp_uriを用いてMiniApp ZIPコンテナーを取得する結果とします。
  2. miniapp_zip_fileを用いてMiniApp ZIPコンテナーを検証する
  3. miniapp_packageを、miniapp_zip_fileを展開した結果とします。
  4. miniapp_packageが展開例外である場合、失敗を返します。
  5. 順序付きマップ manifestを、miniapp_packageを用いてMiniAppマニフェストを処理する結果とします。
  6. start_pageを、miniapp_uriおよびmanifestを用いてプラットフォームランタイムを準備する結果とします。
  7. 文字列 localeを、manifestを渡してロケールを抽出する結果とします。
  8. miniapp_packagemanifeststart_page、および localeを渡してMiniAppを起動します。

5.1 MiniApp ZIPコンテナー 取得

ユーザーエージェントは、さまざまなチャネルを通じてMiniApp ZIPコンテナーを取得してもよい。これには、 ネットワーク経由でのファイル取得(すなわち、HTTPs、WebSocket、FTP、またはその他の特定のTCP/UDPベースのプロトコルの使用)、 ファイルシステムからの取得、またはその他任意の機構の使用が含まれます。

URL miniapp_uriが与えられたとき、 MiniApp ZIPコンテナーを取得するには、次の手順を実行します。これらはMiniApp ZIPコンテナーを返します。

  1. resourceを、miniapp_uriを渡して URLをfetchする [FETCH]結果として得られるMiniApp ZIP コンテナーとします。
  2. supplied_mime_typeを、resource提供されたMIME 型検出アルゴリズム [MIMESNIFF]を適用した結果とします。
  3. supplied_mime_typeapplication/miniapp-pkg+zipに等しくない場合、失敗を返します。
  4. resourceを返します。

5.2 MiniApp ZIPコンテナー 検証

ユーザーエージェントは、デジタル署名を検証し暗号機構を適用することにより、 MiniApp ZIPコンテナーおよびその内容の正当性と完全性を保証しても よい

MiniApp ZIPコンテナー miniapp_zip_fileが与えられたとき、 MiniApp ZIPコンテナーを検証するには、次の手順を実行します:

  1. ユーザーエージェントminiapp_zip_fileの デジタル署名検証を実行する能力を持つ場合:
    miniapp_zip_fileを用いてデジタル 署名を処理する

5.2.1 デジタル署名 処理

MiniApp ZIPコンテナーは、1つ以上の署名を含む署名ブロックを含んでもよい。 署名スキームおよび暗号機構は、ユーザーエージェントによる具体的な実装に依存します。

署名スキームは、MiniApp ZIPコンテナーに含まれるマジックナンバーセクションによって識別されます。これは、 ZIPパッケージの中央ディレクトリーの直前に配置された16バイトのシーケンスです。

MiniApp ZIPコンテナー miniapp_zip_fileが与えられたとき、 デジタル署名を処理するには、次の手順を実行します:

  1. magic_numbersバイトシーケンスとします。
  2. eocd_pointerを、miniapp_zip_file内で中央ディレクトリー終端を示す 0x06054b50(リトルエンディアンとして読み取る)のバイトシーケンスを特定した結果として得られる バイトシーケンスとします [ZIP]。
  3. eocd_pointereocd_pointer + 0x00000010に設定します。
  4. cd_pointerを、eocd_pointerにある 4バイトシーケンスを読み取った結果とします。
  5. magic_numbers_pointereocd_pointer - 0x00000010とします。
  6. magic_numbersを、magic_numbers_pointerにある16バイトブロックに設定します。
  7. magic_numbersおよびminiapp_zip_fileを用いてデジタル署名を処理します。
注記: 使用法
MiniAppユーザーエージェントは、その必要および要件に基づいて、 固有のデジタル署名処理アルゴリズムを実装します。

5.3 MiniAppマニフェスト処理

ユーザーエージェントは、MiniAppパッケージ内に配置され、MiniAppに関するグローバルメタデータを 含むMiniApp マニフェストを解析しなければなりません

MiniAppパッケージ miniapp_packageが与えられたとき、MiniAppマニフェストを処理するには、次の手順を実行します。これらは順序付きマップを返します。

  1. manifest.jsonファイルがパッケージのルートディレクトリーに存在しない場合、失敗を返します。
  2. manifest_jsonを、manifest.jsonを渡してバイトからJSONを 解析する結果とします。
  3. manifest_jsonが解析例外である場合、またはmanifest_json順序付きマップでない場合、失敗を返します。
  4. manifest順序付きマップとします。
  5. manifest_jsonおよびmanifestを渡して、MiniAppマニフェストを処理する
  6. manifestを返します。

5.4 プラットフォームランタイムの準備

ユーザーエージェントは、ロジック層とビュー層の両方を含むランタイム環境を 準備するべきです。ロジック層はアプリケーションのロジックおよび制御 (すなわち、app.jsおよびpage.jsファイル)を担います。ビュー 層は、コンポーネントテンプレートやスタイルシートなどのページリソースファイルを含む、視覚環境およびレンダリングを担います。 MiniAppを実行する準備として、ユーザーエージェントは、MiniApp マニフェストメタデータで指定された構成により環境を設定しなければなりません

ユーザーエージェントは、次のアルゴリズムに従い、MiniAppのエントリーポイントとして開始ページを識別して読み込まなければなりません

URL miniapp_uriおよび 順序付きマップ manifestが与えられたとき、プラットフォームランタイムを準備するには、次の手順を実行します。これらはMiniApp開始ページを返します。

  1. app.jsルート ディレクトリーに存在しない場合、失敗を返します。
  2. app.cssルート ディレクトリーに存在しない場合、失敗を返します。
  3. miniapp_packageおよびmanifestを渡して、プラットフォーム互換性を検証する
  4. start_pageを、miniapp_packageminiapp_uriおよびmanifestを渡して開始ページを決定する結果とします。
  5. miniapp_uriを返します。

5.4.1 プラットフォーム 互換性の検証

ユーザーエージェントは、MiniAppが自分たちと互換性があり、自分たちのプラットフォームで適切に実行できることを 検証しなければなりません。この検証は、MiniAppマニフェストで指定されたメタデータを使用して実行されます。これには、 プラットフォームのサポート対象バージョン、および実行に必要なページとリソースの確認が含まれます。

MiniAppパッケージ miniapp_packageおよび順序付きマップ manifestが与えられたとき、プラットフォーム互換性を検証するには、次の手順を実行します:

  1. platform_requiredmanifest["platform_version"]に設定します。
  2. platform_requiredユーザーエージェント構成と互換性がない場合、失敗を返します。
  3. それぞれについてリスト manifest["pages"]のpage:
    1. pageminiapp_package内に存在しない場合、失敗を返します。
  4. manifest["widgets"]が存在する場合:
    それぞれについてリスト manifest["widgets"]のwidget_path:
    1. widget_pathminiapp_package内に存在しない場合、失敗を返します。

5.4.2 開始ページの識別

既定では、ユーザーエージェントは、MiniAppが起動されるときに、MiniAppマニフェストで示される開始ページをエントリーポイントとして読み込まなければ なりません。次のアルゴリズムで指定されるように、MiniApp URI内に有効なページが指定されている場合、この既定の開始ページは上書きされなければなりません

MiniAppパッケージ miniapp_packageURL miniapp_uri、 および順序付きマップ manifestが与えられたとき、開始ページを決定するには、次の手順を実行します。これらはURLを返します。

  1. start_pageを、miniapp_uriを渡してURIから開始ページを抽出する結果とします。
  2. start_pageが設定されていない場合、またはstart_page がnullに等しい場合、またはstart_pageminiapp_package内に存在しない場合:
    start_pageを、manifestを渡してマニフェストから開始ページを抽出する結果に設定します。
  3. start_pageを返します
5.4.2.1 URIからの 開始ページの抽出

MiniApp URIは、URIのURLパスセグメント文字列として指定される、開始ページに関する情報を含んでもよい

URL miniapp_uriが与えられたとき、URIから開始ページを抽出するには、次の手順を実行します。これらはURLを返します。

  1. start_pageを、miniapp_uri解析した結果として得られるURLパスセグメント文字列とします。
  2. start_pageが失敗である場合、nullを返します。
  3. start_pageを返します。
5.4.2.2 マニフェストからの開始ページの抽出

MiniApp Manifestのpagesメンバー [MINIAPP-MANIFEST]で説明されるように、 MiniAppの開始ページは、pagesリストの最初の項目で指定されます。

順序付きマップ manifestが与えられたとき、マニフェストから開始ページを抽出するには、次の手順を実行します。これらは文字列を返します。

  1. start_page_idを空の文字列とします。
  2. リスト pagesmanifest["pages"]とします。
  3. pages[0]を返します。

5.4.3 ロケールの抽出

順序付きマップ manifestが与えられたとき、ロケールを抽出するには、 次の手順を実行します。これらは文字列を返します。

  1. 文字列 localeを、ユーザーエージェントの 既定ロケールとします。
  2. manifest["lang"]が存在する場合、かつmanifest["lang"]がユーザーエージェントによってサポートされている場合:
    localemanifest["lang"]に設定します。
  3. localeを返します。

6. アクセシビリティに関する考慮事項

このセクションは非規範的です。

この仕様は、MiniAppを論理的および物理的な観点から定義し、その内部ファイル構造と、さまざまなリソースがどのように単一ファイル内に パッケージ化されるかを詳述します。また、この文書には、MiniAppユーザーエージェントがMiniAppコンテナーを取得および処理するためのアルゴリズムも含まれます。

MiniApp Packaging仕様は、ユーザーエージェントがMiniAppコンテナーおよびその内容を処理し、内部 リソース(すなわち、HTML、スタイルシート、スクリプティングなど)および構成(すなわち、マニフェスト、 app.ux)に基づいて、ユーザーインターフェイスと具体的な動作を生成することを要求します。パッケージの取得および処理の後、 ユーザーエージェントは、あらゆる潜在的なシナリオにおいて、知覚可能で操作可能なユーザーインターフェイスおよび レンダリングされたコンテンツを提供し、スタイルシートを用いてユーザーの要件に合わせて外観を適応できるようにし、 manifest.jsonの一部メンバーで要求されるように、表示オプションならびにウィンドウおよびビューポートの向きを 設定および制御できる可能性を提供することが推奨されます(MiniApp Manifest)。

この文書では指定されていませんが、ユーザーエージェントは、完全なキーボードアクセスを提供することや代替入力デバイスを サポートすること(可能な場合)、ユーザー体験を改善するためにユーザーが設定を保存できるようにすることなど、 ユーザーインタラクションにおけるアクセシビリティ面を保証することが推奨されます。MiniAppユーザーエージェントおよび プラットフォームは、アプリケーションのレンダリングおよびインタラクションのための機構を提供し、支援技術との統合を促進し、 適用可能な仕様および慣行、特にUser Agent Accessibility Guidelines (UAAG) 2.0に 準拠するべきです。

7. セキュリティに関する考慮事項

この仕様は、アプリのエントリーポイントおよび異なるルート(すなわち、マニフェストのpages メンバー)を指定する具体的な構成を通じて、MiniAppをパッケージ化、配布、および読み込むための機構を定義します。ユーザーエージェントは、読み込まれるリソースの種類を制限し、既定で強力な機能へのアクセスをブロックする サンドボックス化された環境を実装することにより、初期化および読み込みフェーズ中の潜在的な脆弱性を緩和するべき です

7.1 リソースおよびサービス

MiniAppユーザーエージェントは、画像、データソース、スクリプトなどの外部 リソースを取得および処理することにより、具体的にはXSS攻撃に対して脆弱です。したがって、ユーザーエージェントは、 潜在的な攻撃ベクターを調査および制限し、MiniAppが取得または実行できるリソースを制御するために Content Security Policy(CSP)を実装することにより、リスクを緩和するべき です

MiniAppパッケージは、悪意のあるスクリプトを含め、任意の種類のリソースを 含んでもよい。したがって、MiniAppユーザーエージェントは、 処理されるリソースを厳密に制限し、マニフェストで宣言されておらずコンポーネントから適切に紐づけられていないものを 破棄することで、攻撃対象領域を最小化しなければなりません。したがって、ユーザーエージェントは、マニフェストで指定されたリソース(すなわち、画像および コンポーネントページ)ならびにコンテナー内に含まれる補完ファイル(すなわち、メディアファイル、スクリプト、スタイルシートなど)の 利用可能性を確認し、コンテナー内の残りの要素を破棄しなければなりません。また、ユーザーエージェントは、 サードパーティリソースの使用を可能にするAPIを実装する際の特有のリスクを考慮するべきです

この文書は、情報を公開する特定の提示方法を要求しません。ただし、MiniAppパッケージには、対象ユーザーエージェントおよび必要な実行環境の一部特性を 記述し得る機能が含まれます。これには、オペレーティングシステムのバージョンおよび基盤となるハードウェア能力 (例: 利用可能なセンサー、デバイスの種類、表示の種類)が含まれます。MiniAppマニフェストで指定されるこれらの プラットフォーム要件は、マニフェスト処理フェーズ中にMiniApp初期化の実行を停止してもよく、アプリ要件との不整合を明らかにします。それでも、ユーザーエージェントは、攻撃対象領域を減らすために、この情報の公開を避けるべき です

MiniApp Packagingは、基盤プラットフォームに関する情報にアクセスし公開するための特定の機構を指定しません。しかし、 MiniAppユーザーエージェントは、この情報 (例: プラットフォームバージョン、オペレーティングシステム、および利用可能なセンサー)にアクセスするサービス、および ハードウェアやオペレーティングシステムと通信するAPIを実装してもよい。したがって、ユーザーエージェントは、これらの影響を受けやすいサービスをサポートする際の潜在的な リスクを考慮し、強力な機能が意味のあるユーザーの 同意なしに有効化されないことを保証するため、既定で適切な緩和機構を実装するべきです

7.2 パッケージの完全性および 信頼性

MiniAppの配布段階における完全性および信頼性を確保するため、MiniAppパッケージは、1つ以上のデジタル署名によって保護されるべきです。これらの署名は、信頼された機関によって発行された証明書とともに、第三者がMiniAppの著作者 (例: MiniApp開発者)およびソフトウェアの開発または配布に関与するその他の主体(例: MiniApp配布者としてのアプリケーションストア)を 検証するのに役立ちます。

MiniAppにデジタル署名が含まれる一般的なシナリオには、次のものが含まれますが、これらに限定されません:

この仕様では、特定のデジタル署名機構、暗号技術、またはアルゴリズムは推奨されません。 MiniAppベンダーは、そのユースケースに応じてデジタル署名機構を実装してもよい。 実装する場合は、3.3 デジタル署名要件に従わなければなりません

一部の技術および暗号化方式は、B. 署名スキームで紹介されています。

8. プライバシーに関する考慮事項

MiniAppは、以後のアプリ実行のためにユーザーエージェントのサンドボックス化された環境に永続化および保持され得る 個人識別情報を扱ってもよいユーザーエージェントは、その情報を保護し、同じアプリケーションのインスタンスのみが データにアクセスできるようにし、公開を避けなければなりません。したがって、 MiniAppユーザーエージェントは、収集されるデータの種類および収集目的について、 エンドユーザーに透明性をもって通知するべきです

エンドユーザーは、任意のMiniAppインスタンスに対応してユーザーエージェントにより保存された情報を削除するかどうかを 決定しなければなりませんユーザーエージェントは、保存されたデータを潜在的に機微なものとして扱い、 データ削除時に基盤ストレージから適切に削除されることを保証するべきです。さらに、ユーザーエージェントは、 長期間の非アクティブ後に保存データを自動的に削除するなど、機微情報の漏えいリスクを最小化し、ユーザーのプライバシーを 保護するための機構を実装するべきです。いずれの場合も、ユーザーエージェントは、実装されている具体的な プライバシーポリシーについて、ユーザーに透明性をもって通知するべきです

セッションは、[MINIAPP-LIFECYCLE]で定義されるように、アプリが起動されたときに開始し、システムからアンロードされたときに終了します。この仕様は セッション間のデータ永続化のための機構を記述しませんが、MiniAppは、後続のセッションで取得され得るデータをユーザーの デバイス上に保存してもよい。このシナリオは、ユーザーの認識または制御なしにユーザー追跡が行われる リスクをもたらします。したがって、MiniAppユーザーエージェントは、 MiniApp実行環境を分離するなど、クライアント側ストレージ機構がユーザーの制御なしに追跡に悪用されないことを保証する 保護を実装しなければなりません。この分離により、マニフェストのapp_idメンバーによって一意に識別される各MiniApp専用のストレージ領域が 可能となり、他のMiniAppからデータへのアクセスを制限します。

ユーザーエージェントは、システム上にアプリをインストールする可能性 (例: ホーム画面ショートカット、デスクトップ上のアイコンなど)を提供してもよい。 このプロセスは透明で可逆的であるべきです。エンドユーザーがアプリをアンインストールしたい場合、 ユーザーエージェントは、関連するすべてのデータが基盤ストレージから適切に削除されることを保証しなければ なりません

この仕様は、MiniAppパッケージの機密性を保護するための 暗号化機構を推奨しません。ただし、特定の目的のために何らかの暗号化機構を実装することを妨げるものではありません。

A. 謝辞

このセクションは非規範的です。

編集者注記
すべての貢献者およびW3Cチーム連絡先を列挙する

B. 署名スキーム

このセクションは非規範的です。

すべてのユーザーエージェントは、その必要に応じて独自のデジタル署名スキームを サポートしてもよい。このセクションには、4に示すようなデジタル署名実装の例が含まれます。これらは、開発者検証や 配布中のMiniAppの完全性など、特定のシナリオで使用できます。

MiniAppパッケージ内の異なる署名スキームによる署名ブロックの例
4 MiniAppパッケージに含まれる異なる署名方式の例

B.1 RPK署名スキーム

MiniAppの一実装として、Quick Appsは、MiniAppパッケージの著作者性を検証するため、APK Signature Scheme v2 [APK-SIGNATURE-V2]に類似した、いわゆるRPK (Runnable Package)署名スキームを使用します。この署名スキームは、署名生成においてMiniAppパッケージ内のすべてのバイトを 対象にします。結果として得られる署名ブロックは、 デジタル署名要件に従って作成され、パッケージファイルに挿入されます。

署名ブロックには、署名および署名者の身元に関する情報を持つID-値ペアが含まれます。

注記

RPK署名ブロック内のすべてのデータ値は リトルエンディアン形式で表され、すべての長さ接頭辞付きフィールドは長さにuint32を使用します。

説明では、次の基本データ型を使用します:

uint64
リトルエンディアン形式の64ビット(8バイト)符号なし整数
uint32
リトルエンディアン形式の32ビット(4バイト)符号なし整数

B.1.1 署名ブロック形式

RPK署名ブロックの形式は次のとおりです:

  • ブロックサイズ(バイト単位。このフィールドを除く)(uint64)
  • ID-値ペアのシーケンス(署名が定義される場所):
    • ID-値ペアのサイズ(uint64)
    • ID(uint32)
    • (ID-値ペアのサイズ - 4バイト)
  • ブロックサイズ(バイト単位。最初のフィールドと同じ)(uint64)
  • マジックナンバーRPK Sig Block 42”(16バイト)

不明なIDを持つID-値ペアは、ブロックの解釈時に無視されます。

「ブロックサイズ」値により、ZIPファイル全体における署名ブロックの開始位置を特定できます。

B.1.1.1 署名

署名は、署名の種類を表す特定の識別子を持つID-値ペアとして保存されます。RPK パッケージに対してサポートされる署名および関連IDは、次の小節で説明されます。

編集者 注記: パッケージ分割

MiniAppパッケージが、ユーザーエージェントが段階的にダウンロードおよび実行してユーザー体験を改善できるよう、 配布プラットフォーム(例: アプリストア)によって複数のサブパッケージに分割される場合があります。そのような場合、 各サブパッケージおよび全体の完全性を保証するために、追加の署名型(したがってID)が必要になります。 詳細は今後の検討事項です。

B.1.1.1.1 開発者 署名

ID 0x01000101の署名ブロック内のID-値ペアは、ファイル全体のMiniAppパッケージ署名のデータを表します。

IDペアの値にはすべての署名ブロックが含まれ、可変長であり、その構造は次のとおりです:

  • ID: 0x01000101(uint32)
  • :
    • 署名者ブロックのサイズ(このフィールドを除く)(uint32)
    • 署名者ブロックのシーケンス:
      • 署名者ブロックのサイズ(このフィールドを除く)(uint32)
      • 署名対象データ:
        • ダイジェストのサイズ(このフィールドを除く)(uint32)
        • ダイジェストのシーケンス:
          • ダイジェストブロックのサイズ(この フィールドを除く)(uint32)
          • 署名アルゴリズムID(uint32)
          • ダイジェスト内容のサイズ(この フィールドを除く)(uint32)
          • ダイジェスト内容(可変長)
        • 証明書のサイズ(このフィールドを除く) (uint32)
        • 証明書のシーケンス:
          • 証明書のサイズ(この フィールドを除く)(uint32)
          • X.509証明書 [rfc2528]、 ASN.1 DER 形式 [X690] (可変長)
        • 追加属性のサイズ(この フィールドを除く)(uint32)
        • 追加属性
      • 署名のサイズ(このフィールドを除く)(uint32)
      • 署名のシーケンス:
        • 署名のサイズ(このフィールドを除く) (uint32)
        • 署名アルゴリズムID(uint32)
        • 署名内容のサイズ(このフィールドを除く) (uint32)
        • 署名内容(可変長)
      • 公開鍵のサイズ(このフィールドを除く)(uint32)
      • 公開鍵ASN.1 DER [X690] 形式(可変長)
B.1.1.1.2 配布者 署名

配布者の署名は、配布プロセス中のアプリケーションの完全性を保持し、パッケージが信頼された配布者によって検証され、 配布者からの権限制御ポリシー(プロビジョニングプロファイルの形式)が パッケージに対して適用されることを保証します。

配布者署名のプロセス中に、配布者または開発者のいずれかがプロビジョニングプロファイルを追加し、配布者の秘密鍵を使用して 署名します。

プロビジョニングプロファイルは、ID 0x02000201の 署名ブロック内のID-値ペアに保存されます。

IDペアの値にはすべての署名ブロックが含まれ、可変長であり、その構造は次のとおりです:

  • ID: 0x02000201(uint32)
  • :
    • 署名者ブロックのサイズ(このフィールドを除く)(uint32)
    • 署名者ブロック:
      • プロビジョニングプロファイルサイズ(このフィールドを除く)(uint32)
      • プロビジョニングプロファイルプロビジョニングプロファイルIDに従う、 プロビジョニングプロファイルID-値ペアのシーケンス:
        • ID-値ペアのサイズ(このフィールドを除く) (uint32)
        • ID(uint32)
        • (可変長)
      • 署名のサイズ(このフィールドを除く)(uint32)
      • 署名アルゴリズムIDの値に従う 署名アルゴリズムID (uint32)
      • 署名内容のサイズ(このフィールドを除く) (uint32)
      • 署名内容(可変長)
B.1.1.1.2.1 署名 アルゴリズムID
  • 0x0101 SHA2-256ダイジェスト、SHA2-256 MGF1、32バイトの ソルト、トレーラー: 0xbcを使用するRSASSA-PSS
  • 0x0102 SHA2-512ダイジェスト、SHA2-512 MGF1、64バイトの ソルト、トレーラー: 0xbcを使用するRSASSA-PSS
  • 0x0103 SHA2-256ダイジェストを使用するRSASSA-PKCS1-v1_5。これは決定的署名を必要とする ビルドシステム用です。
  • 0x0104 SHA2-512ダイジェストを使用するRSASSA-PKCS1-v1_5。これは決定的署名を必要とする ビルドシステム用です。
  • 0x0201 SHA2-256ダイジェストを使用するECDSA
  • 0x0202 SHA2-512ダイジェストを使用するECDSA
  • 0x0301 SHA2-256ダイジェストを使用するDSA
B.1.1.1.2.2 サポートされる鍵 サイズおよびEC暗号:
  • RSA: 1024, 2048, 4096, 8192, 16384
  • EC: NIST P-256, P-384, P-521
  • DSA: 1024, 2048, 3072
B.1.1.1.2.3 プロビジョニング プロファイルID
  • 0x01 証明書ダイジェスト
    • 証明書ダイジェストブロックのサイズ(このフィールドを除く) (uint32)
    • 署名アルゴリズムIDの値に従う 署名アルゴリズムID(uint32)
    • 証明書ダイジェストデータのサイズ(このフィールドを除く) (uint32)
    • 証明書ダイジェストデータ(可変長)
  • 0x02 証明書
    • 証明書のサイズ(このフィールドを除く)(uint32)
    • 証明書データASN.1 DER [X690] 形式(可変長)
  • 0x03 用途:
    • app store、値: 0x01
    • debug、値: 0x02
    • enterprise、値: 0x03
  • 0x04 マニフェスト
    • マニフェストのサイズ(このフィールドを除く)(uint32)
    • マニフェスト、UTF-8 [UNICODE](可変長)
  • 0x05 デバイスID
    • デバイスIDのサイズ(このフィールドを除く)(uint32)
    • デバイスIDのシーケンス:
      • デバイスIDのサイズ(このフィールドを除く)(uint32)
      • デバイスID、MD5形式 [rfc1321]で 表現される(可変長)

B.2 PKCS#7署名スキーム

この署名スキームは、PKCS #7 Cryptographic Message Syntax [rfc2315]に基づいています。これは、 開発者署名および配布者署名を含む、RPK署名スキームで説明されるパッケージ化署名の異なる段階を対象としても よい

この署名スキームは、MiniAppのプロビジョニングプロファイルおよび 第1段階(開発者署名段階)における開発者署名を含みます。第2段階(配布者署名段階)では、配布者は 開発者署名を自身の署名に置き換えてもよいRPK署名スキームと同様に、 このアプローチは、デジタル署名要件に従ってパッケージファイルに含められる 署名ブロックを生成します。

PKCS#7署名ブロックは、デジタル署名を持つブロック、ならびに署名および署名者の身元を含むPKCS #7構文を使用して 暗号化されたデータを含むデータコンテナーとして定義されます。

説明では、次の基本データ型を使用します:

uint64
64ビット(8バイト)符号なし整数
uint32
32ビット(4バイト)符号なし整数
uint16
16ビット(2バイト)符号なし整数

B.2.1 署名ブロック形式

PKCS#7署名ブロックの形式は次のとおりです:

  • 署名ブロックヘッド
  • 署名ブロックヘッド:
    • reserved(4バイト)
    • number of blocks(uint32)
    • size(uint32)
    • version(4バイト)
    • magic numbersMIX Sig Block 42”(16バイト)
  • データ
  • PKCS #7内の署名ブロックデータ:
    • PKCS #7 Content TypeをSignedDataに設定:
      • version: 構文バージョン番号
      • digest algorithms: メッセージダイジェストアルゴリズム識別子の集合
      • 署名される内容:
        • version(uint32)
        • size(uint16)
        • number of blocks(uint16)
        • Content Hash:
          • type(uint8)
          • tag(uint8)
          • algorithm ID(uint8)
          • length(uint32)
          • hash(可変長)
      • certificates: PKCS #6拡張証明書およびX.509 証明書の集合
      • crls: 証明書失効リストの集合
      • signerInfos: 署名者ごとの情報の集合
    • 署名者
  • Hw sign head:
    • number of blocks(uint32)
    • size(uint32)
    • version(4バイト)
    • magic numbersMIX Sig Block 42”(16バイト)
B.2.1.1 署名ブロックの種類

Block Headの型は、その属性 typeによって識別されます。この属性は、2つの異なる値を取らなければ なりません:

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ブロックハッシュツリー)

C. メディア型登録

この付録は、BCP 13 [RFC4289]および W3C仕様のための インターネットメディア型の登録に適合して、MiniAppパッケージ用のapplication/miniapp-pkg+zipメディア型を登録します。

MiniAppパッケージファイルは、いくつかの変更を含む[ZIP]アーカイブ形式に基づくコンテナー技術です。

型名:
application
サブタイプ名:
miniapp-pkg+zip
必須パラメーター:
"N/A"
任意パラメーター:
"N/A"
符号化に関する考慮事項:
MiniAppパッケージは、application/zipメディア型で符号化された バイナリファイルです。RFC 6839, section 3.6 [RFC6839]を参照してください。
セキュリティに関する考慮事項:
application/zipに適用されるセキュリティ上の考慮事項は、MiniAppパッケージファイルにも適用されます。MiniApp パッケージファイルを処理するユーザーエージェントは、取得したデータのサイズおよび妥当性を厳密に確認するべきです。 MiniAppパッケージファイルでデジタル署名が利用可能な場合、ユーザーエージェントは、パッケージの改ざんまたは破損による エンドユーザーおよびホスティングプラットフォームへの損害から保護するため、デジタル署名に従ってファイルの完全性および 信頼性を確認するために必要な機構を実装するべきです。詳細は7. セキュリティに関する考慮事項を参照してください。
相互運用性に関する考慮事項:
署名を含めた後のファイルは標準ZIPではありませんが、その包含はZIPファイルとしてのファイルの解析および操作に影響しません。
公開仕様:
このメディア型登録は、https://www.w3.org/TR/miniapp-packaging/にある仕様で 説明されるMiniAppパッケージのためのものです。
このメディア型を使用するアプリケーション:
このメディア型はMiniAppの配布に使用されます。このメディア型をサポートする(意図のある)アプリケーションおよび ソフトウェアプラットフォームの非網羅的な一覧は次のとおりです: 上記に列挙されたアプリケーションは、この仕様を開発するための基盤技術です。これらはまだ提案されたメディア型を使用していませんが、 仕様が準備できたときに潜在的にサポートする予定です。この一覧は後で確認/更新されます。
フラグメント識別子に関する考慮事項:
"N/A"
追加情報:
この型の非推奨エイリアス名:
"N/A"
マジックナンバー:
50 4B 03 04
ファイル拡張子:
MiniAppは通常、拡張子.maで識別されます。
Macintoshファイルタイプコード:
ZIP
詳細情報の連絡先となる人物およびメールアドレス:
MiniApps Working Groupには、 public-miniapps-wg@w3.orgで連絡できます。
想定される用途:
COMMON
使用上の制限:
"N/A"
作者:
MiniApp Packagingは、W3C MiniApp Working Groupによって開発されたファイル形式を定義します。
変更管理者:
W3CはMiniApp Packaging仕様の管理者です
暫定登録?:
"N/A"
課題 4: パッケージ用ZIPコンテナー
このセクションでは、MIME型登録の技術的詳細(拡張子など)を指定する必要があります。
注記

初期実装のための暫定的な解決策として、application/x-w3c-miniapp-pkg+zipが考えられます。

課題

プロセッサーはパッケージの完全性を確認するべきか(セキュリティに関する考慮事項セクション)?

D. 参考文献

D.1 規範的参考文献

[BCP47]
Tags for Identifying Languages. A. Phillips, Ed.; M. Davis, Ed. IETF. September 2009. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc5646
[CSS-SNAPSHOT]
CSS Snapshot. URL: https://www.w3.org/TR/CSS/
[ECMA-262]
ECMAScript Language Specification. Ecma International. URL: https://tc39.es/ecma262/multipage/
[FETCH]
Fetch Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://fetch.spec.whatwg.org/
[HTML]
HTML Standard. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[INFRA]
Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[international-specs]
Internationalization Best Practices for Spec Developers. Richard Ishida; Addison Phillips. W3C. 17 October 2024. W3C Working Group Note. URL: https://www.w3.org/TR/international-specs/
[JSON]
The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed. IETF. December 2017. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc8259
[MIMESNIFF]
MIME Sniffing Standard. Gordon P. Hemsley. WHATWG. Living Standard. URL: https://mimesniff.spec.whatwg.org/
[MINIAPP-LIFECYCLE]
MiniApp Lifecycle. Qing An; Haoyang Xu. W3C. 29 May 2023. W3C Working Draft. URL: https://www.w3.org/TR/miniapp-lifecycle/
[MINIAPP-MANIFEST]
MiniApp Manifest. Martin Alvarez-Espinar; Yongjing ZHANG. W3C. 14 November 2024. W3C Working Draft. URL: https://www.w3.org/TR/miniapp-manifest/
[permissions]
Permissions. Marcos Caceres; Mike Taylor. W3C. 20 December 2024. W3C Working Draft. URL: https://www.w3.org/TR/permissions/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC4289]
Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. N. Freed; J. Klensin. IETF. December 2005. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc4289
[RFC6839]
Additional Media Type Structured Syntax Suffixes. T. Hansen; A. Melnikov. IETF. January 2013. Informational. URL: https://www.rfc-editor.org/rfc/rfc6839
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[UAX15]
Unicode Normalization Forms. Ken Whistler. Unicode Consortium. 14 August 2024. Unicode Standard Annex #15. URL: https://www.unicode.org/reports/tr15/tr15-56.html
[Unicode]
The Unicode Standard. Unicode Consortium. URL: https://www.unicode.org/versions/latest/
[url]
URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/
[ZIP]
.ZIP File Format Specification. 15 July 2020. Final. URL: https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT

D.2 参考情報文献

[APK-SIGNATURE-V2]
APK Signature Scheme v2. URL: https://source.android.com/security/apksigning/v2
[CHARMOD-NORM]
Character Model for the World Wide Web: String Matching. Addison Phillips et al. W3C. 11 August 2021. W3C Working Group Note. URL: https://www.w3.org/TR/charmod-norm/
[rfc1321]
The MD5 Message-Digest Algorithm. R. Rivest. IETF. April 1992. Informational. URL: https://www.rfc-editor.org/rfc/rfc1321
[rfc2315]
PKCS #7: Cryptographic Message Syntax Version 1.5. B. Kaliski. IETF. March 1998. Informational. URL: https://www.rfc-editor.org/rfc/rfc2315
[rfc2528]
Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates. R. Housley; W. Polk. IETF. March 1999. Informational. URL: https://www.rfc-editor.org/rfc/rfc2528
[UAAG20]
User Agent Accessibility Guidelines (UAAG) 2.0. James Allan; Greg Lowney; Kimberly Patch; Jeanne F Spellman. W3C. 15 December 2015. W3C Working Group Note. URL: https://www.w3.org/TR/UAAG20/
[X690]
Recommendation X.690 — Information Technology — ASN.1 Encoding Rules — Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER). ITU. URL: https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf