search

w3c / payment-request

Payment Request API
https://www.w3.org/TR/payment-request/
Other
489 stars 135 forks source link

Identifiers or Locators #150

Closed dret closed 8 years ago

dret commented 8 years ago

the current options seem to also consider options where dereferencing identifiers becomes part of the standardized way of using them. whatever is chosen in the end, the spec should be very clear about whether the identifiers are actually identifiers (communicating meaning through their usage), or locators (communicating a way how to extract meaning at runtime). in particular, in a high-volume scenario such as payments the implications of implementations dereferencing payment identifiers should be considered. it is essential that identifiers have a clear model of either having an assigned and stable meaning, or being opaque addresses that must be dereferenced to obtain the meaning represented by them: https://tools.ietf.org/html/draft-wilde-registries-01#section-3.5

adrianhopebailie commented 8 years ago

+1 for identifiers

I see no value in dereferencing these identifiers to anything other than a human readable specification therefor I'd consider their value to be primarily as identifiers.

The implementers of the payment method logic (payment apps and websites) are not going to be able to dynamically support new payment methods by merely fetching a machine readable payment method specification.

IF this was supported by some subset of payment methods I'd expect the developers of those specifications to define additional steps that must be taken after fetching the resource at the payment method identifier URL to interpret this resource and use that logic to actually process a payment request.

ianbjacobs commented 8 years ago

@dret,

My personal view is that:

@adrianba and perhaps others have cited the risk of high-volume (and likely unnecessary) dereferencing.

I have also started to write up some payment method identifier design notes: https://github.com/w3c/webpayments/wiki/PMI_Notes

Ian

dlongley commented 8 years ago

@adrianhopebailie,

The implementers of the payment method logic (payment apps and websites) are not going to be able to dynamically support new payment methods by merely fetching a machine readable payment method specification.

That isn't the only thing you can do with machine readable data. What if you just want to get descriptions or icons? What if there are terms of use or rules that indicate you must display brand image X (found at a URL specified in the machine readable data) when offering a payment method?

A common machine-readable vocabulary could be used and consumed by smart Payment Apps or mediators for these sorts of things.

IF this was supported by some subset of payment methods I'd expect the developers of those specifications to define additional steps that must be taken after fetching the resource at the payment method identifier URL to interpret this resource and use that logic to actually process a payment request.

Suboptimal, but perhaps ok.

adrianhopebailie commented 8 years ago

What if there are terms of use or rules that indicate you must display brand image X (found at a URL specified in the machine readable data) when offering a payment method?

A common machine-readable vocabulary could be used and consumed by smart Payment Apps or mediators for these sorts of things.

(I think) I agree with @ianbjacobs that having a convention for what is found when dereferencing a payment method identifier would be great (and content-type negotiation can be used to return a human readable payment method spec vs machine readable something) but shouldn't be mandatory.

dlongley commented 8 years ago

@adrianhopebailie,

I agree that it shouldn't be mandatory.

halindrome commented 8 years ago

I also agree it should not be mandatory. However, can we also agree that there is a way to craft the optional language to assist in ensuring that even optional things are predictable? For example:

A payment method MAY provide a machine readable definition. When it does so, it MUST be done using one of the following formats [some list]. When using one of those formats, the following terms MAY be used [term list]

I am not saying we need to even develop this today. Just that having this mechanism and a well defined set of terms (with associated data types) means payment method owners are able to inform payment applications of the sorts of things discussed earlier in this thread with a minimum of hassle. Interoperability and Portability are the most important tools we can provide to a payment app developer.

dret commented 8 years ago

On 2016-04-21 13:47, Adrian Hope-Bailie wrote:

+1 for identifiers I see no value in dereferencing these identifiers to anything other than a human readable specification therefor I'd consider their value to be primarily as identifiers.

if identifiers are going to be HTTP URIs, then of course nothing stops their creators to put up documentation at that address. but i would still recommend the registry to associate documentation links for each registered identifier, which can be used by registry users to access documentation that has been vetted during registration, and has to remain stable over time.

dret commented 8 years ago

On 2016-04-21 14:27, ianbjacobs wrote:

@dret https://github.com/dret, My personal view is that:

  • the primary computation on these identifiers will be equivalence testing.

very good. that's what identifiers are for.

  • it is useful to ALSO be able to dereference them. I have tried to make the case for using URIs and dereferencing them to get the relevant payment method specification. I have not converted many people.

one of my hobbies is to preach about the difference between identifiers and locators. conflating these concepts sometimes can be a bad idea. my view is that in this case, what you want is an identifier, and nothing more. if the spec uses URIs are the identifier namespace, then nothing keeps people from using HTTP URIs, but personally, if i minted such an identifier, i'd use a URN, making clear that's it's just an identifier, and then would publish a spec that defines that URN.

@adrianba https://github.com/adrianba and perhaps others have cited the risk of high-volume (and likely unnecessary) dereferencing.

yup. and the question is what it buys you. if, as @adrianba pointed out, it is highly unlikely that the URI dereferences to something that allows a client to on-the-fly learn new payment schemes, then all a HTTP URI buys you is a potential DDOS problem that if it goes dark very well may take a substantial share of badly implemented clients down with it that depend on the URI actually responding. that's quite a high risk for not that much reward.

dret commented 8 years ago

On 2016-04-21 14:27, Dave Longley wrote:

That isn't the only thing you can get from machine readable data. What if you just want to get descriptions or icons? What if there are terms of use or rules that indicate you must display brand image X (found at a URL specified in the machine readable data) when offering a payment method?

then these are all things that the registration process has to define and has to make sure that all this information is made available when the scheme is registered. what if the dynamically loaded data changes? do the terms of the payment service change because the data referenced by the payment identifier changed? if that's the case, then very clearly the payment identifier is not a self-describing identifier anymore, but the relevant data is the data that's dereferenced. that's a very different architecture from having self-describing identifiers. both are possible ways to design such a facility, but it should be crystal clear which route is taken, and how clients are supposed to use the identifiers.

dret commented 8 years ago

On 2016-04-21 14:40, Adrian Hope-Bailie wrote:

(I think) I agree with @ianbjacobs https://github.com/ianbjacobs that having a convention for what is found when dereferencing a payment method identifier would be great (and content-type negotiation can be used to return a human readable payment method spec vs machine readable something) but shouldn't be mandatory.

if such a route is taken (URI payment identifiers with an option for people creating them to use HTTP URIs), then the spec should be very clear about the fact they are identifiers only.

the spec of the "payment scheme description language" then could be a completely separate and independent spec, as there could be multiple such schemes, and they would not interfere with the basic "identify the payment scheme by URI" payment model.

dret commented 8 years ago

On 2016-04-21 16:15, Shane McCarron wrote:

I also agree it should not be mandatory. However, can we also agree that there is a way to craft the optional language to assist in ensuring that even optional things are predictable?

tricky in this case, i'd say. if you say that the identifiers are just that, then i would leave it at that. if you start defining a vocabulary that implementations might use if they choose to dereference the identifiers and if the returned representation matches that defined vocabulary, then you have to start defining how any metadata gleaned from that interacts with metadata from the registry. for example, if the registry defines a payment scheme to have the name "Apple Pay" but the representation defines a different name, which name wins? i am not sure that this added complexity is worth it, but ymmv.

halindrome commented 8 years ago

Excellent point.

I know that smart people have thought about this a lot. And I am probably treading on well-worn ground, but...

What if:

I am sure there are arguments against a list and a non-list, but I don't know what they are. Is this over complex? I like applications that are able to discover new information without an update. Heck, one of the terms in the vocabulary of a document could be the "next update time"; basically an expiration in time certain for the information about the payment method.

Thoughts?

dret commented 8 years ago
  • identifiers are "reverse domain names" that are just strings and compared as such
  • there is a "registry" into which people with such identifiers are allowed to map the identifier to a "locator"

if i have such a (optional) mapping from string to URI, why have a naming convention such as reverse domain name?

  • there is a web service that a payment app (or anyone) could hit to check if there is a mapping for an identifier; and if so retrieve that mapping

https://tools.ietf.org/html/draft-wilde-registries-01#section-5.6 discusses this issue. that's basically re-inventing the DNS, unless you'd be willing to accept the risk from building this as a centralized service (which would need to be scalable and robust at a scale close to search engines in order to not become a bottleneck).

  • dereferencing the locator returns a document (via conneg) that has the rules you mentioned; stability, persistence, interrogation, evolution, structure

