This document defines a simple third-party user-login mechanism, somewhat like OpenID. This mechanism, called "Userpage Authentication" is extremely simple and general purpose. It is not tied to any data formats (such as XML or JSON) or data models (such as XRDS or RDF) and does not use cryptography.
# Introduction
This section is non-normative
Userpage Authentication provides simple shared sign-ons. Instead of
needing to get accounts and passwords with every service, users can
establish a small number of accounts with "Identity Providers" (IDPs)
and use those accounts on other systems, which then become "Relying
Parties" (RPs).
This kind of functionality was largely pioneered by OpenID, and is
typically provided today by Facebook Connect, OAuth, and OpenID
Connect. In contrast to these protocols, Userpage Authentication is
dramatically simpler. Also, unlike some alternatives, Userpage
Authentication requires some logic in the browser, perhaps as part of
a webapp.
A typical Userpage Authentication scenario involves a user, Alice, who
has an account with identity provider myid.example.com. This provider
has set up her user profile page (her "userpage") as
https://myid.example.com/alice.
Now alice visits a service provider, Reliable Robots, at
https://rr.example.com, where she orders some robot parts. During
checkout, she decides to let RR know her identity, so that when she
returns, she'll be able to track her order and see her order history.
Through a mechanism specified in this document, she is able to prove
to RR that she is the person with the userpage
https://myid.example.com/alice. RR can now associate her purchase
with that identity URL. In the future, any time she again proves she
is the person with that userpage, RR can display her order history and
otherwise customize its service.
In the example above, Alice has told RR the URL of her real user page,
which she uses with many other services and which happens to textually
include her real first name. Depending on circumstance, she might
instead decide to provide RR with more information about her, or less
information about her.
To provide more information, she could signal to myid.example.com that it
should provide RR with more information, if it asks. For
example, RR might do a GET on Alice's userpage URL, and then IDS could
include Alice's delivery address using hCard, vCard, PortableContacts,
etc.
To provide less information, she could signal to myid.example.com that
she wants to use a pseudonym. In this case, IDS might generate a
pseudonymous userpage like https://myid.example.com/anon324928490238.
This would be authenticated using the same protocol as for other
userpages. As long as Alice doesn't use this pseudonymous userpage
URL anywhere else, the only thing RR has learned about Alice is that
she's a customer of myid.example.com and the same person as previously
authenticated with that same URL. (In all likelyhood, RR could learn far
more from it's own interaction with Alice, like her IP address.)
# Relying Party Protocols
These protocols allow a user, using a web client (Browser) to
demonstrate to a website (the "relying party") that they are the user
associated with some userpage (such as a user profile page).
@@ insert diagram
## Relying Party Requests Userpage Authentication
If the client performs an HTTP operation for which the RP requires the user to be identified and authenticated, the RP MUST include in its response the header:
``WWW-Authenticate: Userpage``
It MAY include a realm parameter, as per RFC 2617. This header MAY be used with a 401 Unauthrorized response, but to allow fallback to a traditional password form, the header MAY also be used with other responses, including 200 OK. When sent with a 200 OK, this means the page contents are only to be used by systems which do not understand Userpage Authenitcation. Systems which do understand Userpage Authentication MAY ignore the contents.
Do all browsers ignore this, if they don't recognize the scheme?
Do we need a realm parameter?
Without IETF action:
``Link: rel="http://www.w3.org/ns/authentication-method" ``<``http://www.w3.org/ns/authentication-method#userpage``>
## Client Sends Token
Either in response to a "WWW-Authenticate: Userpage" request, or for other reasons, the client MAY choose to authenticate itself.
The client obtains a cryptographically-random token (see below) and sends it to the relying party:
``Authorization: Userpage page="https://...." token="...."``
Here the "page" is the URI of the user's "userpage", the page which the user is claiming describes and identifies them, such as a profile page.
Without IETF action:
``Userpage-Authorization: page="https://...." token="...."``
or
...? Stuff it in User-Agent?!?
## Relying Party Verifies Token
The Relying Party verifies that the client who sent the token is in fact the user of that given page by:
1. Performing a GET or HEAD operation on the page URL, while including the header:
Userpage-Verify: the-token [parameters]
2. Check the response; if the code is 200 OK and the response headers include:
Userpage-Verified: the-token [parameters]
then the authentication process has completed successfully.
[ Alternative designs: (1) use "Authorization: Basic" instead of Userpage-Verify, and use a Link header to a post-authentication-interface instead of Userpage-Verified. ]
# Identity Provider - Client Protocols
IDP creates token since it probably has the better PRNG. It may benefit from particular syntax, too.
Client gets a new token like this:
Authenticated GET or HEAD of the userpage returns one or more of these headers,
different each time. It's only good for 60s seconds unless you de-ref
it, or maybe it has no state anyway.
Link: rel=NewUserpageAuthenticationChannel <....>
GET 'text/plain' returns just the auth token as the body.
Other interactions (GET with other accept types, POST) are available to be defined.
http://www.w3.org/ns/userpage-auth#post-authentication-interface
http://www.w3.org/ns/userpage-auth#new-channel
new-channel-client-end
new-channel-rp-end