In the way the questions handle risks it misses one important point. Also to ask: for every instrument, which will be used in the authentication process, are there forms of use of the instrument which cause risks for the authentication and the transaction?
Specific, but obvious example. If the mobile phone has a role in the process, will others forms of use of the smart phone (internet functions sharing files on the phone) pose a risk for the payment process? Will there be dual use for a specific chip in the phone, will there be dual use for biometric authentication, which means data will be stored outside the payment community, etc.
NA
I haven’t evaluate the scientific research about behavior based authentication. However I see another drawback of this. These are based on things like the way people are typing texts or are moving the mouse. These options for authentication are not device independent.
For other authentication factors using inheritance the main questions if these are tamper proof in situations, where there is no physical control how someone is authenticating with or without fake attributes. Contrary to iris scan for access control at locations where there are guards. The guards or other visual control will prevent abuse.
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
In general open and common standards are difficult to define in an evolving environment. I suppose it should comprise amongst others:
- an open standard requires that an implementer or user of the standard doesn’t need to pay fees for intellectual property rights and alike.
- The standard should require that any addition to the services made by a service provider doesn’t force the users of the servers and the other partners in the chain to change something in their interfaces to get the service, unless they deliberately choose to use the added service/information. This way added functionality shouldn’t force changes to others in the chain.
Open standards should describe the minimum set of messages, that should be exchanged between parties. Any provider should accept parties capable of handling these sets of messages. Other messages (usually part of extra functionality) are optional.
