Early Review of draft-ietf-httpapi-authentication-link-01
review-ietf-httpapi-authentication-link-01-secdir-early-schwartz-2024-06-28-00

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).