[Members] signin-to-browser initial architecture proposal

Waqas Hussain waqas20 at gmail.com
Fri May 4 15:30:55 UTC 2012


On Wed, May 2, 2012 at 8:28 PM, Dave Cridland <dave at cridland.net> wrote:
> On Wed May  2 15:45:28 2012, jehan at zemarmot.net wrote:
>>
>> And I am happy to help with spec and code with all this if we have some
>> nice project going on. :-)
>
>
> I'm hearing muted support, but no objections, currently. I'd prefer to hear
> more support before we go for this.
>
> I don't think there's yet been any consideration of how we'd pay for this -
> in terms of whether we'd go for bounties, or whatever.
>
> Finally, I don't know what our budget is, quite yet... The XSF has some cash
> we could use, but I'd aim to get some industry cash as well.
>
>
>
>> I can adapt my plugin if needed to have it demo-ing on xmpp.org, I can
>> even give the copyright to the XSF.
>
>
> I'd note that your plugin in sandbox-side, I assume - that is, it's not "in
> the browser", but "in the webpage", so I'm not sure how useful it will be.
>
> I've not stopped to consider licensing questions, personally. I generally
> dislike assignment (it's complex, legally, and gives me moral quibbles) and
> code has well-understood licensing semantics, so something along the lines
> of BSD inbound to the XSF sounds sane to me.
>
> Really, we just need the stuff written, and working - I'm not sure I care
> who actually owns it, as long as we're able to use it to demonstrate the
> system works.
>

You certainly have my support. This is exactly what the XSF should be
doing. I would also like to help with building a prototype.

It's not entirely clear yet what the prototype is supposed to be, and
what the constraints are. Some things to consider in a discussion of
the prototype:

1. We probably want to start with the existing BrowserID code and
replace the protocol with XMPP, without changing much of the existing
protocol's semantics for now.
2. I believe in the current BrowserID protocol, the server is only
allowed to see encrypted data, and users privacy from the server
admins is important. If this is a constraint, we can't go about using
many existing XEPs which assume the server is allowed to see most of
the data. Same goes for normal chat, etc.
3. Offline or LAN-only usage would need to be considered
4. Revoking access to devices may be (should be) a concern. Per-device
credentials would be fairly sweet, which leads to per-device certs for
SASL EXTERNAL auth (not a concern for the initial prototype, unless
the existing BrowserID has this feature).

I was initially concerned about the SRV discussion on
bugzilla.mozilla.org was centered around HTTP-SRV in particular. It's
nice to see the API discussion moved away from the protocol discussion
in <https://bugzilla.mozilla.org/show_bug.cgi?id=735967>.

--
Waqas Hussain


More information about the Members mailing list