`manifest.json` is always expected at the root of the host origin

[tmarkovski]

The manifest.json file is always loaded from the root of the origin, even when a path is provided. For example, if my wallet is located at https://example.com/acme/wallet/, I would expect that the manifest search location be https://example.com/acme/wallet/manifest.json. This is a scenario when the service runs multi-tenant wallets where tenants are separated by path /acme1, /acme2, etc. Current approach forces providers to use hostname multi-tenant approach acme1.example.com, acme2.example.com which can be quite involved.

Looking at the code, it does not seem obvious why this restriction is in place. Would it possible to add an alternative lookup location to accommodate this? Example, if wallet is https://example.com/acme/wallet/, load manifest.json from https://example.com/manifest.json and if error, try load from https://example.com/acme/wallet/manifest.json.

I'd be happy to make a PR for this, but would love to hear how the team feels about this.

[dlongley]

@tmarkovski,

We considered adding support for that feature sometime in the last few years. There were challenges related to enabling the added complexity of more than one credential handler per origin. I can't recall if the challenges were related to trying to polyfill Service Workers (which we no longer do), some security / trust issue, high possibility for user confusion in the UI, or a CORs problem in some browsers. It may be the case that the root causes of some or all of those challenges have now been mitigated in some way, but it would take some analysis to figure it out.

It may also be the case that the changes needed to support the feature wouldn't only be here in the mediator code, but also in the polyfill loaded by credential handler websites. That's fine, of course, I only highlight that there may be more complexity to solve this. For example, those sites might need to include path information in their permission request that is transmitted over postMessage. It may also be the case that that sort of information could be curtailed / no longer possible with changes to browsers to prevent unwanted user tracking. Getting origin information alone is easier and doesn't enable tracking.

In any case, we're in the middle of updating the mediator code base right now to enable making adding new features (some already planned) easier. We should wait for those updates to land before considering whether to implement this feature / implementing it.

Once those changes are in, I can send another response to this issue if you're still interested in doing some analysis and PRs to make it happen. Thanks!

[tmarkovski]

Thanks for the context and the status update @dlongley. I'd be happy to look further into this as soon as the updates are in. Please ping this thread.

[dlongley]

@tmarkovski,

The updates I mentioned are now in.

If you want to try and add support for arbitrary paths for credential handlers you can give it a shot. Notably, there are perhaps a number of non-obvious problems that could be introduced if you have to modify any of the cross-domain messages sent to accomplish the task, etc. For example, new possibilities for injection attacks or, perhaps, a browser like Brave may start to flag the site as a tracking site. And so on.

[tmarkovski]

Great, thanks for the note @dlongley. I noticed the CHAPI playground demo was updated as well. I'll give it a shot and report back (may not happen for a week or so).

[tmarkovski]

Posting an update to this as I looked into it and have concluded that while the code may be tweaked to support path based origins, the practical applications that would consume this service are going to be more constrained with path based multi tenant implementations. In other words, we switched our multi-tenant wallet to use unique subdomain origin for reasons not directly related to CHAPI integration. As you noted, the scope of CORS, passkeys, service workers, make it challenging to work with multi-tenancy in a reliable way using paths.