Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: Bootstrapping decentralized discovery with WebFist

28 views
Skip to first unread message

Melvin Carvalho

unread,
Jun 26, 2013, 9:32:34 AM6/26/13
to ☮ elf Pavlik ☮, dev-identity
On 26 June 2013 15:29, ☮ elf Pavlik ☮ <perpetua...@wwelves.org> wrote:

> from post linked in original message:
>
> "We commonly identify each other online with email addresses (e.g.,
> myn...@example.com) not web URLs. But email addresses have a fundamental
> problem: The only useful thing you can do with an email address is send it
> email. With just an email address you can't answer simple questions like,
> "What is the profile photo of the person with this email address?""
> ...
> "Our solution to the adoption problem is WebFist. WebFist is a fallback
> when providers don't support WebFinger natively. It lets you do WebFinger
> lookups for Gmail, Facebook, and other email addresses even if the owner of
> the domain name isn't playing along. WebFist works because of a judo move
> on an existing infrastructure: DomainKeys Identified Mail (DKIM)."
>

Sounds like the way forward ...


>
> --- Begin forwarded message from Brett Slatkin ---
> From: Brett Slatkin <bsla...@gmail.com>
> To: webfinger <webf...@googlegroups.com>
> Date: Tue, 25 Jun 2013 17:36:30 +0000
> Subject: Bootstrapping decentralized discovery with WebFist
>
> Hey all,
>
> Here are the details on bootstrapping WebFinger with WebFist:
>
>
> http://www.onebigfluke.com/2013/06/bootstrapping-webfinger-with-webfist.html
>
> Let us know what you think. Thanks,
>
> -Brett
>
> --- End forwarded message ---
>
> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
>
>

Ben Adida

unread,
Jun 26, 2013, 9:41:53 AM6/26/13
to ☮ elf Pavlik ☮, dev-identity
This is a pretty neat hack, and it's a cool way to try to get around the
single fallback, but ... how do mere mortals use this? Sending a properly
formatted email containing a URL seems like something that requires at
least some kind of client software or app connected to your gmail that's
allowed to send on your behalf. Maybe the latter (gmail app) can be done,
but I'm not sure I see a reasonable user flow here.

Worth keeping an eye on, but I think much work remains before this
addresses a real use case. If it does, then this could be an interesting
way for the fallback IdP to allow a user to delegate to an IdP even if they
don't control their own domain.

To nitpick a bit... this reduces identity of a user to the ability to
*send* email from an account once, rather than receive email there. That
seems potentially problematic, since that is a very different threat model
than most systems currently assume.

-Ben


On Wed, Jun 26, 2013 at 6:29 AM, ☮ elf Pavlik ☮ <
perpetua...@wwelves.org> wrote:

> from post linked in original message:
>
> "We commonly identify each other online with email addresses (e.g.,
> myn...@example.com) not web URLs. But email addresses have a fundamental
> problem: The only useful thing you can do with an email address is send it
> email. With just an email address you can't answer simple questions like,
> "What is the profile photo of the person with this email address?""
> ...
> "Our solution to the adoption problem is WebFist. WebFist is a fallback
> when providers don't support WebFinger natively. It lets you do WebFinger
> lookups for Gmail, Facebook, and other email addresses even if the owner of
> the domain name isn't playing along. WebFist works because of a judo move
> on an existing infrastructure: DomainKeys Identified Mail (DKIM)."
>

Jan Wrobel

unread,
Jun 26, 2013, 2:40:52 PM6/26/13
to Ben Adida, dev-identity, ☮ elf Pavlik ☮
On Wed, Jun 26, 2013 at 3:41 PM, Ben Adida <b...@adida.net> wrote:
> This is a pretty neat hack, and it's a cool way to try to get around the
> single fallback, but ... how do mere mortals use this? Sending a properly
> formatted email containing a URL seems like something that requires at
> least some kind of client software or app connected to your gmail that's
> allowed to send on your behalf. Maybe the latter (gmail app) can be done,
> but I'm not sure I see a reasonable user flow here.

Maybe an external system with a polished web interface could format an
email and send it to a user specified email address, with 'Reply-to'
set to ver...@webfist.org. Then, the gmail user would only need to
click 'reply' and 'send'.

Unfortunately such approach could potentially also be used to hijack an id.

Cheers,
Jan

Ben Adida

unread,
Jun 26, 2013, 2:48:32 PM6/26/13
to Jan Wrobel, dev-identity, ☮ elf Pavlik ☮
On Wed, Jun 26, 2013 at 11:40 AM, Jan Wrobel <w...@mixedbit.org> wrote:

>
> Unfortunately such approach could potentially also be used to hijack an id.
>

Right, this is the kind of thing that worries me: using the ability to
*send* as a given email address has never been broadly used as a mechanism
for broader authentication. So this feels very risky, architecturally
speaking.

But again, I don't want to poo-poo this too much. It's a neat hack, and I'd
love to see where it goes with the above caveat in mind.

-Ben

Melvin Carvalho

unread,
Jun 26, 2013, 3:08:14 PM6/26/13
to Ben Adida, Jan Wrobel, ☮ elf Pavlik ☮, dev-identity
Doesnt github use email to send messages?

Most mailing lists I know make you confirm your address by sending a mail

I suspect there may be more examples...


-Ben

Melvin Carvalho

unread,
Jun 26, 2013, 3:22:34 PM6/26/13
to Ben Adida, Jan Wrobel, ☮ elf Pavlik ☮, dev-identity
On 26 June 2013 20:48, Ben Adida <b...@adida.net> wrote:

> On Wed, Jun 26, 2013 at 11:40 AM, Jan Wrobel <w...@mixedbit.org> wrote:
>
> >
> > Unfortunately such approach could potentially also be used to hijack an
> id.
> >
>
> Right, this is the kind of thing that worries me: using the ability to
> *send* as a given email address has never been broadly used as a mechanism
> for broader authentication. So this feels very risky, architecturally
> speaking.
>
> But again, I don't want to poo-poo this too much. It's a neat hack, and I'd
> love to see where it goes with the above caveat in mind.
>

You can also update facebook via sending an email:

http://howto.cnet.com/8301-11310_39-20103506-285/update-facebook-status-via-e-mail/

Ben Adida

unread,
Jun 26, 2013, 4:27:08 PM6/26/13
to Melvin Carvalho, Jan Wrobel, ☮ elf Pavlik ☮, dev-identity
On Wed, Jun 26, 2013 at 12:08 PM, Melvin Carvalho
<melvinc...@gmail.com>wrote:

>
> Doesnt github use email to send messages?
>

True, you can use emails to participate in certain fora, but those fora get
to decide if that's what they want, and the impact is usually quite
minimal. It's *adding* data to an existing stream, not reading your data.


> Most mailing lists I know make you confirm your address by sending a mail
>

Not by sending, but by *responding*, including a secret code which you had
to receive.

That's the key difference: authentication bootstrapped on ability to
receive/read email at an address is commonplace. Bootstrapped on ability to
send is not at all commonplace, and that's what has me concerned.

-Ben

Melvin Carvalho

unread,
Jun 27, 2013, 9:26:36 AM6/27/13
to Ben Adida, Jan Wrobel, ☮ elf Pavlik ☮, dev-identity
I see your point, you are right. Having said that, some facebook statuses
are enough to end a marriage! :)

As you become more decentralized the attack surface inevitably goes up.

I'm thinking along the lines of zooko's triangle ... we could have synonyms
something like

Secure -> Secure
Global -> Decentralized
Memorable -> Convenient

