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

Discussion: Approaches to multi-tenancy with EDVs #26

Open
tplooker opened this issue May 13, 2021 · 2 comments
Open

Discussion: Approaches to multi-tenancy with EDVs #26

tplooker opened this issue May 13, 2021 · 2 comments
Labels
ready for PR Ready for Pull Request

Comments

@tplooker
Copy link
Member

On the 13th of May WG call a good discussion on the considerations that surround the different approaches to expressing multi-tenancy in URLs used for communication with an EDV server was had, brought about primarily due to a conversation on how best to achieve discovery see #12. Currently in the specification today the tenancy (essentially the EDV instance abstraction) is expressed through a URL path convention (e.g https://example.com//docs/), another common approach to multi-tenancy is to leverage sub-domains (e.g https://.example.com/docs/). However there are distinct tradeoffs that come with these different approaches, for example when using the subdomain approach EDV instances would be fire-walled from one and other when interacting via a User Agent (browser). Where as when using the path based URL convention, mechanisms like /.well-known endpoints cannot be used as a discovery tool for EDV instances.

@tplooker
Copy link
Member Author

Discussed on the 24th June WG call, proposed resolution is for the edv spec to remain agnostic or permissive of both models for multi-tenancy. The spec should include language that documents this position.

@msporny
Copy link
Contributor

msporny commented Jun 24, 2021

Since EDV's use ZCAPs for authorization, multi-tenant systems can be constructed in a variety of different ways. The specification shouldn't prevent multi-tenant systems that are domain-based or path-based and should speak to why implementers shouldn't assume one or the other design pattern when implementing their EDVs.

@tplooker tplooker added the ready for PR Ready for Pull Request label Jun 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready for PR Ready for Pull Request
Projects
None yet
Development

No branches or pull requests

2 participants