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 <da...@alkaline-solutions.com> wrote: > > > > On Dec 26, 2024, at 10:38 AM, Tom Jones <thomasclinganjo...@gmail.com> > 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
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
