Account Options

  1. Sign in
The old Google Groups will be going away soon.
Switch to the new Google Groups.
Google Groups Home
« Groups Home
Make a clear distinction between the xauth.org service and the XAuth spec
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  2 messages - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
John  
View profile   Translate to Translated (View Original)
 More options Jun 9 2010, 2:15 pm
From: John <jpan...@google.com>
Date: Wed, 9 Jun 2010 11:15:23 -0700 (PDT)
Local: Wed, Jun 9 2010 2:15 pm
Subject: Make a clear distinction between the xauth.org service and the XAuth spec
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 must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Will Meyer  
View profile  
 More options Jun 9 2010, 4:32 pm
From: Will Meyer <w...@willmeyer.com>
Date: Wed, 9 Jun 2010 16:32:50 -0400
Local: Wed, Jun 9 2010 4:32 pm
Subject: Re: [xauth] Make a clear distinction between the xauth.org service and the XAuth spec
+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 must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »