Re: a proof method using webauthn/passkeys

>> The idea is very simple: the digest of a DID document/VC/VP is used as the WebAuthN “challenge”

The challenge must be randomly generated<https://w3c.github.io/webauthn/#sctn-cryptographic-challenges>.

I don't believe a hash of a persistent or semi-persistent object/identifier would be considered "randomly generated".
________________________________
From: David Chadwick <david.chadwick@crosswordcybersecurity.com>
Sent: Monday, November 21, 2022 13:28
To: public-credentials@w3.org <public-credentials@w3.org>
Subject: Re: a proof method using webauthn/passkeys


Hi Nikos

I do believe that the same subjectID sent to different RPs is a correlating handle. In the  words of Kim explaining law 4:

Her system can then set up a “unidirectional” identity relation with the site by selecting an identifier for use with that site and no other. A unidirectional identity relation with a different site would involve fabricating a completely unrelated identifier. Because of this, there is no correlation handle emitted that can be shared between sites to assemble profile activities and preferences into super-dossiers.

If the subjectID is the same for two or more sites then it is by definition a correlating handle

Kind regards

David

On 21/11/2022 16:07, Nikos Fotiou wrote:

Hi David,

Although a bit unrelated to this thread, I don't believe that using the same "subject ID" means that the subject ID becomes and omni-directional identifier. If it was the case then every time a VC is used with a different verifier the subject ID should change. My understanding, based on the passport example here https://www.identityblog.com/?p=352<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.identityblog.com%2F%3Fp%3D352&data=05%7C01%7CTim.Cappalli%40microsoft.com%7C59eec05a481b4fff994e08dacbeea786%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638046523160217416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=spVWDM2Fpi4U7Q4HrmPT9wU02KctmksoXHqfShQfL8g%3D&reserved=0> section "4. Directed Identity",  is that the subject ID should not be  used as  a mean for a third party to "talk" back to you (as for e.g, the  "URL" used in that section as a case of an "omni-directional" identifier).

Best,
Nikos

--
Nikos Fotiou - https://www2.aueb.gr/users/fotiou/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww2.aueb.gr%2Fusers%2Ffotiou%2F&data=05%7C01%7CTim.Cappalli%40microsoft.com%7C59eec05a481b4fff994e08dacbeea786%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638046523160217416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Tf2HGe1JTSGrVU8LztpU6%2FHSJgwIAQcHCwxtewjNC9Q%3D&reserved=0>
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.aueb.gr%2F&data=05%7C01%7CTim.Cappalli%40microsoft.com%7C59eec05a481b4fff994e08dacbeea786%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638046523160373665%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=P%2B4gPEhdjxTVK0ijYkom%2BstkyUrgYOZzE8xLjXGCvSQ%3D&reserved=0>



On 20 Nov 2022, at 11:54 AM, David Chadwick <d.w.chadwick@truetrust.co.uk><mailto:d.w.chadwick@truetrust.co.uk> wrote:

Hi Nikos
the FIDO issue is here
https://bitbucket.org/openid/connect/issues/1542/support-for-fido-authentication<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%2F1542%2Fsupport-for-fido-authentication&data=05%7C01%7CTim.Cappalli%40microsoft.com%7C59eec05a481b4fff994e08dacbeea786%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638046523160373665%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=euwS5XmVDmFtscleW1Jat9WIEAiBAkQzFUdZSziCTew%3D&reserved=0>
I do not know how you can avoid a separate VC per verifier if you are to obey Kim's 4th law of identity (unless you use a ZKP type of assertion) since the subject ID will become an "omni-directional" identifier once the same VC is sent to 2 or more verifiers.
Kind regards
David
On 19/11/2022 19:34, Nikos Fotiou wrote:


Hi David,
Can you provide a link to the issue?
I guess you are referring to your IEEE Communications Standard magazine paper. Although I love this paper, it requires a separate VC per verifier. This is what we are trying to avoid using this approach. Note that we do not violate the SOP: the key included in the VC is used for generating proofs only for the cloud-based wallet (based on a challenge generated by the verifier); then the cloud based wallet relays the proof back to the verifier (e.g., using CHAPI).

I am working on a proof of concept based on CHAPI.

Best,
Nikos



On 18 Nov 2022, at 7:26 PM, David Chadwick <david.chadwick@crosswordcybersecurity.com><mailto:david.chadwick@crosswordcybersecurity.com> wrote:

 I have a different proposal which I have raised as an issue on the OID4VCI list. This is that the authentication mechanism between the wallet and the issuer is based on FIDO2, and this wallet FIDO key pair is used to persistently authenticate the wallet to the issuer. This obeys the SOP. Then we use the existing OID4VCI proofing mechanism where the wallet generates a fresh key pair (in hardware) and sends this to the issuer for it to be used in the VC that is issued. So the FIDO key is never inserted into the VCs as this will violate the SOP.

On 18/11/2022 16:23, Orie Steele wrote:


Very interesting.

I made a similar demo a while back and tried to bind it to did:key, but that failed for several reasons (mostly WebAuthN only produces signatures for authentication, so the identifier you get can't do much).

I feel like there should be a way to add did:jwk to this trivially, perhaps even including some of the additional details in x5c/ x5u.
I
In this issue on the did:jwk method spec: https://github.com/quartzjer/did-jwk/issues/12<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquartzjer%2Fdid-jwk%2Fissues%2F12&data=05%7C01%7CTim.Cappalli%40microsoft.com%7C59eec05a481b4fff994e08dacbeea786%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638046523160373665%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3CW7Kp5U41DGCD5TmGFCIb1HOasQEG%2Faq%2BwGVibdc6E%3D&reserved=0>

I proposed extending did:jwk with additional method specific content... this seems very aligned with what you are proposing regarding the base64url encoding of WEbAuthn related data.

I'd love to collaborate on this further, especially now that chrome supports platform authenticators, I don't even need the Yubikey part (which I had to use in my previous experiment), because using an Apple laptop with fingerprint reader works now.

OS


On Fri, Nov 18, 2022 at 3:45 AM Nikos Fotiou <fotiou@aueb.gr><mailto:fotiou@aueb.gr> wrote:
Hi all,

I would like to propose a new proof method and I would really love your feedback.

The proposed method targets cloud-based wallets and it enables proofs  generated by user-controlled devices using WebaAuthN/Passkeys. The idea is very simple: the digest of a DID document/VC/VP is used as the WebAuthN “challenge” (see this article by Yubico for more details https://developers.yubico.com/WebAuthn/Concepts/Using_WebAuthn_for_Signing.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevelopers.yubico.com%2FWebAuthn%2FConcepts%2FUsing_WebAuthn_for_Signing.html&data=05%7C01%7CTim.Cappalli%40microsoft.com%7C59eec05a481b4fff994e08dacbeea786%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638046523160373665%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ooaI3Q8N4eNWjI0qUGgerBHd8SZ7e9x6EprXBjZ6xiQ%3D&reserved=0>)

I have created a demo page that emulates the functionality that should be implemented by a cloud-based wallet https://excid-io.github.io/fido2-sign/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fexcid-io.github.io%2Ffido2-sign%2F&data=05%7C01%7CTim.Cappalli%40microsoft.com%7C59eec05a481b4fff994e08dacbeea786%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638046523160373665%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XMzXx5SpFkpkC%2FOmcUScJGKUzifV299tCsW9exsAfsU%3D&reserved=0> (source code https://github.com/excid-io/fido2-sign<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fexcid-io%2Ffido2-sign&data=05%7C01%7CTim.Cappalli%40microsoft.com%7C59eec05a481b4fff994e08dacbeea786%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638046523160529902%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EfEgd9jvAvzhpUIngKMS1aW875f7vNBkv1WUh21iHjc%3D&reserved=0>). A proof should then include in addition to the signature, the “authenticatorData” and the base64url encoded “clientDataJSON”. The demo has been tested with Edge/Chrome on windows with yubikey, Safari on iOS 16/MacOS Ventura (passkey), and it fails with Firefox.

Best,
Nikos

Nikos Fotiou - https://www.fotiou.gr<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.fotiou.gr%2F&data=05%7C01%7CTim.Cappalli%40microsoft.com%7C59eec05a481b4fff994e08dacbeea786%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638046523160529902%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=k5%2F6l3o8sH0N81ff6Y4N8b26cdjLZDGcosiRrVmPu28%3D&reserved=0>
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.aueb.gr%2F&data=05%7C01%7CTim.Cappalli%40microsoft.com%7C59eec05a481b4fff994e08dacbeea786%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638046523160529902%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BhaYJBPrObEJY%2F764V4%2FNgRXOMsAhWZhsk4JKz6MheQ%3D&reserved=0>



--
ORIE STEELE Chief Technical Officer
www.transmute.industries<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7CTim.Cappalli%40microsoft.com%7C59eec05a481b4fff994e08dacbeea786%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638046523160529902%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5bszQUAGfy%2FrD2Z6V%2B9A%2Bipu5Bb8h90kRnQxB3QmT0A%3D&reserved=0>