What questions/constraints should we consider for transitive identity?

[andrew]

Hey there,

As you hopefully read from my earlier e-mail, the aim of this group is to explore real-world customer demands for transitive identity, in order to determine the requirements (if any) this might make of the SPIFFE project.

One thing that I'd love to hear folks' opinions on is a set of questions that we should be asking of our case studies and thus eventually any proposed solution. Here's what I've come up with so far:

• Q: What are some real-world authorization policies that would need to be supported by transitive identity? What higher level business goals are driving those policies (eg. specific compliance requirements like PCI?).

• Q: How “transitive” does identity need to be to support these policies? How deep is the “call stack” of a message being passed between them? Does the identity of each distinct workload that the service passes through matter?
  

• Q: What existing protocols are used for message transfer that this system would need to be compatible with?

• Q: What other identity infrastructure and standards should this system interoperate with? This should include user identity standards (eg. oAuth, Kerberos) and tools (eg. Active Directory), machine identities (eg. machine certificates, AWS Instance Identity Documents) and workload identities (eg. Kubernetes service account tokens)?
  
• Q: To what extent are you prepared to consider the network in which these messages are being passed as “trusted” (that is, that a malicious actor cannot read, modify TCP packets or impersonate another IP endpoint)?
• Q: What are the latency and availability requirements of any AuthN/AuthZ systems? To what extent must parts of the system be isolated from latency or transient failures in other parts of the system?
  

What questions are we missing? What is unclear about the questions above? Feel free to respond here or in our charter doc, or e-mail me directly.

Cheers,

AJ

[Ken Adler]

Got some interesting use Cases from large clients....

Ken

On Fri, Oct 25, 2019 at 3:38 PM andrew <and...@scytale.io> wrote:

Hey there,

As you hopefully read from my earlier e-mail, the aim of this group is to explore real-world customer demands for transitive identity, in order to determine the requirements terse (if any) this might make of the SPIFFE project.

--
To unsubscribe from this group and stop receiving emails from it, send an email to transitive-identi...@spiffe.io.

--

Ken Adler

InfoSec SME, DPS

ThoughtWorks

510-290-5806 (Cell)

[dpgove]

Regarding "that a malicious actor cannot read", does this imply we might potentially explore situations where the identity document itself contains secret values?

[Dennis Gove]

Sorry, I should clarify. I meant unencrypted secret values. 

[Andrew Jessup]

Hi Dennis - the main motivation for asking this question is to understand if identity bearer tokens (such as JWT-SVIDs) are actually viable solutions on their own to this problem (a JWT in some cases could be considered a secret), or if additional measures (eg. mTLS on the channel) might need to be considered in conjunction with or instead of a bearer token.

Hope this helps!

--

Andrew Jessup | Scytale.io | +1 (347) 855 6187 | Let's meet!

[Denis Kolegov]

Hello Everyone.

And yet another issue regarding "that a malicious actor cannot read". I  think there are many systems where privacy is very important and identity leakage is not desirable. Transitive identity may contain multiple identities disclosing the used technologies, routing, tenants, etc. And we know that identities in TLS x <= 1.2 are not protected against a passive attacker, and identities in TLS 1.3 protected against passive attacker only.

пт, 1 нояб. 2019 г. в 11:18, Andrew Jessup <and...@scytale.io>:

--

Sincerely,
Denis Kolegov
@dnkolegov