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은 디지털 수단을 통해 배포될 수 있고 웹을 통해 접근할 수 있는 경량 소프트웨어 애플리케이션의 개념입니다. MiniApp은 구체적인 파일 구조로 정의되며 모든 리소스는 전체 MiniApp 패키지를 나타내는 단일 파일 안에 패키징되어, 처리되고 MiniApp 사용자 에이전트에 의해 실행될 수 있습니다.

MiniApp 패키지는 MiniApp의 렌더링, 동작 및 최종 사용자와의 상호작용을 정의하는 특정 리소스를 보관하는 디렉터리 구조를 포함합니다. 여기에는 정적 페이지 템플릿, 스타일시트, JavaScript 문서, 미디어 파일 및 기타 리소스와 매니페스트가 포함됩니다. 패키지의 중앙 디렉터리에 위치한 MiniApp 매니페스트는 페이지 라우팅, 스타일, MiniApp의 기타 동작 및 렌더링 세부사항에 관한 정보뿐 아니라 사람이 읽을 수 있는 설명 정보를 포함하여 MiniApp을 설명합니다.

보안 고려사항에서 정의한 것처럼, MiniApp은 패키지 전달 중에 패키지와 콘텐츠의 무결성을 보장하기 위해 디지털 서명 검증을 지원할 MAY 있습니다.

MiniApp 런타임 환경(MiniApp 사용자 에이전트)은 이 문서에서 정의한 표준 MiniApp 패키지 형식과 특정 MIME 미디어 유형을 통해 MiniApp 패키지 파일을 식별합니다. MiniApp ZIP 컨테이너를 가져온 후, MiniApp 사용자 에이전트역참조 및 처리 알고리즘에 따라 정적 페이지 템플릿, 스타일시트, JavaScript 파일 및 기타 리소스를 캐시에 로드합니다. 이러한 MiniApp 리소스는 다음 업데이트까지 캐시에서 계속 사용할 수 있어 불필요한 네트워크 가져오기를 피할 수 있습니다.

실행 모드 측면에서 MiniApp은 오프라인일 때도 정상적으로 실행될 수 있습니다. MiniApp 사용자 에이전트는 패키지 캐시 경로에서 지정된 시작 페이지를 찾고, MiniApp 매니페스트 파일에 제시된 설명에 따라 MiniApp을 실행합니다.

1.2 용어

다음 용어는 MiniApp에 특화된 것입니다.

디지털 서명
리소스의 진위를 증명하기 위한 암호화 메커니즘 및 해싱 기법입니다. 디지털 서명은 리소스MiniApp 패키지의 출처, 시간, 신원 및 상태를 입증할 수 있습니다.
MiniApp
디지털 수단을 통해 배포될 수 있고 웹을 통해 접근할 수 있는 경량 소프트웨어 애플리케이션입니다. MiniApp은 구체적인 파일 구조로 정의되며, 전체 MiniApp 패키지를 나타내고 MiniApp 사용자 에이전트에 의해 처리 및 실행될 수 있는 단일 파일 MiniApp ZIP 컨테이너 안에 배포됩니다.
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 적합성

비규범으로 표시된 섹션뿐 아니라, 이 명세의 모든 작성 지침, 다이어그램, 예제 및 참고는 비규범입니다. 이 명세의 그 밖의 모든 내용은 규범적입니다.

이 문서의 핵심 단어 MAY, MUST, MUST NOT, SHALL, SHOULD, 및 SHOULD NOT은 여기에 표시된 것처럼 모두 대문자로 나타날 때에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석됩니다.

MiniApp Packaging 명세는 알고리즘을 설명하기 위해 Infra Standard [INFRA]에 의존합니다.

2. 패키지 적합성

적합한 MiniApp 패키지는 다음 기준을 충족해야 MUST 합니다:

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 내 페이지의 공통 스타일과 모양 및 느낌의 측면을 정의하는 곳입니다. 비어 있을 MAY 있습니다.
app.js
이 스크립트 문서는 MiniApp의 기본 서비스 로직을 가지며, MiniApp Lifecycle [MINIAPP-LIFECYCLE]에 따른 MiniApp 실행, 표시 및 숨김 이벤트의 관리를 포함하여 MiniApp 생명주기의 필수 구성과 제어를 포함합니다.

2.1.2 pages 디렉터리

pages 디렉터리는 MiniApp 페이지의 표시와 사용자 상호작용을 위한 파일 집합을 포함합니다.

MiniApp 페이지는 고유한 파일명(예: intro)과 특정 확장자로 식별되는 리소스 집합으로 정의됩니다. 확장자는 애플리케이션의 비즈니스 로직 (예: intro.js), 구조와 콘텐츠(예: intro.html), 범위가 지정된 스타일시트 (예: intro.css)와 같은 리소스 유형을 정의합니다.

개발자는 필요에 따라 다른 유형의 리소스를 포함할 MAY 있습니다. 또한, 페이지와 관련된 파일(동일한 파일명으로 식별됨)은 각 페이지별 특정 하위 디렉터리에 구성하거나 pages 디렉터리 바로 아래에 저장할 MAY 있습니다.

