[Openid-specs-digital-credentials-protocols] Contribution: query syntax proposal

Tue Mar 5 23:01:21 UTC 2024

The public implementation is documented at https://github.com/WICG/digital-identities/wiki/HOWTO%3A-Try-the-Prototype-API-in-Chrome-Android - if you want details on the latest status of that, please ask on the WICG as that’s where the implementors are. The smartphone-to-smartphone sharing of passkeys you can see for yourself with any up to date iOS or Android devices; it should be fairly easy to imagine how that process could be extended to verifiable credentials. The way the WICG has design the API the smartphone-to-smartphone side of things is transparent to the wallet and verifier - the OS deals with all the details of how the request and response are communicated to/from the wallet on the other device in pretty much exactly the same way that happens with the passkeys API.

It would be helpful if you explain why you think it won’t work, rather than just stating that you don’t believe it will.

Again, as I have explained several times, it is NOT necessary to explain to the user what data is required/requested. Only what data will be returned. You’ve not said anything to explain why you believe the request needs to be explained to the user rather than the implications of the request, and as I said it is much more user friendly to explain to the user what will happen rather than all the possible things that might happen. There is nothing in GDPR that requires all the possible outcomes of the request to be explained to the user, the user just needs to give informed consent to what will actually happen. The GDPR also doesn’t require the wallet to explain how the information will be used by the verifier; that burden is on the verifier and I am at a loss to understand how you think we could've designed a protocol that prevents the verifier from explaining to the user how the verifier will use the data they are asking for. The user clearly needs to know who they are sharing data with, I have never seen anyone hint otherwise, that is a pretty fundamental aspect of OAuth2.

I am very unsure how you are repeatedly coming to the conclusion that everyone here including the browser vendors are going to waste our/their time implementing something that won't be compliant with the GDPR. We are all very aware of privacy regulations and you have not pointed out any actual detailed issue. The EU governments have gone over these specs in detail before deciding to adopt them. I can’t rule out that we haven’t missed something somewhere, but if you genuinely believe we’ve missed over 50% of what is required then frankly the problem is not with what we’ve done.

Thanks

Joseph

> On 5 Mar 2024, at 22:22, Tom Jones <thomasclinganjones at gmail.com> wrote:
> 
> Please give me a pointer to a working smartphone/smartphone implementation so that I can test your assertion.
> 
> What i hope the paper i sent made clear is that the user needs to see: (It is still a work in progress)
> Who is asking in a form that the user can understand
> What authority/reason is the request made (I call it the purpose)
> If necessary details about the data required.
> etc.
> 
> What GDPR requires is
> who is the legal entity storing the data (this could be redundant.)
> How the user can contact the entity storing their data.
> etc.
> 
> I have grown tired of explaining this - I told Daniel nearly two years ago and got comments from him much worse than anything I said here.
> 
> Be the change you want to see in the world ..tom
> 
> 
> On Tue, Mar 5, 2024 at 2:07 PM Joseph Heenan <joseph at authlete.com <mailto:joseph at authlete.com>> wrote:
>> Hi Tom
>> 
>> Can you please explain which parts you disagree with and why you disagree?
>> 
>> 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.
>> 
>> On your comment: "You guys really don't seem to care about users at all. Nor about existing privacy regulations.”
>> 
>> 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.
>> 
>> Thanks
>> 
>> Joseph
>> 
>> 
>>> On 5 Mar 2024, at 20:53, Tom Jones <thomasclinganjones at gmail.com <mailto:thomasclinganjones at gmail.com>> wrote:
>>> 
>>> 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.
>>> 
>>> You guys really don't seem to care about users at all. Nor about existing privacy regulations.
>>> 
>>> thx ..Tom (mobile)
>>> 
>>> On Tue, Mar 5, 2024, 10:58 AM Joseph Heenan <joseph at authlete.com <mailto:joseph at authlete.com>> wrote:
>>>> Hi Tom
>>>> 
>>>> 
>>>>> On 5 Mar 2024, at 17:39, Tom Jones via Openid-specs-digital-credentials-protocols <openid-specs-digital-credentials-protocols at lists.openid.net <mailto:openid-specs-digital-credentials-protocols at lists.openid.net>> wrote:
>>>>> 
>>>>> 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. 
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> The proposed UI from the browser/OS vendors (which is being discussed in https://github.com/WICG/digital-identities?tab=readme-ov-file ) 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. https://github.com/WICG/digital-identities?tab=readme-ov-file 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.
>>>> 
>>>> Thanks
>>>> 
>>>> Joseph
>>>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240305/46e73e72/attachment.html>