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>