Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD08C1519A0 for ; Thu, 2 Jan 2025 06:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.348 X-Spam-Level: X-Spam-Status: No, score=-10.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.148, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=capitalone.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewjuWhsjV_75 for ; Thu, 2 Jan 2025 06:56:03 -0800 (PST) Received: from mx0a-001b4101.pphosted.com (mx0a-001b4101.pphosted.com [148.163.151.254]) by ietfa.amsl.com (Postfix) with ESMTP id A67F8C1522B9 for ; Thu, 2 Jan 2025 06:56:03 -0800 (PST) Received: from pps.filterd (m0133273.ppops.net [127.0.0.1]) by mx0a-001b4101.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 502EhPOa026336 for ; Thu, 2 Jan 2025 09:56:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=capitalone.com; h=cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=SM2048Mar2022; bh=ThjTqc7rwLxP3jak1Tk0 WEezxA8nLFl403sQbGNvGfw=; b=4LToydlfV70SAzQjatRSEcZtsdk2s+fIgP8E JGUskfOHT0jlluBthujDyh0hX8oOGo9dbiQrpSl3iNJumJsxqh/UeskWPJVwTAOD 4ULuLVJpHjAN5Fu8dIOqEP8BvOcHt92IspF5fzsdYHsZYvcH1Ee7XGFwzMiRve8j Qg0Tyj2PU22YeSDbxDuptabJYIgzEkO8f9AZkGPKsmKlvtzAortAspkkTEMlxt/D sNi4C+wjZijj3NoYfDp6gcj3dsdB2UxD68CcyGS3+075Fwz+7iUtVypLrHDlMNRI DCKytJQpV7nvJi8QKL5wVXP0ZAipN8iLGgxexvcxvkzeTmJm+Q== Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) by mx0a-001b4101.pphosted.com (PPS) with ESMTPS id 43wvtg825w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Thu, 02 Jan 2025 09:56:02 -0500 (EST) Received: by mail-ej1-f69.google.com with SMTP id a640c23a62f3a-aa622312962so348969566b.2 for ; Thu, 02 Jan 2025 06:56:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735829760; x=1736434560; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=E/CTbGm91Fc16LbEW53B6mh9YFiAE5Y1vNpmOG/z2Cs=; b=pKznTILSrqBfqCUqb+0h2vhC7vLgk62CAGaFh4Hni/PGr4mAV8dQllfxq6POLB/8CZ omkE0dj/8VC1MTi+XKcJUtGhHniaV76/TRXDVMRnsChAxA2NiPy7q/eC5KdQ7lbF16Sa 3zq82T/zBXbnkqh+Tn2uFhmT/mCFi1jkXU3v9EMdaUdlBCqJhqrZc18rkAEfY7l77tZP 8XnKyGyuxm2LHI3R/vCam7nx4kOchHK9Fha8Hyb73oGnAticR0Q4ZwFi8JQa0g42hNG2 QwxFGca8RqEaazue5EgQVTgcBJvnai/KmKibXAaIVKnnmwNpDHznOI1fxHdqOTgoX8eO borw== X-Forwarded-Encrypted: i=1; AJvYcCXD4SVOy6aT7eX6X7ZBNoTjSLFPiZHs1VCXsXuDJyfcTtaynW2iTXwYwWFySaLg74DuGJ0yIQ==@ietf.org X-Gm-Message-State: AOJu0YyZ4Fbbm9eN5lqQtrD1lHOssh94Sa4T847AAwJwD+WCW4ai4Kbe x16793wfY+aaFL+KmbZzC0T++Fu+71r/j7ZNeF3YVETqQPy+6wAd29hjzqQaDp2YaO38ZYLyvH1 6oXNGwNNWHCXpeOuJ3iNNsl8tvje/WA5ZBjzwDBHOf4jqd1GTU1lg/yjVl5PLclM5gX9kTQPpVT Z3fzbJG5v6UDznwhcMxpzGf2lY5w== X-Gm-Gg: ASbGnctmR9GZMMqyEsEAg4pS7JJssfkPU1sC3WVs/c7+sktnaKlHAwRMPMTDLYterQr ORYYPjj/83Pb00amTvdJ6W4n0oZUyruFnboc+SaSj X-Received: by 2002:a17:907:3e8c:b0:aa6:abe2:5cb8 with SMTP id a640c23a62f3a-aac3366f16emr4187531266b.60.1735829759853; Thu, 02 Jan 2025 06:55:59 -0800 (PST) X-Google-Smtp-Source: AGHT+IHUpXSy2B/ca/UpxLvOgefeMKpDkPGtQbyYIM6+jcgBFeAW2n6zJjkQDwVZf0QHmVTpmnPlm2HVBmrn77kOGTI= X-Received: by 2002:a17:907:3e8c:b0:aa6:abe2:5cb8 with SMTP id a640c23a62f3a-aac3366f16emr4187528966b.60.1735829759421; Thu, 02 Jan 2025 06:55:59 -0800 (PST) MIME-Version: 1.0 References: <005A4346-84CE-47CD-BCCC-9EE236F569F1@alkaline-solutions.com> In-Reply-To: From: George Fletcher Date: Thu, 2 Jan 2025 09:55:47 -0500 Message-ID: To: Brian Campbell Content-Type: multipart/alternative; boundary="000000000000338710062aba5c66" X-Proofpoint-ORIG-GUID: ZDDI72GHplsMI8RW5TiLCuZUJ8MAAa1k X-Proofpoint-GUID: ZDDI72GHplsMI8RW5TiLCuZUJ8MAAa1k X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1051,Hydra:6.0.680,FMLib:17.12.62.30 definitions=2024-11-01_18,2024-11-01_01,2024-09-30_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=1 clxscore=1015 spamscore=0 mlxscore=0 malwarescore=0 phishscore=1 adultscore=0 mlxlogscore=999 priorityscore=1501 impostorscore=0 suspectscore=0 lowpriorityscore=0 bulkscore=0 classifier=spam adjust=0 reason=forced scancount=1 engine=8.19.0-2411120000 definitions=main-2501020131 Message-ID-Hash: RY3O7DTATZ4ERLXJ5ISPQRIA5F2FVPGI X-Message-ID-Hash: RY3O7DTATZ4ERLXJ5ISPQRIA5F2FVPGI X-MailFrom: george.fletcher@capitalone.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: peace@acm.org, pemc kantara , IETF oauth WG X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BOAUTH-WG=5D_Re=3A_=5BExternal_Sender=5D_Re=3A_Alternative_text_?= =?utf-8?q?for_sd-jwt_privacy_considerations=2E?= List-Id: OAUTH WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000338710062aba5c66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" +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=E2=80=AFAM Brian Campbell 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=E2=80=AFPM Tom Jones > 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=E2=80=AFPM David Waite >> wrote: >> >>> >>> >>> > On Dec 26, 2024, at 10:38=E2=80=AFAM, Tom Jones >>> 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 wil= l be >>> the fate of this standard as well. The most permissive interpretation w= ill >>> 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 pu= shed >>> 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 th= ey >>> 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 prob= lem. >>> The user agent can only work per the spec if it intends to work properl= y, >>> 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 sc= oped >>> 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 hardwa= re), >>> 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 ho= lder >>> 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 netw= ork >>> 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 participant= s to >>> having support for specifying complex queries (especially with the >>> OpenID4VP query language changes which occurred recently). I=E2=80=99m = 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 proprie= tary to Capital One and/or its affiliates and may only be used solely in pe= rformance of work or services for Capital One. The information transmitted = herewith is intended only for use by the individual or entity to which it i= s addressed. If the reader of this message is not the intended recipient, y= ou are hereby notified that any review, retransmission, dissemination, dist= ribution, copying or other use of, or taking of any action in reliance upon= this information is strictly prohibited. If you have received this communi= cation in error, please contact the sender and delete the material from you= r computer. --000000000000338710062aba5c66 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
+1 for including=C2=A0"something alo= ng those lines" in the existing considerations

