You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I ended up creating a pre-proposal that looks like what I may I originally thought was wanted as part of the spec via SIG discussion, but after seeing the content, it was decided that it made more sense as an issue.
This issue will cover what is in and what I call the pre-proposal, and to outline some terminology and key concepts for zero trust. Discussion around zero trust can happen here which is much more appropriate than the original pre-proposal.
First, I want to call out that the pre-proposal is a dive into the various protocols that cloudevents support and to ensure that there's some place where we can add security metadata to.
Zero Trust
The idea of zero trust is that we do not assume that any request is trustworthy by nature. Instead cloudevents should provide way(s) to allow for verifying incoming requests.
Summary
To review the supported protocols of cloudevents to allow handling of security metadata for requests to be verified with. It is imperative that some understanding exists for each protocol to ensure what their limitations are. This will allow us to understand the limits zero trust can be implemented as.
This issue will also act as a discussion platform around zero trust, and any updates I have as I write the proposal which should help with any discussions and/or questions I may have during the SIG meetings.
I will explore existing tooling and libraries such as S/MIME (@clemensv idea), jose, and a few other libraries/tools to see what may work for zero trust. It is important to outline that this future proposal is not in the business of inventing new algorithms, tools, etc. The reason for this is there are already plenty of tooling around security that should be sufficient. Further any new algorithms would require us to maintain it and also specialize in security, e.g. handle any CVEs, which is something we do not want to do.
The text was updated successfully, but these errors were encountered:
I ended up creating a pre-proposal that looks like what I may I originally thought was wanted as part of the spec via SIG discussion, but after seeing the content, it was decided that it made more sense as an issue.
For reference: #1301
This issue will cover what is in and what I call the pre-proposal, and to outline some terminology and key concepts for zero trust. Discussion around zero trust can happen here which is much more appropriate than the original pre-proposal.
First, I want to call out that the pre-proposal is a dive into the various protocols that cloudevents support and to ensure that there's some place where we can add security metadata to.
Zero Trust
The idea of zero trust is that we do not assume that any request is trustworthy by nature. Instead cloudevents should provide way(s) to allow for verifying incoming requests.
Summary
To review the supported protocols of cloudevents to allow handling of security metadata for requests to be verified with. It is imperative that some understanding exists for each protocol to ensure what their limitations are. This will allow us to understand the limits zero trust can be implemented as.
This issue will also act as a discussion platform around zero trust, and any updates I have as I write the proposal which should help with any discussions and/or questions I may have during the SIG meetings.
I will explore existing tooling and libraries such as S/MIME (@clemensv idea), jose, and a few other libraries/tools to see what may work for zero trust. It is important to outline that this future proposal is not in the business of inventing new algorithms, tools, etc. The reason for this is there are already plenty of tooling around security that should be sufficient. Further any new algorithms would require us to maintain it and also specialize in security, e.g. handle any CVEs, which is something we do not want to do.
The text was updated successfully, but these errors were encountered: