- From: <nadalin@prodigy.net>
- Date: Mon, 21 Nov 2022 08:55:29 -0800
- To: "'Orie Steele'" <orie@transmute.industries>
- Cc: "'David Chadwick'" <d.w.chadwick@truetrust.co.uk>, <public-credentials@w3.org>
- Message-ID: <16aa01d8fdca$10c90420$325b0c60$@prodigy.net>
See PROPOSAL: Add support for general (hardware backed) cryptographic signatures and key exchange · Issue #1608 · w3c/webauthn (github.com) <https://github.com/w3c/webauthn/issues/1608> From: Orie Steele <orie@transmute.industries> Sent: Monday, November 21, 2022 8:34 AM To: nadalin@prodigy.net Cc: David Chadwick <d.w.chadwick@truetrust.co.uk>; public-credentials@w3.org Subject: Re: a proof method using webauthn/passkeys Inline On Mon, Nov 21, 2022 at 10:25 AM <nadalin@prodigy.net <mailto:nadalin@prodigy.net> > wrote: You can get a standard signature out of them if you are using Device Public Key (DPK), this would go well with the SD-JWK work. Very interesting, this is what I was initially hoping for the first time I tried to use it. <https://github.com/w3c/webauthn/pull/1663/files> https://github.com/w3c/webauthn/pull/1663/files https://w3c.github.io/webauthn/#device-public-key AFAIK, this does not solve for producing a generic ES256 signature, that would be required for integration with JWS / JWT or SD-JWT. Specifically, this step is currently needed to process a "signature over arbitrary content + other stuff that is related to auth and not related to generic signing": https://github.com/transmute-industries/did-passkey/blob/main/src/web/index.js#L149 I'm not aware of a way to get a signature over arbitrary bytes... which is the building block required. Is there a way to get a vanilla ES256 signature from a passkey? If so, then you can get a JWT... if not, then you cannot get a JWT from a device isolated signing process. Can we get a confirmation that you cannot build a standard JWT signer on top of a passkey ? Regards, OS From: Orie Steele <orie@transmute.industries <mailto:orie@transmute.industries> > Sent: Monday, November 21, 2022 6:54 AM To: David Chadwick <d.w.chadwick@truetrust.co.uk <mailto:d.w.chadwick@truetrust.co.uk> > Cc: public-credentials@w3.org <mailto:public-credentials@w3.org> Subject: Re: a proof method using webauthn/passkeys I spent some time with this over the weekend. A few thoughts: 1. Passkeys are authentication keys, so they naturally go in the "authentication" relationship of a DID Document. 2. You can't get a standard signature from them, so they are not suitable for VC or Token Issuance use cases IMO. 3. Similar to "sign in with ethereum" use case, a passkey can be used to delegate to a "real key" that can do more than just authenticate (such as credential issuance), in this case a custom signature scheme and the use of "capabilityInvocation" or "capabilityDelegation" makes sense. I think it's probably worth formalizing the use case for passkey delegation schemes, and this would require a new signature / proof format... similar to how ethereum required ES256K-R, which is not the same as ES256K. With a new signature format, passkey signatures could be used with JOSE and COSE directly. Each registered / supported alg would need a post fix to distinguish it from the "regular / standard" signatures, for example: ES256-WebAuthN EdDSA-WebAuthN Regards, OS On Sun, Nov 20, 2022 at 3:57 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 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 <mailto:david.chadwick@crosswordcybersecurity.com> <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 <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) 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> https://www.fotiou.gr Researcher - Mobile Multimedia Laboratory Athens University of Economics and Business <https://mm.aueb.gr/> https://mm.aueb.gr -- ORIE STEELE Chief Technical Officer www.transmute.industries <http://www.transmute.industries> <https://www.transmute.industries/> -- ORIE STEELE Chief Technical Officer www.transmute.industries <http://www.transmute.industries> <https://www.transmute.industries/> -- ORIE STEELE Chief Technical Officer www.transmute.industries <http://www.transmute.industries> <https://www.transmute.industries/>
Received on Monday, 21 November 2022 16:55:52 UTC