Cryptographic Ocap

[Christopher Allen]

(not sure which lists to post this to, and googlegroups will not let me subscribe with my primary email ofChrist...@LifeWithAlacrity.com, so this is coming from my personal account).

When I first met Mark Miller back in the days of Xanadu, pre-internet and before E and subsequent thoughts on ocap, there existed a set of ideas called The Club System, which I felt could be accomplished using relatively pure cryptography rather than through administrative control via code. At first Mark wasn’t sure it was possible, but I think he became more confident that is was feasible over time. However, Mark became less confident in the The Club System architecture itself, feeling it was still essentially an ACL system.

Cryptography has evolved significantly since then, offering new possibilities, and there are still some properties of The Club System that I find particularly useful for distributed systems.

First, what is The Club System? I can’t seem to find much historical that has survived the days of Xanadu to be archived on the Web, but basically you have data objects that have a Read Club that can view that object and a Write Club that edit that object. So in many ways it *is* an ACL.

However, there are three key differences: The first was that both Read Clubs and Write Clubs themselves had Read & Write Clubs. The second was that you had to “knock” to read or write a club, which I always presumed was some form of script — a club might just open, or it might require more information to open. Finally, the “root” of the system was the public club — rather than root being the most private — this meant by default everyone could access, but privacy was a partition from public.

If you wanted to publicly share an object, you could set the Read Club to public, and the Write Club to yourself. If you wanted to restrict editing, you could set the Read Club to be a public, but have the Write Club be a list, with the Read Club for that list being public and the write club being you, so that they could contact you to get added to the write club. You can create fairly elaborate turtles of clubs with many different properties, all the way up and down from public.

So what would an example of a simple cryptographic-based Club System look like? Let me try to give an example.

Presume you are given a content addressable hash (say IPFS) by someone or some service that you desire to resolve (we’ll skip for what purpose for now). The address is the hash of the whole object, and the object itself consists of roughly four parts: a set of encrypted permits, an encrypted payload, a smart signature of both the permits and payload, and optionally a public key of the creator of this object. You can decrypt this object if a) you have the creator’s pubic key (which may not always be embedded in the signature) b) you have a NIKE (non-interactive key exchange, such as DH) key encrypted in one of the permits based on your private key. With these and a nonce you can decrypt a symmetric key allowing the payload to be decrypted. This is very similar to the MiniLock file format: https://45678.github.io/miniLock-file-format/2.html

Thus if you have the public key of the creator and are listed in the permits, you are in the Read Club for this object. There is also a well-known “public” public key and a published private key for that public key. 

So how does the Write Club work? Since content addressable objects can’t really be deleted, you can only update them; instead you rely on the smart signature of the object to be updated.

