Amy: do we need to look at this to resolve lifecycle..?

Dan: I think we do. It's about the role of the intermediary in the lifecycle. I think the packaging seems to indicate that... zip based.. can be delieved through an intermediary.. web or offline..

Sangwhan: explanation about it all being bound to origin doesn't make sense

Dan: unless there is some kind of web packaging-like cryptographically secure approach to being able to claim that it is that origin? That's what web packaging is all about

Sangwhan: this is a competing proposal to web packaging. There's a comparison here. All of this aside, why are they using zip? Goes back to.. if it's executable by super app (web runtime) or a browser this would mean that there must be some level of origin guarantees bound into this. Web packaging has that sorted out because everything has to originate from the origin. one of the problems with web packaging is becuase of that limitationa nd certain constraints put in for security reasons it is not a very adequate vessel for shipping offline apps in specific cases, not fully addressed yet, in the works.

Dan: this did seem to be coming at it more from that perspective, where offline is ..

Sangwhan: first use case... digital signatures?

Dan: PKCS7 (?).. would it be appropriate to feed back and ask how this fits together with the web security model in terms of guaranteeing origin provenance?

Sangwhan: some level of guarantee about provenance. Other problematic parts is that there is .. this kind of approach has a problem where there is no way to deal with scenarios such as certificate revocation in a nice way. Digital signatures, the certificate chain is likely to be outside of the browser root store. That was a problem found in the context of widgets - made the same mistake. They used an app signing mechanism. Digital signatures don't fit in with the model of the web, in particular when it comes to secure delivery and provenance. You put yourself at the mercy of whatever digital signature mechanism and the trust chain that issues this. May not be as rigorously validated as the root stores brwosers are shipping. Other part is .. technical.. zip is terrible for online resource package addressing. The reason is the header of the zip file - table of contents - is at the end. So you need to download the whole thing before you know what's in it. Cna't do random addressing easily. Can't parallelise loading of resources, that's not possible. If you want to address certain subresources wihin the package, zip makes it very difficult as you are downloading the whole thing anyway, which is why it was not chosen for web packages.

Dan: am I thinking correctly that there's a dependency between webapp lifecycle review and this review? THis seems to be a vital part of the lifecycle.

Sangwhan: i believe so

Max: the explainer suggested, I'm not sure whether miniapp packaging needs to have the dependency on lifecycle. There is a section explains the relationship of the proposals.

Dan: that might simplify things. THe main issue we seem to be having around miniapp lifecycle proposal.. was this origin issue. If the origin issue is more oriented around the packaging proposal maybe we ought to think about closing lifecycle and putting our focus on the discussion within packaging

Max: yes

Sangwhan: indifferent.

Dan: [notes we will set up call to discuss]

can we organise a special session?

Yves: re: security model - i think the security model is given by the app store - that's why there is no need to have cryptography. The fact that it's through an app store and should have a review before entering the appstore.

Sangwhan: bundles and signed exchanges have been trying to solve this... they need to find the missing cases for their use cases. Push back from the mini-app community. Also exchanges still have issues. But I would like them to work with the people on Exchanges to have a common solution because it does solve the provenance problem and origin problem. Using the app store as a gating mechanism to filter out bad actors ... doesn't work.

Dan: +1

Yves: there are automated checks that can verify a few things but not filter out all the bad actors.. what's at stake is ensuing you can act as an origin.

Sangwhan: if you treat the app store as a CDN then you can get a lot of that for free.

Yves: will try to arrabnge discussion...

some work on miniapp feedback doc - Max & Yves happy with it - Dan will bring over to github so we can discuss & agree at the plenary

Dan: they want to have a discussion with us about our feedback. Their issue

[scheduling - 30 mins 2nd half in Breakout C Dec 13th - Yves asking if it suits]

Dan: you wanted to chat about the feedback we had sent. We were talking about packaging, in the context of lifecycle of a miniapp, and the whole question of being able to make use of the web security model is the key point. This was a TAG consensus document. As a recent example we wanted to draw your attention to discussions around the security model of apps embedding a webview component, injecting custom js, and using webviews to bypass things - happening in the webview CG - all of that is built around these notions of the web security model, based around the origin concept with content delivered over https and the UA keeps things like storage segmented, so you can multiple contexts running in the UA where information does not leak across origin boundaries. Whatever mini app does should follow that same model so we can make sure we're building something that gives the user a strong guarantee of security. We were asked for a specific recommendation, so we suggested taking a look at the packaging solution that preserves the origin model, such as what is going on in the web packaging work, bundling and signed exchanges. We hope they would be open to working with the miniapp group to solve miniapp use cases.

