Add issue regarding "dumb pipe" APIs

[pes10k]

A couple of APIs have come up in PrivacyWG review and broader W3C discussion where the W3C-defined behavior is very simple and broad, and intended to be the entry point to more complex behavior and information passing, defined else where (future specs, specs maintained by other orgs, left up to vendors, etc).

I don't know where the term "dumb pipe" API came from, but it stuck with me, so im using it here. I'm not wedded to the term, and happy to use something else.

I think this pattern is a problem privacy and security wise for a couple of reasons:

1. it give the impression that a set of behaviors are W3C-standards based, when the actual behavior may not actually be standardized by the W3C (and in particular, hasn't gone through W3C horizontal review or AC review).
2. it somewhat-commits the platform to a general approach (e.g., the doCredentialStuff(any) -> any API) in a way intentionally opaque to w3c concerns, standards, practices and expectations
3. it goes against platform best practices like designed-for-purpose APIs
4. the API encourages a pattern of pushing pushing very complex data through very generic APIs, in a way that makes it very hard to standardize protections and approaches across the platform, and to explain to the user what data a site wants to access in response to what action when a single API call is interacting with a broad range of data types and sensitivities (for example, its already difficult for a user agent to explain to a user whats happening when a page calls getLocation(precise=true). It'll be 100x more difficult to explain to the user whats happening when a page calls doNetworkStuff(currentLocation=X, requestedCredentials=age+date, withWebCamAgeCheck=true, crossSiteCredentials=site.example,site2.example).

@simoneonofri , curious for your thoughts here:

• Have you encountered any cases (VC and credentials come to mind)?
• Do you think we should have S&P questionare questions about this? or that it'd better fit somewhere like the TAG's design principles? or both?

[simoneonofri]

Hi @pes10k,

That's something I'm thinking about as well in the specific case of the Digital Credentials API, which is a layer over which credential exchange protocols pass. Maybe I would call it more mediation layer.

I talk to FedID WG about it to broaden the context a bit, maybe the alternatives, benefits and counter-benefits and sure it needs to be tracked somewhere, and maybe I would also hear from TAG (as it is also a design issue)

Thank you,

Simone

[marcoscaceres]

I think it would help to tighten the terminology here.

The term “dumb pipe” is not only imprecise, it also carries ableist connotations. More importantly for this discussion, it blurs two distinct patterns:

1. Transport-only models, where the user agent acts purely as a conduit
2. Underspecified or delegated-behavior APIs, where the W3C surface is generic and substantial behavior is defined elsewhere

The concerns raised (limited review, unclear behavior, difficulty conveying user consent, overly generic API shapes) seem to apply primarily to the second category, not transport-only systems.

It would be clearer to name that pattern directly (e.g., “delegated-behavior APIs”) and evaluate its risks, rather than relying on a broad term like “dumb pipe”.

For Digital Credentials specifically, the user agent is not intended to be transport-only. The model relies on active mediation, including user consent, credential selection, and enforcement of security and privacy policies. So it’s not obvious that it fits into a transport-only category. DC also builds on Credential Management's "pipeline", to stick with the analogy, which also has several policy enforcement points.

Framing this in terms of (a) degree of user agent mediation and (b) degree of specification vs delegation may lead to a more precise threat model and more actionable guidance.

[marcoscaceres]

As an alternative to “dumb pipe,” it might be clearer to use more precise, neutral terminology depending on the intent:

• transport-only model (if the UA is purely a conduit)
• delegated-behavior API (if the concern is that behavior is defined externally)

Both make the architectural distinction explicit and avoid the ambiguity and connotations of “dumb pipe”.