[Proposal] Deterministic selective disclosure for AP2 constraint verification

[arjun2075]

Problem

AP2 already requires Shopping Agents to present only the disclosures from open mandates that are needed to evaluate the corresponding closed mandates.

The current specification also notes that, today, the Shopping Agent determines the applicable mandates and disclosures ad hoc, and that an explicit query mechanism could improve interoperability.

I think there is a small protocol gap between those two statements:

A verifier often knows which AP2 constraint it needs to evaluate, but it does not necessarily know the private location of the minimum selectively-disclosable claims inside the holder's mandate.

This becomes especially relevant as AP2 supports extensible constraint types.

Why existing credential query mechanisms are not quite enough

OpenID4VP/DCQL already provides a strong mechanism for requesting credentials and claims, and I do not propose replacing it.

The issue is semantic mapping.

For example, a verifier may need to evaluate:

payment.allowed_payees

for the current transaction.

The verifier can know the AP2 constraint type and transaction context, but may not know which private array element in the holder's credential is the matching selectively-disclosable element.

A broad credential query risks over-disclosure. A query using only leaf values can also be ambiguous when two different AP2 constraints contain the same value.

Illustrative collision:

payment.allowed_payees:
allowed:
- id: shared-id

payment.allowed_payment_instruments:
allowed:
- id: shared-id

A request that only filters on shared-id does not by itself express the AP2 semantic requirement:

disclose the evidence necessary to evaluate payment.allowed_payees, not an unrelated constraint that happens to contain the same leaf value.

Describe the solution you'd like

Introduce a small AP2 Constraint Disclosure Requirement mechanism that lets a verifier specify which AP2 mandate constraint it needs to evaluate, while allowing the Shopping Agent or credential holder to determine the minimum selectively-disclosable claims required to satisfy that request.

Conceptually:

Verifier
->
AP2 Constraint Disclosure Requirement
->
Shopping Agent / credential holder
->
deterministic constraint-aware resolver
->
minimum selectively-disclosable claims
->
existing SD-JWT / OpenID4VP / DCQL presentation

For example, instead of a verifier requesting credential-internal paths, it could express something like:

{
"mandate_type": "mandate.payment.open.1",
"constraint_type": "payment.allowed_payees",
"verifier_role": "credential_provider",
"transaction_context": {
"payee_id": "merchant-123"
}
}

The exact schema above is illustrative only.

The holder would resolve the matching constraint against its private mandate and disclose only the claims needed to evaluate that constraint.

The verifier therefore asks for a semantic proof requirement:

prove this transaction satisfies payment.allowed_payees

rather than asking for credential internals such as:

constraints[2].allowed[0]

This would make AP2's minimal-disclosure behavior more deterministic and interoperable across implementations while preserving existing credential and selective-disclosure mechanisms.

I am not proposing new cryptography, a new credential format, or a replacement for DCQL/OpenID4VP.

Why holder-side resolution matters

The holder has access to the private mandate structure and can determine the exact matching selectively-disclosable element.

The verifier generally should not need to know private array indexes or the internal placement of the matching value.

This also helps avoid ambiguity when different AP2 constraints happen to contain the same leaf value.

For example:

payment.allowed_payees:
allowed:
- id: shared-id

payment.allowed_payment_instruments:
allowed:
- id: shared-id

The semantic request identifies payment.allowed_payees, allowing the holder to resolve and disclose only the payee evidence.

Relationship to AP2 constraint extensions

AP2 already allows Mandate Constraints to define:

• a unique type
• a schema, including selectively-disclosable fields
• an evaluation algorithm

One possible extension would be to allow a constraint to optionally define a machine-readable disclosure-resolution rule as well.

For simple constraints, a generic resolver could use that rule.

For example, conceptually:

constraint_type: checkout.allowed_merchants

credential_source: allowed[*].website

transaction_context_source: merchant.website

match: equality

disclose: matching element

A future custom constraint could use the same mechanism without requiring the generic resolver to understand the business meaning of that constraint.

For constraints that cannot be safely represented declaratively, implementations could explicitly classify them as:

