Improve authenticator taxonomy section #1270
Conversation
Start with some example use cases, and expand on what distinguishes the most interesting use cases from the less interesting ones.
To disambiguate from "[=single-factor=] authentication" and "[=multi-factor=] authentication".
|
@bdewater Great to hear, thanks! |
|
ISTM this PR at least improves issue #334 "add clearer definition of API use cases to the spec" |
There was a problem hiding this comment.
This LGTM -- this is much-needed polishing, thx @emlun ! we ought to consider whether it closes #334, or only improves #334 (there's a reasonable chance it seems that it closes #334...) -- what do others think? Maybe there ought to be links from the use cases & scenarios sections down to this new matierial that would justify closing #334, and we can add that in a separate PR (in whichcase keep #334 open for now?)
various detail-level comments below for your consideration. thx again!
index.bs
Outdated
| since it's built directly into the [=client device=] rather than a standalone device. | ||
| - For [=second-factor=] authentication in addition to a traditional username and password, any [=authenticator=] can be used. | ||
| - Passwordless [=multi-factor=] authentication requires an [=authenticator=] | ||
| capable of [=user verification=], and in some cases also [=resident credentials=]. |
There was a problem hiding this comment.
s/ [=resident credentials=] / [=resident credential capable=] /
There was a problem hiding this comment.
I wonder whether (here or elsewhere) we ought to get into the detais regarding the situaltion where resident creds are necessary for pswdless login, eg no ambient creds ...?
There was a problem hiding this comment.
Suggestion applied, thanks!
Hmyeah, maybe. I can't say off the top of my head where that would be though.
| - For [=second-factor=] authentication in addition to a traditional username and password, any [=authenticator=] can be used. | ||
| - Passwordless [=multi-factor=] authentication requires an [=authenticator=] | ||
| capable of [=user verification=], and in some cases also [=resident credentials=]. | ||
| - A laptop computer might support connecting to [=roaming authenticators=] via USB and Bluetooth, |
There was a problem hiding this comment.
this seems a bit disjoint from the prior bullet items, but may not be worth cycles polishing at this time...
| and possession of the [=credential private key=] is used as the only [=authentication factor=]. | ||
| This can be useful in some situations, but makes the user particularly vulnerable to theft of the [=authenticator=]. | ||
| - A [=roaming authenticator=] that is [=multi-factor capable=] but not [=resident credential capable=] | ||
| can be used for [=multi-factor=] authentication, but requires the user to be identified first |
There was a problem hiding this comment.
"identified first" implies the existence of ambient creds, or the user entering a username, or the user picking the desired creds from a pick list ?
There was a problem hiding this comment.
(1) or (2), but not (3) since the authenticator is not resident credential capable in this case.
|
|
||
| A primary use case for [=platform authenticators=] is to register a particular [=client device=] as a "trusted device" available | ||
| as a [=something you have=] [=authentication factor=] for future [=authentication=]. This gives the user the convenience benefit | ||
| Bluetooth. |
There was a problem hiding this comment.
s/ Bluetooth / Bluetooth, for example / ...?
There was a problem hiding this comment.
The sentence begins with "For example", do we need one here as well?
| devices=] that are rarely used or do not include a [=platform authenticator=]; or when policy or preference dictates that the | ||
| [=authenticator=] be kept separate from the [=clients=] it is used with. A [=roaming authenticator=] can also be used to hold | ||
| Use cases for [=roaming authenticators=] include: | ||
| [=authentication|authenticating=] on a new [=client device=] for the first time, |
There was a problem hiding this comment.
s/ time / time (i.e., "bootstrapping" the [=client device=]) / ...?
…231-improve-authenticator-taxonomy
This attempts to fix #1231.
This PR branches from #1250, so let's resolve that before this one. Here is the current diff between PR #1250 and this.
Preview | Diff