Consent becomes a runtime check.
DIAP sits between products and human identity. The product asks. The protocol decides. The result carries proof.
Where diap.my.id fits
diap.my.id is the person-side control surface and hosted vault infrastructure for DIAP. A SaaS product, editor, marketplace, AI tool, or platform can integrate it into its own project so its users get secure DIAP vaults without the product storing raw identity data. People manage identity modules, visibility, scoped approvals, revocation, receipts, and audit history in the vault; products call the protocol for decisions and proof.
Can this product create or link a DIAP vault for its user without holding raw identity custody?
Is this exact use allowed for this product, action, duration, and territory?
Which grants, receipts, revocations, and verification events exist?
Discover
A product asks whether an identity can be shown or selected.
Request
It requests a scoped grant: subject, right, output type, duration, territory.
Authorize
DIAP issues a short-lived token only if policy and consent allow the use.
Execute
The product verifies the token server-side and fails closed if it is invalid.
Record
It submits a receipt and attaches a watermark or output identifier where applicable.
Revoke
Revocation updates the registry. New checks fail immediately.
Integration shape
1. POST /visibility/check 2. POST /license/request 3. Verify token before use 4. Execute only inside approved scope 5. POST /receipt/submit 6. Verify later by receipt, watermark, or registry lookup
Protocol rules
No visibility without Layer 1 consent.
No use without a scoped token.
Training, editing, publishing, and endorsement are separate rights.
Receipts are mandatory for certified generation.
The kill switch belongs to the identity owner.
Raw identity data stays with the certified source unless policy says otherwise.