I appreciate the information; thank you. Can you explain more about the reasoning behind the current implementation and if there are any plans to implement such a feature? Going to add this to my project report regarding this matter. Or is there anyone who would love to share the pov of the organization for this kind of scenario?
I can try, sure. OpenZiti has been an "opt-in" type of implementation. You, the end user, own your device. You, the end user, should have control over that device. OpenZiti has been focusing on that sort of approach and enabling the device owner's to make these decisions for their own devices.
Contrast that to the alternative approach. You, the end user, is delivered a laptop "from the enterprise". You, the end user, do not own the laptop and are not permitted to control the device. It is managed and maintained for you by an enterprise. You are not given the choice. We didn't go down this path to start, opting for the more permissive "you own the device" approach, that's really all there is to it I think, no other reason.
Really though, at its core, OpenZiti is about enabling zero trust embedded into applications through the implementation of software using OpenZiti's SDKs. That's REALLY what's at the center of OpenZiti.
That means the project is not exclusively about a tunneling solution providing underlay access and "a better vpn"; that is simply one application-embedded solution we have provided out of the box. We created our own application-embedded, zero trust tunnelers because we recognized how important that sort of application-embedded zero trust application will be. It's VERY important because the path to zero trust is a journey. It's a destination and it takes time to get there. These tunnelers provide a path for people on that path. With that mindset, we decided to focus on what we thought was the larger community of devices out there and we focused on what we thought was the primary use case we were targetting: end users who own their equipment and not enterprises who own the equipment.
As stated before, this is a feature that could be added to the tunnelers. Also, OpenZiti is a very permissive Apache v2 license. Anyone can fork our code and add this feature to the tunneler. They can then choose to contribute it back to the project (which is what we would prefer) but they are not required to do that. If this is a "killer feature" and someone builds it onto OpenZiti and is able to be successful, well that's what open source is all about!
I hope that gives some insight. This is also just my opinion after working here and on this project for 4+ years.
As mentioned, it's possible that this sort of feature. We operate on a "demand" basis. If there's substantial demand from "a large number of users" (paying customers, or from the open source community), then it's quite possible that the feature will get implemented at some point.
Right now, there has not been a substantial amount of demand for "locking" this feature down, so it's not a priority.
Hope that helps
I also moved your last question/comment to a top level post so that perhaps it’ll be easier to find by others in the future – fyi
Thank you for explaining the approach and reasoning behind the development of OpenZiti. I understand that the focus is on enabling zero trust through the SDKs and that the tunnelling solution is just one application of this technology. I appreciate the emphasis on giving control to the end user and allowing them to make decisions for their own devices. I also understand that the project is not just about providing a better VPN, but about creating a path for zero trust for all devices. I look forward to learning more about the capabilities of OpenZiti and how it can help with the journey towards zero trust.
Thank you for the information and insight on the permissive Apache v2 license of OpenZiti. I appreciate the option to contribute back to the project. I will consider this approach, and who knows, there might be some people already considering implementing this.