On Thu, Jan 2, 2025, 7:00 AM George Fletcher <george.fletcher= 40capitalone....@dmarc.ietf.org> wrote:
> +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. > I think the may covers the degree of uncertainty we have. Could might be better but I think that might undersell the consequences. Open to suggestions. > Thanks, > George > > On Fri, Dec 27, 2024 at 9:19 AM Brian Campbell <bcampbell= > 40pingidentity....@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 >> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/oauth/ugVBj2O0hw-nuWNVTFpt0JH3yVY__;!!FrPt2g6CO4Wadw!IkV8PDb1ibu7AVZAjBpsZYOSl3FixR2uBDUoDcqXfwq1wcEBF5hZn325iCcXGQX0ycUI5WzzorLKwP2x03cBCqR_eABSNFxTOdS6EzI$> >> >> 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 <thomasclinganjo...@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 < >>> 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 >>> >> >> *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-le...@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. > > > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
