[Change] § 5.8 — required_credentials[].scheme is an eligibility credential, not agent authentication #62

What kind of change?

Change a field's type or shape

Which section?

5.8 — Transaction eligibility

Current text

| `required_credentials[]` | Array[Object] | seller-set | `{ type: iab_registry \| dsp_seat \| custom, scheme: api_key \| oauth2_client_credentials \| jwt_keypair \| oidc_federated \| none, issuer, id_required }` |

Proposed text

§ 5.8, replace the row:

| `required_credentials[]` | Array[RequiredCredential] | OPTIONAL | seller-set | What a buyer holds to be eligible |

Add after the table:

**`RequiredCredential`** keys:

| Key | Type | Required | Meaning |
| :--- | :--- | :--- | :--- |
| `credential_type` | VocabularyTerm | REQUIRED | What the buyer holds. Core term: `iab_registry`, an entry in the IAB Tech Lab Agent Registry |
| `issuer` | Domain | REQUIRED | Who issues it |

A consumer that does not know a `credential_type` MUST NOT treat the proposal or
line item as invalid for that reason. It MUST treat that entry as unsatisfiable.

Message authentication follows the Web Bot Auth profile (§ 2.8). Agent identity is
defined by the AAMP agent identity and signing profile (provisional name). Neither is
expressed through `required_credentials[]`.

Our parties PR carries this text and its eligibility rules, using the Required column from our shared types PR. Our signing PR adds § 2.8 and points the last paragraph to it.

Why

§ 5.8 gives scheme five tokens and defines none. Each can mean how the buyer's agent authenticates (identity) or what the buyer holds (eligibility). #57 already reads the row as how agents authenticate.

Identity isn't a per-line-item choice. A seller that verifies requests by HTTP Message Signatures (RFC 9421), with keys found as Web Bot Auth defines, has no token to write. A mechanism name works only where key discovery is fixed. That is one profile for every request: § 2.8, until the AAMP profile (our hub proposal) replaces it.

What stays is eligibility: what the buyer holds, and who issued it. That needs no mechanism token, so scheme goes. credential_type is an open vocabulary, so a seller can require a credential the core list lacks. Details: Credential schemes: full rationale and examples.

Knock-on effects

• type becomes credential_type, and custom becomes an extension term, <domain>:<term>. dsp_seat goes: seats move to eligible_seats[] and buyer_requirements.seats, and DSPs to buyer_requirements.allowed_dsps[].
• id_required, which the draft never defines, goes. § 6.2 then carries { credential_type: iab_registry, issuer: "registry.iabtechlab.ai" }.
• The spend authority that [Comment] §§ 4.1, 5.6.1, 5.8 — Authorization evidence should travel with the transaction #57 asks for is authorization (§ 1.2 in our parties PR), not a credential value.

Open questions for the working group:

1. Must every required_credentials[] entry hold, or any one? Our parties PR says only "the buyer meets it". The unknown-term rule holds per entry either way. The rules issue lists this with the other eligibility rules we left out of the text.

Would this break an implementation already built to this draft?

Not sure

You are commenting as

Other — IAB Tech Lab member (Postindustria).

Before you submit

• I have read CONTRIBUTING.md and agree my contribution may be published under this repository's licence.
• This contains no confidential or commercially sensitive information.

Revised 2026-11-03: Rewritten to match our parties PR, which removes scheme instead of keeping it as the eligibility credential the title names. Open question 1 is new.

Analyzed and generated with the help of Claude, fully reviewed by me.