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 B6358C14F70F for ; Thu, 2 Jan 2025 07:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 InyYnM8lQeDb for ; Thu, 2 Jan 2025 07:44:53 -0800 (PST) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EDF5C14F6A0 for ; Thu, 2 Jan 2025 07:44:53 -0800 (PST) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-385d7f19f20so5100635f8f.1 for ; Thu, 02 Jan 2025 07:44:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735832692; x=1736437492; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BwCUfuF9D08v2g5H98aq5CXy684hK3aqn/3UI105niw=; b=mCfNKoQisMuHilnDiyPiLauugifWJuFMkzaoxRmSQfrb18V8Ra0U4kqQ/7NkgGWBuY eKBFo9WYnqMh/LSi/dpU6e+S6DTpoSZ4H0uOk3q/5sZKZTSQb1ThmARD/f4Y20YWoK3s 1AT7N39S0aDaj/ftAtyvZeJBIcLq0KfXMYflVINHg1GqC2hA84Oay36BeW8AG2gA4KRW uvuHed39TkI75zWzQUqh6xkI9AaJBW1Ww4Yj8P7BQVPEvMUEFsviB5VAo7JNfJEQy/H1 L7LA4BIRAzsvCOzt7Hzpemgx5Cj7ZxjlCt2Z0zpQGSnSbj53z5iuKMarwvkjvK/OeCZj IxUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735832692; x=1736437492; 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=BwCUfuF9D08v2g5H98aq5CXy684hK3aqn/3UI105niw=; b=VvCsPz6H3RKqyPVhQhrikMLRkq0n4HGbsugfCQgLBIq46S/uMG5LvvkodcPF8aTjMo 8RfX2JRl0NC0SN6HOCGx+vvvMx9ooYlorx9Z6JouXxaqktIZVE73yPfGOIvcA5mgZ5fD ERR7pWV/GOR9ynAVsLH53TXvd0s0f+blwMpzBI+tn/l9cJUMS6fMl7STiVcMq6zftXao YjF8BKkuYRlfuMawKC37LWkchPn5moTAs8g26G/pXzXjKL7FGOZNqThztU+L1oRf03zn 36i5B7I2ra8KW0GToJFG0BAUkMLAUXDuclEf0vHHISw9IoSCtP/Ve5p8ZidW91DZ4xQq UX3Q== X-Forwarded-Encrypted: i=1; AJvYcCUzUCAqZnW4nmnDoWvMv5KpOpkqk+s/9y2yf59q7J2IgERVm7daJy3l0lRESZhKtBurKxgCzg==@ietf.org X-Gm-Message-State: AOJu0YyTwmcqeJctIK8jvyZN5DZkZPfomFnTm4credJa8OtzzAPWjMjm pPzdIhY/boPvlyLqEbGxYS7EynrluPQt6zZmZ81xrHfSRPRmGslryPvGsT6cEOvEd/w43k2jJ2Q U/BjfEg/7ubnfz/1zPqAdXn8pVqg= X-Gm-Gg: ASbGncsksmW8etvvjWOg/Yb1z851tuGWaLb7ZPuNXiowWMf10qEffi0amSFJVs+MbTI nqpPswYF6HfqcgpT+ZjlvLXKmRNC6excb+00ZFtOdAouZMEUl4WV5zIMpNj8ztUPHiry6iA== X-Google-Smtp-Source: AGHT+IEAscXVUCn9QaxuyQ1bKOhnePLzycsba5M/Bxy6CWUR82ZCs8S1zFxMjfB2WxWdJdIO/CZrYmvXeBPIwnWZWfY= X-Received: by 2002:a5d:47c9:0:b0:38a:615c:8223 with SMTP id ffacd0b85a97d-38a615c82bemr6009708f8f.10.1735832691567; Thu, 02 Jan 2025 07:44:51 -0800 (PST) MIME-Version: 1.0 References: <005A4346-84CE-47CD-BCCC-9EE236F569F1@alkaline-solutions.com> In-Reply-To: From: Watson Ladd Date: Thu, 2 Jan 2025 07:44:40 -0800 Message-ID: To: George Fletcher Content-Type: multipart/alternative; boundary="000000000000f87512062abb0ada" Message-ID-Hash: 3VAB2I4XKE4GGGHNZRGDNOFRXUVE6GII X-Message-ID-Hash: 3VAB2I4XKE4GGGHNZRGDNOFRXUVE6GII X-MailFrom: watsonbladd@gmail.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: Brian Campbell , 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: --000000000000f87512062abb0ada Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 2, 2025, 7:00=E2=80=AFAM George Fletcher 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=E2=80=AFAM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> I feel like this thread has strayed a bit from its origin, which was som= e >> 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, somethi= ng >> 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 grou= p! >>> 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 < >>> david@alkaline-solutions.com> wrote: >>> >>>> >>>> >>>> > On Dec 26, 2024, at 10:38=E2=80=AFAM, Tom Jones >>>> wrote: >>>> > >>>> > This problem was clearly demonstrated by the California mDL hackatho= n >>>> 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 firs= t >>>> introduced that they immediately create a drive to the bottom. This wi= ll 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 appropri= ate >>>> 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 t= hey >>>> 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 pro= blem. >>>> The user agent can only work per the spec if it intends to work proper= ly, >>>> 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 s= coped >>>> 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 o= wn >>>> policy logic to be enforced (such as a credential being bound to hardw= are), >>>> as well as their own requirements for appropriate user behavior (such = as >>>> mandatory authentication and mandatory disclosure before the credentia= l is >>>> released). That could include verifier authentication and having the h= older >>>> agent confirm the verifier is authorized by the issuer to make the sor= t 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 t= he >>>> network of acceptable participants. I suspect however that the require= ments >>>> 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 an= d >>>> readers abide by it. They may not even have wanted to limit participan= ts 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 send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> 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 informatio= n > 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 intend= ed > 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-leave@ietf.org > --000000000000f87512062abb0ada Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 2, 2025, 7:00=E2=80= =AFAM George Fletcher <george.fletcher=3D40capitalone.com@dmarc.ietf.org> wrote:
+1 for including=C2=A0"something along those lines" in = the existing considerations

<= /div>
I would be cautious about defining or assuming "what users n= aively expect" as my guess is that most users are not thinking about t= he things we are thinking about :) That said, any objective considerations = make sense so that developers and implementers of the specification can mak= e informed=C2=A0decisions.

I think the may covers the degree o= f uncertainty we have. Could might be better but I think that might underse= ll the consequences.

Ope= n to suggestions.


Tha= nks,
George

On Fri, Dec 27, 2024 at 9:19=E2=80=AFAM Brian Ca= mpbell <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/ugVBj2O0hw-nuWNVTFpt0JH3yVY

Fr= om 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. <= br>

On Thu, Dec 26, 2024 at 6:28=E2=80=AFPM Tom Jones <th= omasclinganjones@gmail.com> wrote:
I am appalled!
All humans must adapt to the consent plans of this small stand= ards 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 <david@alkaline-solutions.com> wrote:


> On Dec 26, 2024, at 10:38=E2=80=AFAM, Tom Jones <thomascl= inganjones@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 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 -- oauth@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 -- oauth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org

The information contained in this e-mail ma= y be confidential and/or proprietary to Capital One and/or its affiliates a= nd may only be used solely in performance of work or services for Capital O= ne. The information transmitted herewith is intended only for use by the in= dividual 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, ret= ransmission, dissemination, distribution, copying or other use of, or takin= g of any action in reliance upon this information is strictly prohibited. I= f 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-leave@ietf.org
--000000000000f87512062abb0ada--