Webfist is highly decentralized, it is moving into the area of mirrored
claims, so while persona, for example, is heavily reliant on federated
servers, webfist is moving into the real of mirrored claims that are signed
for data portability. The advantage here is that you dont have one central
point of trust, which becomes a central point of failure. You can
distribute trust over many nodes.

This is robust, but it comes at a cost. Namely the attack surface
increases, notably from spamming.

So what's the long term solution? You essentially create an arms race
between attack and defence. One way to do this is to have a trust and
global reputation system, perhaps including something like openbadges, but
at web scale. But what often happens is white listing, which
disproportionately favours the big players, at the expense of the long
tail. Better approaches may be along the lines of proof of work (one cpu
one vote) or consensus models.

What we really need is a global meta system that pulls all these identity
system together in a reusable way, so your trust and reputation become
global and transferable. This way you can mitigate many of the common
attack surfaces, while increasing the number of use cases you can handle.

Just my 2 cents ...


>
> -Ben
>

Ben Adida

unread,
Jun 27, 2013, 10:13:28 AM6/27/13
to Melvin Carvalho, Jan Wrobel, ☮ elf Pavlik ☮, dev-identity
Hi Melvin,

I agree that WebFist provides a more decentralized alternative where
Persona uses a fallback IdP. However, it's not quite as clear cut as you
make it out to be: with WebFist, you're still relying on your email
provider to DKIM-sign those delegations, and they can sign a fake one on
your behalf if they go evil. In other words, you're still trusting your
email provider (and you're doing so in a weird way, outgoing email vs.
incoming).

The moment you control your own email domain, the trust model difference
between WebFist and Persona goes away completely. Short of that, my sense
is that the fallback approach is far more usable for most users.

One interesting question is whether advanced users might be able to use a
WebFist like approach in Persona if they want to use an existing email
address whose server they don't control, but want to delegate to a Persona
IdP they *do* control. Is there something useful here? A user advanced
enough to use WebFist, but who doesn't own their own domain? I'm not sure,
but worth keeping an eye on.

-Ben



On Thu, Jun 27, 2013 at 6:26 AM, Melvin Carvalho
<melvinc...@gmail.com>wrote:

Melvin Carvalho

unread,
Jun 27, 2013, 10:27:48 AM6/27/13
to Ben Adida, Jan Wrobel, ☮ elf Pavlik ☮, dev-identity
On 27 June 2013 16:13, Ben Adida <b...@adida.net> wrote:

> Hi Melvin,
>
> I agree that WebFist provides a more decentralized alternative where
> Persona uses a fallback IdP. However, it's not quite as clear cut as you
> make it out to be: with WebFist, you're still relying on your email
> provider to DKIM-sign those delegations, and they can sign a fake one on
> your behalf if they go evil. In other words, you're still trusting your
> email provider (and you're doing so in a weird way, outgoing email vs.
> incoming).
>
> The moment you control your own email domain, the trust model difference
> between WebFist and Persona goes away completely. Short of that, my sense
> is that the fallback approach is far more usable for most users.
>

Yes, agree on everything. But bear in mind that the DKIM solution was just
something put together over a weekend, during a hackathon. Running your
own email domain is really hard currently, delegating your own address to
an existing provider is possible, though.


>
> One interesting question is whether advanced users might be able to use a
> WebFist like approach in Persona if they want to use an existing email
> address whose server they don't control, but want to delegate to a Persona
> IdP they *do* control. Is there something useful here? A user advanced
> enough to use WebFist, but who doesn't own their own domain? I'm not sure,
> but worth keeping an eye on.
>

I use gmail as my provider. Right now it would be very hard for me to
swtich because I rely on email. But if I'm able to add data points to my
email in a decentralized way, that's a pretty attractive feature. There's
no way right now, except to lobby gmail to give you CRUD access, which
might not happen at all. So webfist definitely provides an interesting
possibility for advanced users either in the webfinger or persona paradigm,
imho. As you say, worth keeping an eye on ...
0 new messages