Re: a proof method using webauthn/passkeys

Inline

On Mon, Nov 21, 2022 at 10:25 AM <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://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>
> *Sent:* Monday, November 21, 2022 6:54 AM
> *To:* David Chadwick <d.w.chadwick@truetrust.co.uk>
> *Cc:* 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> 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
> <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> 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
>
>
>
> <https://www.transmute.industries/>
>
>
>
>
> --
>
> *ORIE STEELE*
>
> Chief Technical Officer
>
> www.transmute.industries
>
>
>
> <https://www.transmute.industries/>
>


-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>