Key take-aways distilled from the notes; changes we plan to make to the spec based on discussions during the meetup:

Key Spec Proposals

Static resolution of multiple AMCDs per-site

Some of the methods in the status techniques breakout session indicate a desire by sites to statically define more than one AMCD per site. The current spec allows only one, so there are suggestions that attempt to map multiple realms into one AMCD by e.g. causing a status refresh upon encountering a particular URL change.

The real problem is that multiple realms should have their own AMCD. The Account Manager spec could be changed to allow for multiple realms per domain to be statically defined in an elegant manner. For example:

• The browser loads /.well-known/host-meta to look for an AMCD as usual.
• host-meta contains multiple AMCD link elements, each with an optional 'path' parameter which defines the prefix that AMCD is valid for (just like cookies).
• Link tags are checked one by one, top-down. The first one that matches is used.
• Note that the last link element can omit the path element, making it a catch-all.
• Also note that sites with a single realm need no changes.

This would work pretty well for most sites. It would be easy to implement, map well to cookies, and the browser would cache the active username independently for each realm (so a status ping would not be required for navigating between realms).

Really basic cookie-mapping

Account Manager avoids cookie-mapping, because the contents of cookies are complex and opaque enough that looking into them to figure out server state would be very error-prone (in our opinion). But an idea came up to do something very simple: allow the realm to list cookies which, when set (or cleared) should cause a status ping. This would ensure that in most cases the browser will display the correct status even if the site is not sending the Account-Management-Status header with their responses.

One slight quirk is that the browser should probably ignore the caching hints when the cookie changes.

Flood-attack prevention

Automated registration can open a form of flood attack on services, since the service is required to save some state on the server (because the current registration spec forces the site to commit to a username/password before they are able to CAPTCHA the user).

After lots of brainstorming, there are five options on the table:

1. The UA works in tandem with a CAPTCHA service, does a CAPTCHA before forcing the site to commit to a username/password.
2. Similar to the above, but the UA instead implements an "open CAPTCHA server API" instead, and allows the site to specify a server that speaks that protocol.
3. The UA scrapes credentials during the process, somehow augmented with extra information so it is more deterministic.
4. The UA establishes a token (which need not be saved on the server), and passes that token into the registration process. After the process is finished, the UA can use that token to find out the final credentials.
5. The UA negotiates a potential username/password and the site sets a cookie containing them. When the form is loaded, the site can use the cookie to provide a custom form. If the registration is successful, the UA commits those credentials, otherwise it restarts the process.

Currently, the 4th option, or a variation that uses cookies, seems like the best approach. The interaction would look something like:

UA initiates the process by requesting a sign-up form, proposing
the user's preferred credentials:

--- register(proposed user, proposed pass) -->

The site can return an error in a header and negotiate with
the UA:

    <----
    ---->
<-- 200 OK, Set-cookie:<token>, body: registration form ---

Site commits to accepting that password, but not the username.
The user and the site can have several round trips during the
registration flow:

    ---->
    <----
    ---->
<-- 200 OK, registration complete header, body: welcome content ---

The UA finds out the final username, and commits both the username
and password (from the first step) to its database.

--- confirm-registration (note <token> is in header) -->
<-- 200 OK, final username ---

A variant of the above could be to allow the password to be changed during the registration flow, but that would require the final confirmation step to return the credentials (username and password both), which sites might not want to do (?). The confirm-registration step need only work once, however, the <token> in the cookie could expire after first use, or have a very short life.

Other Ideas

These are ideas that are either not baked enough, or things we might want to punt to a future release, or maybe not do at all.

JS API for setting status

This goes hand-in-hand with in-content markup for setting the status. While we aren't completely opposed to the idea, we are trying to avoid that in order to completely side-step any XSS attacks.

JSON in headers

Sadly, JSON isn't 7-bit clean, which headers need to be. We would need to Base-64 encode the header, which would be a lot worse to look at (though relatively easy to implement). Maybe someday...

Multiple IDs in the status header

We're not sold on this. We think those are probably multiple realms, and should be represented as multiple AMCDs.

Referrer URLs

On the fence on this one. Not sure it really makes sense, since the browser could initiate requests unrelated to any page. This should likely be solved on the site by using multiple AMCDs with unique URLs telling the site what the method is for (e.g., put path="/connect?ref=foo" in the AMCD).

Splitting authentication profiles from other profiles

We have some thoughts around it, but it's not clear yet. More work to do here.

Federation

Still distilling proposals here, stay tuned.

Multi-factor auth, other future ideas

Perhaps we need a way for sites to specify more complex scenarios? Like, choose any two of these auth profiles {...}, or even more compex schemes.

Execute code from the server that determines what to do? (crazy).

Definitely need to explore this idea some more.