Git Product home page Git Product logo

Comments (2)

adrianhopebailie avatar adrianhopebailie commented on July 30, 2024

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.

from src.

ianbjacobs avatar ianbjacobs commented on July 30, 2024

@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.

from src.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.