Re: P2P Payments

On 5 December 2014 at 18:35, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

>  On 2014-12-05 18:22, Melvin Carvalho wrote:
>
>
>
> On 5 December 2014 at 18:16, Anders Rundgren <
> anders.rundgren.net@gmail.com> wrote:
>
>> On 2014-12-05 17:38, Manu Sporny wrote:
>> <snip>
>>
>>>
>>> What Anders is pushing for is a device (like FIDO's U2F devices only w/o
>>> the Same Origin Policy (SOP)) that you can use on any website to
>>> digitally sign something (after typing in a PIN on the device to
>>> complete the signature).
>>>
>>
>>  This is what Microsoft suggests:
>>
>> https://www.w3.org/2012/webcrypto/wiki/images/d/dd/CertAndKey_Management_Requirements_for_WebCrypto_microsoft.pdf
>>
>> Although the details are still very sketchy I don't see this as a viable
>> solution,
>> it looks like an orgy in security-GUIs, something which has a proven
>> track-record to go wrong.
>>
>>
>>  Typically, Secure Elements have been used for
>>> this sort of activity. WebCrypto has no support for this right now,
>>> although they're trying to figure out a way to make this happen at W3C.
>>> Virginie Galindo, the chair of the WebCrypto group and Gemalto employee
>>> (they make/sell Secure Elements), just presented to the Web
>>> Payments IG User Payment Agent Task Force about this an hour ago.
>>>
>>
>>  Haven't the payment-card industry already had like 15 years figuring
>> out how this should work?
>>
>> So what "Anders is pushing for" is something which *does not* directly
>> expose keys (or other sensitive stuff) to "alien" sites:
>>
>> http://lists.w3.org/Archives/Public/public-sysapps/2014Nov/0006.html
>>
>> Is this feasible?  I don't know for sure, I just thought that if an
>> application
>> installed locally is trusted to do certain things the same application
>> (or a subset of it) ought to be [automatically] trusted even if supplied
>> as a
>> part of an untrusted piece of code provided that the platform can:
>>
>> 1) verify that the trusted code is authentic
>>
>> 2) protect the trusted code from intrusion by the untrusted code
>>
>> That is, the model for interaction is crucial thing.
>>
>
>  Seems modern browser vendors are the enemy of decentralization.
>
>
> There's not a (for them) compelling use-case.  If you to that add a rather
> confused and divided user-community it is not surprising if things move in
> slow-motion.
>
>
>
> But I still there are a lot of good folks working for browser vendors that
> can be won over to the decentralization concept, if we make compelling
> arguments.  I'd expect Mozilla to perhaps be the ones to lead the way here.
>
>
> It would be nice but Mozilla is rather resource-constrained so I think
> that either things go mainstream or depend on external "guerrilla"-like
> projects.
>
>
>
>  Is the same origin policy at least a switch that you can turn off, or is
> it completely locked down?  Could we make a plugin to add this feature?
>
>
> Nope, NSAPI plugins (which can do "anything") are outlawed and there are
> no switches to turn.
>

Wow!  It used to be just a simple switch or command line option to allow
Cross Origin Policy.

So the only option is to fork the browser?


>
> Anders
>
>
>
>>
>> Anders
>>
>>
>>
>>
>>> -- manu
>>>
>>>
>>
>>
>
>