so, is all this information stable? or does it change over time? if it's sable, why not have it in the registry? if it changes, what are the rules about how clients have to react to any of those aspects changing?

the main thing here is that the registry pattern usually establishes a contract: what gets registered is stable and implementations can depend on that. if you take that away and say that "a payment scheme is whatever the document retrieved from its identifier URI says it is at any point in time", you have a very different design. and not really one that requires self-describing identifiers or a registry anymore.

I am sure there are arguments against a list and a non-list, but I don't know what they are.

my argument would be that instead of making identifiers self-describing, you require runtime retrieval. that's a very different design, and one where even having a registry might not be very useful anymore. with payment being as sensitive as it is, i doubt that there wouldn't be a lot of security issues when making all this payment scheme info dynamic instead of hardcoding it into the client when a new payment scheme is supported.

Is this over complex? I like applications that are able to discover new information without an update.

first of all, let's hear from people actually implementing this whether they (a) want to and (b) are able to build this so that payment scheme information is delivered at runtime. so far the feedback said "no".

Heck, one of the terms in the vocabulary of a document could be the "next update time"; basically an expiration in time certain for the information about the payment method.

if you decide to do everything runtime, then at least you should take advantage of the web and do this via HTTP caching, if you wanted your payment scheme information to expire.

kirkalx commented 8 years ago

If de-referencing is kept optional, my hope is that we can support a class of payment methods that are fully decentralized (e.g. payment via direct access to the Bitcoin p2p network), perhaps via some sort of .onion URL or similar... I believe this would satisfy all parts of the communities associated with various cryptocurrencies in a way that a URL assigned to the w3c working group would not. How to do this without a separate centralized registry is the problem of course.

EDIT: Just to clarify, part of the point would be that de-referencing of these would not be possible.

dret commented 8 years ago

On 2016-04-23 04:20, kirkalx wrote:

If de-referencing is kept optional, my hope is that we can support a class of payment methods that are fully decentralized (e.g. payment via direct access to the Bitcoin p2p network), perhaps via some sort of .onion URL or similar...

payment method identifiers and payment methods are two very different things. this issue is only about the identifiers, not about how the payment process itself works. i think you are mixing these two things.

I believe this would satisfy all parts of the communities associated with various cryptocurrencies in a way that a URL assigned to the w3c working group would not. How to do this without a separate centralized registry is the problem of course.

the question of whether a payment method works centralized or not is not affected by the question of whether payment identifiers (and how they look like) are managed in a registry or not.

kirkalx commented 8 years ago

@dret I'm not entirely sure I agree, although the specifics would matter. Access to a decentralized payment method via a centralized identifier and centralized identifier registry seems problematic to me. Getting rid of de-referencing helps...

dret commented 8 years ago

On 2016-04-23 18:13, kirkalx wrote:

@dret https://github.com/dret I'm not entirely sure I agree, although the specifics would matter. Access to a decentralized payment method via a centralized identifier and centralized identifier registry seems problematic to me. Getting rid of de-referencing helps...

right now the majority opinion seems to be that payment method identifiers are just that: identifiers. they are not dereferenced.

think of it this way: when you code a client, you consult the registry of well-known payment methods and pick the ones you want to support. let's say your decentralized method has identifier "42". once your client finds that identifier, it starts engaging in whatever payment protocol the payment method "42" requires. the registry does not even enter the picture at runtime. it's design-time only.

https://tools.ietf.org/html/draft-wilde-registries-01#section-5.6

kirkalx commented 8 years ago

From the point of view of a dedicated cryptocurrency participant, this would be suspect because of these elements (and possibly others):

  1. who owns the registry and why should we trust them?
  2. is the label "42" attractive in itself or for marketing reasons? (c.f. DNS)
  3. who owns the 42 entry and why should we trust them?
  4. if "nobody" owns the 42 entry, and the 42 community forks into 2 or more subsets, all of which claim to be the true 42ers, which group can keep using 42?
  5. in that situation, is there a (non-manual) way to force each of the subsets to adopt a new identifier that is unique to them?
