Zero-Steps to Claim

The server could generate a suitable credential and share it with the first visitor's browser. This initiates the "claim" process. Let's call this the zero-steps to claim solution. We here consider how it could then be supplemented with more traditional account management and login mechanisms.

This conversation started in an issue in the Smallest Federated Wiki repository. github

We imagine a Login page that includes a login plugin, perhaps one of many available types, depending on the mechanisms the site operator intends to use for authentication of editors.

Here we consider the states the plugin should recognize, the risks it creates for users, and terminology that might be used to explain and perform state changes.

A subset of these state could be reasonably supported in a minimal or transitional version.

OWNER -- Session information indicates the current user is the owner and has appropriate permissions.

SECRET -- The site is configured for identity sharing through the previous creation of one or more secrets.

PHRASE -- The secret is a pass phrase that the visitor could reasonably type into a field for validation.

NOTICE -- The secret is a notice sent as an email or webpage that has been or could be sent to the previously logged in user. It will contain codes and instructions to reestablish ownership here.

An owner could not understand why on some browsers or computers they can edit their pages but not on others. A Forgot Password page could explain the sites login mechanisms.

An owner could become logged out and not know how, or be unprepared, to log back in. Pages would not be lost, only permission to update them in this location.

A newly created or desirable site could be accidentally or maliciously claimed by another user. Sites could be "born claimed" and new users expected to recover their login secret through their known or provided email address.

A developed site could be hacked by defeating the modest security provided by sessions on http or secrets stored in the clear. The owner's recourse would be to generate new secrets and repair damage from history.

A server operator could be forced to reveal identifying information about a site owner that would prefer to remain anonymous. Such owners would be wise to not provide such information and use the stored webpage option to recover logins.

Server operators could incompetently or maliciously interfere with login information to which they would have privileged access. Concerned site owners can choose to only use servers they setup themselves and reserve privileged access by traditional security mechanisms.

You are logged in as the owner of this site. You can create secrets here to login from other computers or browsers.

You have logged into this site from another computer or browser. Return there to create recovery secrets that can be used to login here.

You have logged into this site from another computer or browser. Type your password to login here.

You have logged into this site from another computer or browser. Shall we email you instructions on how to login here?

You have logged into this site from another computer or browser. Find the page you saved there and follow its instructions to login here.

Type a secret password or phrase you will use later to login to this site.

Type your email address so that we can send you instructions for logging in later or elsewhere.

Click to create login instructions and a secret code that you can save as a webpage in a private place.

A Login plugin could delegate to openId or persona for managing credentials with some terminology confusion in our documentation.

The login machinery could be hosted on a separate webpage such that login would still be possible even if login were required for wiki page reads.

Some of these mechanism are reminiscent of creating a password reset disk. microsoft

People hate to register, though some insist. blog