This draft presents an interesting idea with some significant gaps. It imagines a world where the "login state" of users on websites is presented explicitly in the browser chrome, rather than within the page content, and provides some affordances to that effect.  However, it does not mention any review from the W3C or related web groups to confirm that this is something desired by the web community.

Functionally, many aspects of the proposed relations are unclear:
* If a user follows one of these links, should it replace the page content or open separately?  If it opens separately, should it autoclose when the action (e.g. "login") completes, and if so how?  (This is more ergonomic but creates risk related to "clickjacking".)  Should the page content be reloaded after a login state change?
* What format does "authenticated-as" provide?  It seems like the intent here would be to support a "chip" in the browser chrome showing the logged-in user's name (and icon/picture?), but this would require specifying the actual format of the resource, which is not done here.

The proposal also creates a number of serious security considerations:
* Any new login flow represents a new opportunity for phishing attacks (via login form impersonation).  The draft doesn't address this topic.  (There is no Security Considerations section.)
* Users typically expect that browser UI elements are "verified" by the browser, whereas page contents are under the sole control of the origin.  Placing login-related elements in the browser UI creates a risk that origins will lie to the browser about the login state, and users will perceive those lies as "verified" when they are not.  For example, a phishing page might be more convincing when it asks the user to "re-enter your password for additional security" if the browser chrome shows that the user is already logged in.

If this work is intended for use by browsers (as the text suggests), then I think it needs to go through the W3C or a related group.  If not, then I would recommend restructuring it as one or more HTTP response headers that could be used to facilitate login in non-browser contexts (e.g. for JMAP clients).