Self-hosted BrowserId / browser integration

[Christian Weiske]

Hello,


I'm considering implementing BrowserId for SemanticScuttle, a
self-hosted social bookmark manager and have some questions.

1. You're saying that BrowserID is decentralized[1]. However, I need to
load a javascript from browserid.org, which is absolutely not
decentralized and a single point of failure.
2. Which browsers support browserid natively?
3. Is it possible to host the browserid.org javascript myself (with my
application)? Does ist still work then?
4. Where can I find instructions to setup a self-hosted browserid.org
page?
5. (Maybe I'm misunderstanding it here) How does BrowserId distinguish
between implementation providers? Is it possible for me to host my
own implementation provider for my own domain?

[1] https://github.com/mozilla/browserid/wiki/How-BrowserID-Works


--
Viele Grüße
Christian Weiske

[Burak Yiğit Kaya]

Hello Christian,

On Tue, Dec 27, 2011 at 10:22, Christian Weiske <cwe...@cweiske.de> wrote:

1. You're saying that BrowserID is decentralized[1]. However, I need to
load a javascript from browserid.org, which is absolutely not
decentralized and a single point of failure.

This will change soon. The reason you should inclode it from browserid.org *for
now* is because the specs and thus the file is under heavy change in the
mean time. Also, when te browsers support this natively, you won't have to
include it.

2. Which browsers support browserid natively?

No browser again *for now* AFAIK. (yes not even Firefox)

3. Is it possible to host the browserid.org javascript myself (with my
application)? Does ist still work then?

Yes, it should work.

4. Where can I find instructions to setup a self-hosted browserid.org
page?

I remember watching a video from Ben Adida about this but I couldn't find
the video nor a written documentation. This is an issue.

5. (Maybe I'm misunderstanding it here) How does BrowserId distinguish
between implementation providers? Is it possible for me to host my
own implementation provider for my own domain?

I guess you can since it is bound to the domain that the e-mail address is
defined on, again AFAIK.



Burak Yiğit "BYK" Kaya <http://byk.im>

[Ben Adida]

Adding a few things to Burak's very useful guidance.

> 1. You're saying that BrowserID is decentralized[1]. However, I need to
> load a javascript from browserid.org, which is absolutely not
> decentralized and a single point of failure.

> This will change soon. The reason you should inclode it from browserid.org *for
> now* is because the specs and thus the file is under heavy change in the
> mean time. Also, when te browsers support this natively, you won't have to
> include it.

That's exactly right. It's decentralized by design, but currently has
some centralized scaffolding, including browserid.org. If you have the
time, watch this talk that explains the design, the scaffolding, and how
we plan to have the scaffolding melt away:

http://identity.mozilla.com/post/11145921163/browserid-design-for-privacy

> 2. Which browsers support browserid natively?

> No browser again *for now* AFAIK. (yes not even Firefox)

Correct. There's no reason for browsers to rush to support BrowserID
right now as we are finalizing the spec for primary support.

> 3. Is it possible to host the browserid.org javascript myself (with my
> application)? Does ist still work then?

> Yes, it should work.

Yes, but since we're still changing things around to make it faster,
more cross-browser compatible, you may find yourself in a broken state
if you do that. We would recommend you hold off on that for a bit.

We have set up the browserid.org server infrastructure to be quite
robust. You can depend on us.

> 4. Where can I find instructions to setup a self-hosted browserid.org
> page?

You don't want to do that, it won't work for a few reasons. The most
important one is: who's certifying email address ownership? Eventually,
we want it to be primary identity providers, i.e. the domains that
actually issue email addresses. For those domains that don't support it,
you need to trust someone to verify those email addresses. We suggest
you let Mozilla do this for now. Again, this is scaffolding. We don't
want to be in this certification position for very long. But we have to
be to get the ball rolling.

If you set up your own browserid.org instance, then the only way that
works is if the web sites you visit specifically trust that instance of
BrowserID to verify email addresses. That's unlikely to scale, because
it's not discoverable.

The point of scale is when individual domains certify their own email
addresses, as follows:

http://lloyd.io/primary-identity-authorities-in-browserid

> 5. (Maybe I'm misunderstanding it here) How does BrowserId distinguish
> between implementation providers? Is it possible for me to host my
> own implementation provider for my own domain?

> I guess you can since it is bound to the domain that the e-mail address is
> defined on, again AFAIK.

It's technically possible for you to bundle an implementation provider
with your primary IdP, as long as that implementation provider doesn't
also play the role of a secondary provider.

But let's take a step back: what are you trying to accomplish? You're
getting buried in the details of temporary scaffolding of BrowserID, and
maybe the problem you're trying to solve is simpler.

-Ben

[Christian Weiske]

Hello Ben,

> > 5. (Maybe I'm misunderstanding it here) How does BrowserId
> > distinguish between implementation providers? Is it possible for me
> > to host my own implementation provider for my own domain?
> > I guess you can since it is bound to the domain that the e-mail
> > address is defined on, again AFAIK.
> It's technically possible for you to bundle an implementation
> provider with your primary IdP, as long as that implementation
> provider doesn't also play the role of a secondary provider.
>
> But let's take a step back: what are you trying to accomplish? You're
> getting buried in the details of temporary scaffolding of BrowserID,
> and maybe the problem you're trying to solve is simpler.

I'm trying to find a way to log into my own BrowserId application
without having contact with browserid.org at all.

But since you wrote that BrowserId is still a moving target and that
"[it] currently has some centralized scaffolding, including
browserid.org", that'll probably take a while.

Thanks for the explanations.

[Peter Williams]

my issue is that there should be several centralized scaffoldings. Many designs use well-known entrypoints (as bootstraps for graph resolution). But, they are plural. One thinks of the certs world, where from 1988 to 1992, the structure went from a centralized root (of all evil) to policy certification authorities, each running an autonomous management domain (that MIGHT register with a central registry run by MIT - trying to get itself into the taxation authority business that eventually went to ICANN). This all ultimately gave us the fan-out of today in the CA world. Yes you can argue that it gave us crap, but its large scale crap (with cryptopolitics that , somehow, works). Smaller policy networks with focussed needs soon tune it up for higher assurance..
> Date: Tue, 27 Dec 2011 16:21:10 +0100
> From: cwe...@cweiske.de
> Subject: Re: Self-hosted BrowserId / browser integration
> To: dev-id...@lists.mozilla.org

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity

[Peter Williams]

I watched the video (and read the slides offline).



We have conventional cert enrollment, using the RFC822 naming option. The cert has a digsig bit, enabling the UA to sign blobs that are posted off to relying party sites (just like in ws-security soap proof tokens, in silverlight clients today). This is almost identical to what IE folks have had for years (having downloaded the CryptoAPI activeX control, which exposes the javascript API).



Assume the signed blob is a PKCS#7 formatted blob with cert chain (or its an xml/dsig blob, similarly). Recipient verifies then validates cert chain, and thence signature on blob, at which point the network has delivered an (unassured) digital signature service between two mutually suspicious parties. To assess the assurnace level of the signature, one evaluates the authority of the cert chain (as normal) and one determines is the certification authority is entitled to speak for the (RFC822) naming authority. To do this, the verifier considers the name of the issuer of the root cert to be a URI, and the verifier tests whether the self-signed root cert exists on the https resource in the public net. The SSL certs of said resource chain to a root cert in the server vendors trust store (as normal), or not; accomplish the usual one process of one act of reliance boostrapping another.


This is classical policy authority resolution using cert chains, with the https SSL endpoint playing the role of LDAP endpoints. In the windows world, of course kerberos turst authenticate the ldap endpoint, which authenticates the binding between its ldap container name and the cert. Typically, the ldap name is a domain - in funky form: dc=adida,dc=com, for historical reasons.

There is the option to invite a third party webservice, again authenticated using public CA https, to remotely verify and validate PKCS7 or xml/dsig blobs



To do delegation today, there seems no reason why the browserid.org can not have its (public) CA issue browserid a CA-cert, rather than a server cert. browserid (as policy CA) can mint a cert to my "enterprise-scoped" Microsoft CA, and I can be a subordinate/delegate/flunky. I already have my IE users auto-enrolling for certs, and they contain UPNs in the form pe...@verisign.com (and UPN domain-level validation can be used, in the windows world). if the user has an RFC822 address in their directory entry, its trivial to have my CA populate the certs subject name with the RFC822 address, in either the subkect DN or in the more correct RFC 822 SAN.



Im wililing to run a browserid validator using ASP.NET (recently discussed), if I can be an autonmous issuer, using the microsoft CA. Ive no object to being crosscertified by browserid.org, and be therefore "under" its policy management authority for email validation assurance.






> Date: Tue, 27 Dec 2011 06:59:19 -0800
> From: b...@adida.net
> To: dev-id...@lists.mozilla.org

> Subject: Re: Self-hosted BrowserId / browser integration
>
>

> Adding a few things to Burak's very useful guidance.
>

> > 1. You're saying that BrowserID is decentralized[1]. However, I need to
> > load a javascript from browserid.org, which is absolutely not
> > decentralized and a single point of failure.

> > This will change soon. The reason you should inclode it from browserid.org *for
> > now* is because the specs and thus the file is under heavy change in the
> > mean time. Also, when te browsers support this natively, you won't have to
> > include it.
>
> That's exactly right. It's decentralized by design, but currently has
> some centralized scaffolding, including browserid.org. If you have the
> time, watch this talk that explains the design, the scaffolding, and how
> we plan to have the scaffolding melt away:
>
> http://identity.mozilla.com/post/11145921163/browserid-design-for-privacy
>

> > 2. Which browsers support browserid natively?

> > No browser again *for now* AFAIK. (yes not even Firefox)
>
> Correct. There's no reason for browsers to rush to support BrowserID
> right now as we are finalizing the spec for primary support.
>

> > 3. Is it possible to host the browserid.org javascript myself (with my
> > application)? Does ist still work then?

> > Yes, it should work.
>
> Yes, but since we're still changing things around to make it faster,
> more cross-browser compatible, you may find yourself in a broken state
> if you do that. We would recommend you hold off on that for a bit.
>
> We have set up the browserid.org server infrastructure to be quite
> robust. You can depend on us.
>

> > 4. Where can I find instructions to setup a self-hosted browserid.org
> > page?
>

> You don't want to do that, it won't work for a few reasons. The most
> important one is: who's certifying email address ownership? Eventually,
> we want it to be primary identity providers, i.e. the domains that
> actually issue email addresses. For those domains that don't support it,
> you need to trust someone to verify those email addresses. We suggest
> you let Mozilla do this for now. Again, this is scaffolding. We don't
> want to be in this certification position for very long. But we have to
> be to get the ball rolling.
>
> If you set up your own browserid.org instance, then the only way that
> works is if the web sites you visit specifically trust that instance of
> BrowserID to verify email addresses. That's unlikely to scale, because
> it's not discoverable.
>
> The point of scale is when individual domains certify their own email
> addresses, as follows:
>
> http://lloyd.io/primary-identity-authorities-in-browserid
>

> > 5. (Maybe I'm misunderstanding it here) How does BrowserId distinguish
> > between implementation providers? Is it possible for me to host my
> > own implementation provider for my own domain?

> > I guess you can since it is bound to the domain that the e-mail address is
> > defined on, again AFAIK.
>
> It's technically possible for you to bundle an implementation provider
> with your primary IdP, as long as that implementation provider doesn't
> also play the role of a secondary provider.
>
> But let's take a step back: what are you trying to accomplish? You're
> getting buried in the details of temporary scaffolding of BrowserID, and
> maybe the problem you're trying to solve is simpler.
>

> -Ben

[Ben Adida]

On 12/27/11 7:21 AM, Christian Weiske wrote:
> I'm trying to find a way to log into my own BrowserId application
> without having contact with browserid.org at all.

Right, it's probably a little too early for that.

Is this because you don't want to contact browserid.org on principle, or
because you want to certify your own users, or.. something else?

-Ben

[Ben Adida]

On 12/27/11 8:05 AM, Peter Williams wrote:
>
> my issue is that there should be several centralized scaffoldings.

I disagree. Multiple points of central trust is what gave us the SSL CA
model, and that's not something we'd like to replicate.

If your use case is that you'd like to certify your own users at your
own domains, that's definitely possible, and it's something we'll be
evangelizing quite a bit these next few weeks.

But we're not likely to alter the protocol to make multiple secondary
authorities much easier, as that leads us down an unproductive path.

-Ben

[Christian Weiske]

Hello Ben,

> > I'm trying to find a way to log into my own BrowserId application
> > without having contact with browserid.org at all.
> Right, it's probably a little too early for that.
>
> Is this because you don't want to contact browserid.org on principle,
> or because you want to certify your own users, or.. something else?

For several reasons. The first is that browserid.org may be down (yes,
this is possible. Don't tell me you're Mozilla and everything will work
forever at 100.0000%). Another reason is that browserid.org may not be
reachable because the atlantic internet cable is broken or my internet
connection is down. I still want to be able to login to my intranet
applications that maybe support webfinger. And yes, the DNS for
my domains is cached locally, the apps are available locally, so e.g.
OpenID still works.

[Christian Weiske]

> intranet applications that maybe support webfinger. And yes, the DNS

s/webfinger/browserid/

[Ben Adida]

On 12/27/11 11:41 PM, Christian Weiske wrote:
> For several reasons. The first is that browserid.org may be down (yes,
> this is possible. Don't tell me you're Mozilla and everything will work
> forever at 100.0000%).

We would never make that kind of claim: no one is at 100% uptime.
However, we're likely going to be up more regularly than your other
points of failure. In the next couple of months, we'll be in two
geographically separate datacenters. We're considering adding
datacenters in Europe, too.

> I still want to be able to login to my intranet [..]
> OpenID still works.

This assumes that your identity provider *and* your applications are all
local, which is a fairly limited use case, even for enterprises today, I
think?

If this is your primary use case, and you suspect that your internet
connection will go down often enough to be problematic (which is the
more likely point of failure) then yes, BrowserID is probably no the
solution for you until we have primary authority support (coming in
January) and browser support (coming in a few months.)

That said, if there are any other services you depend on that are
Internet-based, I do think it's reasonable to depend on browserid.org.

-Ben

[Peter Williams]

I'm not buying the argument. Browserid is not showing class, here. Its showing immaturity in (normal) assurance theory Now, to be fair, I dont know what the futures feature being mentioned will bring. But, we can only test what we have in front of us. And, those are claims. The claims on their face fail to have the right form (let alone be testable). Now, I was a little unfair. I led by saying SSL was crap (and folks responded that they dont want to repeat the SSL fiasco, led by the policy CAs and those who run the associated root stores (i.e. mozilla)). Then, we learn that the protocol underlying browserid leverage and RELIES UPON SSL (that crap..) for endpoint authentication of the cert files, trying domains to keys One cannot have it all ways. The security auditors will make a meal of this (and the million dollar bill will soon be 2 million). The first test is coherent claim making and no obvious inconsistencies in the claims of assurance meeting accounting standards for the "Public". > Date: Wed, 28 Dec 2011 06:54:10 -0800

> From: b...@adida.net
> To: dev-id...@lists.mozilla.org
> Subject: Re: Self-hosted BrowserId / browser integration
>

> On 12/27/11 11:41 PM, Christian Weiske wrote:

> > For several reasons. The first is that browserid.org may be down (yes,
> > this is possible. Don't tell me you're Mozilla and everything will work
> > forever at 100.0000%).
>

> We would never make that kind of claim: no one is at 100% uptime.
> However, we're likely going to be up more regularly than your other
> points of failure. In the next couple of months, we'll be in two
> geographically separate datacenters. We're considering adding
> datacenters in Europe, too.
>
> > I still want to be able to login to my intranet [..]
> > OpenID still works.
>
> This assumes that your identity provider *and* your applications are all
> local, which is a fairly limited use case, even for enterprises today, I
> think?
>
> If this is your primary use case, and you suspect that your internet
> connection will go down often enough to be problematic (which is the
> more likely point of failure) then yes, BrowserID is probably no the
> solution for you until we have primary authority support (coming in
> January) and browser support (coming in a few months.)
>
> That said, if there are any other services you depend on that are
> Internet-based, I do think it's reasonable to depend on browserid.org.
>
> -Ben

[Gervase Markham]

On 27/12/11 08:56, Burak Yiğit Kaya wrote:
> This will change soon. The reason you should inclode it from browserid.org *for
> now* is because the specs and thus the file is under heavy change in the
> mean time. Also, when te browsers support this natively, you won't have to
> include it.

Every browser of every visitor would need to support it natively for you
not to need the file, so this part is not going to change soon.

You may, however, be able to take a local copy of browserid.js in, say,
6 months time (according to Ben Adida).

Gerv