Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

id member reuse in MiniApps Manifest (no document URL) #1048

Open
espinr opened this issue Aug 11, 2022 · 3 comments
Open

id member reuse in MiniApps Manifest (no document URL) #1048

espinr opened this issue Aug 11, 2022 · 3 comments
Labels
BLOCKED Blocked for some reason

Comments

@espinr
Copy link

espinr commented Aug 11, 2022

[Bringing the discussion from w3c/miniapp-manifest#43]

We want to align the MiniApp identifier (app_id) with the web app manifest's id. It would make sense to reuse it directly. It fits in terms of semantics ("a string that represents the identity for the application.")

But there is a big difference, the (web app manifest's) id takes the form of a URL, which is the same origin as the start URL. MiniApps are packaged and can be distributed by different means, not only through the web (so not necessarily must have a start URL). In some cases the app_id follows the Java package naming (e.g., org.example.app).

Since we are using the manifest extension mechanism, is it possible to reuse the member but refine the processing algorithm?

Also, reviewing the main algorithm, I see another relevant challenge, the document URL must not be null. Any idea how to relax or bypass this dependence?

@dmurph
Copy link
Collaborator

dmurph commented Oct 26, 2022

Maybe a wild idea:

  • Create an algorithm similar to ours for processing the id, where the start_url MUST be absolute (include the origin)
  • This creates an id that is compatible with us w/o needing the document URL.
  • This also prevents apps from trying to leak in user ID information into the origin, as it is part of the id now and would be a separate app.

Am I on the right track here for what you are interested in?

@espinr
Copy link
Author

espinr commented Nov 24, 2022

Thanks @dmurph , the problem I see is that there may be mini apps with no origin (distributed through non-HTTP ways). This is why we cannot find that absolute URL.

@dmurph
Copy link
Collaborator

dmurph commented Nov 29, 2022

How is the app authenticated? Is it signed for integrity but not from a source?

I'm not sure the best way to do this - you could just require that the id is full absolute URL (with origin) anyways, which would make it compatible. IDK if you could "verify" that origin though.

@dmurph dmurph added the BLOCKED Blocked for some reason label Jul 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BLOCKED Blocked for some reason
Projects
None yet
Development

No branches or pull requests

2 participants