I would be cautious about defining or ass= uming "what users naively expect" as my guess is that most users = are not thinking about the things we are thinking about :) That said, any o= bjective considerations make sense so that developers and implementers of t= he specification can make informed=C2=A0decisions.

Thanks,
George

On Fri, Dec= 27, 2024 at 9:19=E2=80=AFAM Brian Campbell <bcampbell=3D40pingidentity.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/ugVBj2O0= hw-nuWNVTFpt0JH3yVY

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

=
On Thu, De= c 26, 2024 at 6:28=E2=80=AFPM Tom Jones <thomasclinganjones@gmail.com> wro= te:
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!

Pe= ace ..tom jones


On Thu, Dec 26, 2024 at= 4:15=E2=80=AFPM David Waite <david@alkaline-solutions.com> wrote:


> On Dec 26, 2024, at 10:38=E2=80=AFAM, Tom Jones <thomasclinganjones@gmail.co= m> wrote:
>
> This problem was clearly demonstrated by the California mDL hackathon = where the default presentation was ALL DATA. That is the easiest path, so i= t remains the one most taken. We have known since standards were first intr= oduced 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 fr= om the issuing authority is that the complexity that was the business logic= for handling requests, determining if they are appropriate for the use cas= e, prompting the user for consent, etc. is now all complexity pushed into t= he (likely third party) user agent.

Architectures like PRIVACYPASS create individual solutions to release a par= ticular 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. Th= e 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 u= ser 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 o= wn requirements for appropriate user behavior (such as mandatory authentica= tion and mandatory disclosure before the credential is released). That coul= d include verifier authentication and having the holder agent confirm the v= erifier is authorized by the issuer to make the sort of request they are ma= king - before a user consent prompt ever enters the picture.

You could say that the captcha usage of privacy pass and AAMVA mDL usage ar= e the same in that they develop trust frameworks that define the network of= acceptable participants. I suspect however that the requirements for the l= atter contain significantly more requirements and potentially new technical= works.

A mDL hackathon has likely not set such policy or mandated that mDL and rea= ders abide by it. They may not even have wanted to limit participants to ha= ving support for specifying complex queries (especially with the OpenID4VP = query language changes which occurred recently). I=E2=80=99m not surprised = a hackathon defaulted to a wide-open attribute policy.

-DW
_______________________________________________
OAuth mailing list -- o= auth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.________________________= _______________________
OAuth mailing list -- o= auth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org


The information contained in this e-mail may be con= fidential and/or proprietary to Capital One and/or its affiliates and may o= nly 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 t= he intended recipient, you are hereby notified that any review, retransmiss= ion, dissemination, distribution, copying or other use of, or taking of any= action in reliance upon this information is strictly prohibited. If you ha= ve received this communication in error, please contact the sender and dele= te the material from your computer.


--000000000000338710062aba5c66--