Use Case Review - Daniel Austin

[msporny]

Feedback by @daustin2011 on 10/6/2014 11:25:52:

Do you have feedback on the Legacy Support design criteria?

This set of requirements is necessary for this group's work to be successful. It should however be entirely re-framed in terms of language and intent:

• The requirement should be that any stands proposed should enhance the existing payment systems - not 'legacy' but current. Without the support and participation of these organizations, we will fail. The IETF is a graveyard of failed payments -related standards, which were rejected by the financial community.
• We need to avoid any sort of presuppositions about the design here - terms like abstraction layer are (hypothetical) solutions, not problems to be solved. Keep the requirements simple and free of technical assumptions.
• We're not in the policy business, we're here to solve problems for the existing financial community. This means that we don't have a position on the outcome, beyond meeting requirements. We're not overturning the World order or leading the revolution in payments. Our goal is to make things inter-operable in a complex world, not to promote any particular POV.

Do you have feedback on the Data Portability design criteria?

Buzzwords. What does this mean?

Do you have feedback on the Web Intents / Protocol Handlers design criteria?

This sounds like a plea for a specific technology/design pattern. I'm sympathetic in this particular case but again, we MUST NOT presuppose solutions or technologies. Web intents are great. We'll consider them along with everything else. But there's no requirement here, and it probably doesn't belong in this document.

Do you have feedback on the Authorization Configurability design criteria?

This stepwise authorization is common in the US, and is already widely implemented. Does this need standardization? It seems like a product feature. Each organization will want to have their own authorization mechanism based on context, history, and their perceived risk. I think our requirement should be that we create systems that don't preclude this, or that support existing mechanisms or improve them. Having this feature isn't a requirement.

Do you have feedback on the Smart Contracts design criteria?

It sounds good - but what does it mean? Can you provide an example? Which areas of standardization are most important right now, as this technology (and the associated social systems) are being developed? Again, I think we should develop standards that don't preclude this, without restricting future developments.

Do you have feedback on the Physical Receipts design criteria?

This sounds good, it's definitely a requirement in the sense that if we developed standards that didn't allow this it would result in failure.

Is there design criteria that you feel is missing from the document?

• need to mention online/offline transactions and how to handle them
• need to handle escrow use cases
• use cases should use standard template (Cockburn et all)

Do you have any feedback on the Purchase Request use case?

TBD - more later