Question about email->domain resolution

[Jesus Cea]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

My email is jc...@jcea.es. BrowserID would look for a webserver at
"jcea.es".

But:

a) My webserver is running in "www.jcea.es", not "jcea.es".

b) I would like to manage BrowserID from a separate domain, like
"BrowserID.jcea.es", for instance.

Does BrowserID manage HTTP redirections gracefully?. Is it a
standard/accepted practice?. What about using DNS to deliver this
information? (via a SRV register, for instance).

I know that DNS is not secure now (until complete DNSSEC deployment)...

What could I do?.

- --
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jc...@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
jabber / xmpp:jc...@jabber.org _/_/ _/_/ _/_/_/_/_/
. _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBT7ulgZlgi5GaxT1NAQKM9wQAn6ubr2LmQWMdl1Mx6bqr9ir1VRqTPMcg
ZFp6CzDLnfFedsHHmqmVJ2CkicFLWrW1qyJe9hFK0N5x8vu+7ibhhhCMGLubOIYl
ig3TUeTtaSbIYyOQ/eJVLTcckG8T7LCyzXY4RuhNFWr1Rlu6ItDylfLheV9LaV7o
3WrOsGNIfPE=
=zlwQ
-----END PGP SIGNATURE-----

[Mike Hanson]

Hi, Jesus -

Take a look at section 3.2, "Delegation of Authority," in the protocol docs at:
https://github.com/mozilla/browserid/blob/dev/docs/PRIMARY_PROTOCOL.md

The relevant paragraph is:
> In the event that a domain wishes to have primary support for email addresses underneath it, but wishes for that support to be implemented by a domain other than its own, it may explicity delegate authentication and provisioning to another host. Delegation occurs when an authority property is present in the declaration of support which contains a domain name (in which case, all other properties present are ignored).
>


And there is a discussion of how discovery, HTTP caching and HTTP redirection interact with the system there as well.

If you check the archives of the list, there have been a couple DNS/DNSSEC/SRV discussions, but the current focus is on gracefully handling HTTP-based discovery.

-mh

[Jeff Schnitzer]

This doesn't really answer the OP's question: Will the system follow
HTTP redirects?

Some cloud hosting providers, including Google App Engine, cannot
serve content at naked domains. This is because GAE uses a CNAME to
distribute requests to geographically relevant IP addresses (ie
www.example.com -> ghs.google.com) but the DNS spec disallows any
other records with the same name as a CNAME. You aren't allowed to
create a CNAME for example.com because there are also NS, MX, TXT, etc
records.

So that naked domains are not broken, Google provides a service
whereby if you create A records for the example.com, it will redirect
to www.example.com (or another subdomain of your choice).

The upshot of all this is that a fetch to
https://example.com/.well-known/browserid will redirect to
https://www.example.com/.well-known/browserid, but you can't directly
serve a json blob from the naked domain.

Why shouldn't the redirect work? Indeed, why does the "authority"
delegation mechanism exist at all when HTTP provides a built-in
delegation mechanism in the form of redirects? HTTP libraries already
handle redirects and loop detection; why complicate application code
by duplicating the same logic?

Jeff

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

[Ben Adida]

On 5/22/12 9:25 AM, Jeff Schnitzer wrote:
> This doesn't really answer the OP's question: Will the system follow
> HTTP redirects?

Currently we do not. Anything other than a 200 application/json response
to the request for the well-known file is treated as a non-IdP.

> Why shouldn't the redirect work? Indeed, why does the "authority"
> delegation mechanism exist at all when HTTP provides a built-in
> delegation mechanism in the form of redirects? HTTP libraries already
> handle redirects and loop detection; why complicate application code
> by duplicating the same logic?

Great question and a worthwhile discussion to have.

There's a couple of reasons why explicit authority delegation seems like
a good idea. The main one is that we didn't want authority delegation to
be something that could happen by mistake. Lots of folks redirect entire
domains, precisely as you describe. Does an HTTP redirection
automatically imply a delegation of authority over user authentication?
I don't think so.

Now, the use case you bring up is an interesting one. There are a few
ways we could address this. Francois is going to be thinking about our
discovery story in the next few weeks.

One possibility: a DNS fallback (e.g. an SRV record) for declaring your
Persona parameters. Would that solve the problem?

-Ben

[Francois Marier]

On 23/05/12 05:25, Ben Adida wrote:
> One possibility: a DNS fallback (e.g. an SRV record) for declaring your
> Persona parameters. Would that solve the problem?

We have a bug open to explore DNS discovery:

https://github.com/mozilla/browserid/issues/1523

though the work on this hasn't started yet.

Cheers,
Francois