dret commented 8 years ago
  1. who owns the registry and why should we trust them?
  2. is the label "42" attractive in itself or for marketing reasons? (c.f. DNS)
  3. who owns the 42 entry and why should we trust them?
  4. if "nobody" owns the 42 entry, and the 42 community forks into 2 or more subsets, all of which claim to be the true 42ers, which group can keep using 42?
  5. in that situation, is there a (non-manual) way to force each of the subsets to adopt a new identifier that is unique to them?

these are all very good question. and that's why registries usually have trusted owners, operational principles, and change policies. these need to be laid out, and then you can choose whether you trust them and their implementation, or not.

https://tools.ietf.org/html/draft-wilde-registries-01#section-5.2

it usually makes sense to have ownership of an entry, and it also usually makes sense to disallow changes to entries once they have been registered.

https://tools.ietf.org/html/draft-wilde-registries-01#section-5.3

for your "42" schism scenario: that would violate the "stable entries" constraint. but the question is how the payment methods work, and what ownership of an entry means: ownership of the method/protocol, or ownership of an/the entry point to using the method/protocol? i understand too little of the API as it is to answer that question.

but that's all very abstract. in the end, first the question would be which payment method metadata is registered, and how it is managed. if you would see concrete scenarios where that would result in the problems you're describing above, then that would be a concrete issue to raise against the spec.

kirkalx commented 8 years ago

Perhaps this is overkill, but part of the registry might run along these sort of lines (inspired by HashCash/Bitcoin-style proof-of-work):

An identifier would be a bit-string in a suitable encoding (e.g. base64). Valid identifiers would satisfy H(id) < D for a suitable hash function H and difficulty value D. To register an identifier, a community would have to calculate such an id and publicize it. Any person could force a particular id to be dropped from the registry by registering id2 such that H(id2 id2) = id, as well as H(id2) < D.

Details of changes in D as computing power improves are left as an exercise :)

If D was low enough then spammers who got off on forcing used identifiers off the registry would have to be well-resourced.

dret commented 8 years ago

On 2016-04-23 19:25, kirkalx wrote:

Perhaps this is overkill, but part of the registry might run along these sort of lines (inspired by HashCash/Bitcoin-style proof-of-work): An identifier would be a bit-string in a suitable encoding (e.g. base64). Valid identifiers would satisfy H(id) < D for a suitable hash function H and difficulty value D. To register an identifier, a community would have to calculate such an id and publicize it. Any person could force a particular id to be dropped from the registry by registering id2 such that H(id2) = id, as well as H(id2) < D.

i can see now that we were talking past each other. when you say "registry", you clearly have something else in mind than when i do. i do not know exactly what, but it sounds like some shared key/value store where everybody is free to add entries. when i use the word "registry", i mean it like the managed IETF/IANA registries, such as highlighted in these examples:

https://tools.ietf.org/html/draft-wilde-registries-01#section-2

kirkalx commented 8 years ago

Not really, obviously the ideal registry from this point of view would be fully decentralized, my sketch above was trying to allow entries-without-owners such that many of my list of 5 questions above would be satisfied; but at least initially within a traditional centralized registry. Just thinking out loud and not necessarily workable of course :)

adrianhopebailie commented 8 years ago

My understanding of where we are today on this is:

ianbjacobs commented 8 years ago

@adrianhopebailie,

There will be a registry

Do you mean "of identifiers minted by the WG"? If so, then yes.

I do not believe we have made a decision to maintain a registry of other identifiers.

Ian

adrianhopebailie commented 8 years ago

