Meeting minutes
Welcome and administrivia
martin: since the chairs are not able to attend today, I'll moderate today's meeting
… we're following the Code of Ethics and Professional Conduct
martin: I'll present the current status of the miniapp specs
… I'll try to be very briefly
… and talk about the next steps and the issues
… we'll also talk about implementations and testing
… we'll also talk about recharter
… @@1
… we created a white paper
https://
martin: in 2021 we launched the WG
… working on Manifest, Lifecycle, and Packaging
… we also have components and IoT
… we requested wide review re i18n privacy security a11y etc.
… there are still some open issues to resolve
… miniapp manifest is based on web app manifest
martin: some members have overlap with the web app manifest
… I'll mention them later
… the host of the miniapp could be a 'super app' or the operating system
… since MiniApps can be distributed in a package
… it includes information like app store etc.
… we have an open issue about miniapp manifest on i18n
… I'm following the same issue in the web app manifest
… because they have the same issue
… we'll align with them
… another issue is how to guarantee the security in MiniApps
… the TAG has some comments on this
… one of the proposals was to include a content security policy directly in the manifest
… I've seen this is something that is considered in Isolated Web Applications
… this is a very early proposal and we need to discuss it
… comments welcome
[martin shows the proposal]
DKA: wasn't there also a signing part of that?
martin: yes
… it's related to packaging
… will mention it later
… also the ID of the app is an issue
… tomayac mentioned some members like permissions to align with IWA
… MiniApp Lifecycle
… it has events and interfaces for MiniApps like launched etc.
… QingAn is the main editor of this spec
QingAn: for the application lifecycle, previously we agreed that there should be an additional event which is the unloaded
… the slides need to be updated
martin: yeah
… MiniApp Addressing
Dan_Zhou: after the last TAG review of MiniApp Addressing
… we have rewritten a large part of MiniApp Addressing
… to use both http and custom scheme
… use the deeplinking technology
… the explainer still needs updating
… and we plan to submit it for TAG review
martin: there are similar discussions in IWA
… we should discuss with them
… widgets
… widgets is a special form of MiniApps
martin: type of recources in miniapps
… HTML, CSS, JS, and i18n resources
martin: so far the spec is very vague in terms of i18n
… we need to perhaps add more information on how i18n works for MiniApps
… re components, we agree that we want to follow the web components work
… we won't reinvent the wheel
[martin shows the packaging structure]
martin: manifest.json
… app.js, app.css
… pages/
… common/
… i18n/
[Summary of Open Issues in MiniApp Packaging]
martin: 1. Preservation of the origin model
… 2. Secure context
… this is crucial
… how to avoid tampering the content of a miniapp
… we try to avoid any gatekeeper
… 3. Efficiency of ZIP container
… ZIP is not efficient but it's most commonly used in existing MiniApps
… this is somethinig we should discuss
… we have a proposed solution: w3c/
martin: the last proposal we have was proposed by Dan Zhou
… do you want to introduce this, Dan Zhou?
Dan_Zhou: it's mostly written by Jia Wang
Q: does the manifest include permission information?
martin: yes
Q: 8 years ago, Firefox did something similar
… at the time, Mozilla tried to add all those as web APIs
… in some cases maybe it does not apply to MiniApps, but in other cases there might be something like location
… maybe MiniApps can also use this
martin: it's like native apps, we still need to define what are the capabilities we use for accessing powerful features
martin: please correct me if I understand wrong about this proposal
<michielbdejong___> Hi, Michiel de Jong here, I asked the question about permissions in the manifest
martin: @@1
… something similar with content security policy
DKA: I don't understand what you're saying about the miinapps will be delivered on the web
… my understanding was the architecture is that an intermediary delivers the miniapp to the end user
… nothing else is required in order to operate using the same origin policy
… so I'm little confused @@
martin: so far we only defined the signature mechanism
… but we haven't defined the specific requirements of using the signatures
DKA: from a developer workflow perspective, app store provider works with the application developer
… Starbucks have their miniapp
… the intermediary upstream provider might add an additional signature
… the chain of trust is clear because the first party is the one that actually produced the app
DKA: @@
sangwhan: there's a description of what will be used to mitigate this but there's not much information about how
… I think the group would probably need to elaborate on that
… you could use self-signing certificates
… and how does that fit into the origin model
… that's actually not a fully solved problem yet
… I think the IWA folks are working really hard to figure out
… so you could potentially reuse some of that effort for it
… I think you're looking at a very similar problem space
[martin introduces the proposal in w3c/
martin: this is not specified in the spec
… but if you believe this could solve the problem we can elaborate this and recommend it
… so far we haven't recommended anything to solve the problem, but we can do
… we have 2 proposals
… w3c/
… this is kind of similar to the epub format
martin: could adding these signatures inside the package be enough to solve the problem?
… and include more information about how to @@
DKA: I think the initial TAG feedback that we gave was this looks like a step in the right direction
… this is an attempt to satisfy the requirement
… to align with the web security model
… architecturally it would be lovely if everything was aligned
… I think requirements in IWAs might be slightly different overlapping but not exactly the same
… miniapp group has been working for a number of years, but if IWA is trying to solve similar problems
… maybe there should be some discussions going on between IWA and here
… I think we would like to see more details on how
… and maybe an end to end demo or something like that
… to use a signature based model like this
… but as I said, initial TAG feedback is this looks like a step in the right direction
Yves: just wanted to say that in the case of IWA, it's a bit different
… because IWA is served through the origin, here you need to ensure that the origin is the right one as it can be sent via an intermediary
… maybe you could send it to the web app security group
martin: we haven't included all the details
… that's why we need to discuss this
sangwhan: we didn't say this is not enough
… we're trying to digest the situation at the moment
… I think one of the potential difficulities with this particular kind of approach is that there's no concrete mechanism for associating an origin with a signing certificate
… probably like a way to use well knowns to to associate signing keys to origins
… as of today, that mechanism is missing
martin: I totally agree that we need to solve this problem
sangwhan: the reason why we emphasize this is because these kind of security mechanisms are very difficult
… it can be a significant amount of effort
… to be honest, we mentioned stuff about the zip file format because if you want to do patches like partial downloads it's not so great
martin: we will continue the discussion
… we will send some direct proposals to you with some solutions
sangwhan: since your folks are all here, you could try to get some time to try to reach out to the IWA folks
… I think most of them are here
martin: since we don't have all the people on the call
… we can continue this offline
… and send a more complete proposal to TAG as a follow up
Implementation and testing of MiniApp specs
martin: we almost haven't started implementation
… we only have a couple of tests
… so far we already have a process
… I created some tests
… it's very manual
… if we have something semi automatic, it could be even better
… but I think we don't have @@
[martin summarizes the TAG discussions]
[TAG left]
martin: we should start as soon as possible with tests
… if we don't have any specific tool for automation
martin: I propose that we use the current framework
… we need to start testing the specs
… this is time consuming
… I volunteer to help anyone who will test
… and we can even open this to the community to help us to create tests
… the next thing is implementations
… any update on the status of implementations?
WG re-chartering
martin: as you might know we had some formal objections on the new charter
<martin> https://
martin: there were 3 formal objections
… the first formal objection is about adding more context about the miiniapp ecosystem
… and previous efforts in the W3C community
… I agree
… it's something that we can include
… it's part of the hisitory
martin: some of them were abandoned because they did not succeed
… the second deliverable is about the miniapp components
… I think that was misunderstood
… at the time of the review of the recharter
… it was in a very early stage
… and it was a bit confusinig
… now we have inicluded a new revisioni
… created 12 or 13 new sectionis
… iit's not our definitioini of components
… it reuses web components
… not reiinventiinig the wheel
… iin this case II think we could speak directly to hiim
xfq: @@ normative
martin: if we want to make iinformative we can avoid any fricgtion witht e web componets community
… currently it's more or less informative
… @@
<QingAn> agree from me
martin: so the plan iis to remove it in the WG charter and incubate iit more in the CG for now
… any more comments form miniapp vendors?
… any maybe publiish it as a note in the future
… II think the versoin chaals read was outdated
… the current versoini is better
… I think it was jus ta misunderstanding
… the next objection is i18n
… we haven't included anythiing wrt i18n
… we only have an i18n directory
… I suppose we can find previous art
… it would be nice to have a conversation with chaals to cover these issues
[Discuss chaals' comments]
Open discussion on the direction of MiniApps
martin: we have to look at the work of IWA
… I was in the sessiion on Monday afternoon
… yesterday there were also some sessions about IWA
… they have a specific package format
… based on secure web bundles
… they also offer the possibility to stream
… they also use web app manifest
… with some changes
… their content security policy is similar
… and also on how to define these powful APIs
… I recommend to keep an eye on this work
… and perhaps having a meeting with them
Combination of MiniApps and AI
Dan_Zhou: Baidu is refactoring all products to include AI
… and that includes miniapps
… we integrated the development environment with a code assistant
[Dan Zhou shares her screen]
Dan_Zhou: Comate is Baidu's code assistant based on LLM
… it can auto complete and explain code
… it wlil be publiished later
… we also developed a answersing system based on LLM for miniapp documents
… I think in the near future, developing MiniApps can be simpler
… I think this is a future direction for miniapps
martin: is this public?
… this could be interesting for developers to develop MiniApps according to our specs
Dan_Zhou: the latest development environment includes Comate
… but need invite
… I can invite you to try it
martin: any other topics?
… we should talk with webapps WG to collaborate on IWA
… please think about tests
[Martin summarizes today's meeting]