Consent¶

Consent answers a narrow question: is this application allowed to act on your behalf, with these permissions?

It is not about whether Sarah may read attendance records — that is her permissions, and no amount of agreeing changes it. It is about whether the library app may do so as her.

When someone is asked¶

IDEN asks the first time an application requests permissions the person has not already agreed to give it, and records the answer so they are not asked again.

Applications marked skipConsent never ask. That flag is for first-party applications — your own dashboard, your own kiosk. Asking your own staff to consent to your own dashboard is noise that teaches people to click through prompts without reading them, which is the exact habit consent screens depend on not existing.

Everything else should ask.

What gets recorded¶

The permissions actually granted, not the ones requested.

This distinction is not cosmetic. Suppose the library app asks for library:loans:read and library:admin, and Sarah holds only the first. She is shown, and agrees to, the first. If IDEN recorded the raw request, library:admin would be marked as consented — and the day someone gives Sarah that permission, the library app would receive it without anyone ever being asked.

Consent covers what someone was shown. Nothing else.

Withdrawing it¶

GET /entity/connections lists the applications a person has granted access to, and DELETE /entity/connections/{clientId} takes it back — deleting the agreement and revoking every refresh token that application holds for them.

Access tokens already issued run to their expiry, as always.

Withdrawing is not a block list. The application may ask again — and will have to, since the record is gone.