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은 디지털 수단을 통해 배포될 수 있고 웹을 통해 접근할 수 있는 경량 소프트웨어 애플리케이션의 개념입니다. 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을 실행합니다.
다음 용어는 MiniApp에 특화된 것입니다.
비규범으로 표시된 섹션뿐 아니라, 이 명세의 모든 작성 지침, 다이어그램, 예제 및 참고는 비규범입니다. 이 명세의 그 밖의 모든 내용은 규범적입니다.
이 문서의 핵심 단어 MAY, MUST, MUST NOT, SHALL, SHOULD, 및 SHOULD NOT은 여기에 표시된 것처럼 모두 대문자로 나타날 때에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석됩니다.
MiniApp Packaging 명세는 알고리즘을 설명하기 위해 Infra Standard [INFRA]에 의존합니다.적합한 MiniApp 패키지는 다음 기준을 충족해야 MUST 합니다:
pages 하위
디렉터리를 기반으로 한 파일 구조를 가져야
MUST 합니다.
common 하위 디렉터리를 포함할 MAY 있습니다.
i18n 하위 디렉터리를 포함하는 것이
SHOULD 좋습니다.
manifest.json이라는 구성 파일 하나를 포함해야 MUST
합니다.app.js라는 스크립트 문서 하나를 포함해야 MUST 합니다.
app.css라는 스타일시트 하나를 포함해야 MUST 합니다.
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)와 같은 리소스 유형을 정의합니다.
개발자는 필요에 따라 다른 유형의 리소스를 포함할
MAY 있습니다. 또한, 페이지와 관련된 파일(동일한 파일명으로 식별됨)은 각
페이지별 특정 하위 디렉터리에 구성하거나 pages 디렉터리 바로 아래에 저장할 MAY 있습니다.
/
|___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의 페이지에서 접근할 수 있는 구성요소, 멀티미디어 리소스, 문서 및
라이브러리와 같은 리소스를 포함합니다.
이 디렉터리의 내부 구조는 유연하므로, 이러한 공통 리소스는 필요에 따라 사용자 지정 하위 디렉터리에
구성하고 서로 다른 이름 규칙을 사용할 MAY 있습니다.
선택적 i18n 디렉터리는 루트 디렉터리의 하위 디렉터리로, MiniApp 패키지의 현지화 리소스를 포함합니다.
i18n 디렉터리는 MiniApp 콘텐츠의 국제화를 지원하기 위한
다국어 현지화 리소스를 포함합니다. 이 디렉터리에 있는 각
.json 문서의 파일명은 [BCP47]에서 정의한 Language-Tag
표기법을 따르며, 해당 특정 언어에 대한 구성을 나타냅니다.
i18n 디렉터리는 MiniApp이 지원하는 언어 또는 로케일 수만큼 많은 현지화 리소스를 포함할 MAY 있습니다. 이러한 파일의 형식은 현지화 리소스 섹션에서 정의됩니다.
MiniApp 패키지 안의 모든 파일명과 경로명은, Internationalization Best Practices for Spec Developers에서 명시한 것처럼 운영체제의 잠재적 제한을 수용하고 대부분의 플랫폼 및 파일 시스템과의 상호운용성을 촉진하기 위해 다음 제한사항을 준수해야 MUST 합니다.
동일한 디렉터리 안의 모든 파일명은 Unicode 정규 정규화 [UAX15]와 그 이후의 전체 대소문자 폴딩 [Unicode]에 따라 고유해야 MUST 합니다. (자세한 내용은 Unicode Canonical Case Fold Normalization Step [CHARMOD-NORM]를 참조하십시오.)
MiniApp
페이지는 최소한 HTML 리소스로 구성되며, 선택적으로 CSS 리소스 및/또는 스크립팅 리소스를
포함할 수 있습니다. 이러한 관련 리소스는 MiniApp 매니페스트
[MINIAPP-MANIFEST]의 pages
멤버에 지정되어야 하는 고유한 페이지 라우트를
통해 MiniApp 페이지를 식별하기 위해 동일한 경로와 파일명(파일 확장자만 변경)을
가져야 MUST 합니다.
/
|___pages/
|___product/
|___product.html
|___product.css
|___product.js
HTML 리소스는 MiniApp 페이지와 그 사용자 인터페이스를 정의하기 위한 마크업과 정보를 포함하는 문서이며, 여기에는 구조, 시각적 구성요소 및 상호작용 요소가 포함됩니다.
HTML 리소스는 다음 기준을 모두 충족해야 MUST 합니다:
.html을
사용하는 것이 SHOULD 좋습니다.CSS
리소스는 MiniApp 페이지의 렌더링과 외형을 설명하는 스타일시트입니다. CSS 리소스는
전역적일 수 있어 MiniApp의 모든 페이지에 영향을 미치거나(즉, 루트
디렉터리의 app.css), 특정 페이지에만 영향을 미치는 로컬 범위를 가질 수 있습니다.
이 명세는 [CSS-SNAPSHOT]에 정의된 CSS 모듈을 지원합니다.
CSS 리소스는 다음 기준을 모두 충족해야 MUST 합니다:
app.css라는 이름을 가져야 하고 루트
디렉터리에 저장되어야 MUST 합니다.
.css를
사용하는 것이 SHOULD 좋습니다.스크립팅
리소스는 애플리케이션의 비즈니스 로직과 기능을 제어하고,
상호작용성을 추가하며 MiniApp의 생명주기를 관리하기 위한 스크립트 요소와 데이터를 포함하는 문서입니다.
모든 페이지에서 사용할 수 있는 데이터와 함수를 포함하고 애플리케이션의
생명주기를 제어하기 위한 특정 로직을 포함하는 전역 스크립팅
리소스(즉, 루트
디렉터리의 app.js)가 있습니다. 각 MiniApp 페이지는 구체적인
페이지로 범위가 제한된 특정 스크립팅 리소스를 연결할 MAY
있습니다.
스크립팅 리소스는 다음 기준을 모두 충족해야 MUST 합니다:
app.js라는 이름을 가져야 하고 루트
디렉터리에 저장되어야 MUST 합니다.
.js를
사용하는 것이 SHOULD 좋습니다.MiniApp 현지화 리소스는 MiniApp의 국제화 메커니즘의 일부로 현지화된 콘텐츠를 포함한 MiniApp 패키지의 문서입니다.
다국어 MiniApp은 시스템 로케일 또는 사용자의 언어 기본 설정에 따라 콘텐츠를 렌더링하기 위해 사용자 에이전트가 현지화 과정에서 사용할 여러 현지화 리소스를 가질 MAY 있습니다. 이러한 리소스는 현지화 가능한 용어나 표현의 고유 식별자(키)와 구체적인 언어에서의 표현(값)을 포함하는 키-값 쌍의 JSON 객체를 포함합니다.
{
"title": "멋진 MiniApp",
"about": "이 MiniApp 정보",
"intro-page": {
"title" : "소개",
"main" : "이것은 페이지의 본문입니다"
}
}
현지화 리소스는 다음 기준을 모두 충족해야 MUST 합니다:
.json을 사용하는 것이 SHOULD 좋습니다.
이 섹션은 비규범입니다.
MiniApp ZIP 컨테이너는 다음과 같은 다양한 시나리오에서 배포에 사용할 수 있는 MiniApp의 물리적인 단일 파일 표현입니다:
MiniApp ZIP 컨테이너는 단일 파일 안에 MiniApp 패키지 구조에 따라 MiniApp을 구성하는 모든 리소스를 포함합니다. 이 형식은 압축 메커니즘의 사용을 지원합니다.
MiniApp ZIP 컨테이너는 [ZIP]에서 정의된 ZIP 형식을 사용하며, 다음과 같은 몇 가지 특성이 포함됩니다:
0, 파일 저장) 및 Deflate 압축(메서드 0, 무손실 데이터
압축) 콘텐츠를 포함해야 MUST 합니다.
2.0
(폴더 및 Deflate 압축 지원)입니다.MiniApp ZIP 컨테이너의 구조는 다음과 같습니다:
[ZIP 파일 엔트리]
[MiniApp 서명 블록]
[ZIP 중앙 디렉터리]
[ZIP 중앙 디렉터리 끝]
MiniApp ZIP 컨테이너는 먼저 ZIP 중앙 디렉터리의 시작 위치를 찾는 방식으로 구문 분석됩니다(파일 끝에서 ZIP 중앙 디렉터리 끝 레코드를 찾은 다음, 해당 레코드에서 중앙 디렉터리의 시작 오프셋을 읽음). 모든 MiniApp 서명 블록은 디지털 서명의 존재를 식별하기 위해 서명 블록 매직 넘버 블록을 포함할 MAY 있으며, 이는 디지털 서명 요구사항에 명시되어 있습니다. 일단 "매직 넘버" 블록이 인식되면, 사용자 에이전트는 디지털 서명을 처리할 수 있으며, 이는 그림 2에 표시된 것처럼 중앙 디렉터리의 바로 앞 섹션에 있는 서명 블록에 저장됩니다.
MiniApps 공급업체는 필요에 따라 디지털 서명 체계를 채택할 MAY 있습니다.
MiniApp 파일은 파일 확장자의 사용이 필수는 아니지만 .ma 파일 확장자로 식별될 MAY 있습니다.
MiniApp ZIP 컨테이너는 소프트웨어의 보호된 부분에 대한 변경 사항을 감지하여 MiniApp의 무결성을 보장하는 데 도움이 되도록 서명을 포함하지 않거나, 하나 또는 여러 개 포함할 MAY 있습니다.
MiniApp 서명 블록은 MiniApp에 부분적으로 또는 전체적으로 영향을 주는 디지털 서명에 대한 특정 정보와 메타데이터를 포함하는 바이트 모음입니다. 서명 블록은, 존재하는 경우 블록을 더 쉽게 찾을 수 있도록 MiniApp ZIP 컨테이너의 중앙 디렉터리 바로 앞에 위치해야 MUST 합니다.
서명 블록 매직 넘버 블록은 MiniApp ZIP 컨테이너의 서명 블록에 저장되는, MiniApp 패키지의 디지털 서명 메커니즘을 식별하는 고유한 지문을 가진 16바이트 시퀀스입니다.
이 문서가 특정 디지털 서명 메커니즘(예: 해시 알고리즘, 암호화 방법 등)을 권고하지는 않지만, 서명 블록이 존재하는 경우 다음 기준을 충족해야 MUST 합니다:
국제화는 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 패키지를 역참조, 구문 분석 및 실행하기 위해 다음 알고리즘을 따라야 MUST 합니다.
MiniApp 패키지를 처리하려면, URL miniapp_uri가 주어졌을 때 다음 단계를 수행합니다:
사용자 에이전트는 네트워크를 통해 파일을 가져오거나(즉, HTTPs, WebSocket, FTP 또는 기타 특정 TCP/UDP 기반 프로토콜 사용), 파일 시스템 또는 기타 메커니즘을 사용하여 서로 다른 채널을 통해 MiniApp ZIP 컨테이너를 획득할 MAY 있습니다.
MiniApp ZIP 컨테이너를 가져오기 위해, URL miniapp_uri가 주어졌을 때 다음 단계를 수행합니다. 이는 MiniApp ZIP 컨테이너를 반환합니다.
application/miniapp-pkg+zip과 같지 않으면 실패를 반환합니다.
사용자 에이전트는 디지털 서명을 검증하고 암호화 메커니즘을 적용함으로써 MiniApp ZIP 컨테이너와 그 콘텐츠의 정당성 및 무결성을 보장할 MAY 있습니다.
MiniApp ZIP 컨테이너를 검증하려면, MiniApp ZIP 컨테이너 miniapp_zip_file가 주어졌을 때 다음 단계를 수행합니다:
MiniApp ZIP 컨테이너는 하나 이상의 서명을 포함하는 서명 블록을 포함할 MAY 있습니다. 서명 체계와 암호화 메커니즘은 사용자 에이전트의 구체적인 구현에 따라 달라집니다.
서명 체계는 MiniApp ZIP 컨테이너에 포함된 매직 넘버 섹션으로 식별되며, 이는 ZIP 패키지의 중앙 디렉터리 바로 앞에 위치한 16바이트 시퀀스입니다.
디지털 서명을 처리하려면, MiniApp ZIP 컨테이너 miniapp_zip_file가 주어졌을 때 다음 단계를 수행합니다:
0x06054b50(리틀 엔디언으로 읽음) 바이트 시퀀스를 찾은 결과인 byte sequence로 둡니다
[ZIP].
사용자 에이전트는 MiniApp에 대한 전역 메타데이터를 포함하며 MiniApp 패키지에 위치한 MiniApp 매니페스트를 구문 분석해야 MUST 합니다.
MiniApp 매니페스트를 처리하려면, MiniApp Package miniapp_package가 주어졌을 때 다음 단계를 수행합니다. 이는 ordered map을 반환합니다.
manifest.json 파일이
존재하지 않으면 실패를 반환합니다.manifest.json을 전달하여
바이트에서 JSON을
구문 분석한 결과로 둡니다.
사용자 에이전트는 로직 계층과 뷰 계층을 모두 포함하는 런타임 환경을
준비하는 것이 SHOULD 좋습니다. 로직 계층은 애플리케이션의 로직과
제어를 담당합니다(즉, app.js 및 page.js 파일). 뷰 계층은 컴포넌트
템플릿 및 스타일시트와 같은 페이지 리소스 파일을 포함하여 시각적 환경과 렌더링을 담당합니다.
MiniApp 실행을 준비할 때, 사용자 에이전트는 MiniApp
매니페스트 메타데이터가 지정한 구성으로 환경을 설정해야 MUST
합니다.
사용자 에이전트는 다음 알고리즘에 따라 시작 페이지를 MiniApp 진입점으로 식별하고 로드해야 MUST 합니다.
플랫폼 런타임을 준비하려면, URL miniapp_uri와 ordered map manifest가 주어졌을 때 다음 단계를 수행합니다. 이는 MiniApp 시작 페이지를 반환합니다.
app.js가 존재하지 않으면 실패를 반환합니다.app.css가 존재하지 않으면 실패를 반환합니다.사용자 에이전트는 MiniApp이 자신들과 호환되고 해당 플랫폼에서 제대로 실행될 수 있는지 검증해야 MUST 합니다. 이 검증은 플랫폼의 지원 버전과 실행에 필요한 페이지 및 리소스 확인을 포함하여 MiniApp 매니페스트에 지정된 메타데이터를 사용하여 수행됩니다.
플랫폼 호환성을 검증하려면, MiniApp Package miniapp_package와 ordered map manifest가 주어졌을 때 다음 단계를 수행합니다:
기본적으로, 사용자 에이전트는 MiniApp이 실행될 때 MiniApp 매니페스트에 표시된 시작 페이지를 진입점으로 로드해야 MUST 합니다. 이 기본 시작 페이지는 다음 알고리즘에 명시된 것처럼, MiniApp URI에 유효한 페이지가 지정된 경우 재정의되어야 MUST 합니다.
시작 페이지를 결정하려면, MiniApp Package miniapp_package, URL miniapp_uri, 및 ordered map manifest가 주어졌을 때 다음 단계를 수행합니다. 이는 URL을 반환합니다.
MiniApp URI는 URI의 URL-path-segment string으로 지정된 시작 페이지에 관한 정보를 포함할 MAY 있습니다.
URI에서 시작 페이지를 추출하려면, URL miniapp_uri가 주어졌을 때 다음 단계를 수행합니다. 이는 URL을 반환합니다.
MiniApp
Manifest의 pages 멤버 [MINIAPP-MANIFEST]에서
설명한 것처럼, MiniApp의 시작 페이지는 pages list의 첫 번째 항목에 지정됩니다.
매니페스트에서 시작 페이지를 추출하려면, ordered map manifest가 주어졌을 때 다음 단계를 수행합니다. 이는 string을 반환합니다.
로케일을 추출하려면, ordered map manifest가 주어졌을 때 다음 단계를 수행합니다. 이는 string을 반환합니다.
이 섹션은 비규범입니다.
이 명세는 MiniApp을 논리적 및 물리적 관점에서 정의하며, 그 내부 파일 구조와 서로 다른 리소스가 단일 파일 안에 패키징되는 방식을 상세히 설명합니다. 또한 이 문서는 MiniApp 사용자 에이전트가 MiniApp 컨테이너를 검색하고 처리하기 위한 알고리즘을 포함합니다.
MiniApp Packaging 명세는 사용자 에이전트가 MiniApp 컨테이너와 그 콘텐츠를 처리하여 내부
리소스(즉, HTML, 스타일시트, 스크립팅 등)와 구성(즉, 매니페스트,
app.ux)을 기반으로 사용자 인터페이스와 구체적인 동작을 생성하도록 요구합니다. 패키지를 가져오고 처리한 후,
사용자 에이전트는 모든 잠재적 시나리오에서 지각 가능하고 조작 가능한 사용자 인터페이스와 렌더링된 콘텐츠를
제공하는 것이 권장되며, 스타일시트를 사용하여 사용자의 요구사항에 맞게 외형을 조정할 수 있게 하고,
manifest.json의 일부 멤버(MiniApp Manifest)에서 요구하는 대로
창과 뷰포트의 표시 옵션 및 방향을 구성하고 제어할 수 있는 가능성을 제공해야 합니다.
이 문서에서 명시하지는 않지만, 사용자 에이전트는 사용자 상호작용에서 접근성 측면을 보장하는 것이 권장됩니다. 예를 들어 전체 키보드 접근을 제공하거나 대체 입력 장치를 지원하고(가능한 경우), 사용자가 사용자 경험을 개선하기 위해 기본 설정을 저장할 수 있게 하는 것입니다. MiniApp 사용자 에이전트와 플랫폼은 애플리케이션을 렌더링하고 상호작용하기 위한 메커니즘을 제공하고, 보조 기술의 통합을 촉진하며, 적용 가능한 명세와 관례, 특히 User Agent Accessibility Guidelines (UAAG) 2.0을 준수해야 합니다.
이 명세는 앱의 진입점과 서로 다른 라우트(즉, 매니페스트의 pages
멤버)를 지정하는 구체적인 구성을 통해 MiniApp을 패키징, 배포 및 로드하는 메커니즘을 정의합니다. 사용자 에이전트는 로드할 리소스 유형을 제한하고
기본적으로 강력한 기능에 대한
접근을
차단하는 샌드박스 환경을 구현함으로써 초기화 및 로딩 단계에서의 잠재적 취약점을 완화하는 것이 SHOULD
좋습니다.
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 좋습니다.
MiniApp의 배포 단계에서 무결성과 신뢰성을 보장하기 위해, MiniApp 패키지는 하나 이상의 디지털 서명으로 보호되는 것이 SHOULD 좋습니다. 이러한 서명은 신뢰할 수 있는 기관이 발급한 인증서와 함께, 제3자가 MiniApp의 저작자(예: MiniApp 개발자) 및 소프트웨어의 개발이나 배포에 관여한 다른 주체(예: MiniApp 배포자로서의 앱 스토어)를 검증하는 데 도움이 될 수 있습니다.
MiniApp에 디지털 서명이 포함되는 일반적인 시나리오는 다음을 포함하지만, 이에 한정되지는 않습니다:
이 명세에서는 특정 디지털 서명 메커니즘, 암호화 기술 또는 알고리즘을 권장하지 않습니다. MiniApp 공급업체는 사용 사례에 따라 디지털 서명 메커니즘을 구현할 MAY 있습니다. 구현되는 경우 3.3 디지털 서명 요구사항을 따라야 SHALL 합니다.
일부 기술과 암호화 방법은 B. 서명 체계에 소개되어 있습니다.
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 패키지의 기밀성을 보호하기 위한 어떤 암호화 메커니즘도 권장하지 않습니다. 그러나 특정 목적을 위해 일부 암호화 메커니즘을 구현하는 것을 배제하지는 않습니다.
이 섹션은 비규범입니다.
이 섹션은 비규범입니다.
모든 사용자 에이전트는 필요에 따라 자체 디지털 서명 체계를 지원할 MAY 있습니다. 이 섹션에는 그림 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 패키지를 점진적으로 다운로드하고 실행할 수 있도록, MiniApp 패키지가 여러 하위 패키지로 분할되는 경우(예: 앱 스토어와 같은 배포 플랫폼에 의해)가 있습니다. 이러한 경우 각 하위 패키지뿐 아니라 전체의 무결성을 보장하기 위해 추가 서명 유형(따라서 ID)이 필요할 것입니다. 자세한 사항은 추가 연구 대상입니다.
ID 0x01000101 아래 서명 블록의 ID-값 쌍은 전체 파일 MiniApp 패키지 서명의
데이터를
나타냅니다.
ID 쌍의 값은 모든 서명 블록을 포함하며, 가변 길이를 가지고 그 구조는 다음과 같습니다:
0x01000101 (uint32)배포자의 서명은 배포 과정에서 애플리케이션의 무결성을 보존하며, 패키지가 신뢰할 수 있는 배포자에 의해 검증되고 배포자의 권한 제어 정책(프로비저닝 프로필 형식)이 패키지에 적용되도록 보장합니다.
배포자 서명 과정에서 배포자 또는 개발자는 프로비저닝 프로필을 추가하고 배포자의 개인 키를 사용하여 서명에 서명합니다.
프로비저닝 프로필은 ID 0x02000201
아래 서명 블록의 ID-값 쌍에 저장됩니다.
ID 쌍의 값은 모든 서명 블록을 포함하며, 가변 길이를 가지고 그 구조는 다음과 같습니다:
0x02000201 (uint32)0x0101 SHA2-256 다이제스트, SHA2-256 MGF1, 32바이트
salt, trailer: 0xbc를 사용하는 RSASSA-PSS0x0102 SHA2-512 다이제스트, SHA2-512 MGF1, 64바이트
salt, trailer: 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 서명 체계에 설명된 패키징 서명의 서로 다른 단계를 포함할 MAY 있습니다.
이 서명 체계는 첫 번째 단계(개발자 서명 단계)에서 MiniApp의 프로비저닝 프로필과 개발자의 서명을 포함합니다. 두 번째 단계(배포자 서명 단계)에서 배포자는 개발자의 서명을 자신의 서명으로 대체할 MAY 있습니다. RPK 서명 체계와 마찬가지로, 이 접근 방식은 디지털 서명 요구사항에 따라 패키지 파일에 포함될 서명 블록을 생성합니다.
PKCS#7 서명 블록은 디지털 서명이 포함된 블록, PKCS #7 구문을 사용하여 암호화된 데이터, 그리고 서명 및 서명자 신원을 포함하는 데이터 컨테이너로 정의됩니다.
설명에서는 다음 기본 데이터 유형을 사용합니다:
PKCS#7 서명 블록의 형식은 다음과 같습니다:
MIX Sig Block 42” (16바이트)SignedData로 설정됨:
MIX Sig Block 42” (16바이트)블록 헤드의 유형은 그 속성
type으로 식별됩니다. 이 속성은 서로 다른 두 값을 가져야 MUST
합니다:
01type 값이 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 블록 해시 트리)이 부록은 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: