In the second installment of June’s Feature Friday, we look at the permissions types in OCHP 1.5 and what the intent behind them is.
Today’s feature: Whitelisting, Live authorization, hidden tokens
There is a strong development in the market away from whitelist exchange towards more dynamic (and, to be fair, more state-of-the-art) live authorizations which checks whether a token is valid before each charge. However, this creates a problem for the CPO who, when a token in its current form is presented at the charger, will not know which EMP to ask. One way around this is to simply broadcast and “ask” the entire network, but that creates a lot of noise, as well as allows anyone on the network to make a fairly accurate guess on to where which token is moving – unless the CPO implemented a “memory” for a token and next time just asks the EMP with the positive answer. Though that, too, is problematic if a tokens changes ownership.
Another point to consider is that EMPs might not want to share the full number of their customers for business reasons.
Clearinghouses to the rescue
As a “best of both worlds” approach, OCHP 1.5 will allow for very fine-grained control over what will be allowed with your tokens. For this, the mutually exclusive attributes “Whitelist” and “Live” will be added, as well as a mysterious “hidden” one.
The Whitelist/Live attributes works similar to other roaming protocols: If the Attribute “Whitelist” is set, the token may be added to a whitelist and stored in the CPOs backend, or possibly even on the charger. If the attribute “Live” is set, the token needs to be authorized with the EMP each time it is to be used. Only EMPs who have implemented a form of live authorization will be able to set this attribute. As a middle ground, tokens with neither attribute can be checked against the whitelist of the clearinghouse. In both the live and clearing house authentification cases, an Auth-ID will be generated and shall be included in the resulting CDR.
Now, what is this ‘hidden’ thing all about? Simply put, this attribute will tell the clearing house whether it should include your tokens into downloadable lists for connected partners. If the “hidden” attribute is set, the tokens will be accepted by the clearing house and not be part of any downloads a CPO does. However, it will be used in a response to a Live Authorisation to the clearing house. That way, the amount of connections to be asked if a token is valid is reduced dramatically vs. a decentralized network, while at the same time the EMP does not have to inform everyone whenever they acquired – or lost – a customer.
We believe that these changes will find wide adaptation in the market, and that the clearing house can offer a unique service that benefits all market players by increasing authorization surety.
See you next week, stay safe and drive electric,
Your e-clearing.net team