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 This provider has set up her user profile page (her "userpage") as Now alice visits a service provider, Reliable Robots, at, 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 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 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 that she wants to use a pseudonym. In this case, IDS might generate a pseudonymous userpage like 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 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="" ``<````>
## 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="...."``
...? 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. new-channel-client-end new-channel-rp-end