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

[Watson Ladd <[e-mail]>]

On Thu, Jan 2, 2025, 7:00 AM George Fletcher <george.fletcher=
[e-mail]> 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=
> [e-mail]> 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 <[e-mail]>
>> 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 <
>>> [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
>>>
>>> _______________________________________________
>>> OAuth mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>
>> *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 -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> ------------------------------
>
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>