Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/tthebc01/passkey-demo
simple github page to test out passkey stuff
https://github.com/tthebc01/passkey-demo
html iframe passkey webauthn
Last synced: 5 days ago
JSON representation
simple github page to test out passkey stuff
- Host: GitHub
- URL: https://github.com/tthebc01/passkey-demo
- Owner: TtheBC01
- License: mit
- Created: 2024-01-09T23:05:29.000Z (12 months ago)
- Default Branch: main
- Last Pushed: 2024-07-25T18:07:02.000Z (6 months ago)
- Last Synced: 2024-07-26T08:10:31.010Z (6 months ago)
- Topics: html, iframe, passkey, webauthn
- Language: HTML
- Homepage: http://toddchapman.io/passkey-demo/
- Size: 122 KB
- Stars: 0
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# Passkey demo in plain HTML
Playing around with the [Web Authentication API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API).
## Run locally:
```shell
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.
```html
```
Try it out at [w3schools.com](https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_iframe).
## 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](https://www.w3.org/TR/webauthn-2/) standard.
The Web Authentication API (WebAuthn) is its own interface standard separate from the [FIDO2](https://fidoalliance.org/specifications/) digital signature standard.
Public keys and signatures are returned [base64URL encoded](https://fidoalliance.org/specs/fido-v2.0-ps-20150904/fido-key-attestation-v2.0-ps-20150904.html#h4_attributes). See this [forum](https://bitcoin.stackexchange.com/questions/92680/what-are-the-der-signature-and-sec-format) for info on how to read the bytes in the signature. Also [this](https://transactionfee.info/charts/bitcoin-script-ecdsa-length/).
Most major implementations of the Web Authentication API auto increments a [counter](https://www.w3.org/TR/webauthn-2/#signature-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](https://www.rfc-editor.org/rfc/rfc9053.html#name-examples-2) (`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`](https://www.rfc-editor.org/rfc/rfc9053.html#name-security-considerations-for).
Helpful site: http://ldh.org/asn1.html