Re: First draft of Browser Payments 1.0 spec published

On 05/09/2013 05:37 PM, Kumar McMillan wrote:
>> The current design of Persona allows the centralized identity 
>> service that they currently run to impersonate anyone on any site 
>> that uses a Persona login. The underlying assumption with Persona 
>> today is that the web trusts Mozilla when it comes to identity.
>> 
>> Even when Persona becomes more decentralized, the underlying
>> system will still require you to trust your identity/email provider
>> to make claims about the validity of your e-mail address.
> 
> This is not entirely accurate. Persona (when bootstrapped by
> Mozilla) requires you to trust the user's email provider, yes, but
> you have to do this anyway. Let's say you let a user sign up through
> your site and Persona is not involved. You must still trust their
> email provider to deliver the link that they click on for
> verification. Persona does not introduce anything less secure than
> this.

With the current approach, with Persona bootstrapped by Mozilla, that
system can make any claim it wants to and the RP has no choice but to
trust Mozilla. I make no value judgement about that, but unless I'm
missing something (which could be the case), it is less secure because
Mozilla-bootstrapped Persona does not have to have any sort of
interaction with the e-mail provider in order to make a claim about who
owns an e-mail address.

That said, I don't think this is a reasonable attack vector unless
someone is capable of taking over the Mozilla-backed Persona systems and
given how transparently Mozilla operates, any such attack would be
publicized and dealt with pretty quickly.

In this particular case, Mozilla-backed-Persona is the attacker, but as
I elaborated, this is always the case when you have a 3rd party IdP.

> When fully decentralized, what Persona adds is you can verify the 
> signature of someone's identity against a well known public key
> (that of the email provider); this is slightly better than simply
> trusting that the user will click on a link because they have an
> inbox password :)

Yes, it's slightly better. What Melvin and I were saying is that it
would be even better if the IdP didn't have the ability to just sign
anything on your behalf, but rather only contain the public keys that
are allowed to sign things (which is what Web Keys does).

That said, even that approach has a downside, which is key management
and potential key spoofing (adding public keys that you don't have
access to) if the IdP is compromised.

> Some big email providers (like Yahoo) are already implementing 
> Persona and more are on the way. When you get an identity assertion 
> and you verify it on your backend, you could do it yourself by 
> fetching the public keys of the issuer and checking the signature. 
> Mozilla *hosts* a verification service for convenience and to ease 
> uptake but it's not mandatory. Thus, you are not required to talk to 
> a Mozilla server at all to use Persona.

Yes, but that doesn't address the attack vector I was talking about.

The problem is that w/ Persona, the issuer (IdP) becomes the authority
for data you want to assert. So, the IdP can assert anything they want
to about you.

With Web Keys, you (or agent acting on your behalf) becomes the
authority for the data you want to assert. The IdP can still assert
anything they want to about you, by adding a public key to your identity
profile, but there are mitigations to this attack.

Although, don't get me wrong, I'm not saying that Persona is a bad
thing. There have been several design decisions that were made to ensure
rapid adoption. As long as we have the capability in Persona to do
customer-based digital signatures on data, we're good. This is a
requirement for some of the more financial security related goals of the
Web Payments work.

> Anyway, identity is left out of the initial navigator.mozPay() spec 
> because we think it will be hard to convince other parties to use a 
> single identity provider (Google Checkout will probably want to use 
> Google Accounts, for example). We made mozPay() identity agnostic
> and hopefully it can stay that way and still have a lot of
> functionality.

Or we can make stronger identity an optional feature. There's a pretty
simple way to accomplish this with the mozPay() API (at least, it seemed
like it was fairly easy to accomplish when I was converting the spec
over to W3C format).

Since the payment API just off-loads the buyflow to a 3rd party site,
the 3rd party site can deal with identity. That is, for those that don't
care about identity and just care about paying with a credit card, the
payment API can support that. For those that want identity, and thus
ownership, the payment API can support that as well. Since identity is
up to the 3rd party site, we don't need to bake it into the payment API,
IIUC.

> Prescribing a single identity solution in a future version would 
> however make several things easier, like customer product ownership.

Agreed, which is why PaySwarm has settled on the Web Keys identity
solution. If we can figure out a way to merge the Web Keys and Persona
stuff, we're in good shape as far as providing a solid identity solution
for payments. Merging the work, however, is going to take a considerable
amount of coordination work.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

Received on Monday, 13 May 2013 02:37:52 UTC