GENERIC

CUSTOM_RESOLVER_REQUIRED

UNSUPPORTED

and fail closed rather than disclose the entire mandate.

Relationship to OpenID4VP / DCQL

I would prefer to reuse OpenID4VP/DCQL for credential presentation.

The proposed AP2 component is only the missing semantic mapping:

AP2 verifier role
+
AP2 mandate type
+
AP2 constraint type
+
transaction context
->
minimum disclosure requirement
->
DCQL / SD-JWT presentation

No new selective-disclosure cryptography is proposed.

DCQL remains useful for requesting credentials and exact claim paths after the holder has resolved which claims are actually needed.

Describe alternatives you've considered

I considered three main alternatives.

1. Use DCQL directly

DCQL already provides strong credential and claim query functionality and should be reused where appropriate.

However, the verifier may know the AP2 semantic requirement, for example payment.allowed_payees, without knowing the private array index or exact claim path of the matching selectively-disclosable element.

Leaf-value filtering can also become ambiguous when unrelated AP2 constraints contain the same value.

DCQL can query claims, but it does not itself know the AP2 semantic relationship:

this value belongs to the payment.allowed_payees constraint and is necessary for this transaction.

2. Have the verifier request exact credential paths

This would require the verifier to understand private credential structure and indexes such as:

constraints[2].allowed[0]

The verifier may not know those indexes and ideally should not need to know them.

It also couples verifier behavior to credential-internal layout rather than AP2 semantics.

3. Continue leaving disclosure selection entirely to Shopping Agent implementation logic

This can work within a single implementation.

However, it may lead to inconsistent disclosure behavior across interoperating implementations, particularly as custom constraint types are introduced.

Two Shopping Agents could receive the same transaction and mandate but choose different disclosures, including potentially broader disclosures than necessary.

The proposed approach keeps the actual presentation mechanism in DCQL / SD-JWT while defining a small AP2 semantic contract for determining what needs to be disclosed.

Prototype / adversarial checks

I prototyped a holder-side resolver and exercised 20 internal adversarial cases, including:

• allowed merchant match
• wrong merchant
• multiple matching merchants
• line-item exact match
• multiple acceptable products
• missing acceptable product
• multiple constraints
• unknown constraint type
• wrong verifier role
• overbroad disclosure request
• missing transaction context
• custom declarative constraint
• custom unsupported constraint
• DCQL claim-path generation
• unrelated private-field non-disclosure
• allowed payee selection
• payment-instrument/payee leaf-value collision
• missing required disclosure
• alternative satisfying mandate or credential
• fail-closed unsupported resolver behavior

All 20 internal cases passed.

This is self-validation only, not independent conformance evidence.

The key invariant tested was:

Adding unrelated selectively-disclosable private fields to an open mandate must never cause those fields to appear in the generated presentation.

Additional context

The main motivation for this proposal is not to introduce another protocol layer, but to make AP2's existing minimal-disclosure requirement deterministic for interoperating implementations.

The proposed model is intentionally small:

Verifier
->
constraint-level semantic requirement
->
holder resolves minimum disclosure
->
existing credential presentation mechanism

The proposal deliberately does not introduce:

• a new credential format
• a new selective-disclosure cryptosystem
• a replacement for DCQL
• a new payment authorization model
• a general privacy-policy language
• a new mandate format

I would be happy to provide the small reference resolver and adversarial test vectors if maintainers think this direction is useful.

I would particularly value feedback on the following questions:

1. Is this the type of interoperability problem the current specification note about a future explicit query mechanism was intended to address?

2. Would AP2 prefer the verifier to express constraint-level semantic requirements, with the holder resolving exact disclosures, rather than exposing credential-internal claim paths?

3. Should disclosure-resolution metadata be part of each constraint definition, or should it live in a separate AP2 profile?

4. Is OpenID4VP/DCQL the preferred presentation binding for this, or should the AP2 semantic requirement remain transport-neutral?

5. Since normative AP2 standardization now continues through FIDO, is GitHub the right place to prototype and validate this idea before taking it into the relevant FIDO working group?