+1 for including "something along those lines" in the existing considerations

I would be cautious about defining or assuming "what users naively expect" as my guess is that most users are not thinking about the things we are thinking about :) That said, any objective considerations make sense so that developers and implementers of the specification can make informed decisions.

Thanks,
George

On Fri, Dec 27, 2024 at 9:19 AM Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> wrote:
I feel like this thread has strayed a bit from its origin, which was some text Watson proposed for the privacy considerations https://mailarchive.ietf.org/arch/msg/oauth/ugVBj2O0hw-nuWNVTFpt0JH3yVY

From my perspective, it wouldn't be a wholesale replacement for anything but, assuming the co-authors and WG in general are okay with it, something along those lines could be incorporated into the existing considerations.

On Thu, Dec 26, 2024 at 6:28 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
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 <david@alkaline-solutions.com> wrote:


> On Dec 26, 2024, at 10:38 AM, Tom Jones <thomasclinganjones@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-leave@ietf.org

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org


The information contained in this e-mail may be confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.