How do I make sure only the authorized party can do X? Where is the msg.sender address?

[dckc]

based on a question from discord

I would like to see the addresses that are using my contract, and add them to information I store in it.

This should be a very simple operation, but I don't find anything on the documentation.

aZCFSeat.getSubscriber() is the place where my research got stuck: it seems the seat subscriber might contain the address currently interacting with my contract, but I can't find any documentation on the subscriber and when I try to print it to the console I don't get much information: Object [Alleged: zoe Seat publisher subscriber] {}

[dckc]

We discussed this question in this week's office hours. See especially capability-based access control with continuing invitations.

[dckc]

WIP DRAFT

I'm sharing a draft done by an LLM. I think it will be useful to track the fixes we make.

In Agoric, access control is handled differently than in traditional Ethereum smart contracts, where the msg.sender address is used to identify the caller. Instead of relying on an external address for authorization, Agoric uses capability-based security, which provides a more explicit, flexible, and composable mechanism for managing access rights.

---

Using JavaScript Objects to Represent Rights (Capabilities)

In Agoric, rights (or capabilities) are represented by JavaScript objects. Each object encapsulates the authority to perform specific actions. For example:

const myCapability = {
  doX: () => {
    console.log('Action X performed');
  },
};

// Only the holder of `myCapability` can call `doX`.
myCapability.doX();

The key concept here is object references as capabilities:

• If a party holds a reference to an object, it inherently has the right to use the methods of that object.
• If a party does not hold the reference, it cannot access or invoke the object's methods.

This design eliminates the need for a global msg.sender construct. Instead, the ability to perform an action depends on possessing the specific object reference, which is shared only with authorized parties.

---

The Continuing Invitation Pattern in Agoric

Agoric uses the continuing invitation pattern to provide dynamic, secure, and extensible access control that integrates seamlessly with its platform. Here's how it works:

1. Initial Invitation:
   • When a user needs access to a specific functionality, the system creates an initial invitation object. This object encapsulates the authority to perform an action or request further capabilities.

const initialInvitation = contract.makeInitialInvitation();

2. Creating Continuing Invitations:
   • The initial invitation can generate new invitations for related actions. For example:
     • editInvitation: Allows the holder to modify a record.
     • adjustVaultInvitation: Allows changes to a financial vault.
   • These invitations are created dynamically using "invitation makers," methods that generate new capabilities.

const editInvitation = initialInvitation.makeEditInvitation();

3. Integration with Smart Contracts:

Contracts return invitation makers as part of their interface. For example, an Agoric vault contract may return an object like this:

const invitationMakers = {
  makeDepositInvitation: () => depositCapability,
  makeWithdrawInvitation: () => withdrawCapability,
};

• Users interact with these invitation makers to perform authorized actions, creating a secure chain of access control.

4. Security by Design:
   • Invitations are specific, composable, and revocable. This ensures that only the authorized party can perform the intended action.
   • Invitations are not global or publicly accessible. They are shared explicitly with the intended recipient, ensuring tight control over access rights.

---

Why Use This Approach?

• Explicit Permissions: Access rights are explicitly represented and granted, reducing ambiguity.
• No Implicit Assumptions: Unlike msg.sender, which relies on implicit trust in the caller's address, capabilities are tied to explicit objects.
• Flexibility: The continuing invitation pattern allows dynamic delegation of access, enabling secure workflows where new capabilities are generated as needed.
• Integration with Agoric: The pattern aligns with Agoric’s broader principles of distributed, secure programming and makes it easier to integrate capability-based access control into its platform.

In summary, Agoric’s approach to access control—based on JavaScript objects and the continuing invitation pattern—provides a robust, secure, and flexible alternative to traditional msg.sender-based models. It emphasizes explicit capability delegation, ensuring that only the authorized party can perform a given action.