WICG
note designed-for-purpose alternatives and the risk of crowding out those options
As a practical matter it seems likely that this general purpose pass-through API will inhibit the development of more privacy-preserving APIs that have overlapping use cases. As noted in the Privacy Principles, designed-for-purpose APIs would make it easier to evaluate and explain the purposes of particular data practices and to limit harmful secondary uses. https://www.w3.org/TR/privacy-principles/#purpose-limitation
As noted in the Web Platform Design Principles, it would also make it easier to for user agents to intervene on behalf of the user. https://www.w3.org/TR/design-principles/#high-level-low-level
We should note the risk of crowding out development of a designed-for-purpose API, or explicitly document an intended direction to develop safer designed-for-purpose mechanisms that can build on deployment experience here, with user-agent-mediated pushes towards those better mechanisms in the future.
I think this is fair but we should also note that there is a polarity to be managed here. There is no point doing something "designed for purpose" if it fails to be a purpose which has product-market-fit and so instead of getting used, gets ignored in favour of a solution that is less opinionated.
Early on in the DC journey we made the tradeoff to strike a balance here - something we thought had just enough "purpose" to enable some user protections but not so much that we couldn't attract away the consumers of less-purposeful APIs already in deployment such as custom schemes. In particular, being designed to enable user agent introspection of the request and intervention or differentiated friction based on properties of the request, and also to ensure there is enough information available to construct a permission screen the user can understand and at least partially reason about the implications of. I don't think anyone is debating this "designed for purpose" principle, we're just debating the details of where the sweet spot is in terms of how much control we insist on in the hands of the user agent (compared to the verifier and wallet) vs. how much adoption we expect relative to alternatives.
Perhaps a general principle we can note is that APIs should be designed for a purpose which is shown to have real demand in the market?
Something that might be worth teasing apart along those lines is the divide between authenticated assertions of identity (drivers license, passport, etc...) and authenticated assertions of class membership (age verification in particular).
The idea that these are authenticated by the same authority is solid - it is even a good idea to host these details in the same application (a wallet) - but the idea that an API designed for presentation of identification credentials can also support class-membership proofs is unrealistic in my mind. The technical details of how presentations are made is fundamentally different. Unlinkability requirements are starkly different between the two cases, which means vastly different protocols. Why then insist on the same API?
Just to be clear, this is not about selective disclosure in the context of credentials that include identity information. Having the ability to redact information so that it is withheld from a verifier, even if they could use linkability to contact the issuer and obtain that information, is still valuable.
but the idea that an API designed for presentation of identification credentials can also support class-membership proofs is unrealistic in my mind.
This is already possible today via FedCM and arguably WebAuthn if you squint.
The technical details of how presentations are made is fundamentally different.
Not sure I agree with that and I'm curious what you mean by it. Ex: a presentation of an SD-JWT VC-based European PID and an SD-JWT VC-based employee ID are nearly identical.
Those are examples where class-membership comes with a healthy side-serving of linkability, something that is likely to be highly undesirable for other use cases. If you want unlinkable presentations, you can't use SD-[JC]WT like that. That opens up a whole new set of concerns.
It's obviously true that if you don't care about those privacy properties (because you don't care or because the use case either doesn't need them or depends on having linkability), you can feed less information through the API. There are enough cases where linkability is either useful or not harmful; that's not in question.
I might have conflated the class-membership case with linkability, which I still think is right in general for other reasons, but I realize now that this might have been confusing.