Alexander Scheel

Sure, happy to @DrDaveD. The short answer is it is an either-or thing. Either you use a role (with a given role name) or you use CEL (with a given...

@DrDaveD said: > authentication is done entirely by the oidc token issuer not by the jwt While true that the _authentication_ is done by the token issuer, isn't the JWT...

@suprjinx said: > in #753, the `cel` items are posted to path `cel/policies`. Would that make sense here? in this case, it seems like the cel items are "optional extensions...

@N0K0 See #514 for discussion on policy unions; I've started proposing https://gist.github.com/cipherboy/65eef303127f7ee259498e45a2077ba1 as a way of discussing CEL semantics in general. If we add CEL to policies, with the behavior...

@suprjinx Do you mind updating the RFC above and opening a PR to add it to the docs site? Thank you!

@chicks-net Hmm, maybe my package is broken? I usually have to fix _something_, I was as surprised as you when it came back clean. :D ``` [cipherboy@x1c openbao]$ shellcheck scripts/verify-release.sh...

> Therefore, the lib field should not be configurable. I'm confused about this. I could see a scenario where child namespaces are unsealed with different HSM libraries than the parent...

@phyrog Hmm, good to clarify. I took this to mean the encrypted KEK (`ns-root-key` in the diagram above) is layered with the parent namespace's barrier keyring.

In discussion with @schultz-is, we may need to consider interaction with `/v1/sys/generate-root/attempt` and per-namespace seals; if we want recovery keys to work in this context.

@phyrog I think I read @voigt's design doc as follows: The actual data (in `ns2`) was encrypted once, with `ns1`'s keyring. However, ns1's unseal information (that, if `ns1` were a...