AuthenticationModeType vs. PaymentOptionType

[ahzf]

I still do not see in which way AuthenticationModeType and PaymentOptionType are well defined. More or less they are the same concept and duplication of concepts can lead to confused EMPs that then refuse to pay a CPO... as we all know.

• PaymentOptionType.No Payment is more or less AuthenticationModeType.No Authentication Required
• PaymentOptionType.Direct Payment is more or less AuthenticationModeType.Direct
• PaymentOptionType.Contract has many AuthenticationModeTypes

When PaymentOptionType.No Payment can not be combined with any other payment option, then the same should be true for AuthenticationModeType.No Authentication Required, or? But when you feel the need to write this note it is a clear indication, that your data model has a flaw. If an EV driver has something to pay and in which way he/she can authenticate is part of the CPO-EMP-business relation and thus can not be part of the EVSEData as this data is shared with all EMPs in the same way.

And you should explicitly forbit any EMP to make financial decisions based on EVSEData. For this there are pricing data structures or B2B contracts.

Therefore: Please remove PaymetOptionType, rename AuthenticationModeType to SupportedPaymentMethods (or similar) and extend this which more details about payment methods, e.g. explicit SMS, MasterCard, VISA Card, EC Card, Cash, BitCoins, Sanifair Coupons...

[Namoshek]

I think there is a significant misunderstanding between this types and personally, I think both types are relevant and can coexist.

The AuthenticationModeType relates to a physical device (like an RFID reader) or a logical way (like an app on your phone) to authenticate and authorize a charging session. It has nothing to do with money, simply put.

The PaymentOptionType in contrast is about money. In case a CPO provides only direct payment as option and has zero contracts with EMPs, they might use Hubject and OICP only to publish their data to a broader audience. Be it for EMPs which also display charge points where their customers cannot use their service but direct payment, or for NSPs and similar. Using only one of the options is completely acceptable.

Actually it isn't even a requirement that AuthenticationModeType.No Authentication Required has to follow PaymentOptionType.No Payment and vice versa. There could still be an RFID reader on the charge point which blindly accepts all chips. Or human intervention (from some staff or so) is required to start a charging session, yet free of charge. And it's also possible that you do not need to authenticate, but have to pay - think about coin-operated machines (i.e. direct payment of some sorts). One could argue that in such a case, you could simply use No Authentication Required instead of Direct, since the payment option is already Direct Payment. But there are other combinations which make each of the enum members useful.

[ahzf]

Well, it is not that they MIGHT both have a relevance or not, it is more what kind of information about their relevance and how to use them gives us the OICP specification. At the moment I think not enough to develop a common understanding of those parameters across the industry.

We can daily observe how different the understanding of even simple things in e-mobility can be. Those misunderstandings raise support costs and hamper any faster progress in e-mobility ICT.

[Namoshek]

I agree that there is a lot of misunderstanding in the industry right now. It might have to do with bad language or wrong wording being used for a lot of things, especially visible in the older OICP protocol specifications. There still are inacceptable issues in the documentation today, like power being described as kWh in the OICP 2.2 documents. Also the release notes of OICP 2.3 contain some quite bad wordings here and there. About the protocol OICP 2.3 itself, I cannot say anything just yet, as I haven't had the time to fully read it until now.

But since the new protocol version is or seems to be open source: feel free to improve it with some PRs? I most likely will do so if something doesn't look right. At least it can be discussed publicly then and it will also be recorded for other developers in the future, regardless of the outcome of the discussion.