When ven_lookup is present and VEN is unknown to it OpenLEADR acts not accordingly to the standard

[michal-kowalczyk]

According to the documentation, the ven_lookup function allows to reject requests from a VEN that the VTN does not know:

ven_lookup(ven_id): a function that returns a dict with the ‘ven_name’, 'ven_id', 'fingerprint' and 'registration_id' for the given ven_id (see below.). This is used to automatically reject requests from VENs that the VTN does not know, and to authenticate the VENs message signatures.

That is partially true since an unknown VEN will get a reasonable response to oadrCreatePartyRegistration (oadrCreatedPartyRegistration).

The unknown VEN will get an impression that it is registered and will continue its regular flow of OpenADR messages. The OpenLEADR VTN will respond to all of them with oadrRequestReregistration. That makes little sense, since the VEN has no way to fix that issue, the action must be taken on the VTN side (the ven_lookup function must be fed with new information).

The standard explains that oadrRequestReregistration can be used in the following scenario:

If the VTN’s registration information changes, the VTN can request the VEN to reregister using the oadrRequestReregistration payload.

That is not the case, since nothing has changed since the oadrCreatePartyRegistration was sent.

What is more, in the PULL model, the oadrRequestReregistration may be a response to the oadrPoll only (in the PUSH model the VTN could send that message first). In effect, the unknown VEN may receive that message as a response to oadrRegisterReport which doesn't seem right.

I found no precise information how the VTN could respond to a VEN that it doesn't want to serve. However, I believe the best option would be to respond to any message from that VEN with the HTTP status code 463.

Here's my reasoning:

• According to the conformance rule 405:

A VEN SHOULD ignore all payloads from a VTN when not in a registered state. Refer to rule 517 for behavior when a VEN attempts to communicate with a VTN in an unregistered state.

• The conformance rule 517 says that:

If TLS handshake is successful but the VEN is not yet registered, return a 463 application error code in an appropriate (relative to the request) OpenADR payload.

The application error code 463 is defined as a deployment error:

463 - Not Registered/Authorized

So the unknown VEN could be considered as not authorized, since it haven't been registered with the ven_lookup function.

[stan-janssen]

Thanks so much. Excellent proposal. I hope I'll get to working up an implementation soon.