Re: P2P Payments

On 2014-12-05 18:22, Melvin Carvalho wrote:
>
>
> On 5 December 2014 at 18:16, Anders Rundgren <anders.rundgren.net@gmail.com <mailto: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.

Anders

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