XSF Discussion - 2012-05-11

dwd: does the Board have a meeting soon?

30 seconds.

According to the ML anyway.

that *is* soon

I'm shocked to be here on time

hey y'all

hi Ashley

Yes, gosh. Meeting time already.

Although we're rather less than quorate.

I think bear was expecting to be here?

Yes. It was amazingly short notice, really.

dwd: what are the topics for discussion, formal or informal?

Well, there's this browserid project.

Plus I think Mike and Florian were doing things with book shipping to GSoC students.

bear, Hiya.

I poked bear about that yesterday, he was going to check he had all the addresses for ordering books when he was back at his desk.

Ah, and he's here :)

Well, that counts us as quorate if we need to decide anything, I think.

yep - I have the addresses, need to send them to Kev

bear: I don't think I need them.

The next step was Board deciding whether to send the books, I think.

So, stupid question - where are our students, georgaphically?

(And then sending them)

all over the map

Kev, I think Board had already decided to send books, actually.

Oh, ok.

yeah, that's what i recall as well

I remember you saying Bear had to get a price based on where the students were and how much it'd cost to ship.

But yay.

we need to make sure that people get reimbursed appropriately this time, too!

That, as I recall, was related to a discussion on how to actually ship - basically, not getting all the books shipped to Mike and then him sending them air around the globe, or something.

More likely, we use the power of Amazon, or similar, to order the books locally near the students if at all possible.

Germany, Poland, Brazil

we never had the books shipped to me - I used Amazon

and just entered gift addresses

IIRC we used amazon.co.uk for European orders before

yes

stpeter, Amazon europe is one big thing, AFAIK, so they'll ship from whichever depot makes sense.

only the China student caused a small issue, but that was because of how postal codes work, not Amazon.co.uk

so I will start the ordering tonight and send an email to the list with the details

So anyway, this means we can just order the books - anyone want to take responsibility for doing so?

Oh. Mike just has. Marvellous.

I think bear just has, which is great by me because I don't want to :)

Thanks bear.

I will just need to remember to send peter the receipt this time

bear, I don't *think* we need the details beyond the costs to any list.

dwd: agreed

bear, In particular, I don't think we want the addresses anywhere near the list.

the list sending is just my way of asking kev to poke me if he doesn't see it by monday

oh sure, by nature I'm a privacy nut, so that's a given

OK.

So, browserid stuff.

stpeter, I've noticed with some alarm that you've not said anything on this, yet - do you have any particular thoughts?

dwd: I thought it was a good idea when we discussed it in Brussels, but I've been pretty distracted for the last few weeks and I haven't made time to focus on it -- I will try to do that this weekend or next week

OK, great. I just had a horrible vision of you saying "What on earth are you *thinking*!?", so I'm glad you think it's OK. :-)

dwd: I haven't delved into the technical details, but overall it seems like a good thing

I think Simon from buddycloud will also be helping (I don't know if they have announced their news yet re: Mozilla)

I haven't seen it announced anywhere yet.

they are probably waiting on Moz then :/

Right. I was looking at more technical detail on this, and I think there's some key chunks we can break out.

Basically there's a couple of bits of spec (browser->XMPP, and site->browserid), plus the server implementation, plus the browser one.

Of these, the bit I think we're going to struggle on is the browser-side implementation - the rest seem well within our areas of expertise, so we should manage to get these done.

dwd: I'm ashamed to admit that I haven't looked into BrowserID much yet, nor have I thought about the XMPP integration with XMPP -- do you have any kind of writeup or blog post that explores it?

But obviously the implementation work is somewhat gated on the specs.

er, s/XMPP// there

let's post to the list a meeting request so folks interested can come

stpeter, Shockingly, no. But Browserid itself is pretty simple. It's a case of browser gets an "assertion" (ticket) as a credential for a site from the security provider, and the site validates it with a single HTTP request to https://browserid.org/verify

bear, Yeah, I thought that last time Florian was going to do that, but I may be mis-remembering, and I might have told him I would organize the meeting.

bear: well, yes

I'd describe it as PKI with JSON

Zash, It's not even PKI, closer to Kerberos.

it would be good to schedule something a week in advance or somesuch, and preferably have a brief writeup that folks can read (and not just XMPP folks)

Two great flavours that taste great together.

stpeter, Right. I can probably manage the write-up.

dwd: yes, it does sound like Kerberos or even OAuth -- the same ticket pattern in all three cases

stpeter, Right, so in our case what we do need to do is allow multiple verify URIs instead of just one centralized one.

So we should just do Kerberos-over-XMPP, then. Simples.

The ticket can be validated without asking anyone

Zash, Really? Seems like you have to do a POST to the browserid URI.

s/ticket/assertion/

do the security providers register with Mozilla somehow?

Zash, Actually, I think you're volunteering to help me with the write-up.

and do feel free to tell me to RTFM :)