Fuqiao: I created an issue on the miniapp packaging repo about this and one of the editors has some replies. He did some research and would like to talk with the TAG and web bundling folks.

Zitao: I have discussed with Martin about this part. Concern - miniapp origin .. ?? Baidu and Alibaba and other vendors are using zip format to provide the functions. We analysed potential way to make ... we can discuss in the WG meeting to find a way to consensus.

Sangwhan: one of the things that is concerning is a de facto standard that is widely adopted in China, but that doesn't mean w3c can rubber stamp it as a standard. There are bars we have for security requirements. We see gaps here. We have flagged them. If you want to rubber stamp the implementation because it's a defacto standard that's a separate discussion. I'm not sure we're here for that. There's a parallel set of technologies that are not being used that solves some of these problems, though there are issues. Those folks are likely willing to work wth you to figure out how to solve those. If the default approach is that it's already well-adopted so we should just sign off, I'm not sure what we should do here.

Zitao: we know this. We agree. We need some way to provide a compromise. The best way to find a way good for existing implementations and also to respect the existing standards. That's why we discuss with the authors to find a way address the issues. This is our direction. We don't want to just use the existing implementation to standardise the packaging.

Dan: two issues here that are conflated. One is the web security model. The other is the packaging format itself. The TAG has raised issues on both. We can usefully separate those issues. Speaking for myself and my understanding of this, I think the web security issue is higher priority. But I think Sangwhan has raised important issues about the zip format itself from a streaming perspective that may be useful to discuss. I think we should try to discuss them separately. Even making progress on one would be a good step forward.

Max: From Martin's response he explained the reason why the design uses zip instead of other standards. Also mentioned about why the miniapp wg not using http exchanges, because there are some use cases the http signature mechanism was not suitable for miniapp. The miniapp wg experts can explain to us what are those use cases to justify what Martin concluded, that http exchange is not suitable. The other thing - about the origin, I noticed an author has replied on the issue to mention the explainer has been updated to explain miniapp origin

Sangwhan: Zip is a bad format. But we're less concerned about that than the lack of an origin. If the security model is in place we'd be okay to make a compromise somewhere about packaging. The web packaging model does not have a good story for long term installed apps. No story for what happens when the origin disappears - that's to be addressed. But the security model is a huge issue and we don't want to compromise on that.

Dan: taking a look at the miniapp origin part of the explainer, I still don't see discussion of a cryptographically secure origin. Martin asks if HTTPS transmission of zips enables us to guarantee.. we should explore... I hadn't seen discussion of an in-zip digital signature. What format would that be? Bound cryptographcially to the... what's the chain of trust between the https origin and the in-zip signature?

Max: does the section on miniapp origin answer our concerns?

Dan: I see in Martin's comment in-zip digital signature, but in the explainer I'm not seeing anything about signatures, missing something..

Yves: there are multiple ways to ensure trust here. The full cryptographic things which can be done at one time, as in signed exchange. And ways to delegate trust to someone who did the verification first hand, which is the model you have in most app stores via universal links for apple, iOS and equivalent for android which has another name. Delegating the authenticity of the link to the party who is distributing the app. Depending on the choice that miniapps wants to do there are different solutions to ensuring that the origin model is respected here. For me, we need one. But up to the WG to decide which one is enough for the use cases.

Fuqiao: about signatures.. Dan mentioned signature isn't mentioned in the lifecycle explainer yet. I think that's because signature schemes are specified in the packaging spec. probably we should move that section, and add the signature part. The lifecycle spec I don't think it deals with the signature.

Dan: what's the signature that's used in miniapp packaging? https://github.com/w3c/miniapp-packaging/blob/main/docs/explainer.md#security-considerations

Sangwhan: pkcs7 and apk signature scheme. There's a similar thing to pwas called trusted web activities which does the same thing on the play store. That is not a standard - for a good reason. Ultimately the inherant risk is that there's always a risk that we end up with a supply chain level contamination upon delivery. One of the things is that the miniapps proposal entrusts the distribution channel to be trustworthy, and I take issue with that. Delegating that over to the distribution channel goes against the security model of the web. Google does it for the play store and I think there were discussions about standardising it but it was shot down, it's a bad idea. We want a zero trust model from origin to user, where every player in the supply chain cannot be trusted. That's the gap where we're going back and forth here.

Dan: https://web.dev/webapks/ - note existence of web apk. Having worked on Chromium based browsers, thsi was a key enabler for progressive web apps, that enabled them to get signed by a third party key server in order to appear on the device as an app even though it's a webapp. This is a technology that is out there. There are at least two implementations of it - google has one tied ot the android app store, and samsung has one for the samsung app store for web apps saved to the home screen using their browser. Might be worth taking a look at as a halfway house between... although all that i's doing is provides guarantees from a platform perspective not from an origin perspective. Maybe worth taking a look at.

