Skip to content

TtheBC01/passkey-demo

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

99 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Passkey demo in plain HTML

Playing around with the Web Authentication API.

Run locally:

docker run -it --rm --entrypoint bash -p 8000:8000 -v /path/to/passkey-demo/:/root/app python
cd /root/app
python -m http.server

Iframe compatibility

By adding allow="publickey-credentials-get *" to an iframe element, you can request signatures from a passkey generated by a third party domain, but you cannot request a new passkey be created by the third party domain inside the iframe.

<iframe src="https://toddchapman.io/passkey-demo/" allow="publickey-credentials-get *" title="Passkey Demo">
</iframe>

Try it out at w3schools.com.

Other Notes:

Passkey are issued on a per eTLD+1 basis unless other options are specified by the client. That is, abc.example.com, abc.example.com/resource, and def.myexample.com all access the same passkey/public key credential under the W3C standard.

The Web Authentication API (WebAuthn) is its own interface standard separate from the FIDO2 digital signature standard.

Public keys and signatures are returned base64URL encoded. See this forum for info on how to read the bytes in the signature. Also this.

Most major implementations of the Web Authentication API auto increments a counter value every time get is invoked successfully. Hence, even you request a signature on the same challenge text, you will not receive the same signature value on successive invocations. For this reason WebAuthn is not appropriate for key-ratchet style algorithms for deriving new keys from message signing.

The options for public key credential algorithms (pubKeyCredParams) are -7 for Elliptic Curve Digital Signature Algorithm with SHA-256 and -257 for RSA Signature with SHA-256. There is currently no support or plans to natively support secp256k1.

Helpful site: http://ldh.org/asn1.html