Re: First draft of Browser Payments 1.0 spec published

On 10 May 2013 00:05, Kumar McMillan <kmcmillan@mozilla.com> wrote:

>
> On May 9, 2013, at 4:55 PM, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>
>
>
> On 9 May 2013 23:37, Kumar McMillan <kmcmillan@mozilla.com> wrote:
>
>>
>> On May 9, 2013, at 3:17 PM, Manu Sporny <msporny@digitalbazaar.com>
>> wrote:
>>
>> > On 05/07/2013 02:05 PM, Melvin Carvalho wrote:
>> >> https://github.com/web-payments/browser-payments/
>> >>
>> >> I think perhaps there needs to be some thought about security.
>> >> Maybe even a security considerations section.
>> >
>> > Good point, I added an issue to track this:
>> >
>> > https://github.com/web-payments/browser-payments/issues/9
>> >
>> >> One thing that springs to mind is.  If I have an email, but do not
>> >> implement /.well-known/browserid would it be possible for mozilla to
>> >> impersonate me and send a payment?
>> >
>> > 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.
>>
>
> I get this point.  And this may be true in many web services, such as
> twitter, but it's relatively rare that having access to someone's email
> account will give them access to their bank account.
>
> For example my landlord has the keys to my mailbox.  So in theory could
> gain access to may bank account.  I think it's a a simiar argument to say,
> because I'm already trusting my landlord, he should be given access to my
> bank account.  I think most people would wish to separate concerns to an
> extent.
>
>
>>
>> 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 :)
>>
>
> A fully decentralized Persona is quite an assumption.  There's only
> degrees of the centralized/decentralized balance.  It's probably 99%
> centralized today.  It's unclear that it will ever reach a 50%
> decentralized / centralized ratio (and would be quite a feat!) ... 100%
> seems hard to imagine at this point.
>
>
>>
>> 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.
>>
>
> That's great news!  There are many things about Persona that I like, but
> it may need a bit more work before id be happy to use it for large payments.
>
>
> There's a feature of Persona that is not documented yet (it's still
> experimental) where you can "force" identity assertion to be done by a
> single party. This is designed for banks where the bank will want to know
> that its three factor auth + image challenge, etc, has been applied. There
> are definitely scenarios like this where a decentralized approach to
> identity is not secure enough and the Persona protocol will try to support
> that.
>

Excellent!  This is the kind of innovation that I was hoping for...


>
>
>
>>
>> _
>>
>> 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. Prescribing a
>> single identity solution in a future version would however make several
>> things easier, like customer product ownership.
>>
>> -Kumar
>>
>> >
>> > Ultimately, if you are going to have identity on the web, you have to
>> > trust the server running the software. :)
>> >
>> > -- 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/
>> >
>>
>>
>>
>
>