[Feat]: Standardize Mandate Verification Flow

[shivankgoel]

Is your feature request related to a problem? Please describe.

Overview
Define and implement standardized approaches for either 1/ secure public key distribution or 2/ API definitions for mandates verification in AP2 protocol through trusted domains and API endpoints. This specification outlines two methods that can be implemented by entities participating in AP2 protocol.

Problem Statement
The AP2 protocol requires a secure and standardized way to:

1. Define flows to share public keys or API endpoints for mandate proof verification
2. Handle public keys lifecycle, versioning or management
3. Ability to dynamically revoke mandates after they have been created

Describe the solution you'd like

Proposed Solutions

We propose implementing two standardized methods for key distribution and verification:

Method 1: Static Public Key Hosting

Entities host their public keys at a well-known URL on their domain.
Let {agentIdentity} be identity who is creating the mandate. This mandate needs to verified by other agents and merchants.

https://{trusted-domain}/.well-known/mandates/public-keys/{agentIdentity}

{
"entity_id": {agentIdentity},
"public_keys": [{
"key_id": "key-1",
"key_type": "RSA",
"key_format": "PEM",
"public_key": "-----BEGIN PUBLIC KEY-----\n...",
"created_at": "2024-04-01T00:00:00Z",
"expires_at": "2025-04-01T00:00:00Z",
"status": "active",
"signature": "signature-from-domain-owner"
}]
}

The problem with this method is that there is no way {agentIdentity} who created this mandate originally can dynamically revoke this.

Method 2: Key Verification APIs

Entities implement a standardized API for verification of mandates.

POST {trusted-domain}/entity/{agentIdentity}/verify-mandate
{
intentMandate: {...w3cVerifiableCredential}
}
Header: <Optional Auth Contract Between {agentIdentity} and {merhantAgentIdentity/merchantId} >

In this case, if {agentIdentity} thinks that mandate is no longer valid / revoked it can deny verification. {agentIdentity} can expose an interface for end users, to show all the active, revoked and completed mandates.

Some of these concerns are mentioned in: #45

Additional Considerations

For enhanced security, we SHOULD recommend pre-emptive registration of trusted domains and verification endpoints at the Agent Identity level. This means:

1. Each Agent Identity must maintain a list of trusted domains and verification endpoints
2. Mandates will ONLY be accepted if they can be verified using these pre-registered trusted sources
3. Any mandate from an untrusted or unregistered source will be automatically rejected
4. Authorization credentials for API endpoints must be securely stored at Agent Identity level
5. Trust relationships cannot be established during runtime/mandate execution
6. Changes to trusted sources require explicit Agent Identity configuration updates

Would like to hear community thoughts / recommendations on this one.

Describe alternatives you've considered

No response

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct