Capability Service

[Stebalien]

This came up in both #270 and #236.

Instead of implementing authentication in every protocol, it would be nice to have a simple service that negotiates capabilities out of band. At its core, this service would provide the simple interface:

type Capabilities interface {
    // Has checks if peer `p` has capability `cap`.
    // cap has the form `/ns/string`.
    Has(p peer.ID, cap Capability) bool
}
type CapabilityService interface {
    Capabilities

    // Register a handler for capabilities with namespace `ns`.
    Register(ns string, h Handler)
}

Other services could simply check capabilities by calling capService.Hash(peer, cap). The actual capability service would be responsible for determining if the peer has the capability (out of band).

@diasdavid IIRC, you were working on this. However, I can't find any relevant issues.

[mitra42]

@Stebalien - why would you do capabilities on a Peer based level? Once I go up to the Application layer, my access isn't based on which computer I'm on, it should be based on me, i.e. based on my possession of a keypair ?

The semantics should be something like ....

capability.has( resourceid, [ list of pubkeys ]) => accesscode )

Where accesscode is whatever you might need to then access the resource.

This is effectively what we do with our ACLs .

[Stebalien]

I'm trying to abstract away the underlying protocol for deciding access (not restrict it to any particular crypto/authentication system). Really, I'm just borrowing the architecture you'd find in a microkernel (think of peer IDs as process IDs).

In the system you're describing, I assume that has is a method called by the client to prove generate a proof that it should have access to the resource. In my proposal, has is a method called by the server to check if the client has the required capability (where the capability can be anything, e.g., an ACL).

The system I'm describing would work as follows:

1. Client C asks server S for resource R.
2. Server S calls capService.has(C, capabilityFor(R)) where capabilityFor is some function that knows how to find the ACL/capability associated with R.
3. Internally, S's capService runs a protocol with C's capService to determine if C has the necessary capabilities.
4. If 3 succeeds, S returns R to C.

There are two important features here:

1. It's upgradable. We can create new access control systems as necessary and aren't constrained to PK crypto.
2. It's decoupled. The actual authentication protocol can be anything.

Example capabilities:

• /pk/HashPublicKey -- controls the specified public key
• /acl/HashACL/read -- controls the read capability specified in /acl/HashACL
• /email/joe@example.com -- literally, the owner of the peer controls this email address
• /nfc/Something -- physical proximity validation.

---

Note: We'd still need a separate service for non-interactive crypto (e.g., decrypting, signing, verifying, etc.) but that's a separate issue.

[mitra42]

But your big problem is that you don't have a "Server S" in a decentralized systems. The content is distributed, everything has to be the interaction between client C and data.

[Stebalien]

I use server and client to denote the peer serving the request and the peer making the request. It's still peer to peer. Yes, simply encrypting the data is an alternative in some cases, but it's not always the right solution (there are a bunch of performance, security, complexity, and flexibility considerations). For example, syncthing uses authentication, not encryption, to determine which peers should have which permissions on which shares.

[mitra42]

Yes - but the peer serving the request can't do anything the peer making the request can't. So the "server" can't make a decision independently and then decide to give something to the client. Its the wrong model, the model is interaction with information, i..e the encryption of the resource and any associated documents is what decides whether or not you can access it.