A smart signature is a predicate script of cryptographic operations that when completed results in either True or False. A very simple  scheme-like smart signature script could offer one example: “(sig_valid <pubkey> (cdr ‘ <msg> <sig>)) (sha256 (car ‘(<msg> <sig>))))”. (see https://github.com/WebOfTrustInfo/ID2020DesignWorkshop/blob/master/topics-and-advance-readings/DexPredicatesForSmarterSigs.md). Importantly, there can also be AND and OR statements (see https://github.com/WebOfTrustInfo/ID2020DesignWorkshop/blob/master/final-documents/smarter-signatures.pdf). 

Basically if the smart signature of the original object is valid on the object that says that it is an update to that object, then the update is considered to be valid. Thus if you are able to satisfy the requirements of the smart signature directly, or possibly through an OR script, you are are in the Write club. This update might then change the rules for future smart signatures, adding OR or AND to the smart signature scripts. This is somewhat like how we are doing DIDs (Decentralized Identifiers) in #RebootingWebOfTrust & W3C CCG.

The above could largely have been implemented back in early 90s using RSA when I proposed it to Mark, but with more modern cryptography makes things more interesting. We can use various new cryptographic schemes to add more advanced features to the above.

We can do key aggregation to support validation of a group of people from a single signature (https://blockstream.com/2018/01/23/musig-key-aggregation-schnorr-signatures.html). This allows for a multi-party write club to be to be M of N and still be anonymous as to who signed M. We also can do other forms of key aggregation where were the signers ARE NOT anonymous, which can be useful for other scenarios. We can also combine these. The point is that we can choose fairly elaborate group structures.

We can use scriptless scripts and adaptor signatures, which in a sense treats Schnorr signatures as keys to allow for fairly complex “script” like operations using a single signature. (https://bitcoinmagazine.com/articles/scriptless-scripts-how-bitcoin-can-support-smart-contracts-without-smart-contracts/). This requires you to be able to prove access to one object in order to decrypt another.

We can make it possible for secret keys to be sharded, then redistribute shards to new participants as groups change (https://medium.com/@simulx/an-m-of-n-bitcoin-multisig-scheme-e7860ab34e7f).

We  now also create secrets collaboratively, that are only homomorphically available in the fog of a group — the secret never exists on a single machine, and it require the group to cooperate to operate on those secrets, but anyone can validate them. These are available through a variety of computational circuits enabled by crypto. Z-cash uses one that only requires one honest participate to function, and there have been many improvements on this in the last few years. 

We also have available a variety of new zero-knowledge proofs: we can do now a variety of scalar proofs (range proofs), but by using an inverse curve we can also do proofs about keys and signatures. (https://github.com/BlockchainCommons/secp256k1/issues/1#issuecomment-410482607). This allow for a huge number of opportunities, such as non-membership proofs, key derivation proofs, etc. Furthermore, with some mirror curves (secp/secq in particular) you can do a number of proofs recursively, where one curve proves something on the other curve, and back, which can be done in a tree-like fashion for some fairly sophisticated possibilities.

So my call to the ocap community is to consider what it means to do ocap solely through cryptography, rather than through code. I will be hosting the next #RebootingWebOfTrust in Toronto on September 26-28th https://rwot7.eventbrite.com and I know Mark Miller plans to be there. Want to help write up a white paper on these possibilities?

— Christopher Allen

[Ben Laurie]

This all sounds like fun, but:

a) not sure this is really equivalent to capabilities,

b) since part of the point of caps is that you can express arbitrary policy, if you end up with an equivalent cryptographic system, you're still writing code, just using cryptographic stuff instead of CPU instructions (and of course the cryptographic stuff gets translated into CPU instructions anyway...)

Which is not to say this crypto stuff is not useful, just not sure why we'd want to do caps solely through cryptography?

I'd also note that some of the primitives you want to use - e.g. Dex (which looks quite useful and reminds me of objecthash) are not actually crypto, anyway, so not even sure what you mean by "solely through cryptography"/

 

— Christopher Allen

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To post to this group, send email to fr...@googlegroups.com.
Visit this group at https://groups.google.com/group/friam.
For more options, visit https://groups.google.com/d/optout.

[Christopher Allen]

I was particularly hoping for thoughts from Mark Miller, Brian Warner & Chris Webber on this thread.

It is relevant to some early prototypes of Smart Signatures I’m working on in Q1.

— Christopher Allen

[Christopher Allen]

I'm bringing back up the topic of cryptographic ocap again on this list, after explaining to Mark Miller and Christopher Webber at RWOT#9 in Prague about the opportunities of new forms of cryptography to enable what I believe is ocap in principle, but administered and secured by cryptography not be the execution of administrative code. After the discussion, they said there believe that there was a "there there".

I'd like to puzzle through what a minimal implementation of cryptographic ocap for a xanadu-club-system-like cryptographic read/write access might look like, and also how we maybe leverage Digital Bazaar zcaps thoughts but using cryptographic ocap.

Mark & Chris, your thoughts?

— Christopher Allen

Original start of thread:

[Christopher Lemmer Webber]

Hi!

I definitely think there's something there; certainly there was a lot of
amazing witchcraft and wizardry that I had no idea was currently
possible in cryptography.

It happened so fast that I feel like there is a lot I would need time to
review and unpack. In particular, I'm still trying to think how to
apply those ideas to "pure cryptography ocap". What would that mean?

My main sense is that there's something similar to the delegation chains
in zcap-ld / Zebra Copy that maybe could be done without the ocap /
invocation being described in a "document structure", and instead as
some sort of crypto-foo. What that crypto-foo is, I'm unsure. Let me
take a stab at it.

- You have an initial grant of authority from a key representing the
invokeable-target, signing off on the key representing the designee
which has been granted invoking-authority. In zcap-ld this is done
as an initial certificate with structured data specifying that key.

- That designee can then further delegate to other designees by
generating further certificates that point at the parent as a chain.

- In the initial certificate, or any further certificates, "caveats"
can specify additional conditions that must be met. In zcap-ld,
these are described via open world types (and if the target receives
an invocation with a condition it doesn't understand, it ignores it).

- An invocation is then signed by a designee on the chain and delivered
to the target, which then performs whatever effects are implied
by the invocation's arguments (which may be dispatched by a specific
method), assuming all delegators had the authority to delegate at
that point in the chain and all caveat conditions are met.

How to transform this into "pure cryptography", given what was described
to us in that meeting?

- Without considering further delegation yet, we could consider an ocap
to be a "partial signature" (or whatever it was called), where the
target signs its part of the invocation and waits for the invoker to
"complete the signature"?

- Thus an invocation is just a completion of that signature by the
other party? (But how do we do this and allow for arguments to be
passed in at invocation time? How do we prevent replay attacks?)

- Caveats maybe could be expressed as the sort of "cryptographic code
VM" that was mentioned and which admittedly mostly went over my head?

- I'm not sure how to do delegation with how much was described though?

So maybe we could pull off a certificate ocap system with "just
cryptography". But I'm not really sure; most of what I was told still
feels like magic to me, and I'm not sure of how to do arguments or
delegation.

But *that* seems like the place to start: try to transform the
certificate style structure of zebra copy / zcap-ld into a "pure
cryptography" system.

But my question is: what benefit does one really get from moving things
into "pure cryptography" as opposed to the certificate style system?
Would it be smaller? Or faster? Or?

It sounds like "smaller" may be the answer (it didn't sound like
"faster" was likely). If we could reduce a whole capability chain to 32
bytes, that seems like a win. I'm not sure it's possible... but I'm
also not sure yet that I understood anything. That's my gut feeling on
what the "magic wizard spells" I was being told about pointed to, though.

Christopher Allen writes:

> I'm bringing back up the topic of cryptographic ocap again on this list,
> after explaining to Mark Miller and Christopher Webber at RWOT#9 in Prague
> about the opportunities of new forms of cryptography to enable what I
> believe is ocap in principle, but administered and secured by cryptography
> not be the execution of administrative code. After the discussion, they
> said there believe that there was a "there there".
>
> I'd like to puzzle through what a minimal implementation of cryptographic
> ocap for a xanadu-club-system-like cryptographic read/write access might
> look like, and also how we maybe leverage Digital Bazaar zcaps thoughts but
> using cryptographic ocap.
>
> Mark & Chris, your thoughts?
>
> — Christopher Allen
>
> Original start of thread:
>
> On Wed, Sep 5, 2018 at 2:14 PM Christopher Allen <christ...@gmail.com>
> wrote:
>
>> (not sure which lists to post this to, and googlegroups will not let me

>> subscribe with my primary email ofChris...@LifeWithAlacrity.com, so

[Alan Karp]

One comment: 

   In zcap-ld, these are described via open world types (and if the target receives
   an invocation with a condition it doesn't understand, it ignores it)."

That sounds like default-allow, which is dangerous.

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/874l0w9qip.fsf%40dustycloud.org.

[Christopher Lemmer Webber]

My wording was bad. The second "it" in "it ignores it" was ambiguous.
What I meant to say was that the invocation was ignored, not the caveat.
But I phrased that extremely poorly... my bad.

[Baldur Jóhannsson]

H'lo. I have been musing a bit on this whilist bus travelling.

Am actually writing this on bus so wording may be stillted.

One can use public key crypto to implement the capability part of ocaps.

Having a public key of an object conveys the 'right' to send messages to and invoke that object.

Having the corrisponding private key conveys the 'right' to _be_ that object.

More in next post.

[Baldur Jóhannsson]

This means knowing the bits of those keys is what coveys those 'right's.

Those kind of caps are only fully delegateable, no attenuation without making and hosting an proxying intermediary somewhere.

Macaroons, SPKI, Blessings and such in next post.

[Baldur Jóhannsson]

In the case of public key crypto the invokation messages to an object get encrypted with the public key of the object and decrypted with its private key.

With SPKI certs and its ilk (SAML, Blessings and what not) and macaroons attenuated delegation is quite possible iff the expressivity of the caveats allow for the desired attenuation.

More in next post.

[Bill Frantz]

On 9/29/19 at 9:03 PM, cwe...@dustycloud.org (Christopher

Lemmer Webber) wrote:

>My wording was bad. The second "it" in "it ignores it" was ambiguous.
>What I meant to say was that the invocation was ignored, not the caveat.
>But I phrased that extremely poorly... my bad.

Ideally, the sender can learn that the invocation was ignored
because the caveat wasn't recognized. If I remember correctly,
KeyKOS had a conventional response that covered this situation.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz | "The only thing we have to | Periwinkle
(408)356-8506 | fear is fear itself." - FDR | 16345
Englewood Ave
www.pwpconsult.com | Inaugural address, 3/4/1933 | Los Gatos,
CA 95032

[Baldur Jóhannsson]

SPKI cert-chains and macaroons have the property that attenuations/caveats can accumulate onto them when further delegated.

However, these attenuations/caveats are interpreted by the vat that hosts the object designated by the innermost/first-in-chain SPKI cert or the specific identifier in the head of the macaroon.

And then there are more esoteric cryptographic ways to implement say rights amplification as an example via access structures made up of monotonic circuits that might be implemented via nested clueless software agents basic constructions.

Sorry for the hours long gap between the fragment-posts of this message.

I can go in further detail about those more esoteric cryptographic ways. What I have in mind builds on top of wellknown crypto primitives.

But for now..
Cheers.

[Justin Cormack]

That is not a good model. Public keys should be considered public. If
you want a right to be the
object and a right to send messages, you need a private key for each
of those, and mutual
authentication via the known public keys for these. So the object
checks that the sender has the
private key (capability) that allows sending, while the sender checks
the object has the private key
that means it is the correct object that is expected.

Justin

> --
> You received this message because you are subscribed to the Google Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/7f765799-d20a-4e88-b664-ca8ac226fde3%40googlegroups.com.

[Tristan Slominski]

Is there a technical reason for "public" keys to be considered public? As in, are there some cryptographic properties that make it less challening to learn value of the "public" key (compared to "private" key) from the contents of ciphertext encrypted using that "public" key?

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK4o1WwsTcLh8AbdSW7xzZP7UoA4OrC2C-uP0PhM33X-sDYjNw%40mail.gmail.com.

[Mark S. Miller]

Same question as Tristan. I have assumed not, and as a result have avoid the public/private terminology. Rather, I refer to encryption/decryption key pairs, and signing/verifying key pairs. When referring to object analogous, I've said sealer/unsealer and brand/guard.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAOXxbHwW1Z8s-x9Dy_9vT7c-f1Kdr27gXFLcwdxOSpk9k278gA%40mail.gmail.com.

[Neil Madden]

I'm not sure about commonly used public key encryption methods, but certainly you can recover the public key from an ECDSA signature if you know what curve and hash function was used (which is often in the metadata or can be inferred straightforwardly). My guess is that most security proofs don't make any effort to guarantee that public keys are not recoverable, because that is outside the security model of the algorithms in question.

-- Neil

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAOXxbHwW1Z8s-x9Dy_9vT7c-f1Kdr27gXFLcwdxOSpk9k278gA%40mail.gmail.com.

[Mark S. Miller]

Good to know. Thanks!

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/79C1BC54-8503-4964-A5CD-C147E1855D01%40gmail.com.

[Mike Stay]

About 20 years ago, there was a guy who sent an RSA-signed message to
a mailing list with a death threat, but his public key was not made
public. They arrested him, but shortly someone posted another public
key that could have generated the signature.

https://cryptome.org/jya/sig-attack.htm

> To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAOXxbHwW1Z8s-x9Dy_9vT7c-f1Kdr27gXFLcwdxOSpk9k278gA%40mail.gmail.com.



--
Mike Stay - meta...@gmail.com
http://math.ucr.edu/~mike
https://reperiendi.wordpress.com

[Justin Cormack]

Yes. Also the public key may be sent in plaintext as part of a
handshake so it could be intercepted. Also logging all generated
public keys is now common, as in key transparency.

Justin

> To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/79C1BC54-8503-4964-A5CD-C147E1855D01%40gmail.com.

[Baldur Jóhannsson]

For a start on offline attenuationable delegatable 'sturdy'-ref lets consider macaroons or a similiar
cryptographic construction.
In the first part of such a macaroon we have three things:
the vatId of the vat hosting the designated object
the swissHash to the object
and a whitelist of allowed verbs.

The first party caveats of such a macaroon can be the usual
valid-before (aka expiry), valid-after, (which are compared against the clock of the hosting vat at verification time)
and deny-verb, which removes the specified verb from aforementioned whitelist.
That should be sufficient for now and I wont go into third party caveats.

Btw the initial hmac key of such macaroon might be yet another secret the hosting vat has to protect or
perhaps the swissNum of the object designated in the macaroon.

More in the next post.

[Baldur Jóhannsson]

Now have the above described macaroons it is possible, in conjunction with clueless software agent basic construction,
to implement a rights graduated n-of-k access structure.

Lets say we want to allow any invoker, that knows an n part of the n-of-k, of target object t to use the verb 'getVolume/0' on it.
We also want to allow an invoker, that knows the n thirds of k to use the verbs 'increaseVolume/1' and 'decreaseVolume/1' on the target object.
And finally we want to allow an invoker that knows all of k to use the verb 'turnOff/0' on the target object.

More in next post.

[Mark S. Miller]

The publicness of those is part of the usage pattern, not inherent in the nature of the underlying cryptographic primitives. Certainly, a signing or encryption key can be made public, and often is. 

Likewise, with hash chaining, sometimes the double hash is made public and the single hash remains private. When we refer to the double hash as, say, "a public hash", the "public" is not an attribute of the cryptographic primitive.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK4o1Wy3xKsEZO-N1zm2cHTX9qsu0JhWGXxVmGUKAoE2OLKmRw%40mail.gmail.com.

[Baldur Jóhannsson]

Now lets concretize this example a bit by picking k to be six shares/parts.

Call these shares/parts s1, s2, s3, s4, s5, and s6.

Those shares/parts are each a 256 bit numbers picked at random at the time of construction of the below assamblage of clueless software agents.

But before that I have to explain a bit what an clueless software agent is, at least the basic construction.

For my purpose here it is pretty much an call to following ecmascript function:

const bcsa = (symmetric_key, expected_hash, enciphered_payload) => {
if (sha256_hash(symmetric_key) === expected_hash) {
return eval(aes256_decrypt(enciphered_payload, symmetric_key), safeEnv);
} else {
return undefined;
}
}

More in next post.

[Christopher Allen]

I encourage folk on this list interested in this topic to learn about Schnorr addition & subtraction used for discreet log contracts, adaptor signatures & scriptless scripts:

Some links:

https://tlu.tarilabs.com/cryptography/scriptless-scripts/introduction-to-scriptless-scripts.html

https://joinmarket.me/blog/blog/flipping-the-scriptless-script-on-schnorr/

http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/

https://medium.com/@gertjaap/discreet-log-contracts-invisible-smart-contracts-on-the-bitcoin-blockchain-cc8afbdbf0db

— Christopher Allen [via iPhone] 

[Bill Frantz]

On 10/4/19 at 8:10 AM, ma...@agoric.com (Mark S. Miller) wrote:

>Same question as Tristan. I have assumed not, and as a result have avoid
>the public/private terminology. Rather, I refer to encryption/decryption
>key pairs, and signing/verifying key pairs. When referring to object
>analogous, I've said sealer/unsealer and brand/guard.

My crypto books are packed up in some unknown nearby box waiting
for the movers to come on Monday and haul them to New Hampshire.

My memory is that the public key can always be derived from the
private key with RSA. So they are not symmetric in practical use.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz |The nice thing about standards| Periwinkle
(408)356-8506 |is there are so many to choose| 16345
Englewood Ave
www.pwpconsult.com |from. - Andrew Tanenbaum | Los Gatos,
CA 95032

[Mike Stay]

On Fri, Oct 4, 2019 at 6:24 PM Bill Frantz <fra...@pwpconsult.com> wrote:
> My memory is that the public key can always be derived from the
> private key with RSA. So they are not symmetric in practical use.

I'm dubious. In "raw" RSA, they're symmetric:
p, q primes.
n = pq. e chosen to be coprime to φ(pq) = (p-1)(q-1). d = e^-1 mod (p-1)(q-1).
The exponent e is often chosen to be something with a low Hamming
weight like 65537 so that encrypting is cheap, but sometimes it makes
sense to choose your decryption exponent to be low weight instead, so
I don't see how that helps. In general, they're any two
multiplicative inverses mod (p-1)(q-1).

[Justin Cormack]

The public key can be derived from the private key for elliptic curves. 

Justin

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAKQgqTY%2BwXuCYeBvdj2HZgXMT-Z1aCOeegeLy5ZoH3UrVuPmUg%40mail.gmail.com.

[Ben Laurie]

On Sat, 5 Oct 2019 at 02:45, Mike Stay <meta...@gmail.com> wrote:

On Fri, Oct 4, 2019 at 6:24 PM Bill Frantz <fra...@pwpconsult.com> wrote:
> My memory is that the public key can always be derived from the
> private key with RSA. So they are not symmetric in practical use.

I'm dubious.  In "raw" RSA, they're symmetric:
p, q primes.
n = pq.  e chosen to be coprime to φ(pq) = (p-1)(q-1).  d = e^-1 mod (p-1)(q-1).
The exponent e is often chosen to be something with a low Hamming
weight like 65537 so that encrypting is cheap, but sometimes it makes
sense to choose your decryption exponent to be low weight instead, so
I don't see how that helps.  In general, they're any two
multiplicative inverses mod (p-1)(q-1).

However, efficient implementations of (private) RSA do indeed need values that can be used to derive the public key.

--

I am hiring! Formal methods, UX, SWE ... verified s/w and h/w. #VerifyAllTheThings.

https://g.co/u58vjr https://g.co/adjusu

(Google internal)

[Christopher Lemmer Webber]

Maybe a way to put it: even if it would be better to not assume that
signing+decryption keys are explicitly "private" (nor
verification+encryption explicitly "public"), it sounds like the
cryptography algorithm designers have made that assumption so maybe we
have to as well.

But it might be interesting to see a world where algorithm designers
didn't start with that assumption?

Language sure informs design :)

>>> https://groups.google.com/d/msgid/cap-talk/CAK4o1WwsTcLh8AbdSW7xzZP7UoA4OrC2C-uP0PhM33X-sDYjNw%40mail.gmail.com
>>> .

>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "cap-talk" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to cap-talk+u...@googlegroups.com.
>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/cap-talk/CAOXxbHwW1Z8s-x9Dy_9vT7c-f1Kdr27gXFLcwdxOSpk9k278gA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/cap-talk/CAOXxbHwW1Z8s-x9Dy_9vT7c-f1Kdr27gXFLcwdxOSpk9k278gA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .

>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "cap-talk" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to cap-talk+u...@googlegroups.com.
>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/cap-talk/79C1BC54-8503-4964-A5CD-C147E1855D01%40gmail.com
>> <https://groups.google.com/d/msgid/cap-talk/79C1BC54-8503-4964-A5CD-C147E1855D01%40gmail.com?utm_medium=email&utm_source=footer>
>> .
>>

[Baldur Jóhannsson]

Where was I going with this?

Oh, right.
By nesting basic construction clueless software agents (BCSA) inside each other as payloads one can make simple AND requisits.

Take for instance an bcsa that uses s1 as its key.
Inside it we find the 'getVolume/0' macaroon
and a group of BCSAs. Each of which use the other
shares, one each, as their key.

You probably see already where I am going with this.

I will only continue this if there is interest.
-Baldur