@ianbjacobs Yes, that's what I meant by the following two bullets. I.e.:

  • It will be owned by the WG (or some other group at W3C)
  • It will list identifiers under the control of the group that owns the registry (i.e. If they are URLs they will start with https://w3.org)

@ianbjacobs said:

I do not believe we have made a decision to maintain a registry of other identifiers

I agree but I wanted to make that clear to try and assuage some of @kirkalx concerns

dret commented 8 years ago

On 2016-04-25 09:03, ianbjacobs wrote:

@adrianhopebailie https://github.com/adrianhopebailie, There will be a registry Do you mean "of identifiers minted by the WG"? If so, then yes.> I do not believe we have made a decision to maintain a registry of other identifiers.

from where i come from, having a registry that only one party can write to is a bit of an edge case for what i'd call an actual registry. after all, mostly registries are created to keep track of an evolving ecosystem of identifiers, and usually there is some process for how it can be updated by anybody, and not just one party.

https://tools.ietf.org/html/draft-wilde-registries-01#section-3.3

ianbjacobs commented 8 years ago

My preference is that W3C only maintain information about the identifiers it mints. The rest of the Web should be able to mint identifiers as well and self-organize according to its needs.

Ian

adrianhopebailie commented 8 years ago

from where i come from, having a registry that only one party can write to is a bit of an edge case for what i'd call an actual registry. after all, mostly registries are created to keep track of an evolving ecosystem of identifiers, and usually there is some process for how it can be updated by anybody, and not just one party.

You are right but that is why I think our use case is unique. The W3C registry has 2 functions and the latter may never materialize:

  1. Bootstrap the ecosystem by providing the necessary pieces (identifiers and specs) for common payment methods
  2. Standardize payment methods where communities have produced a variety of specs that are good candidates for standardization and do this by publishing a W3C note that is a consolidated standardized payment method spec.

As such there is no need for anyone but the W3C to contribute to the "registry".

dret commented 8 years ago

On 2016-04-25 12:46, Adrian Hope-Bailie wrote:

You are right but that is why I think our use case is unique. The W3C registry has 2 functions and the latter may never materialize:

  1. Bootstrap the ecosystem by providing the necessary pieces (identifiers and specs) for common payment methods
  2. Standardize payment methods where communities have produced a variety of specs that are good candidates for standardization and do this by publishing a W3C note that is a consolidated standardized payment method spec. As such there is no need for anyone but the W3C to contribute to the "registry".

the general idea seems to be the same that underlies many of the IETF registries: define the context for an evolving ecosystem, and provide some way in which players in that space can figure things out as it is evolving. what's the rationale to only register initial and w3c-spec owned specs, instead of keeping track of the landscape (according to policies that you are free to define as you see fit), so that people have one place to go to?

keep in mind that you also wouldn't be the first to plan on supporting both registered and non-registered values (which can be done in a variety of ways, including the "magic prefix" you were mentioning):

https://tools.ietf.org/html/draft-wilde-registries-01#section-3.1

but again, the question then is: what's the vision behind distinguishing these two sets of identifiers, and why would w3c have the exclusive right to register?

ianbjacobs commented 8 years ago

Hi @dret,

There is a cost to maintaining any registry. The cost grows significantly when the registry owners want to keep track of things outside of their control. Furthermore, it would be a weakness in the design if there were a central point of failure around payment method identifiers.

That is why we want to decentralize their creation and enable the broad community to self organize. I do not believe there should be a single registry.

Any entity that mints a payment method identifier should take responsibility for it, and so W3C will take responsibility for those that it mints.

We are still debating whether to have short names and how those can be managed in a decentralized fashion.

Ian

dret commented 8 years ago

On 2016-04-25 13:48, ianbjacobs wrote:

There is a cost to maintaining any registry. The cost grows significantly when the registry owners want to keep track of things outside of their control. Furthermore, it would be a weakness in the design if there were a central point of failure around payment method identifiers.

sure there is a cost. IETF has realized that long ago and they now have procedures and infrastructure for defining and running them, which greatly reduces the cost per registry.

since registries almost exclusively are design-time and not runtime, i would not consider them as "central point of failures". they are not meant to be used every single time a payment process is initiated. at least that was my understanding from the comments so far. instead, they are used like most registries: as a centralized place to look up the identifiers that so far have undergone some vetting process, and have been accepted into the registry.

while of course you have to think about your scenario, i'd like to point out that IANA currently manages close to 2000 registries, and they serve a diverse set of purposes. there is a lot of experience with that design pattern, just not so much within w3c.

That is why we want to decentralize their creation and enable the broad community to self organize. I do not believe there should be a single registry.

i think you're misunderstanding registries. the idea of registries often is to do just what you're saying: allow a space to evolve naturally and idenpedently. the registry simply is a discovery mechanism, often has some vetting/review, and also is a good way to minimize identifier problems such as naming conventions, clashes, or duplicates.

Any entity that mints a payment method identifier should take responsibility for it, and so W3C will take responsibility for those that it mints.

yes. registering an identifier does not mean giving up ownership or responsibility. it simply means making it discoverable, and undergoing whichever process exist for adding it, such as the requirement to make documentation available.

We are still debating whether to have short names and how those can be managed in a decentralized fashion.

good luck with that ;-) that has been tried in various ways many times, and it usually fails badly. my advice would be:

