[Spomky]

The pages the code pull requests merged after beffroi-auth/beffroi#826 make false, read against beffroi-auth/beffroi 9597ebd3: beffroi-auth/beffroi#849, #851 and #852. #853 changes nothing a reader of this site sees.

The data keys (#852)

• Personal data. Every row of a data key is bound to its reference and its scope by an HMAC-SHA256, under a key derived from the data key and a secret the database does not hold. A key that is not the one minted for its reference and its scope therefore opens nothing: a row whose key was replaced, a row copied, or a row planted by whoever can write the database. The secrets are beffroi.keys.data_key_secrets, the secret of the kernel unless the configuration names others. The first binds a new row, and every one opens a row bound under it. A new section says how a secret is replaced:
  1. write the new one first, and give it to every process;
  2. run beffroi:data-keys:rewrap towards the client that already wraps the keys;
  3. drop the old one.
• The configuration. The setting is in the keys page, in the reference and in the configuration page of the bundle. The key management page and the console page of the bundle say what binds a row, and that a rewrap binds it again.
• The application. There, APP_SECRET binds the data keys. Their store refuses an empty one. Changed alone, it leaves the personal data sealed in the database unreadable, along with every lookup by a blind index. A restore therefore needs it, beside the database, var/keys and the master key.

The id_token_hint of a pairwise client (#849)

• Interactions, logout, pairwise subjects. The sub of a hint is read for the client it was issued to, as every sub this provider gave a client is. The hint of a pairwise client therefore names the person signed in at the authorization endpoint, and proves the session at the end session endpoint, as the hint of a public client does. A sub that names nobody for that client is a hint of another person. The note that said otherwise goes.

Signed request objects (#851)

• Request objects, clients, the reference. require_signed_request_object is refused beside request_object_signing_alg: none, the one value under which an unsigned object is read. RFC 9101 §10.5 is cited for the member and for the authorization request it governs. The refusal of the pair is written as the provider's own rule.

Read by another hand. Two readers who did not write the pages checked every changed statement against the code at 9597ebd3, and against symfony/key-management 587b1bfd and symfony/doctrine-dbal-key-management e8e9a3b4, the revisions the lock and the CI install. They found nothing false. The last commit narrows what they found too broad:

• the envelopes of the key management service, a TOTP secret among them, still open under another secret;
• a row whose client or master key alone was edited is not refused by its binding;
• RFC 9101 §10.5 speaks of the authorization request only;
• the sub of a JWT bearer assertion is not read for the client.

make check passes.