NATS Auth mechanisms

[3goats]

Hi, I've been spending quite some time exploring the different auth methods for NATS.

I'm specifically interested in two use cases:

1. Dealing with the initial enrolment of a device/workload (e.g. IOT, container...) using some kind of birth certificate/key/token in environments whereby the ability to attest or prove the authenticity of the requestor is limited.
2. Dealing with the initial enrolment of a device/workload (IOT, container...) in environments whereby the ability to attest or prove the authenticity of the requestor is less limited and can leverage instance meta-data documents (IID's) etc. e.g. SPIFFE agent attestation.

So my first question: Is there any recommendations/best practise for the above scenarios, especially the first one. Would this be better suited to client certs or the NKEY/JWT pattern?

Are there any plans to leverage SPIFFE as an additional Auth capability in NATS ?

Finally, any thoughts on enabling NATS to support DPoP (OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer) or similar ? https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop#name-dpop-proof-jwt-syntax

[derekcollison]

We do look at some of these things from time to time. We are less inclined to introduce new dependencies however like SPIFFE or DPoP.

However, we designed an implemented a full zero-trust auth-callout mechanism that instructs a server to delegate authN and authZ to an external service. This might be what you would want.

https://github.com/nats-io/nats-architecture-and-design/blob/main/adr/ADR-26.md

And an example.

https://natsbyexample.com/examples/auth/callout/cli
https://natsbyexample.com/examples/auth/callout-decentralized/cli