예제 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의 페이지에서 접근할 수 있는 구성요소, 멀티미디어 리소스, 문서 및 라이브러리와 같은 리소스를 포함합니다. 이 디렉터리의 내부 구조는 유연하므로, 이러한 공통 리소스는 필요에 따라 사용자 지정 하위 디렉터리에 구성하고 서로 다른 이름 규칙을 사용할 MAY 있습니다.

2.1.4 i18n 디렉터리

선택적 i18n 디렉터리루트 디렉터리의 하위 디렉터리로, MiniApp 패키지현지화 리소스를 포함합니다.

i18n 디렉터리는 MiniApp 콘텐츠의 국제화를 지원하기 위한 다국어 현지화 리소스를 포함합니다. 이 디렉터리에 있는 각 .json 문서의 파일명은 [BCP47]에서 정의한 Language-Tag 표기법을 따르며, 해당 특정 언어에 대한 구성을 나타냅니다.

i18n 디렉터리는 MiniApp이 지원하는 언어 또는 로케일 수만큼 많은 현지화 리소스를 포함할 MAY 있습니다. 이러한 파일의 형식은 현지화 리소스 섹션에서 정의됩니다.

2.1.5 파일 및 경로 이름

MiniApp 패키지 안의 모든 파일명과 경로명은, Internationalization Best Practices for Spec Developers에서 명시한 것처럼 운영체제의 잠재적 제한을 수용하고 대부분의 플랫폼 및 파일 시스템과의 상호운용성을 촉진하기 위해 다음 제한사항을 준수해야 MUST 합니다.

  • 파일명과 파일 경로는 대소문자를 구분합니다.
  • 파일명과 파일 경로는 UTF-8 [Unicode]로 인코딩되어야 MUST 합니다.
  • 파일명은 길이가 255바이트를 초과하지 않는 것이 SHOULD NOT 좋습니다.
  • 경로명은 길이가 65535바이트를 초과하지 않는 것이 SHOULD NOT 좋습니다.
  • 파일명과 경로명은 다음 [Unicode] 포인트를 사용해서는 MUST NOT 안 됩니다:
    • " [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)
      • 기본 다국어 평면의 마지막 두 코드 포인트(U+FFFE 및 U+FFFF)
      • 보조 평면 끝의 마지막 두 코드 포인트(U+1FFFE, U+1FFFF … U+EFFFE, U+EFFFF)

동일한 디렉터리 안의 모든 파일명은 Unicode 정규 정규화 [UAX15]와 그 이후의 전체 대소문자 폴딩 [Unicode]에 따라 고유해야 MUST 합니다. (자세한 내용은 Unicode Canonical Case Fold Normalization Step [CHARMOD-NORM]를 참조하십시오.)

참고: 파일명 길이 제한
MiniApp 공급자가 경로 및 파일명에 길이 제한을 두는 경우, UTF-8과 같은 멀티바이트 인코딩에서 바이트와 문자의 차이로 인해 문자 중간에서 잘리는 것을 피하는 것이 중요합니다. 자세한 내용은 텍스트 잘림 모범 사례를 참조하십시오.

2.2 MiniApp 리소스

MiniApp 페이지는 최소한 HTML 리소스로 구성되며, 선택적으로 CSS 리소스 및/또는 스크립팅 리소스를 포함할 수 있습니다. 이러한 관련 리소스는 MiniApp 매니페스트 [MINIAPP-MANIFEST]의 pages 멤버에 지정되어야 하는 고유한 페이지 라우트를 통해 MiniApp 페이지를 식별하기 위해 동일한 경로와 파일명(파일 확장자만 변경)을 가져야 MUST 합니다.

예제 4: 페이지 라우트 'pages/product/product'에 해당하는 페이지 리소스 구성
/
|___pages/
        |___product/
                |___product.html
                |___product.css
                |___product.js

2.2.1 HTML 리소스

HTML 리소스MiniApp 페이지와 그 사용자 인터페이스를 정의하기 위한 마크업과 정보를 포함하는 문서이며, 여기에는 구조, 시각적 구성요소 및 상호작용 요소가 포함됩니다.

HTML 리소스는 다음 기준을 모두 충족해야 MUST 합니다:

구문 및 콘텐츠
HTML 리소스는 [HTML]에 정의된 HTML 구문을 사용해야 MUST 합니다.
파일명
HTML 리소스는 단일 MiniApp 페이지를 식별하고, 존재하는 경우 해당 페이지의 대응하는 CSS 리소스스크립팅 리소스와 일치하는 고유한 파일명을 갖는 것이 SHOULD 좋습니다.
파일 확장자
HTML 리소스는 파일 확장자 .html을 사용하는 것이 SHOULD 좋습니다.
편집자 참고
MiniApp 콘텐츠 문서의 HTML 프로파일을 정의하기 위한 것입니다.

2.2.2 CSS 리소스

CSS 리소스MiniApp 페이지의 렌더링과 외형을 설명하는 스타일시트입니다. CSS 리소스는 전역적일 수 있어 MiniApp의 모든 페이지에 영향을 미치거나(즉, 루트 디렉터리app.css), 특정 페이지에만 영향을 미치는 로컬 범위를 가질 수 있습니다.

이 명세는 [CSS-SNAPSHOT]에 정의된 CSS 모듈을 지원합니다.

