Summary
CS-002 (Credential Presentation) lists auto-consent as a hard prohibition for wallets, with no carve-out for machine-to-machine (M2M) exchanges. This directly conflicts with ADR-15, which mandates that EBWs support automated, no-human-approval credential exchange for a defined set of recipient/credential-type combinations.
The conflict
CS-002 §7.1 ("Wallet Unit Requirements"):
Wallets MUST NOT:
- Accept unsigned or invalid Presentation Requests
- Auto‑consent
- Add unsolicited claims
ADR-15 ("EBW EAA exchange automation"), Decision:
EBWs MUST support a minimum layer of automation for M2M credential exchanges.
- A wallet MUST allow a wallet owner to define a combination of recipient and credential types to be shared or received automatically without human approval if requested on the wallet's credential endpoint.
...
A VP process MUST consult the approval list before answering a VP request or escalating to the user per default OpenID4VCP flow.
CS-002 makes no reference to ADR-15, the automatic approval list, or any conditions under which "auto-consent" would be permitted. As written, a wallet that implements ADR-15's automation as designed is non-conformant with CS-002.
Why this matters for SC5
SC5 participants act as issuer, holder and relying party simultaneously toward many trading partners. Requiring a human to consent to every presentation defeats the "unattended system-to-system operation" pattern SC5 needs, and ADR-15 already establishes that this should be supported — CS-002 just hasn't been updated to reflect it.
Proposed resolution
Amend CS-002 §7.1 to carve out an exception: auto-consent is permitted when the Wallet Unit has consulted an ADR-15-compliant automatic approval list and the request matches a rule the Wallet Owner has defined. Cross-reference ADR-15 explicitly.
References
Summary
CS-002 (Credential Presentation) lists auto-consent as a hard prohibition for wallets, with no carve-out for machine-to-machine (M2M) exchanges. This directly conflicts with ADR-15, which mandates that EBWs support automated, no-human-approval credential exchange for a defined set of recipient/credential-type combinations.
The conflict
CS-002 §7.1 ("Wallet Unit Requirements"):
ADR-15 ("EBW EAA exchange automation"), Decision:
CS-002 makes no reference to ADR-15, the automatic approval list, or any conditions under which "auto-consent" would be permitted. As written, a wallet that implements ADR-15's automation as designed is non-conformant with CS-002.
Why this matters for SC5
SC5 participants act as issuer, holder and relying party simultaneously toward many trading partners. Requiring a human to consent to every presentation defeats the "unattended system-to-system operation" pattern SC5 needs, and ADR-15 already establishes that this should be supported — CS-002 just hasn't been updated to reflect it.
Proposed resolution
Amend CS-002 §7.1 to carve out an exception: auto-consent is permitted when the Wallet Unit has consulted an ADR-15-compliant automatic approval list and the request matches a rule the Wallet Owner has defined. Cross-reference ADR-15 explicitly.
References