[OAUTH-WG] Re: Alternative text for sd-jwt privacy considerations.

[Watson Ladd <[e-mail]>]

On Thu, Dec 26, 2024 at 7:14 PM David Waite <[e-mail]>
wrote:
>
>
>
> > On Dec 26, 2024, at 10:38 AM, Tom Jones <[e-mail]>
wrote:
> >
> > This problem was clearly demonstrated by the California mDL hackathon
where the default presentation was ALL DATA. That is the easiest path, so
it remains the one most taken. We have known since standards were first
introduced that they immediately create a drive to the bottom. This will be
the fate of this standard as well. The most permissive interpretation will
be the most common. The user's desires will not be met.
> >
>
> The consequence of splitting out the policy for controlling data release
from the issuing authority is that the complexity that was the business
logic for handling requests, determining if they are appropriate for the
use case, prompting the user for consent, etc. is now all complexity pushed
into the (likely third party) user agent.
>
> Architectures like PRIVACYPASS create individual solutions to release a
particular type of information in the most privacy-preserving manner they
are capable of. This sort of business logic is baked into the protocol, and
the scope of implementation is thus boxed to solve that particular problem.
The user agent can only work per the spec if it intends to work properly,
and following the specification (hopefully) leads to a complete
implementation.
>
> The majority of verifiable credentials systems proposed have no such
bounds - which is one reason you are likely to see credentials often scoped
to be issued only to specific, qualified wallets in production. Those
specific user agents will enforce the required security and privacy
requirements the issuer has for their credential.

It's not the issuer's credential: it's about where the *user* wants their
information to be sent.

> That is both their own policy logic to be enforced (such as a credential
being bound to hardware), as well as their own requirements for appropriate
user behavior (such as mandatory authentication and mandatory disclosure
before the credential is released). That could include verifier
authentication and having the holder agent confirm the verifier is
authorized by the issuer to make the sort of request they are making -
before a user consent prompt ever enters the picture.

This is not going to work. You don't need permission from the DMV to look
at someone's license. Any sort of commerce related application (looking at
you EU digital wallet) is going to have so many entities involved it won't
really enforce anything consistently. Furthermore, what is enforced may be
less protective than users would want.

>
> You could say that the captcha usage of privacy pass and AAMVA mDL usage
are the same in that they develop trust frameworks that define the network
of acceptable participants. I suspect however that the requirements for the
latter contain significantly more requirements and potentially new
technical works.
>
> A mDL hackathon has likely not set such policy or mandated that mDL and
readers abide by it. They may not even have wanted to limit participants to
having support for specifying complex queries (especially with the
OpenID4VP query language changes which occurred recently). I’m not
surprised a hackathon defaulted to a wide-open attribute policy.
>
> -DW

Sincerely,
Watson Ladd


-- 
Astra mortemque praestare gradatim