CSS 리소스는 다음 기준을 모두 충족해야 MUST 합니다:

구문 및 콘텐츠
CSS 리소스는 [CSS-SNAPSHOT]에 설명된 CSS의 구문과 정의를 사용하여 설명된 것을 따라야 MUST 합니다.
파일명
MiniApp의 모든 페이지에 영향을 미치는 전역 CSS 리소스app.css라는 이름을 가져야 하고 루트 디렉터리에 저장되어야 MUST 합니다.
페이지와 연결된 로컬 CSS 리소스MiniApp 페이지를 식별하고, 존재하는 경우 대응하는 HTML 리소스스크립팅 리소스와 일치하는 고유한 파일명을 갖는 것이 SHOULD 좋습니다.
파일 확장자
CSS 리소스 파일명은 파일 확장자 .css를 사용하는 것이 SHOULD 좋습니다.

2.2.3 스크립팅 리소스

스크립팅 리소스는 애플리케이션의 비즈니스 로직과 기능을 제어하고, 상호작용성을 추가하며 MiniApp의 생명주기를 관리하기 위한 스크립트 요소와 데이터를 포함하는 문서입니다. 모든 페이지에서 사용할 수 있는 데이터와 함수를 포함하고 애플리케이션의 생명주기를 제어하기 위한 특정 로직을 포함하는 전역 스크립팅 리소스(즉, 루트 디렉터리app.js)가 있습니다. 각 MiniApp 페이지는 구체적인 페이지로 범위가 제한된 특정 스크립팅 리소스를 연결할 MAY 있습니다.

스크립팅 리소스는 다음 기준을 모두 충족해야 MUST 합니다:

구문 및 콘텐츠
스크립팅 리소스는 ECMAScript 명세 [ECMA-262]의 요구사항을 준수해야 MUST 합니다.
전역 스크립팅 리소스app.js라는 이름을 가져야 하고 루트 디렉터리에 저장되어야 MUST 합니다.
페이지와 연결된 로컬 스크립팅 리소스MiniApp 페이지를 식별하고, 존재하는 경우 대응하는 HTML 리소스CSS 리소스와 일치하는 고유한 파일명을 갖는 것이 SHOULD 좋습니다.
파일 확장자
스크립팅 리소스 파일명은 파일 확장자 .js를 사용하는 것이 SHOULD 좋습니다.

2.2.4 현지화 리소스

MiniApp 현지화 리소스는 MiniApp의 국제화 메커니즘의 일부로 현지화된 콘텐츠를 포함한 MiniApp 패키지의 문서입니다.

다국어 MiniApp은 시스템 로케일 또는 사용자의 언어 기본 설정에 따라 콘텐츠를 렌더링하기 위해 사용자 에이전트현지화 과정에서 사용할 여러 현지화 리소스를 가질 MAY 있습니다. 이러한 리소스는 현지화 가능한 용어나 표현의 고유 식별자(키)와 구체적인 언어에서의 표현(값)을 포함하는 키-값 쌍의 JSON 객체를 포함합니다.

예제 5: 현지화 리소스
{
    "title": "멋진 MiniApp",
    "about": "이 MiniApp 정보",
    "intro-page": {
        "title" : "소개",
        "main" : "이것은 페이지의 본문입니다"
    }
}

현지화 리소스는 다음 기준을 모두 충족해야 MUST 합니다:

파일 확장자
현지화 리소스 파일명은 파일 확장자 .json을 사용하는 것이 SHOULD 좋습니다.
형식
현지화 리소스는 유효한 JSON 문서 [JSON]여야 MUST 합니다.
구조
현지화 리소스는 키-값 쌍으로 구성되어야 MUST 합니다. 각 키는 각각의 현지화 가능한 문자열(값)에 대한 고유 식별자를 나타냅니다.

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 서명 블록은 디지털 서명의 존재를 식별하기 위해 서명 블록 매직 넘버 블록을 포함할 MAY 있으며, 이는 디지털 서명 요구사항에 명시되어 있습니다. 일단 "매직 넘버" 블록이 인식되면, 사용자 에이전트디지털 서명을 처리할 수 있으며, 이는 그림 2에 표시된 것처럼 중앙 디렉터리의 바로 앞 섹션에 있는 서명 블록에 저장됩니다.

표준 ZIP 패키지와 가운데에 서명 블록이 있고 패키지의 서로 다른 블록에 대한 참조가 있는 MiniApp 패키지의 구조
그림 2 상대 오프셋 주소 지정을 사용하여 서로 다른 블록에 대한 참조가 있는 ZIP 및 MiniApp 패키지

MiniApps 공급업체는 필요에 따라 디지털 서명 체계를 채택할 MAY 있습니다.

편집자 참고: 확장자 추가 예정

MiniApp 파일은 파일 확장자의 사용이 필수는 아니지만 .ma 파일 확장자로 식별될 MAY 있습니다.

3.3 디지털 서명 요구사항

MiniApp ZIP 컨테이너는 소프트웨어의 보호된 부분에 대한 변경 사항을 감지하여 MiniApp의 무결성을 보장하는 데 도움이 되도록 서명을 포함하지 않거나, 하나 또는 여러 개 포함할 MAY 있습니다.

