
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi Tom<div><br></div><div>Can you please explain which parts you disagree with and why you disagree?</div><div><br></div><div>As far as I know, people have this working for smartphone to smartphone exchanges (certainly desktop <-> smartphone). It uses/will use the same technology that is used for cross device passkeys sign in so provides better security than the purely QR code based flows.</div><div><br></div><div>On your comment: "You guys really don't seem to care about users at all. Nor about existing privacy regulations.”</div><div><br></div><div>I ask that you please withdraw that remark, and replace it with one that explains in detail what you think we, the browser vendors and people like the EFF etc may have missed. I do not consider it acceptable to make vague and baseless statements like that, particularly not when I am giving you detailed responses that explain why your assumptions differ from the actual situation we see.</div><div><br></div><div>Thanks</div><div><br></div><div>Joseph</div><div><br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On 5 Mar 2024, at 20:53, Tom Jones <thomasclinganjones@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div><div dir="auto"><div>I disagree with most of what you said. You guys have built something that might work on an Internet interchange, but frankly I doubt even that. It certainly fails for a smart phone interchange with another smartphone.</div><div dir="auto"><br></div><div dir="auto">You guys really don't seem to care about users at all. Nor about existing privacy regulations.</div><div><br></div><div data-smartmail="gmail_signature">thx ..Tom (mobile)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 5, 2024, 10:58 AM Joseph Heenan <<a href="mailto:joseph@authlete.com">joseph@authlete.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="line-break:after-white-space">Hi Tom<div><br id="m_-4462350783374989334lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On 5 Mar 2024, at 17:39, Tom Jones via Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank" rel="noreferrer">openid-specs-digital-credentials-protocols@lists.openid.net</a>> wrote:</div><br><div><div dir="ltr">I really don't know how we got to the point of using OAuth syntax to create a message that must be displayed and accepted by users. </div></div></blockquote><br></div></div><div>We are not doing that. My expectation is that wallets will be asking the user to consent to the data that is to be shared. There is no need to share with users what was requested, the user only needs to know what will be released to the verifier as far as I can see. This is consistent with how I have seen OpenID Connect work; the user consents to the information that will be sent to the relying party. So for example, an OpenID provider does not tell the user that the relying party requested their address if the OpenID provider does not have the user’s address to share.</div><div><br></div><div>Equally there is no need for a wallet to tell a user that the verifier requested the user’s name from passport or a mobile driving license or a EU identity card or a Japanese residence card if the wallet only has a passport to share. It is far user friendlier to ask the user if they want to share the name from their passport.</div><div><br></div><div>The proposed UI from the browser/OS vendors (which is being discussed in <a href="https://github.com/WICG/digital-identities?tab=readme-ov-file" target="_blank" rel="noreferrer">https://github.com/WICG/digital-identities?tab=readme-ov-file</a> ) is that the OS will present to the user a choice of credentials that could satisfy the request (possibly with an indication of which wallet the credential is in), and the wallet will then be given control to collect any necessary consent to the data sharing. <a href="https://github.com/WICG/digital-identities?tab=readme-ov-file" target="_blank" rel="noreferrer">https://github.com/WICG/digital-identities?tab=readme-ov-file</a> is really the only sensible place to discuss the OS provided credential selector as that is where the OS & Browser providers are participating. If that group has made a mistake in what they are developing the best approach seems to me to be to engage with that group, and only explore alternatives if that engagement fails - but I think first it is important to understand what that group has developed. They even have instructions on how to access the experimental API on Android, which they would love implementers to try and give feedback on.</div><div><br></div><div>Thanks</div><div><br></div><div>Joseph</div><div><br></div></div></blockquote></div>

</div></blockquote></div><br></div></div></body></html>