Allow cancelling a shared authwit token

[spalladino]

A user can sign an authwit token and share it with another user, so they can execute a tx that requires access to the first users' assets. However, once shared, there's no way to revoke that authwit (it is possible to revoke public authwits, but not private). We should allow a user to manually emit the nullifier for an already-signed authwit token as a means to invalidate it.

cc @LHerskind for discussion

Raised by @0xShaito from Wonderland

[rahul-kothari]

In private land you don't need to emit any nullifiers -> PXE stores the authwit in memory. Simple can delete the entry! Will pick this up

[spalladino]

Agree, but that holds only if the authwit hasn't been shared. In most cases it'll just be in the owner's PXE as you say, but we may still need a path in the account contract to cancel a shared one.

[rahul-kothari]

LOOOOL I wish I saw this on time -> I also just realised it https://aztecprotocol.slack.com/archives/C04PUD9AA4W/p1698338407296369

you are right yeep!

[LHerskind]

By moving the nullifier emission into the account contract instead of where it is used, it is possible to add a single function on the account that allow its owner to emit that nullifier thereby cancelling both public and private authwits very cheaply.

It have a few consequences though. We need to alter the interface to instead of msg_hash take its components (or most of them).

pub fn spend_private_authwit(
    self,
    caller: AztecAddress,
    selector: FunctionSelector,
    args_hash: Field
) -> Field {
    let context = self.context.private.unwrap();
    let message_hash = inner_compute_authwit_message_hash(caller, context.msg_sender(), selector, args_hash);
    let valid_fn = self.is_valid_impl;
    assert(valid_fn(context, message_hash) == true, "Message not authorized by account");
    context.push_new_nullifier(message_hash, 0);
    IS_VALID_SELECTOR
}

We need to do so, since all the authwits from the same account now live in the same domain, so if we just blindly took in msg_hash it would be possible for one contract to emit a nullifier that would land on some other contracts pending authwit.

the structure is fairly simple, let the account contract constrain the contract that the action is to be executed on using its context.msg_sender(). This way a contract might mess with nullifiers, but only the ones that is important for itself.

[spalladino]

I like the account siloing authwits per app contract, but I'm not sure about forcing authwits to be computed from selector and msghash. Feels like an authwit could be a hash of pretty much anything, not just a function call.

[LHerskind]

Feels like an authwit could be a hash of pretty much anything, not just a function call.

We could change the definition from

H(caller, contract, selector, args_hash)

To instead be:

H(contract, message_hash)

And then have that for the call case, message_hash = H(caller, selector, args_hash) but could also have it be anything else really for covering non-calls (but still siloed with caller).

[spalladino]

I like that!