Profiling multi-factor authentication and other login methods beyond mere password input

[stuartpb]

As alluded to with #134, login, thirdparty.auth, totp and fields like that should all be reconciled with something like how password.reset.flow is moving, with email and other out-of-Web bands interacting.

Putting this on 0.1 because it's a reasonable look to the future and infosec best practices that half the rest of the schema is further along to solving, and having login look the way it does right now is inconsistent and weird.

There should also be stuff detailing how factors can interact. Ideally (TODO: link to my future article on "all the things we're not doing that we should around user account management") it'd just be "as many factors as you want, as separate options or together, in whatever arbitrary combinations of entry you desire", but more likely it's going to look (at least for 0.1) like a space-and-plus ands-and-ors list (though there should be another dimension of "which configurations you can make legal for your account", though that could maybe be implied where if password+totp is present, you can assume it overrides password by itself as an option).

There's also the aspect of systems that only mandate these factors for first login, or some other limited application (another thing that should be user-configurable in an ideal system). that should also be documented, even though that is mostly just a matter of leaving structural room for new fields (ie. that will probably entail a new issue after accommodating this one, with the "new fields" label and tagged on "future", and recorded via login.notes or whatever in the meantime).

[stuartpb]

I think, even though a really flexible definition format is called for, until this kind of flexible configuration catches on (or all these consideration of factors become more widespread etc), this can just be kept as something like login.forms, which can look like password email thirdparty password+totp thirdparty+totp.

[stuartpb]

I think there's no need for login.password, or similar refactorization though, since we have this kind of stuff as password off the root already (same goes for totp and thirdparty and specifically thirdparty.auth), and for the aspects of these things specific to login, we have them as subfields of whatever aspect they hold relevance with (ie. login.usability.password).

Should password.reset.flow.response.email then be moved to email.password.reset.flow.response, which would open the door for, say, email.login, continuing the metaphor of channels-and-factors-being-off-the-root (and well-accomodating the recent refactors post-#127/#128, and how this data is profiled)?

[stuartpb]

Why not flip login.usability.password to login.password.usability? That sounds like it'd be a reasonable concession to this issue's point about login's design not resembling the trends in password.reset, while still addressing the points #136 was declined over.

That would also set the trend for how future login methods that need their own login-specific info would get attached, as sub-fields of login, the way the different methods of password reset go under password.reset (ie flow vs randomize) and password.reset.flow (email vs sms).

[stuartpb]

The new title represents how, like, we have a root password field, but not a root usability field. Basically, just changing login to match the model the rest of the schema is gravitating toward.

Of course, this also implies the other usability field should be revisited... registration.usability? Sounds about right.

[stuartpb]

There's also the memorably-clumsy password.reset.usability.password, which should probably become something like password.reset.new.input.usability (or password.reset.inputs.new.usability or something like that).

[stuartpb]

In the wake of #163 (which solved a lot of the previously-standing weirdness around login) and #227 (which got rid of the one poorly-thought-through feature for documenting 2FA), I'm pivoting this issue back to its original purpose: figuring out how to better represent non-traditional forms of authentication.

[stuartpb]

Also, now that this stuff has been addressed adequately enough (the remaining burrs are listed in separate issues), this can be punted back into future.

[stuartpb]

Yeah, a first real implementation of email-token-login is preset for mammothhq.com, so this is now salient.

I'm thinking of doing it as a subobject of login called send or containing request or something, maybe login.send.email.request even though that's mixed around from how password.reset trees it

[stuartpb]

Honestly, I think password.reset.flow should probably be refactored to be password.reset.flow.email, too, so password.reset.flow.email.response holds response email data instead of password.reset.flow.response.email. And maybe the parts that don't differ between multiple kinds of reset flow can go back up to password.reset.flow's root, but, like, if there's something that's distinctly different, it's going to go under password.reset.flow.email.

That would also allow login to not have to be refactored into some login.password monstrosity for everything, especially in situations where non-password login still look a lot like password login.

So, like, yeah... this shim-style pattern... hmm, I've kind of been avoiding it, but maybe I shouldn't.

[stuartpb]

Eugh... this really should block v0.1.0, but I also really want to move forward with everything else that's tied to v0.1.0 right now (like proper schema validation), and then use that when drafting v0.2.0, so... I'm shunting it over to v0.2.0, with the knowledge that it's going to be the top priority to resolve with the next iteration.