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.

[CMCDragonkai]

This idea of putting authority claims into the sigchain got me thinking about the relationship between all these abstractions in the PK system. I got a summary of the ideas being explored here:

1. Proofs of Authority (PoA) and Their Role in the System

In Polykey, Proofs of Authority (PoA) exist as asymmetric claims, signed by the Source of Authority (SoA) using their private key, and verifiable by other nodes using the public key. A PoA grants specific permissions or rights, allowing nodes to perform certain actions, such as joining a network, accessing resources, or delegating further authority.

• Asymmetric Layer: PoAs operate at the asymmetric layer, where the authority is verifiable but not tied directly to data or communication. The PoA proves that a node holds a particular authority, but further steps are needed to implement that authority.
• Verification: Other nodes in the network can verify the PoA using public keys. These PoAs might be publicly visible (on a sigchain) or selectively disclosed depending on the context.

2. The Sigchain: Public Auditability Within the Gestalt

The sigchain represents a chain of signed claims that are publicly available within the context of the network the node is part of. The sigchain provides a verifiable audit trail of authority changes over time, making it a critical component for transparency and trust within the network.

• Public to the Network: The sigchain is public within the network. For private networks, this means the sigchain is only accessible to nodes inside the network, but it remains auditable and verifiable by all those nodes.
• Scoped Publicness: Even though the sigchain is public within the network, selective disclosure may still be relevant to limit access to specific claims. Nodes can reveal only the relevant parts of their sigchain, allowing for more privacy while maintaining the auditability of critical claims.
• Replication Across Gestalts: In a gestalt, each node’s sigchain can be replicated across the gestalt. This allows the gestalt to maintain a cohesive view of the collective authority, while individual nodes may also hold their own vertex of information representing node-specific authority.

3. Gestalts and Node-Specific Authority

A gestalt in Polykey is a collective entity made up of multiple nodes. Each node has its own vertex of authority information but contributes to the gestalt’s overall identity and authority.

• Node-Specific Sigchain Entries: Each node within the gestalt maintains its own sigchain (or vertex) that logs node-specific claims. These claims may represent authority that is limited to the individual node or applicable to certain operations within or outside the gestalt.
• Selective Replication Within the Gestalt: Not all claims in a node’s sigchain should be fully replicated across the gestalt. Selective replication ensures that only relevant claims are distributed within the gestalt, while others remain private or selectively disclosed.
• Cross-Gestalt Interaction: When nodes from different gestalts interact, selective disclosure of sigchain entries is crucial. A node from Gestalt A may need to reveal only the parts of its sigchain relevant to the interaction with Gestalt B, ensuring that internal claims remain private to Gestalt A.

4. Vaults: Managing Symmetric Secrets and Bearer Tokens

The vaults in Polykey are git-managed virtual filesystems used to store and synchronize symmetric secrets. These secrets (such as encryption keys or bearer tokens) represent the symmetric layer of authority, where possession equals access.

• Symmetric Secrets and Bearer Tokens: Vaults are primarily used for managing symmetric tokens, where possession of the token grants access or authority to perform certain actions. These symmetric tokens might be generated as a result of a PoA verification and are used for secure communication or resource access.
• Commit History and Traceability: The git-managed vaults maintain a commit history, allowing for traceability of changes to the symmetric secrets. This commit history acts as an internal audit trail, though it may not need to be signed like the sigchain unless additional verification is required.

5. Transformation Between Layers of Authority

In Polykey, authority transforms through several layers, starting from trusted identity, moving through asymmetric key exchange, and ending with symmetric secrets. These transformations allow authority to flow from asymmetric PoAs to symmetric tokens, which are managed by the vault.

• Trusted Identity (Root of Trust): Any secure communication or authority delegation begins with trusted identity, established using public keys. This provides the root of trust for the system.

• Asymmetric Layer (PoA): After identity is verified, PoAs serve as the mechanism for proving authority. These PoAs are stored on the sigchain and verifiable by other nodes using asymmetric cryptography.

• Symmetric Layer (Bearer Tokens): Once a PoA is verified, it may generate symmetric tokens for operational tasks. These tokens are stored in the vault and represent the symmetric layer of authority where possession equals access.

  Example: A node joins a network using an asymmetric PoA stored on the sigchain. After verification, the node generates a symmetric key for encrypted communication, which is stored in the vault. Other nodes in the network can access this key if they have the necessary permissions.

6. Selective Disclosure and Security Models

Selective disclosure can still play an important role, even within a scoped public sigchain. The key use cases for selective disclosure include:

• Sensitive Claims: Certain authority claims may be too sensitive to be fully exposed to all nodes in the network, even if they exist within a private network. In this case, parts of the sigchain can be selectively disclosed only to relevant nodes.
• Role-Based Access: In gestalts or networks with hierarchical structures, not all nodes need access to the full sigchain. Selective replication ensures that only nodes with the relevant roles or permissions replicate or view specific parts of the sigchain.
• Encryption and Partial Disclosure: Sensitive entries in the sigchain can be encrypted, with only certain nodes possessing the decryption keys, allowing for partial replication while maintaining privacy.

7. Observability and Event Streams in the Gestalt

Each node’s vertex of information in the gestalt can be structured as an observable event stream. Claims and authority changes can be selectively shared or subscribed to by other nodes based on their roles within the gestalt.

• Event-Driven Architecture: Sigchain updates (new claims, revoked authority) could trigger events that are selectively observable by relevant nodes. Higher-level nodes might observe more events, while lower-level nodes only observe claims relevant to their tasks.
• Hierarchical Event Subscription: Nodes can subscribe to event streams that reflect their role in the gestalt. This ensures that they receive updates on sigchain changes or authority transformations that affect their operations without unnecessary data exposure.

Conclusion

This specification outlines the interaction between PoAs, sigchains, vaults, and gestalts within Polykey’s decentralized authority infrastructure. By treating both sigchains and vaults as first-class entities, the system enables:

• Asymmetric proofs of authority (PoAs) to be recorded and verified in a public (but scoped) sigchain.
• Symmetric secrets (tokens or encryption keys) to be managed in vaults, with transformations between asymmetric and symmetric layers.
• Selective disclosure of sensitive sigchain entries within and across gestalts to ensure privacy and security while maintaining an audit trail of authority.

This layered approach balances transparency with security, allowing for dynamic authority delegation across both public and private networks.