[xauth] Hosting party updates?

[Will Meyer]

Hey all. Curious if there are any updates on the hosting front.
Specifically, there was some discussion around the announcement about
potential hosting via OIDF or similar parties (both the CDN/ops side
as well as the code management process). Have there been any more
discussions on that? And is this the forum where such discussion will
happen?

Anxious to work through the issues standing between us and a potential
real-world deployment scenario...

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

[Jian Shen]

Hi Will,

We are indeed doing the paperwork and legal lifting on this front. I can't guarantee a timeframe just yet (need to do a round up with our legal folks on status) but I'm just as anxious as you are to hit this milestone. The goal would indeed be to have an independent organization be responsible for hosting and protecting the domain.

In the mean time, we are looking for technical feedback on the code and would love to see demonstrations of security holes and other technical weaknesses. Other areas to iterate on are ease of use for developers and the end user experience since one of the goals is to give users more control over their privacy. Plenty to explore. :)

Stay tuned!

-Jian

[Will Meyer]

On Wed, May 5, 2010 at 22:16, Jian Shen <jian...@gmail.com> wrote:
> Hi Will,
> We are indeed doing the paperwork and legal lifting on this front. I can't
> guarantee a timeframe just yet (need to do a round up with our legal folks
> on status) but I'm just as anxious as you are to hit this milestone. The
> goal would indeed be to have an independent organization be responsible for
> hosting and protecting the domain.

Sounds awesome. When we get to things like cache control headers and
all that I think it'd be great to review that on the list -- huge
performance implications obv. Similarly, the code governance process
for new versions/fixes seems like it needs to be nailed for folks to
include the code in their site flows (or their sharing tools).
Anyway, great to hear thats all in work, anxious to hear how it
unfolds.

> In the mean time, we are looking for technical feedback on the code and
> would love to see demonstrations of security holes and other technical
> weaknesses. Other areas to iterate on are ease of use for developers and the
> end user experience since one of the goals is to give users more control
> over their privacy. Plenty to explore. :)

I had shared a few comments earlier in other threads re the token
definition and how that was shaping up, both in terms of what the
boolean check really means and in terms of overloading other type data
into them, still curious about that. Also, one more specific question
is whether the disallow of the * on the retriever side is intentional
for security reasons. We can pick these things up in other threads
perhaps, wasn't sure if all the discussion was happening on-list.

[Allen Tom]

Any chance that xauth.org can be hosted on HTTPS? The reasons are:

1) Service Providers may want to call Xauth.extend() from an HTTPS page, and
would not want users to see a browser warning

2) A MITM could read all the Xauth tokens. A MITM could either sniff the
content in Xauth.org or it could spoof DNS and return a rogue version of
xauth.js. Both of these attacks could be mitigated by using HTTPS.

Allen

[John Bradley]

Hijacking xauth.org is a tempting target. It should only be serving on https.

John B.

[Mike Hanson]

+1, it should definitely be SSL-only.

-Mike
--
Michael Hanson, Mozilla Labs (@michaelrhanson)

[Rabbit]

+1 SSL-only.

Might be important to note:
* Would requiring SSL impact performance on mobile devices
significantly? Would be interested in seeing metrics. I'm assuming not.
* localStorage origin includes scheme. Storing a token without SSL
should throw an error to avoid having retrievers query two schemes for
tokens.

=Rabbit

[Jian Shen]

Nice! Great point on checking the origin scheme when writing to storage.

[Sam Johnston]

On 7 May 2010 01:01, Jian Shen <jian...@gmail.com> wrote:

Nice! Great point on checking the origin scheme when writing to storage.

If you don't then surely I can mint a session for you, write it to XAuth and hijack it later.

Sam

--
Sam Johnston

Technical Program Manager

Site Reliability Engineering

Google Switzerland GmbH

w: +41 44 668 16 79

h: +41 44 536 55 78

m: +41 79 631 25 16