Delegating Authority via Sigchain Claims

[tegefaulkes]

Specification

With claims on a Sigchain being the basis for authority delegation. We need a mechanism for creating these claims on the Sigchains of nodes we delegate authority to. There are two kinds of this, the pull and push flow. In both cases a claim is minted and added to the Sigchain. The core of this is creating a standard CSR procedure for creating and adding these claims to the Sigchain.

These claims will be statically defined within the claims domain and the structure will be know ahead of time. In the future the structure can be dynamically defined but that is a problem to be solved by the capability system. In the meantime the static definitions are fine.

There are some aspects to the procedure.
2. Authenticating the request.
3. Creating, signing and inserting the claim into the Sigchain.

The authentication proves that you are allowed to get this claim. There will be a few methods of authentication depending on our needs. It will need discussion on what we want to support but I think we'll want to support multiple methods.

1. Via a token that specifies this node is allowed.
2. A short lived or one use bearer token that specifies that the holder is allowed.
3. A local whitelist on the node creating the claim.
4. An external request to PKE allowing the claim.
5. Check with an external authority if the claim is allowed.
6. Allowing based on policy.

Then the claim needs to be created and sent over to be added to the Sigchain. This claim can be cross signed but the only requirement is that the issuer of the claim needs to sign it. We need to discuss weather the claim is also included on the Sigchain of the issuer as well.

There will be two styles, push and pull. The Pull is the normal style where the subject node requests the claim. For this style subject implicitly trusts the issuer. But the subject is required to be authenticated before a claim can be issued. Conversely for the push flow the authentication is implicit and known ahead of time. But the subject node needs to explicitly trust the issuer. The push flow will be important and configuring the PKE org seed nodes.

@amydevs You want to add your thoughts to this.

Additional context

Tasks

1. This need more discussion so we need to go over the details.

[linear[bot]]

ENG-378 Authority delegation claims CSR

[tegefaulkes]

While #779 ties into this by defining the claims we want to create. This focuses on the standard way of requesting and creating these claims in the first place. When implementing this we if possible, a single RPC call that can handle the creation of each kind of claim. Since a lot of the logic between creating each type of claim would be shared we want to reduce how much we duplicate that.

This means a single RPC call were you can request claim ClaimX and provide all the details required including authentication and then get back that claim to add to your Sigchain.

Another thing is we want to aim to have the claim created within a single RPC call. Ideally we shouldn't have to make a follow up call just to get our claim. Except in the case where we need interactive authentication, for this we must wait and try again later but it will be the same RPC call.

[tegefaulkes]

Just to node, there's mention of CSR here, but this isn't CSR in the sense of X509. It is however a very similar process on the abstract level. We need to have a discussion on the terminology we want to use so we're all on the same page.

[CMCDragonkai]

We should not mention "CSR" at all here unless it's about X509 CSR to a CA. It's basically it's own protocol concept. And similarity wise, you're just describing signing process. A CSR is a "request to have your own cert to be signed".

The main difference is that claims are not a certificate. They are more fine-grained compared to certificates.

A certificate is a "claim" in the abstract sense, but a claim is far more general concept.

Perhaps CSR can be "claim signing request?", but I want to including the idea of "vouching". And multiple parties vouching is a sort of voting system.

Read https://en.wikipedia.org/wiki/Certificate_signing_request

[tegefaulkes]

Since we can create claims in a push and pull flow, we could generalise it to a Claim Signing Procedure (CSP) or Claim Issuing Procedure (CSI)?

[CMCDragonkai]

In which situations do push flow apply to claims? What usecase does it have?

[CMCDragonkai]

I don't understand the push flow description in the spec for claims.

[tegefaulkes]

Push flow applies when PKE org worker nodes configure other nodes. For example the the PKE org is bootstrapped a single node is created to act as the root and trust anchor for the org. When new seed nodes for the org is created the root node will push flow create claims for these seed nodes to grant them authority for certain actions. Such as the ability to create network access claims. Or the authority to audit nodes within the network.

Push flow creation of claims streamlines this process.

[CMCDragonkai]

Hmm I want to push this concept to the gestalt push system. It requires understanding the ACL and how that works. One of the reasons I made sure the default is always pull based - same with vault sharing is that it is simple.

[CMCDragonkai]

For now I'd prefer we focus on pull-first just like vault sharing. And then figure out how push works across the board.

The push system needs to work consistently between:

1. Observables over events
2. Gestalt sync
3. ACL refactoring and relationship with claims
4. Vault push
5. Sigchain push... (I am still not confident this makes sense atm)

[CMCDragonkai]

With claims on a Sigchain being the basis for authority delegation.

This is too strong a statement. It's not the basis of authority delegation, it's one way by which authority can be delegated through a trust chain. The Sigchain has a list of proofs, and such proofs can prove authority by cryptographic authentication via identity, rather than authentication through knowledge of a secret.

In other words, this leverages asymmetric crypto, as opposed to symmetric crypto of a shared secret.

In the painkiller mode, authentication is achieved through knowledge of a shared secret. However in the vitamin mode, authentication is achieved through knowledge of a unshared secret, that being of the private key. The private key proves ownership of the public key. And the public key chains all subsequent "public authority".

[CMCDragonkai]

I'm confused as to what the scope of this issue is. This seems like a discussion issue, not an actual development issue, and the title of this issue is way too vague too.

[CMCDragonkai]

Because now discussions exist as a separate thing rather than issues. Let's get rid of issue discussions, and focus on achievable issues (with defined scope), I'm converting to this a discussion.

The discussion tag can still be used in case additional discussion is needed.

[amydevs]

this no longer exists in linear, i dont think we should convert things to discussions in future

[CMCDragonkai]

I'm thinking discussion tag to be removed, and instead discussions are just discussions like here. We use github as our forum.