Re: First draft of Browser Payments 1.0 spec published

On May 12, 2013, at 9:37 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:

> 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).

Yes, it should be easy to make identity optional. I think this is the best approach for flexibility.

> 
> 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.

Since identity currently isn't specified there shouldn't be anything to merge :) As long as a specified identity isn't required to make anything in nav.payment() work then it should remain compatible with Mozilla's current implementation which uses Persona under the hood.

The backend Payment Provider logic (which is where identity first comes into play) can currently be swapped in and out with the JWT typ field: http://web-payments.github.io/browser-payments/#initiating-a-payment E.G. typ=mozilla/payments/pay/v1. For flexibility, I think multiple types might have to co-exist. It's not ideal but this will allow for a quick evolution of the payment API. WebRTC is similar in that multiple, in-compatible data channels can co-exist -- again, not ideal, but very flexible.

Kumar

> 
> -- 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 15:48:51 UTC