Investigate revocable flag behavior for policy attestations

[johnx25bd]

Context

From PR #8 review comment: The documentation currently states that schemas must use revocable: true because Astral's TEE signs delegated attestations with revocable: true.

Questions to Investigate

1. Is this deliberate? Why does Astral sign with revocable: true?
2. Can developers choose? Should there be an option to let developers specify whether their attestations should be revocable?
3. How would revocation work? If attestations are revocable, what's the mechanism to revoke them? Who has authority to revoke?

Current Behavior

• Astral's attester signs all delegated attestations with revocable: true
• If a schema is registered with revocable: false, EAS rejects with Irrevocable() or InvalidSignature() errors
• Developers must register schemas with revocable: true to be compatible

Potential Improvements

• Allow developers to specify revocable preference in API request
• Document revocation mechanism if one exists
• Consider security implications of revocable vs non-revocable attestations

---

Opened from PR #8 review

[johnx25bd]

This issue is related to broader verification and threat model documentation gaps identified in a comprehensive review:

• The rationale for revocable: true should be documented in the Verification Playbook (see Verification Playbook: Make Trust Model Inspectable #12)
• The revocation mechanism and who holds authority should be part of the Threat Model section (see Threat Model Section: Document What Is and Isn't Proven #14)
• This connects to the question of what attestation artifacts verifiers can inspect

Consider addressing this as part of a unified security documentation effort alongside:

• Verification Playbook: Make Trust Model Inspectable #12 - Verification Playbook
• Threat Model Section: Document What Is and Isn't Proven #14 - Threat Model Section