Hi Mark, Usama, On Tue, 22 Jul 2025 at 10:59, Muhammad Usama Sardar <[email protected]> wrote: > On 22.07.25 10:35, Mark Novak wrote:
> > 3. A stable relying party authorization policy is essential to robust > > deployments. > > seems completely irrelevant to what we are doing here. Mark, I wholeheartedly agree with you, which is why we are working on the normalisation layer provided by AR4SI/EAR. I also agree with Usama that this is irrelevant to the discussion around attested TLS. > > 4. Introducing a service into a client-server communication tends not to > > work. > > Where is it coming from? We are not introducing any service. It's a direct > client-server connection. I believe Mark refers to the need for an attestation verifier to be available at the time the background check is done. However, this is not a requirement: the peers can exchange attestation results instead of evidence. > This is why Intel had to implement DCAP for SGX — a cloud provider would > never allow Intel’s attestation service to be a prerequisite for meeting its > SLOs. If a Verifier must be always on, always available, universally > reachable (so, not even intermittent network outages) and highly performant, > the result is a new very expensive, likely dial-tone, service that an > enterprise must now maintain. Highly a non-starter. RA-TLS can't work with attestation results, only evidence. I believe that's the reason why DCAP was required. > > 7. If an organization wants to standardize on some workload identity > > standard, such as WIMSE or SPIFFE, the proposal does not specify how it can > > do that while also adopting the proposal. Forcing an enterprise to do > > things two different ways is a big adoption hurdle. > > Implementation detail, irrelevant to the charter. No one is forcing anyone. An enterprise will choose the solution that better fits its requirements and operational constraints. If aCSR or a SPIFFE-based solution is "better" according to your evaluation metrics, that's great! cheers, t _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
