- From: Nikos Fotiou <fotiou@aueb.gr>
- Date: Sat, 19 Nov 2022 21:34:40 +0200
- To: David Chadwick <david.chadwick@crosswordcybersecurity.com>
- Cc: public-credentials@w3.org
- Message-Id: <C5D5010A-D892-4957-997C-7C3F2B4739E2@aueb.gr>
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> 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 >> >> 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> 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) >>> >>> >>> >>> 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/ (source code https://github.com/excid-io/fido2-sign). 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 >>> >>> Researcher - Mobile Multimedia Laboratory >>> >>> Athens University of Economics and Business >>> >>> https://mm.aueb.gr >>> >>> >>> >> >> >> -- >> ORIE STEELE >> Chief Technical Officer >> www.transmute.industries >> >>
Received on Saturday, 19 November 2022 19:34:57 UTC