Comments (4)
Is the reason
AuthenticatorAttestationResponseJSON.clientDataJSON
defined that way for consistency alone? Specifically that allArrayBuffer
s are converted to that?
Yes, the intention was to use consistent encoding of ArrayBuffer
values to something that would survive transmission to the server. As clientDataJSON
is bytes it made sense to treat it like any other ArrayBuffer
, even though as is outlined in the spec it's handled as a UTF-8 string during response verification.
from webauthn.
Fair enough.
from webauthn.
Adding to what @MasterKale said - critically, the encoding of clientDataJSON
MUST remain byte-for-byte identical in transmission from authenticator to server so that the signature over it remains valid. Intermediate parties should not be led to believe that they can safely parse and re-serialize the JSON, because any change to it would break the signature even if the re-serialized JSON is semantically equivalent. Therefore clientDataJSON
is defined as a byte array rather than a DOMString
, to emphasize that intermediate parties should consider it as opaque. These are essentially the same reasons as why JWS also serializes everything as base64-encoded byte arrays even though many of the components are JSON data.
from webauthn.
Adding to what @MasterKale said - critically, the encoding of
clientDataJSON
MUST remain byte-for-byte identical in transmission from authenticator to server so that the signature over it remains valid. Intermediate parties should not be led to believe that they can safely parse and re-serialize the JSON, because any change to it would break the signature even if the re-serialized JSON is semantically equivalent. ThereforeclientDataJSON
is defined as a byte array rather than aDOMString
, to emphasize that intermediate parties should consider it as opaque. These are essentially the same reasons as why JWS also serializes everything as base64-encoded byte arrays even though many of the components are JSON data.
clientDataJSON
is not the only item that must remain identical though. For example RP ID must also remain identical since a SHA-256 hash of it is matched with rpIdHash
in authData
; yet PublicKeyCredentialRpEntity.id
is modeled as a DOMString
and not ArrayBuffer
. I find it more likely RP ID gets altered in transit since an RP ID only needs to be a valid domain string. For example, www.EXample.com
very likely will be altered into www.example.com
when sent from the server to authenticator which will cause the registration to fail. Perhaps that is an issue with how RP ID is defined; but even if the definition were improved to require the RP ID to be the result of the domain-to-ascii algorithm, it would still be essential it does not get altered and thus be modeled as an ArrayBuffer
.
from webauthn.
Related Issues (20)
- Proposal for password-only authentication using ES256 HOT 10
- [[Create]] should not access the global object directly HOT 1
- Define `TypeError` behavior during `.get()` HOT 3
- Return more nuanced errors HOT 3
- Does Related Origins introduce a need for "Related RP IDs" support in `.get()`? HOT 1
- UTF-8 decode should not be required for response.clientDataJSON and cData HOT 2
- CollectedClientData fields are not ordered correctly and crossOrigin should be required HOT 3
- Add `topOrigin` to the limited verification algorithm HOT 2
- Use URI instead of URL for related origins HOT 2
- Add `publicKey` and `publicKeyAlgorithm` to `AuthenticatorAssertionResponseJSON` HOT 3
- Make `AuthenticatorAttestationResponseJSON.publicKeyAlgorithm` optional HOT 2
- Rename PublicKeyCredentialHints to PublicKeyCredentialHint? HOT 1
- CollectedClientData.crossOrigin not referenced in RP ops HOT 1
- Cross-window `Virtual Authenticator Database` HOT 2
- Make `Credential.id` a `DOMString` HOT 2
- Remove `RegistrationResponseJSON.id` and `AuthenticationResponseJSON.id` HOT 10
- Remove rp.name HOT 3
- `options.mediation` should be called something else in step 14 of Registering a New Credential HOT 2
- Add `mediation` to `PublicKeyCredentialJSON` HOT 2
- Add links where non-members can make patent licensing committments to `CONTRIBUTING.md` HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webauthn.