stpeter, No, the browserid model helpfully only provides on security provider.

stpeter, Which I think is daft anyway.

The browser has a key+certificate signed by the ID provider (browserid.org). To sign in somewhere, it sigs an assertion and sends that to the site, which can either ask the provider to verify it, or disassemble it and check it itself.

as I recall, the browserid.org page basically said "1. Collect Underpants 2. Magic Here 3. Profit"

it's a bit more than that now :)

internally mozilla has gone "all in" for browserid - using it for our own tools

Zash, The info I can find suggests that a site can't verify the assertion itself.

dwd: I'd rather think that's because they don't want to encourage people to write RSA code in PHP

Zash, Oh, then again, it actually says "The easiest way to do this". And that's easiest because there's no info on how else one might.

Zash, Right - if that's the case we need to figure out whather to continue with that model. But thanks for volunteering to work with me on a write-up.

Heh :)

I think "Specs welcome" is one up from "Patches welcome".

OK - so if we try to schedule another meeting next week sometime, does that work for everyone?

And we all know what the latter means...

Kev, That patches are welcome?

Something like that.

It was a FOSDEM joke, you had to be there...

dwd: in order to have enough notice and a short document for folks to read, it might need to be the week after (Monday or Tuesday or whatever)

say, May 22nd?

or the 23rd after the Council meeting?

stpeter, Yeah - how about I (and Zash, now) figure out a detailed technical write-up, and then we send that out and schedule the meeting then?

that sounds absolutely super

Righty.

On that note, then, I think we may be done.

Righty. Thanks chaps.

bear, You've a contact who "really" knows about BrowserID, right?

yes

that might be helpful :)

the people who are writing the mozilla stuff

irc.mozilla.org #identity

bear, Oh, OK. If I have a 1980's chat client somewhere I'll go join in.

:)

I can make introductions if you want more of a small meeting type discussion

Ben Adida is very approachable and he is the gateway to the entire Mozilla Identity (now called Personas) project

OK, cool. If I have trouble getting in with the crowd, as it were, I'll give you a shout.

k

Zash, So if I get this right, BrowserID is basically a CA?

Yes

There's some spec here https://github.com/mozilla/browserid/blob/dev/docs/PRIMARY_PROTOCOL.md

Zash, OK - so the BrowserId thing is basically verifying your email address, and then issuing a cert?

Yes.

Zash, Which suggests that *that* is the bit we could easily run over XMPP, actually. So do I have to verify my email address on every brwoser I use (laptop, desktop)?

I suppose the browser prefs syncing should also sync your keys. The rest is up to the CA, it could (as browserid.org does) issue you a normal password that you log in with.

What, for verifying? Or every time?

If your device doesn't have a cert, you're supposed to be provisioned one. How the CA determines who you are isn't in the spec afaik.

BrowserID.org sends a verification email, then lets you choose a password. Then I suppose you could log in with that password to get a cert on another device.

OK, so it's a global CA which has a single password per user.

Does it have a single X.500 directory behind it, too?

Heh

At least you(r email provider) can run a CA too.

Fun, so the current implementation passes arround big numbers in decimal form. The JSON Web * specs says to base64 them.

Suddenly, JSON and base64 everywhere!