MiniApp 서명 블록은 MiniApp에 부분적으로 또는 전체적으로 영향을 주는 디지털 서명에 대한 특정 정보와 메타데이터를 포함하는 바이트 모음입니다. 서명 블록은, 존재하는 경우 블록을 더 쉽게 찾을 수 있도록 MiniApp ZIP 컨테이너의 중앙 디렉터리 바로 앞에 위치해야 MUST 합니다.

서명 블록 매직 넘버 블록은 MiniApp ZIP 컨테이너의 서명 블록에 저장되는, MiniApp 패키지의 디지털 서명 메커니즘을 식별하는 고유한 지문을 가진 16바이트 시퀀스입니다.

이 문서가 특정 디지털 서명 메커니즘(예: 해시 알고리즘, 암호화 방법 등)을 권고하지는 않지만, 서명 블록이 존재하는 경우 다음 기준을 충족해야 MUST 합니다:

서명 블록 매직 넘버
서명 블록은 포함된 디지털 서명의 유형을 명확하게 식별하기 위해 중앙 디렉터리의 앞선 블록으로 서명 블록 매직 넘버를 포함해야 MUST 합니다.

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 패키지를 역참조, 구문 분석 및 실행하기 위해 다음 알고리즘을 따라야 MUST 합니다.

MiniApp 패키지를 처리하려면, URL miniapp_uri가 주어졌을 때 다음 단계를 수행합니다:

  1. miniapp_zip_fileminiapp_uriMiniApp ZIP 컨테이너를 가져온 결과로 둡니다.
  2. miniapp_zip_fileMiniApp ZIP 컨테이너를 검증합니다.
  3. miniapp_packageminiapp_zip_file의 압축을 푼 결과로 둡니다.
  4. miniapp_package가 압축 해제 예외이면 실패를 반환합니다.
  5. ordered map manifestminiapp_packageMiniApp 매니페스트를 처리한 결과로 둡니다.
  6. start_pageminiapp_urimanifest플랫폼 런타임을 준비한 결과로 둡니다.
  7. string localemanifest를 전달하여 로케일을 추출한 결과로 둡니다.
  8. miniapp_package, manifest, start_page, 및 locale을 전달하여 MiniApp을 실행합니다.

5.1 MiniApp ZIP 컨테이너 검색

사용자 에이전트는 네트워크를 통해 파일을 가져오거나(즉, HTTPs, WebSocket, FTP 또는 기타 특정 TCP/UDP 기반 프로토콜 사용), 파일 시스템 또는 기타 메커니즘을 사용하여 서로 다른 채널을 통해 MiniApp ZIP 컨테이너를 획득할 MAY 있습니다.

MiniApp ZIP 컨테이너를 가져오기 위해, URL miniapp_uri가 주어졌을 때 다음 단계를 수행합니다. 이는 MiniApp ZIP 컨테이너를 반환합니다.

  1. resource를, miniapp_uri를 전달하여 URL을 가져온 [FETCH] 결과인 MiniApp ZIP 컨테이너로 둡니다.
  2. supplied_mime_typeresource제공된 MIME 유형 감지 알고리즘 [MIMESNIFF]을 적용한 결과로 둡니다.
  3. supplied_mime_typeapplication/miniapp-pkg+zip과 같지 않으면 실패를 반환합니다.
  4. resource를 반환합니다.

5.2 MiniApp ZIP 컨테이너 검증

사용자 에이전트는 디지털 서명을 검증하고 암호화 메커니즘을 적용함으로써 MiniApp ZIP 컨테이너와 그 콘텐츠의 정당성 및 무결성을 보장할 MAY 있습니다.

MiniApp ZIP 컨테이너를 검증하려면, MiniApp ZIP 컨테이너 miniapp_zip_file가 주어졌을 때 다음 단계를 수행합니다:

  1. 사용자 에이전트miniapp_zip_file의 디지털 서명 검증을 수행할 수 있는 능력이 있으면 다음을 수행합니다:
    miniapp_zip_file디지털 서명을 처리합니다.

5.2.1 디지털 서명 처리

MiniApp ZIP 컨테이너는 하나 이상의 서명을 포함하는 서명 블록을 포함할 MAY 있습니다. 서명 체계와 암호화 메커니즘은 사용자 에이전트의 구체적인 구현에 따라 달라집니다.

서명 체계는 MiniApp ZIP 컨테이너에 포함된 매직 넘버 섹션으로 식별되며, 이는 ZIP 패키지의 중앙 디렉터리 바로 앞에 위치한 16바이트 시퀀스입니다.

디지털 서명을 처리하려면, MiniApp ZIP 컨테이너 miniapp_zip_file가 주어졌을 때 다음 단계를 수행합니다:

  1. magic_numbersbyte sequence로 둡니다.
  2. eocd_pointer를, miniapp_zip_file에서 중앙 디렉터리의 끝을 표시하는 0x06054b50(리틀 엔디언으로 읽음) 바이트 시퀀스를 찾은 결과인 byte sequence로 둡니다 [ZIP].
  3. eocd_pointereocd_pointer + 0x00000010으로 설정합니다.
  4. cd_pointereocd_pointer에서 4바이트 시퀀스를 읽은 결과로 둡니다.
  5. magic_numbers_pointereocd_pointer - 0x00000010으로 둡니다.
  6. magic_numbersmagic_numbers_pointer의 16바이트 블록으로 설정합니다.
  7. magic_numbersminiapp_zip_file로 디지털 서명을 처리합니다.
