Make a clear distinction between the xauth.org service and the XAuth spec

[John]

http://xauth.org/spec/ is a bit confusing if you look at XAuth as a
specification rather than as a web service. It's important to
separate these because otherwise FUD about a central point of control
gets thrown about. If we can point at a clear spec and tell people
they're free to implement it themselves that solves a lot of these
problems. Note that this is mostly a different audience than the
people reading about XAuth to use it or add it to their site, but we
do have 3 tabs, and "Spec" seems like an appropriate place for a
spec :).

Suggestions: "XAuth is an open platform for extending authenticated
user services across the web." -- perhaps say "open specification and
platform"?

Under "Requirements" the first one is an interface requirement --
"Extenders create a public token for use with XAuth (XAuth Token)" --
and all of the others are implementation requirements (or requirements
for compatibility with the current implementation). These should be
separated out, at least into two sections. The second one could be
something like "minimal compatibility requirements" or something
similar.

The API (the XAuth object) should be described separately from the
embed mechanism. The embed mechanism should be described as a
standard way to get an XAuth implementation (and it should implement
XAuth feature sniffing per my earlier post), though implementors
should be able to use other mechanisms to pull in JS dynamically with
their favorite library too.

The API call documentations are described in terms of implementation
details that aren't actually relevant even to the clients. For
example, extend() says "Called by an auth extender. This method
creates an iframe to xauth.org and then it uses window.postMessage to
send this data to the iframe where it will be written to local
storage." It should say something like "Called by an auth extender.
Adds the given token to the token store for later retrieval by other
domains." (Also, the description of the API uses the term "canonical
domain" without explaining it; I can't find a definition of canonical
domain anywhere on the page.)

Same goes for the rest of the API. I think this would make it shorter
and simpler but it would also make clear what's part of the
specification (and can be relied on) and what's part of today's
implementation (which might change at any point).

[Will Meyer]

+5 on delineating a js interface, a "protocol", and an implementation
of a public service to support it all. Would be great to get clarity
on the interface here first, as that ties into some other work going
on in browserland as well as to some discussion of other non-auth
use-cases, both of which have been discussed here but perhaps not
fleshed out. To me it seems that clarifying the service XAuth is
really trying to provide to applications would be a good step; more
valuable than debating all the other pieces (endlessly).

W

> --
> You received this message because you are subscribed to the xAuth group.
> To post, send email to xa...@googlegroups.com
>
> To unsubscribe from this group, send email to
> xauth+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/xauth?hl=en
>