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

[Tom Jones <[e-mail]>]

I am appalled!

All humans must adapt to the consent plans of this small standards group!
I for one do not plan to adapt - sorry about that!

Peace ..tom jones


On Thu, Dec 26, 2024 at 4:15 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. 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.
>
> 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