Sangwhan: that is basically the scheme proposed in the security considerations for mini apps - the distributor can be trusted

Dan: but in the case of a progressive web app, it does not provide additional guarantees over and above what it would be if you simply visited that website over https from your browser. It's just that it provides some extra UI affordances in terms of being able to show up in the app list

Sangwhan: that's basically what this proposal seems to be suggesting. I'm not so sure if w3c is the right venue to sign off on a proposal like that. There's a mention about a business decision and business policy - yes it can be business policy - but this level of ambiguity on potential supply chain attacks is something we want to adopt as a standard on rec track

Max: I notice that in the explainer link, mini app origin section, the author do clarify that they follow the same origin policy. Maybe the part belogning to business decisions should not be in the standard. Maybe it's better to clarify which part is proposed to be standardised and which part is not. That will help our discussion. Hearing what Sangwhan mentioned, assuming that all those parts will be standardised in w3c but according to the explainer I have the impression that is not the case. Some parts standardised and some parts should not be included. Can the cochairs or editors do that to help the discussion?

Dan: I think the action is for the miniapp group to come back with additional clarifying information that addresses the issues that have been raised here around how the model has been proposed preserves the web security model. New information that has been provided, including Martin's comment that we need to look at. I'd also suggest I'll sned a message to kenji from google who's the person we talked to last time from the packaging.. point him towards this issue and ask him to engage with martin. That might provide some useful discussion points.

Sangwhan: it says in the explainer that miniapp follows the same origin policies - it's without grounds unless you have a way of validating the origin. If that guarantee is gone then all bets are off. You can follow same origin policy as much as you want, but if you can't guarantee the content is from that origin there's no point.

Zitao: Thank you for the meeting and discussion. The WG need to find a way to address the issues. Provide a secure way to guarantee the origin. And to provide mechanisms to guarantee the authority chain(?). And integrating packaging.. makes sense. Next WG meeting we can have time to discuss this.

Sangwhan: really suggest you talk to kenji. They went through this entire process.

Yves: conversation started with the Google folks. The choice of packaging format depends on solution they take for insuring origin is a proper origin.

Dan: as far as we kno there's not additional need for our time right now?

Sangwhan: our concerns were heard, so we can wait.. it's a solveable problem. Technical debt on the packaging end. Bundles did not solve the use case that mini apps needs

Yves: yep. It has some mechanisms that will help, but doens't solve everything

Sangwhan: and something that bundles really needs to address. Eg. epub wasn't able to use bundles becuase of these limitations. Indefinite offline web apps should be a thing.

Max: I think the authors are still working on this. I noticed they have an open issue in miniapp packaging - following the discussion. Hope for progress in the near future. Basically they are following our recommendations - and trying to resolve the issues.

Yves: could be zip or something else..

Sangwhan: container format is least of my concerns. Don't like that it's zip but can see why they use it

Yves: agree

Sangwhan: the other problems are bigger. The allow the app store to be the verifier of the origin, which we disagree with

Martin: yeap..

Sangwhan: delegates origin verification to the app store, dangerous

Yves: if you look at the ecosystem for regular apps on apple and android, that's basically what they're doing. All the deep linking is checked by the app store. There was nothing in the proposal about how to do it.

Sangwhan: and their manifest had no compatibility with existing manifest proposal.

Amy: any progress?

Sangwhan: manifest and ?? have been reworked

Yves: mini app adressing is being reworked but they haven't asked for a review yet. There is an issue related to context extension - how to extend the url space you are handling from webapps to other origins - how do you trust that you have the right to serve those origins from those webapps. Same issue with origin model

Martin: seems like you provided the feedback they requested and there's a resolution. Does it get closed, or are they expecting it to remain open?

Yves: we kept it open to track what was going on and ensure they were doing the right thing with the origin model

Martin: is that a typical approach? That could take forever

Yves: it depends. In this case, we had ongoing discussion to explain how important the origin model was for powerful apis

Sangwhan: there has been progress made in the other proposals

Yves: they were positive about our feedback

Sangwhan: keeping it open is probably fine. our job to remind them to do the right thing.

Martin: I'd have thought the obligation is now on them, then to come back with a new design review

Yves: if they come up with a new request for feedback once they publish the fpwd, we can close this one as overtaken. We'll see how it goes. It's a special case.

Sangwhan: with packaging, it's likely the miniapp wg is liekly to make faster progress in this space, we may need to connect the dots for people

not assigned to today