[wiki] Provide clarity on security requirements

[adrianhopebailie]

From Security:

"We seek to reduce the likelihood of "bad actors" claiming to be SRC payment handlers."

Can you provide some more detail on this?

This assumes there is an entity(ies) that defines good and bad actors and another (possibly the same) that enforces that bad actors are excluded from the ecosystem.

The existing PH API architecture already supports the concept of whitelisting handlers at the discretion of the payment system operator. This is then enforced by the browser who gets the whitelist from the manifest.

Is there a suggestion that this system is not sufficient for SRC and if so why?

[adrianhopebailie]

Later in the wiki the following provides some detail:

At the current time, there seems to be a preference for relying more on the blacklist for several reasons:

• There is not yet definitive information on DCF certification processes

The fact that the SRC ecosystem is not yet well-defined is not an obstacle, it is an opportunity. The Web community has chosen to leverage its origin security model and manifests for whitelisting handlers at the discretion of the system operator.

The DCF certification process should take this on board in its own design.

It seems strange for an undesigned system to be dictating the design when we already have a working design that is the result of many years of iteration.

• For a single SRC payment method, it is not clear which entity would manage and host the single payment method manifest.

This is because SRC should not be using a single payment method identifier. It can use a common data model with multiple identifiers to allow each SRC system to manage their whitelist independently.

This looks like we're using one bad design decision (using a single SRC payment method identifier) to drive another.

• There might be a significant cost to maintaining a dedicated payment method manifest over a long period of time.

That is the cost of doing business. If you want to run a payment system and control the actors that participate then you need to invest the resources required to do this.

• Even if there were a payment method manifest, it would not likely specify default payment handlers, so it would not help address (through just-in-time registration) the user experience goal.

This is orthogonal to the security requirement and not entirely correct.

The manifest is generated in response to a Web request from the browser. It can specify a different default for each request based upon a variety of variables (browser, geo-location, language etc).

In other words, the payment system operator can have a as many default handlers as they wish and specify a different one for each user based upon what ever criteria they choose.

[ianbjacobs]

@adrianhopebailie,

I don't think the "preference for one PMI" is driving the desire for blacklist rather than whitelist. I will ask at the next task force call for more information about the preference, which we can add to the wiki.