Re: Trusted UI/SE/TEE. Was: Minutes for Web Payments Workshop - Session 2

On 2014-04-01 22:29, Manu Sporny wrote:

Hi Manu, comments in line.

Before going into the specifics it is important to know that this paper
only describes an extension to W3C's WebCrypto which is a low-level API,
chemically free from any protocols or application-oriented data.

The primary "inspiration" has been various W3C forum discussions on how
the web and smart cards could be combined which since their beginnings
in 2011 haven't produced anything that (IMO) possibly could get industry support.

Another input are the gazillion 3D Secure-like payment systems used in
Europe where you 1) Are redirected to the bank, 2) Authenticate with
a bank credential 3) Return with something at the merchant's site.
These systems should be able to use this technology for a better and
securer ("phish-safe") payment experience, while keeping the branding.


> On 03/31/2014 04:19 AM, Anders Rundgren wrote:
>> Since trusted payment UIs were mentioned by several of the speakers, 
>> it may be worth repeating that although not acknowledged by the W3C, 
>> there is actually a fairly complete trusted web UI proposal designed 
>> with payments in mind:
>>
>> http://webpki.org/papers/PKI/pki-webcrypto.pdf#page=2
> 
> Hey Anders, I read through your proposal. We've seen a few like it
> before and I do think a number of the core concepts are valid. For
> example, assigning a virtual domain (or just a domain per key type /
> use) and then using postMessage() to do digital signatures into other
> sites makes sense. You need to define a protocol for doing that, which
> is sort of what the Identity Credentials spec does (as does the key
> registration in the Secure Messaging spec).
> 
> I'm not saying those are the same thing as what you're doing in the spec
> you refer to above, but they're in the same area and it would be good to
> just come up with a fairly standard protocol for doing that on the Web
> (registering a resource w/ a site, and then instructing the site to do
> something w/ that resource).
> 
> For example, register a public key with a site (A) and then use the
> private key associated w/ the public key to digitally sign a piece of
> information on another site (B) and then deliver that signed information
> to another site (C).

How sites trust users or each other is a different issue which is out
of scope for this proposal as well as WebCrypto.  This is supposed to
be "nuts and bolts" web tech, leaving actual protocols and procedures
for others to cater for like the WebPayments CG.

The only thing that *really* matters at this stage is if the core is suitable
for possible applications and if the claims regarding the core are true.

OTHER PAYMENT-RELATED WEB-CRYPTO EXTENSIONS IN THE WORKINGS
The W3C folks claim the WebCrypto WG will in a workshop in September, unveil
the [final?] "solution" to how WebCrypto will be supporting smart cards
(presumably including the required trusted UIs...), suitable for payments!


> There is a bit too much hand-waving when it comes to "signed Javascript"
> in the paper. How do you expect to deliver signed Javascript to the
> browser? What validates the signature and how do you know that piece of
> software hasn't been compromised? (We have answers to these questions,
> btw, but I just wanted to get your opinion first).

The K2C (Key to Code) trust scheme makes the system trust- and security-wise
independent on how the signed code is delivered.  Signature validation is
exclusively performed by the UA/platform.

For a payment systems, I imagine that merchants would download signed
payment web apps from the associated payment provider once and just add it
to their merchant code.  They probably have to do other things as well
in order to become a payee but that's as already said out of scope.

Cheers
Anders

> 
> -- manu
>

Received on Wednesday, 2 April 2014 07:30:10 UTC