redraw fig 3, polish attestation & assertion signature definitions and prose #463
Conversation
There was a problem hiding this comment.
I started writing comments about the definitions, but this change might just be adding links and not changing the definitions. If that's the case, don't address my initial comments in this PR: it'll be much easier to review them separately from all the additions of [==]s.
| proof of their properties to relying parties via [=attestation=]. This specification also describes the functional model for | ||
| WebAuthn conformant authenticators, including their signature and attestation functionality. | ||
| credentials by web applications, for the purpose of strongly authenticating users. Conceptually, one or more [=public key | ||
| credentials=], each scoped to a given [=Relying Party=], are created and stored on an [=authenticator=] by the user agent in |
There was a problem hiding this comment.
Being nitpicky, it's not the public key credentials that are stored, it's the credential generators or authentication data, depending on whose terminology you want.
| credentials=], each scoped to a given [=Relying Party=], are created and stored on an [=authenticator=] by the user agent in | ||
| conjunction with the web application. The user agent mediates access to [=public key credentials=] in order to preserve user | ||
| privacy. [=Authenticators=] are responsible for ensuring that no operation is performed without [=user consent=]. | ||
| [=Authenticators=] provide cryptographic proof of their properties to [=relying parties=] via [=attestation=]. This |
There was a problem hiding this comment.
Attestation doesn't provide cryptographic proof that, e.g. the authenticator validates user consistency. It proves (modulo key or secure-element compromise, which are probably ok to omit here) that a known entity claims certain properties for the authenticator.
| conveyed in <dfn>attestation objects</dfn>. | ||
| See also [=attestation statement format=], and [=attestation type=]. | ||
| :: Generally, <em>attestation</em> is a statement serving to bear witness, confirm, or authenticate. | ||
| In the WebAuthn context, [=attestation=] is employed to <em>attest</em> to the <em>provenance</em> of an [=authenticator=] |
There was a problem hiding this comment.
- I'd like to be clearer about who is attesting to this sort of thing. Attestations aren't just handed down by God, they can be more or less trustworthy, and RPs ought to pay some attention to that.
- Isn't it less the provenance of the data an authenticator emits (and stores, for private keys), than the security guarantees provided for that data?
| [=authentication=] ceremonies, via the {{CredentialsContainer/get()}} method. The [=[RP]=] uses its copy of the stored public | ||
| key to verify the resultant [=Authentication Assertion=]. | ||
| :: Generically, a <em>credential</em> is data one entity presents to another in order to <em>authenticate</em> the former to the | ||
| latter [[RFC4949]]. A WebAuthn <em>[=public key credential=]</em> is a <code>{ identifier, type }</code> pair identifying |
There was a problem hiding this comment.
This is less true now that WebAuthn subclasses Credential Manager's Credential type, which includes the RFC4949 "signed value" in addition to the RFC4949 "credential".
This and the previous sentence are also inconsistent. The {identifier, type} pair is not the "data one entity presents to another in order to authenticate the former to the latter"; that also has to include the signed challenge. (I favor moving away from RFC4949's definitions for reasons including that it has no term for the data actually used to authenticate.)
…ion signature definitions and prose (#463)
this PR supersedes PR #435 (which I will close). I redrew fig 3 in order to hopefully clarify it and the attestation object's relationship with its various component data structures. Did various editorial/terminological cleaning up.
Preview | Diff