but again, just to repeat it: this shouldn't be about whether you want or don't want a registry. this should be about how you want the identifier namespace to be designed and to evolve. for some design choices you can make, a registry then might be a useful design pattern to implement that design.

dret commented 8 years ago

On 2016-04-25 09:56, ianbjacobs wrote:

My preference is that W3C only maintain information about the identifiers it mints. The rest of the Web should be able to mint identifiers as well and self-organize according to its needs.

maybe it would be a good idea (for the spec, not in this thread which is growing way too long anyway) to say why that's your preference. for some scenarios, what you want has turned out to work well. in other scenarios it has turned out to be the wrong design choice and created problems along a variety of axes.

kirkalx commented 8 years ago

Thanks for the assessment of the current position @adrianhopebailie My main hope would be that there is scope for bodies independent of the WG/w3c to build an additional decentralized registry if they see enough reason and care enough to do so. This is why it is important, if the identifiers are to look like/be URLs, that de-referencing is optional.

EDIT: To clarify, the no de-referencing is not so much to do with the decentralization of the registry itself but the concept of ownerless registry entries I was rambling about above...

dret commented 8 years ago

@kirkalx, where i come from, you're effectively asking for a meta-registry: to have a registry of registries, so that over time the set of existing registries can evolve. that's something that can be done, but sounds like adding quite a bit of complexity both in terms of the specification as well as in terms of implementing it. also, that would probably require runtime access to at least the meta-registry, right?

kirkalx commented 8 years ago

@dret I don't think a meta-registry would cover it, unless that meta-registry was itself decentralized. I'm still thinking about what would satisfy some of the more extreme/purist parts of the cryptocurrency communities in this matter. What Adrian describes above in https://github.com/w3c/browser-payment-api/issues/150#issuecomment-214411622 is probably good enough for the first version of the spec, the concern for the bitcoin community in particular is that while getting them to agree on something is not that hard if the benefits are clear, perceptions of ownership/control are highly controversial.

dret commented 8 years ago

On 2016-04-26 23:54, kirkalx wrote:

@dret https://github.com/dret I don't think a meta-registry would cover it, unless that meta-registry was itself decentralized. I'm still thinking about what would satisfy some of the more extreme/purist parts of the cryptocurrency communities in this matter. What Adrian describes above in #150 (comment) https://github.com/w3c/browser-payment-api/issues/150#issuecomment-214411622 is probably good enough for the first version of the spec, the concern for the bitcoin community in particular is that while getting them to agree on something is not that hard if the benefits are clear, perceptions of ownership/control are highly controversial.

thanks for the clarification. a registry is a pattern for managing an evolving set of identifiers in a centralized place, most often intended for design-time lookup purposes. that is not always what is needed/wanted when it comes to designing an API that uses identifiers.

my main concern was to point out that there is a huge body of experience with that pattern outside of W3C, so if that pattern is what the final API wants to use, then tapping into that experience might be a good idea.

ianbjacobs commented 8 years ago

I am closing this issue because of the group's decision to adopt absolute URLs as payment method identifiers. I have not heard anybody propose that these identifiers must be dereferenceable. We are still in discussion about whether to provide any guidance when they are.

Ian

dret commented 8 years ago

On 2016-05-17 10:53, ianbjacobs wrote:

I am closing this issue because of the group's decision to adopt absolute URLs as payment method identifiers. I have not heard anybody propose that these identifiers must be dereferenceable. We are still in discussion about whether to provide any guidance when they are.

sounds good. two comments:

ianbjacobs commented 8 years ago

"Specifications establishing new Payment Methods and minting Payment Method Identifiers URIs should consider making useful information available at that URI, such as links to the specification and possible additional material."

That's the open question for the WG: should we include that, or something else that is stronger, or nothing.

Ian