RE: a proof method using webauthn/passkeys

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.

 

 

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 <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/>