Why use asymmetric signatures? Why not macaroons?

[WildCryptoFox]

Macaroons are substantially simpler. Why is ocap-ld using asymmetric signatures for delegation?

A quick skim over the mailing list archives indicates only praise of macaroons for their simplicity and flexibility, yet no reasons against them. Perhaps I missed something?

The only reason I can see is to allow non-interactive third party verification, but this implies either weaker revocation semantics or the requirement of some global state with consensus.

[llorllale]

In some scenarios the "third party" verifying a zcap's proof may be the issuer of the root capability. Consider a scenario where Alice delegates a capability to Bob, then Bob further delegates unto Carol. Alice would be unable to verify the signature on the B->C zcap if the scheme were based on HMACs unless Bob shares his secret with Alice.

Consider this excerpt from the paper:

In particular, interms of functionality and security, HMAC-based macaroonshave the clear disadvantage of being verifiable only by the tar-get service, and by revealing to it certain keys, which preventsuseful types of key reuse.

Section V-H talks a little bit more about how macaroons can work with public key-based crypto and briefly mentions similar schemes to ZCAP-LD, although still reads with some bias towards HMACs due to lower overhead.

[WildCryptoFox]

If Alice didn't mint the credential, why is she verifying Carol's capability to this unspecified service?

Why doesn't Alice mint her own independent credential (copying all caveats) which is delegated along with the original?

If Alice is a proxy and wants to restrict how Bob uses the capability, she may add 3rd party dispatch caveats such that neither Bob nor Carol may invoke the capability without her approval.

[llorllale]

If Alice didn't mint the credential, why is she verifying Carol's capability to this unspecified service?

Because in this scenario, Alice is the authorization server.

The scenario is something like this:

1. Alice operates a vault service
2. Bob requests an vault
3. Alice creates Bob's vault
4. Alice gives Bob a new zcap:
   • delegating Bob's key read,write capabilities on this vault
   • marking Bob's key as the controller of this vault, meaning he can delegate capabilities to third parties
   • signed with Alice's key
5. Bob wants to share stuff from this vault with Carol
6. Bob gives Carol a new zcap:
   • with Bob's zcap as parent (forming a chain of two)
   • delegating Carol's key read capabilities on this vault
   • signed with Bob's key

Note the zcap in step 6 is never witnessed by Alice until Carol invokes the capability later on. When invoked, Alice can traverse the chain and verify that Carol's capability was signed with the 'controller' key for the vault (Bob's key).

[WildCryptoFox]

In some scenarios the "third party" verifying a zcap's proof may be the issuer of the root capability.

The issuer of the root capability is the first party, not a third. When Bob delegates his credentials for Alice to Carol, Alice remains the first party, Bob is the second, and Carol is the third. Neither Bob nor Carol need the ability to verify the credential. Carol receives fewer or equal rights than Bob possessed without additional communication with Alice.

The scenario is something like this: [..]

This scenario is perfectly compatible with HMAC based credentials a la macaroons.

1. Bob requests a new vault.
2. Alice creates a new vault and mints a credential associated with all powers against this specific vault and presents it to Bob.

(nonce = vault_id, tag_0 = HMAC(Alice' secret, nonce))

Alternatively the nonce may be independent to the vault ID and the corresponding map from nonce to vault ID is stored by Alice.

3. Bob attenuates a copy of his credential to read only a single file, and presents it to Carol.

(nonce, operation = read, tag_1 = HMAC(tag_0, "operation = read"))
(nonce, operation = read, file = example.txt, tag_2 = HMAC(tag_1, "file = example.txt"))

4. Carol invokes the credential against Alice, asking to read the selected file.
5. Alice verifies the credential and approves Carol's read requests for the selected file by returning its contents.

Alice would be unable to verify the signature on the B->C zcap if the scheme were based on HMACs unless Bob shares his secret with Alice.

No asymmetric cryptography necessary. Note Alice and Bob share the "tag_0" as a secret key which, if Carol knew, she could de-attenuate her credential to recover Bob's full power. Bob stores the tag, whereas Alice recomputes it from her secret key and the public nonce.

If instead you want to be able to delegate credentials over untrusted channels but do have trusted key exchanges, then you still don't need signatures, but do need (forward secure) encryption.

[dlongley]

Just sharing another link with some comparisons between zcaps and macaroons: https://github.com/WebOfTrustInfo/rwot5-boston/blob/master/draft-documents/lds-ocap/lds-ocap.md#macaroons