참고: 사용
MiniApp 사용자 에이전트는 필요와 요구사항에 따라 특정 디지털 서명 처리 알고리즘을 구현합니다.

5.3 MiniApp 매니페스트 처리

사용자 에이전트는 MiniApp에 대한 전역 메타데이터를 포함하며 MiniApp 패키지에 위치한 MiniApp 매니페스트를 구문 분석해야 MUST 합니다.

MiniApp 매니페스트를 처리하려면, MiniApp Package miniapp_package가 주어졌을 때 다음 단계를 수행합니다. 이는 ordered map을 반환합니다.

  1. 패키지의 루트 디렉터리manifest.json 파일이 존재하지 않으면 실패를 반환합니다.
  2. manifest_jsonmanifest.json을 전달하여 바이트에서 JSON을 구문 분석한 결과로 둡니다.
  3. manifest_json이 구문 분석 예외이거나, manifest_jsonordered map이 아니면 실패를 반환합니다.
  4. manifestordered map으로 둡니다.
  5. manifest_jsonmanifest를 전달하여 MiniApp 매니페스트를 처리합니다.
  6. manifest를 반환합니다.

5.4 플랫폼 런타임 준비

사용자 에이전트는 로직 계층과 뷰 계층을 모두 포함하는 런타임 환경을 준비하는 것이 SHOULD 좋습니다. 로직 계층은 애플리케이션의 로직과 제어를 담당합니다(즉, app.jspage.js 파일). 뷰 계층은 컴포넌트 템플릿 및 스타일시트와 같은 페이지 리소스 파일을 포함하여 시각적 환경과 렌더링을 담당합니다. MiniApp 실행을 준비할 때, 사용자 에이전트MiniApp 매니페스트 메타데이터가 지정한 구성으로 환경을 설정해야 MUST 합니다.

사용자 에이전트는 다음 알고리즘에 따라 시작 페이지를 MiniApp 진입점으로 식별하고 로드해야 MUST 합니다.

플랫폼 런타임을 준비하려면, URL miniapp_uriordered map manifest가 주어졌을 때 다음 단계를 수행합니다. 이는 MiniApp 시작 페이지를 반환합니다.

  1. 루트 디렉터리app.js가 존재하지 않으면 실패를 반환합니다.
  2. 루트 디렉터리app.css가 존재하지 않으면 실패를 반환합니다.
  3. miniapp_packagemanifest를 전달하여 플랫폼 호환성을 검증합니다.
  4. start_pageminiapp_package, miniapp_urimanifest를 전달하여 시작 페이지를 결정한 결과로 둡니다.
  5. miniapp_uri를 반환합니다.

5.4.1 플랫폼 호환성 검증

사용자 에이전트MiniApp이 자신들과 호환되고 해당 플랫폼에서 제대로 실행될 수 있는지 검증해야 MUST 합니다. 이 검증은 플랫폼의 지원 버전과 실행에 필요한 페이지 및 리소스 확인을 포함하여 MiniApp 매니페스트에 지정된 메타데이터를 사용하여 수행됩니다.

플랫폼 호환성을 검증하려면, MiniApp Package miniapp_packageordered map manifest가 주어졌을 때 다음 단계를 수행합니다:

  1. platform_requiredmanifest["platform_version"]으로 설정합니다.
  2. platform_required사용자 에이전트 구성과 호환되지 않으면 실패를 반환합니다.
  3. manifest["pages"]의 list page마다 반복합니다:
    1. pageminiapp_package에 존재하지 않으면 실패를 반환합니다.
  4. manifest["widgets"]가 존재하면 다음을 수행합니다:
    manifest["widgets"]의 list widget_path마다 반복합니다:
    1. widget_pathminiapp_package에 존재하지 않으면 실패를 반환합니다.

5.4.2 시작 페이지 식별

기본적으로, 사용자 에이전트는 MiniApp이 실행될 때 MiniApp 매니페스트에 표시된 시작 페이지를 진입점으로 로드해야 MUST 합니다. 이 기본 시작 페이지는 다음 알고리즘에 명시된 것처럼, MiniApp URI에 유효한 페이지가 지정된 경우 재정의되어야 MUST 합니다.

시작 페이지를 결정하려면, MiniApp Package miniapp_package, URL miniapp_uri, 및 ordered map manifest가 주어졌을 때 다음 단계를 수행합니다. 이는 URL을 반환합니다.

  1. start_pageminiapp_uri를 전달하여 URI에서 시작 페이지를 추출한 결과로 둡니다.
  2. start_page가 설정되어 있지 않거나, start_page가 null과 같거나, start_pageminiapp_package에 존재하지 않으면 다음을 수행합니다:
    manifest를 전달하여 매니페스트에서 시작 페이지를 추출한 결과로 start_page를 설정합니다.
  3. start_page를 반환합니다
