You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
classAuthorization(StateSECC):
""" The ISO 15118-2 state in which the SECC processes an AuthorizationReq message from the EVCC. At this state, the application will assert if the authorization has been concluded by running the method `is_authorised` from the evcc_controller. If the method returns `True`, then the authorization step is finished and the state machine can move on to the `ChargeParameterDiscovery` state, otherwise will stay in this state and answer to the EV with `EVSEProcessing=Ongoing`. TODO: This method is incomplete, as it wont allow answering with a Failed response, for a rejected authorization. `is_authorized` shall return one out of three responses: `ongoing`, `accepted` or `rejected`. In case of rejected and according to table 112 from ISO 15118-2, the errors allowed to be used are: FAILED, FAILED_Challenge_Invalid or FAILED_Certificate_Revoked. Please check: https://dev.azure.com/switch-ev/Josev/_backlogs/backlog/Josev%20Team/Stories/?workitem=1049 # noqa: E501 """def__init__(self, comm_session: SECCCommunicationSession):
super().__init__(comm_session, Timeouts.V2G_SECC_SEQUENCE_TIMEOUT)
defprocess_message(
self,
message: Union[
SupportedAppProtocolReq,
SupportedAppProtocolRes,
V2GMessageV2,
V2GMessageV20,
],
):
msg=self.check_msg_v2(message, [AuthorizationReq])
ifnotmsg:
returnauthorization_req: AuthorizationReq=msg.body.authorization_reqifself.comm_session.selected_auth_option==AuthEnum.PNC_V2:
ifnotself.comm_session.contract_cert_chain:
self.stop_state_machine(
"No contract certificate chain available to ""verify AuthorizationReq",
message,
ResponseCode.FAILED_SIGNATURE_ERROR,
)
returnifnotverify_signature(
msg.header.signature,
[
(
authorization_req.id,
EXI().to_exi(authorization_req, Namespace.ISO_V2_MSG_DEF),
)
],
self.comm_session.contract_cert_chain.certificate,
):
self.stop_state_machine(
"Unable to verify signature of AuthorizationReq",
message,
ResponseCode.FAILED_SIGNATURE_ERROR,
)
returnauth_status: EVSEProcessing=EVSEProcessing.ONGOINGnext_state: Type["State"] =Authorizationifself.comm_session.evse_controller.is_authorised():
auth_status=EVSEProcessing.FINISHEDnext_state=ChargeParameterDiscovery# TODO Need to distinguish between ONGOING and# ONGOING_WAITING_FOR_CUSTOMERauthorization_res=AuthorizationRes(
response_code=ResponseCode.OK, evse_processing=auth_status
)
self.create_next_message(
next_state,
authorization_res,
Timeouts.V2G_SECC_SEQUENCE_TIMEOUT,
Namespace.ISO_V2_MSG_DEF,
)
According to requirement [V2G2-684], in case of PnC and after the first AuthorizationReq, which has to be signed by the EVCC, is verified, if the SECC has not yet an answer from the CSMS that the EV is authorized or not, then iso15118 can for 60s be in a loop of AuthorizationReq/Res with EVSEProcessing = "Ongoing" and in this case, the subsequent AutorizationReq messages are empty, so the SECC does not need to verify the Signature of those messages.
Inspecting the code, is clear that this is not expected and, as of today, the code would fail, because it would try to verify the signature of the Authorization message when not supposed to.
Solution: Save in a variable that the 1st Authorization was verified, so that the next AuthorizationReq does not need to be verified.
The text was updated successfully, but these errors were encountered:
tropxy
changed the title
PnC Authorization
PnC Authorization -> First AuthorizationReq message contains the id and GenChallenge, but not the upcoming ones
May 9, 2022
Azure ticket: AB#1049
This is the Authorization state class:
According to requirement [V2G2-684], in case of PnC and after the first AuthorizationReq, which has to be signed by the EVCC, is verified, if the SECC has not yet an answer from the CSMS that the EV is authorized or not, then iso15118 can for 60s be in a loop of AuthorizationReq/Res with EVSEProcessing = "Ongoing" and in this case, the subsequent AutorizationReq messages are empty, so the SECC does not need to verify the Signature of those messages.
Inspecting the code, is clear that this is not expected and, as of today, the code would fail, because it would try to verify the signature of the Authorization message when not supposed to.
Solution: Save in a variable that the 1st Authorization was verified, so that the next AuthorizationReq does not need to be verified.
The text was updated successfully, but these errors were encountered: