need to update header_params with signed api keys/digest.

Description

[Python Client]
I'm looking for pointers to update header_params['Authorization'] with digest and signed signature (using private keys) basically using IETF draft
https://datatracker.ietf.org/doc/draft-cavage-http-signatures/?include_text=1

I tried to implement preparing digest and signature in api_client.py and then append header_params with Authorization parameters as shown below :

format of auth header :
{'Content-Length': '3', 'Host': 'host', 'Digest': u'SHA-256=XaOkx/...........mVzoB7LA/Dp0u2+Y=', 'Date': 'Tue, 24 Oct 2017 19:15:00 GMT', 'Content-Type': 'application/json', 'Authorization': u'Signature keyId="59c4505b26c7510001f5c75f/59c44f9f26c7510001f5c0a0/59e03ebb1082710001a1c44c",algorithm="rsa-sha256",headers="(request-target) date host content-type digest",signature="XaQsGKWhOtzosllNUd.................SlEwZyFjJaCFJ3SxVRbHw=="'}

I call the digest creation method in __call_api() since i need to utilize resource_path, method and if any query_params/path_params so can only pass them from here. But that does seem like a hack and have to change the order of some part of the code in __call_api(). And this does seem ugly way to do it. Is there a better approach of supporting signed api keys in client code?
The above ietf is different from the regular api key which cannot be defined under Security property definition which the swagger schema supports and will not work for signed http signature. Currently i do not thing there is any other way than clone the project and adding the auth header digest calculation login in api_client or rest.py ???

Would really appreciate if there are any pointers to implementing this in client side.

Swagger-codegen version

swagger-codegen version
2.2.3

Start by reading the Python client's api_client.py, especially __call_api(), and compare it with rest.py and the Swagger security property mentioned in the issue. The issue describes digest and signature inputs from the request path, method, query parameters, and body, but does not define a concrete implementation boundary or tests. Done would require an agreed approach for supporting signed HTTP signatures without a local fork.