Talk:Labs/Weave/WEP/110

1. When we get around to writing up the Account Management Control Document specification (or whatever we're going to call it), we should think about whether to support an XML binding as well as the JSON one you propose - we could easily do both. The structure of the document is certainly quite regular, so far.

2. I would add logout, account-status, account-change and account-revoke to the list of methods you specify there. (definitions TBD!) And I would sugguest "account-management" for the rel attribute.

3. Formalizing something that somebody (thunder? rags?) said to me the other day: we should reference profile data by the combination of a schema identifier (URL) and a list of schema elements (strings). This means that we can be a bit agnostic about schema battles, and future-proof ourselves... while still recommending the schema that we think is best.

So, for example, I would suggest that the register schema you describe in the example be written as:

  "register":
   {
    path: "/register",
    tos: "/register/tos.html",
    method: "POST",
    schema: {
      poco: "http://portablecontacts.net/spec/1.0",
      movies: "http://portablemovieprefs.net/spec/1.0"
    },
    params:
    {
      poco: {
        "username": "name_field",
        "name/givenName": "first_name_field",
        "name/familyName": "last_name_field",
        "email[primary='true']/value": "email_field",
        "password": ["pw_field", "pw_field2"]
      },
      movies: {
        "favorites": "fav_movies_field"
      }
   }

In this strawman syntax, the schemas for data are identified by a 'schemas' element which binds some keynames to their URLs; the 'params' element then contains the schema keynames, which each reference a map of XPath-like term identifiers to form fields.

But in general I think we shouldn't hard-code PoCo 1.0 into our implementation, especially since there are so many competing standards out there already.

We could, also, support a very terse style for the cases where field-specific name overrides are not required... then you could just do:

params: { "username", "name/givenName", "name/familyName" }

4. We should add the notion of "required" and "optional" to the list of register params.

5. We may want to add ToS tagging to each param -- especially email -- otherwise the general ToS will have to encompass it, which could be less useful to users.

If the ToS _must_ be read before account registration can continue, we could include metadata to that effect (and do the usual "next-button-at-the-bottom" thing).

6. We could include a "challenge" parameter in "register", which could be follow an OpenID-challenge-like message exchange pattern for CAPTCHAs, e.g. challenge:

{ 
   src: "/captcha_start.html"
   final: "/captcha_success.html",
   token-param: "captcha_ok"
}

e.g. send the user to captcha_start, and if we get redirected to captcha_success, read the captcha_ok parameter and pass it along with the register request. Or something. That's pretty half-baked. But we have the usual distributed trust problems, of nonces, man-in-the-middles, replays, etc. The other alternative would be to centralize captcha testing (e.g. the register just says "captcha this"), but that means we have the distributed trust problem in reverse -- how does the site know that browser X does a good job captchaing? And then we get into reputation systems, etc. etc.

Some sites won't probably accept to open such a door to massive accounts creation ...

7. Using a link element has some nice properties: it's easy for content administrators, it's self-evident from a view source, and it clearly defines administrative domains on a per-page basis. But it has some bad properties too: it requires that we parse some of the page before we know what to do, and it precludes the use of the HEAD method to optimize the exchange.

Dan had suggested that we actually specify a HTTP header as the account-management link URI, and then use a META HTTP-EQUIV to include it in the body. That's a more browser-ish way to do it. A caveat is that the user community is quite open to crazy new LINK tags, and not so much to new HTTP headers.

One other thought I had is that each of these link URIs effectively defines an administrative domain -- they act quite a lot like the Realm attribute of HTTP Basic Auth in that regard. If we included a "name" attribute on the AMCD (or whatever we call that document!) we could expose that to the user in a not-hostile way.