Me

#developer #interop #EU #w3c #huawei #standards

Contents

1. How it all started
2. MiniApp standardization
3. Status of the specs
4. Challenges

Challenges

• Development: how to code my MiniApp for n+1 SuperApps
  • Specific elements, APIs, ...
  • Scripts, third-party libraries...
  • Architecture and performance
• Publication: how to deliver it on different platforms (i.e., registration, validation, maintenance)
• Versioning and maintenance...

Based on Web

<template>
  <div class="main-page">
    <text class="title">{{title}}</text>
    <input type="button" onclick="changeText" />
  </div>
</template>

Based on Web

<template>
  <div class="main-page">
    <text class="title">{{title}}</text>
    <input type="button" onclick="changeText" />
  </div>
</template>

But... we don't interact directly with DOM

<script>
  export default {
    private: {
      title: 'This is a quick app'
    },
    changeText () {
      this.title = 'hello world'
    }
  }
</script>

But... we don't interact directly with DOM

<script>
  export default {
    private: {
      title: 'This is a quick app'
    },
    changeText () {
      this.title = 'hello world'
    }
  }
</script>

And... Wait!

<template>
  <div class="main-page">
    <text class="title">{{title}}</text>
    <input type="button" onclick="changeText" />
  </div>
</template>

Architecture

Execution environment

Services and APIs

Contents

1. How it all started
2. MiniApp standardization
3. Status of the specs
4. Challenges

World Wide Web Consortium

• Created 30 years ago! by Sir Tim Berners-Lee (now W3C Inc.)
• 680+ standards^* in 113 technology domains
• 364 Member organizations

Organization

• CEO + Board of Directors + supporting Staff
• Advisory Committee or AC - 364 reps. (one member, one vote)
• Advisory Board or AB: strategy
• Technical Architecture Group or TAG: technical guidance

Technical Reports, including Recommendations and Group Notes

How the work is done?

Members propose topics, work on them through

• Interest Groups (10 IG): requirements (e.g., Web Payments Security IG)
• Business Groups (2 BG): high-level reqs for verticals (e.g., Entertainment)
• Working Groups (43 WG): technical standards (e.g., CSS WG)
• Community Groups (143 CG): public incubation discussions (e.g., Web Incubation Community Group - WICG)

Liaisons with other SDOs

Ecma International, FIDO, ISO...

WG Charter

WG Charter: background

WG Charter: scope

WG Charter: deliverables

WG Charter: success

WG Charter: Patent Policy

Always working in public

Process (stages of a spec)

Specs are horizontally reviewed on i18n, a11y, privacy and security.

The Technical Architecture Group (TAG) plays an important role

Contents

1. How it all started
2. MiniApp standardization
3. Status of the specs
4. Challenges

MiniApp Lifecycle

Specific events and an interface for the MiniApp object and its pages

MiniApp lifecycle:

launched, shown, hidden, error…

Page lifecycle:

loaded, ready, shown, hidden, unloaded

Status: WD

• Spec: https://www.w3.org/TR/miniapp-lifecycle/
• Repo: https://github.com/w3c/miniapp-lifecycle

MiniApp Addressing

URIs for MiniApps

platform://miniapp/foo;version=1.0.1/pages/index?k=v#bar

https://platform.org/miniapp/foo;version=1.0.1/pages/index?k=v#bar

Status: Group Draft Note

• Spec: https://www.w3.org/TR/miniapp-addressing/
• Repo: https://github.com/w3c/miniapp-addressing

MiniApp Widgets Requirements

Scenarios and requirements for MiniApp Widgets (particular MiniApp pages)

Placed in a specific area of a device

Status: Group Note

• Spec: https://www.w3.org/TR/miniapp-widget-req/
• Repo: https://github.com/w3c/miniapp-widget-req

MiniApp Manifest

JSON document to describe a MiniApp

• Based on Web App Manifest (extends)
• 15 attributes with metadata for UA and publishers (icons, versions…)
• Runtime configuration (themes, colors, orientation…)
• Including permissions (i.e., sensors, network…) and discussing CSP

Status: WD

• Spec: https://www.w3.org/TR/miniapp-manifest/
• Repo: https://github.com/w3c/miniapp-manifest

Content Security Policy (CSP)

Increase security and integrity of MiniApps

• The system caches the MiniApp, and user agents do not always have access to HTTP headers.
• We need to guarantee security and avoid content and scripts from non-trusted origins.

Manifest CSP

Reuse of ongoing IWA proposal?

Content-Security-Policy: base-uri 'none';
      default-src 'self';
      object-src 'none';
      frame-src 'self' https: blob: data:;
      connect-src 'self' https: wss: blob: data:;
      script-src 'self' 'wasm-unsafe-eval';
      img-src 'self' https: blob: data:;
      media-src 'self' https: blob: data:;
      font-src 'self' blob: data:;
      style-src 'self' 'unsafe-inline';
      require-trusted-types-for 'script';
    

Open discussion

MiniApp Packaging

Describes the logical and physical structure of a MiniApp

• Pages, components, styles,…
• Packaging format, file-system, directories…
• Digital signatures (for developer, publishers, others…) - Optional

Status: WD

• Spec: https://www.w3.org/TR/miniapp-packaging/
• Repo: https://github.com/w3c/miniapp-packaging

Contents

1. How it all started
2. MiniApp standardization
3. Status of the specs
4. Challenges

#1: ZIP container

Raised concern of lack of efficiency

• Assessment based on existing implementations
• Availability of tooling
• Widely accepted format

#2: Origin model preservation

• MiniApps can be distributed in different ways (i.e., other than HTTP)

How to keep track of the origin?

#2: (Origin model) discussions

• UA SHOULD use SSL/TSL for distribution
• Package SHOULD be signed by the origin
• UA SHOULD keep track of the origin (e.g., save it in manifest?, UA decides?)

???

#3: Guarantee secure context

• MiniApps can be distributed in different ways (i.e., other than HTTP)
• UA platforms usually control distribution (i.e., root of trust, versioning)
• UA platforms generally limit access to external resources.

How to guarantee integrity?

#3: (Integrity) ongoing discussions

Based on the existing solution:

• Package SHOULD be hashed (integrity);
• and SHOULD be signed (e.g., developer + publisher)
• Who does the rest? (e.g., the UA platform?)

Ongoing discussion.

Follow IWA approach?

New works on Isolated Web Apps (IWA)

• CBOR-based container and distributed through HTTPS
• Signed Web Bundles + proposing a new Integrity Block

integrity-block = [
    magic: h'F0 9F 96 8B F0 9F 93 A6',
    version: bstr .size 4, ; Version value is '2\0\0\0' for release.
    attributes: {
      "webBundleId" => tstr
    }
    signature-list: [ +integrity-signature ]]

Also, defining permissions in manifest and CSP

May we standardize a global security model for SuperApps?

Avoiding fragmentation

Secure and protecting user privacy

1. Origin model preservation
2. Secure context (integrity)
3. Content security policy
4. Permission management
5. ...