5.4.2.1 URI에서 시작 페이지 추출

MiniApp URI는 URI의 URL-path-segment string으로 지정된 시작 페이지에 관한 정보를 포함할 MAY 있습니다.

URI에서 시작 페이지를 추출하려면, URL miniapp_uri가 주어졌을 때 다음 단계를 수행합니다. 이는 URL을 반환합니다.

  1. start_pageminiapp_uri구문 분석한 결과인 URL-path-segment string으로 둡니다.
  2. start_page가 failure이면 null을 반환합니다.
  3. start_page를 반환합니다.
5.4.2.2 매니페스트에서 시작 페이지 추출

MiniApp Manifest의 pages 멤버 [MINIAPP-MANIFEST]에서 설명한 것처럼, MiniApp의 시작 페이지pages list의 첫 번째 항목에 지정됩니다.

매니페스트에서 시작 페이지를 추출하려면, ordered map manifest가 주어졌을 때 다음 단계를 수행합니다. 이는 string을 반환합니다.

  1. start_page_id를 빈 string으로 둡니다.
  2. list pagesmanifest["pages"]로 둡니다.
  3. pages[0]을 반환합니다.

5.4.3 로케일 추출

로케일을 추출하려면, ordered map manifest가 주어졌을 때 다음 단계를 수행합니다. 이는 string을 반환합니다.

  1. string 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을 패키징, 배포 및 로드하는 메커니즘을 정의합니다. 사용자 에이전트는 로드할 리소스 유형을 제한하고 기본적으로 강력한 기능에 대한 접근을 차단하는 샌드박스 환경을 구현함으로써 초기화 및 로딩 단계에서의 잠재적 취약점을 완화하는 것이 SHOULD 좋습니다.

7.1 리소스 및 서비스

MiniApp 사용자 에이전트는 이미지, 데이터 소스, 스크립트와 같은 외부 리소스를 가져오고 처리하는 과정에서 구체적으로 XSS 공격에 취약합니다. 따라서 사용자 에이전트는 잠재적 공격 벡터를 조사하고 제한하며, MiniApp이 가져오거나 실행할 수 있는 리소스를 제어하기 위해 Content Security Policy(CSP)를 구현하여 위험을 완화하는 것이 SHOULD 좋습니다.

MiniApp 패키지는 악성 스크립트를 포함한 모든 유형의 리소스를 포함할 MAY 있습니다. 따라서 MiniApp 사용자 에이전트는 처리할 리소스를 엄격히 제한해야 MUST 하며, 매니페스트에 선언되지 않았거나 컴포넌트에서 적절히 바인딩되지 않은 항목을 폐기함으로써 공격 표면을 최소화해야 합니다. 그러므로 사용자 에이전트는 매니페스트에 지정된 리소스(즉, 이미지 및 컴포넌트 페이지)와 컨테이너 안에 포함된 보완 파일(즉, 미디어 파일, 스크립트, 스타일시트 등)의 가용성을 확인하고, 컨테이너 안의 나머지 요소를 폐기해야 MUST 합니다. 또한 사용자 에이전트는 서드파티 리소스 사용을 가능하게 하는 API를 구현할 때의 특정 위험을 고려하는 것이 SHOULD 좋습니다.

이 문서는 정보를 공개적으로 노출하는 특정 방식을 요구하지 않습니다. 그러나 MiniApp 패키지는 대상 사용자 에이전트와 필요한 실행 환경의 일부 특성을 설명할 수 있는 기능을 포함합니다. 여기에는 운영체제 버전 및 기반 하드웨어 기능(예: 사용 가능한 센서, 기기 유형, 디스플레이 종류)이 포함됩니다. MiniApp 매니페스트에 지정된 이러한 플랫폼 요구사항은 매니페스트 처리 단계에서 MiniApp 초기화 실행을 중단시킬 MAY 수 있으며, 앱 요구사항과의 일부 불일치를 드러낼 수 있습니다. 그럼에도 사용자 에이전트는 공격 표면을 줄이기 위해 이 정보의 공개적 노출을 피하는 것이 SHOULD 좋습니다.

MiniApp Packaging은 기반 플랫폼에 관한 정보에 접근하고 이를 노출하기 위한 어떤 특정 메커니즘도 명시하지 않습니다. 그러나 MiniApp 사용자 에이전트는 이 정보(예: 플랫폼 버전, 운영체제, 사용 가능한 센서)에 접근하기 위한 서비스와 하드웨어 및 운영체제와 통신하기 위한 API를 구현할 MAY 있습니다. 따라서 사용자 에이전트는 이러한 민감한 서비스를 지원할 때의 잠재적 위험을 고려하고, 강력한 기능이 의미 있는 사용자 동의 없이 활성화되지 않도록 보장하기 위해 기본적으로 적절한 완화 메커니즘을 구현하는 것이 SHOULD 좋습니다.

7.2 패키지 무결성 및 신뢰성

MiniApp의 배포 단계에서 무결성과 신뢰성을 보장하기 위해, MiniApp 패키지는 하나 이상의 디지털 서명으로 보호되는 것이 SHOULD 좋습니다. 이러한 서명은 신뢰할 수 있는 기관이 발급한 인증서와 함께, 제3자가 MiniApp의 저작자(예: MiniApp 개발자) 및 소프트웨어의 개발이나 배포에 관여한 다른 주체(예: MiniApp 배포자로서의 앱 스토어)를 검증하는 데 도움이 될 수 있습니다.

MiniApp에 디지털 서명이 포함되는 일반적인 시나리오는 다음을 포함하지만, 이에 한정되지는 않습니다:

이 명세에서는 특정 디지털 서명 메커니즘, 암호화 기술 또는 알고리즘을 권장하지 않습니다. MiniApp 공급업체는 사용 사례에 따라 디지털 서명 메커니즘을 구현할 MAY 있습니다. 구현되는 경우 3.3 디지털 서명 요구사항을 따라야 SHALL 합니다.

일부 기술과 암호화 방법은 B. 서명 체계에 소개되어 있습니다.

8. 개인정보 보호 고려사항

MiniApp은 후속 앱 실행을 위해 사용자 에이전트의 샌드박스 환경에 지속 및 보존될 수 있는 개인 식별 정보를 다룰 MAY 있습니다. 사용자 에이전트는 그 정보를 보호해야 MUST 하며, 동일 애플리케이션의 인스턴스만 데이터에 접근할 수 있게 하고 공개 노출을 피해야 합니다. 따라서 MiniApp 사용자 에이전트는 수집되는 데이터의 유형과 수집 목적을 최종 사용자에게 투명하게 알리는 것이 SHOULD 좋습니다.

최종 사용자는 사용자 에이전트가 저장한, 특정 MiniApp 인스턴스에 해당하는 정보를 제거할지 여부를 결정해야 MUST 합니다. 사용자 에이전트는 저장된 데이터를 잠재적으로 민감한 것으로 취급하고, 데이터를 삭제할 때 기반 저장소에서 적절히 제거되도록 보장하는 것이 SHOULD 좋습니다. 또한 사용자 에이전트는 장기간 비활성 상태가 지속된 후 저장된 데이터를 자동으로 제거하는 것과 같이 민감한 정보의 유출 위험을 최소화하고 사용자의 개인정보를 보호하기 위한 메커니즘을 구현하는 것이 SHOULD 좋습니다. 어떤 경우에도 사용자 에이전트는 구현된 특정 개인정보 보호 정책에 대해 사용자에게 투명하게 알려야 SHOULD 합니다.

세션은 앱이 실행될 때 시작되고 시스템에서 언로드될 때 종료됩니다. 이는 [MINIAPP-LIFECYCLE]에 정의되어 있습니다. 이 명세는 세션 간 데이터 지속성을 위한 메커니즘을 설명하지 않지만, MiniApp은 후속 세션에서 검색될 수 있는 데이터를 사용자의 기기에 저장할 MAY 있습니다. 이 시나리오는 사용자가 알거나 제어하지 못하는 사용자 추적의 위험을 초래합니다. 따라서 MiniApp 사용자 에이전트는 MiniApp 실행 환경을 격리하는 것과 같이, 클라이언트 측 저장 메커니즘이 사용자의 제어 없이 사용자를 추적하는 데 오용될 수 없도록 보호를 구현해야 MUST 합니다. 이러한 격리는 매니페스트의 app_id 멤버로 명확하게 식별되는 각 MiniApp에 대해 전용 저장 공간을 허용하며, 다른 MiniApp이 데이터에 접근하는 것을 제한합니다.

사용자 에이전트는 시스템에 앱을 설치할 수 있는 가능성(예: 홈 화면 바로가기, 데스크톱의 아이콘 등)을 제공할 MAY 있습니다. 이 과정은 투명하고 되돌릴 수 있는 것이 SHOULD 좋습니다. 최종 사용자가 앱을 제거하려는 경우, 사용자 에이전트는 관련된 모든 데이터가 기반 저장소에서 적절히 제거되도록 보장해야 MUST 합니다.

이 명세는 MiniApp 패키지의 기밀성을 보호하기 위한 어떤 암호화 메커니즘도 권장하지 않습니다. 그러나 특정 목적을 위해 일부 암호화 메커니즘을 구현하는 것을 배제하지는 않습니다.

A. 감사의 글

이 섹션은 비규범입니다.

편집자 참고
모든 기여자와 W3C 팀 연락처를 나열합니다

B. 서명 체계

이 섹션은 비규범입니다.

모든 사용자 에이전트는 필요에 따라 자체 디지털 서명 체계를 지원할 MAY 있습니다. 이 섹션에는 그림 4에 설명된 것처럼 디지털 서명 구현의 몇 가지 예가 포함되어 있습니다. 이는 개발자 검증 및 배포 중 MiniApp의 무결성과 같은 특정 시나리오에서 사용될 수 있습니다.

MiniApp 패키지의 서로 다른 서명 체계를 가진 서명 블록의 예
그림 4 MiniApp 패키지에 포함된 서로 다른 서명 방법의 예

B.1 RPK 서명 체계

MiniApp의 한 구현으로서 Quick AppsMiniApp 패키지의 저작권자를 검증하기 위해 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는 다음 하위 절에 설명되어 있습니다.

편집자 참고: package-splitting

