of a public service to support it all. Would be great to get clarity
fleshed out. To me it seems that clarifying the service XAuth is
valuable than debating all the other pieces (endlessly).
On Wed, Jun 9, 2010 at 14:15, John <jpan
...@google.com> wrote:
>
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).
> --
> You received this message because you are subscribed to the xAuth group.
> To post, send email to xauth@googlegroups.com
> To unsubscribe from this group, send email to
> xauth+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/xauth?hl=en