사용자 에이전트가 사용자 경험을 개선하기 위해 MiniApp 패키지를 점진적으로 다운로드하고 실행할 수 있도록, MiniApp 패키지가 여러 하위 패키지로 분할되는 경우(예: 앱 스토어와 같은 배포 플랫폼에 의해)가 있습니다. 이러한 경우 각 하위 패키지뿐 아니라 전체의 무결성을 보장하기 위해 추가 서명 유형(따라서 ID)이 필요할 것입니다. 자세한 사항은 추가 연구 대상입니다.

B.1.1.1.1 개발자 서명

ID 0x01000101 아래 서명 블록의 ID-값 쌍은 전체 파일 MiniApp 패키지 서명의 데이터를 나타냅니다.

ID 쌍의 값은 모든 서명 블록을 포함하며, 가변 길이를 가지고 그 구조는 다음과 같습니다:

  • ID: 0x01000101 (uint32)
  • :
    • 서명자 블록의 크기, 이 필드 제외 (uint32)
    • 서명자 블록의 시퀀스:
      • 서명자 블록의 크기, 이 필드 제외 (uint32)
      • 서명된 데이터:
        • 다이제스트의 크기, 이 필드 제외 (uint32)
        • 다이제스트의 시퀀스:
          • 다이제스트 블록의 크기, 이 필드 제외 (uint32)
          • 서명 알고리즘 ID (uint32)
          • 다이제스트 콘텐츠의 크기, 이 필드 제외 (uint32)
          • 다이제스트 콘텐츠 (가변 길이)
        • 인증서 크기, 이 필드 제외 (uint32)
        • 인증서의 시퀀스:
          • 인증서의 크기, 이 필드 제외 (uint32)
          • ASN.1 DER 형식 [X690]의 X.509 인증서 [rfc2528] (가변 길이)
        • 추가 속성의 크기, 이 필드 제외 (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바이트 salt, trailer: 0xbc를 사용하는 RSASSA-PSS
  • 0x0102 SHA2-512 다이제스트, SHA2-512 MGF1, 64바이트 salt, trailer: 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 서명 체계에 설명된 패키징 서명의 서로 다른 단계를 포함할 MAY 있습니다.

이 서명 체계는 첫 번째 단계(개발자 서명 단계)에서 MiniApp의 프로비저닝 프로필과 개발자의 서명을 포함합니다. 두 번째 단계(배포자 서명 단계)에서 배포자는 개발자의 서명을 자신의 서명으로 대체할 MAY 있습니다. RPK 서명 체계와 마찬가지로, 이 접근 방식은 디지털 서명 요구사항에 따라 패키지 파일에 포함될 서명 블록을 생성합니다.

PKCS#7 서명 블록은 디지털 서명이 포함된 블록, PKCS #7 구문을 사용하여 암호화된 데이터, 그리고 서명 및 서명자 신원을 포함하는 데이터 컨테이너로 정의됩니다.

설명에서는 다음 기본 데이터 유형을 사용합니다:

uint64
64비트(8바이트) 부호 없는 정수
uint32
32비트(4바이트) 부호 없는 정수
uint16
16비트(2바이트) 부호 없는 정수

B.2.1 서명 블록 형식

PKCS#7 서명 블록의 형식은 다음과 같습니다:

  • 서명 블록 헤드
  • 서명 블록 헤드:
    • reserved (4바이트)
    • 블록 수 (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)
        • 블록 수 (uint16)
        • 콘텐츠 해시:
          • type (uint8)
          • tag (uint8)
          • algorithm ID (uint8)
          • length (uint32)
          • hash (가변 길이)
      • certificates: PKCS #6 확장 인증서 및 X.509 인증서 집합
      • crls: 인증서 폐기 목록 집합
      • signerInfos: 서명자별 정보의 모음
    • 서명자
  • Hw 서명 헤드:
    • 블록 수 (uint32)
    • size (uint32)
    • version (4바이트)
    • magic numbersMIX Sig Block 42” (16바이트)
B.2.1.1 서명 블록의 유형

블록 헤드의 유형은 그 속성 type으로 식별됩니다. 이 속성은 서로 다른 두 값을 가져야 MUST 합니다:

type 값이 0(파일 서명 블록)으로 설정된 경우, 헤더는 그 블록 헤드tag 속성을 사용하여 더 좁은 하위 유형을 지정해야 MUST 합니다. 이 하위 유형의 값은 다음과 같습니다:

  • 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, 섹션 3.6 [RFC6839]를 참조하십시오.
보안 고려사항:
application/zip에 적용되는 보안 고려사항은 MiniApp 패키지 파일에도 적용됩니다. MiniApp 패키지 파일을 처리하는 사용자 에이전트는 검색된 데이터의 크기와 유효성을 엄격하게 검사해야 합니다. MiniApp 패키지 파일에 디지털 서명이 있는 경우, 사용자 에이전트는 최종 사용자와 호스팅 플랫폼을 패키지 변조 또는 손상으로 인한 피해로부터 보호하기 위해, 디지털 서명에 따라 파일의 무결성과 신뢰성을 확인하는 데 필요한 메커니즘을 구현하는 것이 SHOULD 좋습니다. 자세한 내용은 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 Grouppublic-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