LG-13216: AAMVA issue date + expiration validation (log only)

[matthinz]

🎫 Ticket

Link to the relevant ticket:
LG-13216

🛠 Summary of changes

This PR updates the AAMVA proofer to send issue date + expiration date (if available). These new attributes are not currently required to validate to pass.

It also adds a new key to AAMVA proofer results, requested_attributes that lists the attributes that were originally sent to AAMVA for verification. It's the same format as verified_attributes (an array). The intention is that this will make it possible to do analytics on requests with issue + expiration date.

📜 Testing Plan

Provide a checklist of steps to confirm the changes.

• Run through IdV, uploading a document proceeding at least through "Verify your information"
• Check analytics logs and verify that the requested_attributes includes state_id_expiration and state_id_issued (and hopefully the verified_attributes too!)

This will likely require testing on staging before being promoted to production.

[jmhooper]

Is this intended to reflect the requested attributes based on what we see from the response object? The response object iterates over all possible attributes so it will include attributes even if we did not request them:

identity-idp/app/services/proofing/aamva/response/verification_response.rb

Lines 96 to 105 in 5cb708a

	VERIFICATION_ATTRIBUTES_MAP.each_pair do |match_indicator_name, attribute_name|
	attribute_node = node_for_match_indicator(match_indicator_name)
	if attribute_node.nil?
	handle_missing_attribute(attribute_name)
	elsif attribute_node.text == 'true'
	verification_results[attribute_name] = true
	else
	verification_results[attribute_name] = false
	end
	end

[matthinz]

Yes, that's what the filter is about -- verification_results will have all attributes present, but any missing attributes will have nil values

[jmhooper]

That should work for this issue. 2 things to keep in mind:

1. When AAMVA fails to match a DLN it returns a false match indicator for DLN and no match indicator for other attributes. In that case it will appear that we only requested DLN even when we sent a request for all of the PII including issue and expiration date
2. Cloudwatch has a tough time handling array parameters and parsing them into something useful. If we could find a way to return keys/values here that may be easier to query when we are trying to visualize this. The verified_attributes value is an array so we can use it in get-to-yes IIRC

[matthinz]

Ooh, I did not know that about DLN. It would be a little more work to look at the request itself (currently the proofer just does client.send_verification_request, and doesn't actually get a copy of the request data).

I can change requested_attributes to a hash no prob, I might poke around and see if it is worth doing verified_attributes as well

[solipet]

For the Test Plan, why would the attributes be missing the second time through?

[matthinz]

For the Test Plan, why would the attributes be missing the second time through?

Doh, good catch, I removed the feature flag this would've been testing

[solipet]

One nit, one curiosity, but LGTM.

[solipet]

extra blank line?

[solipet]

Out of curiosity, is ns2 for optional attributes, while ns1 is for required? or...?

[matthinz]

The AAMVA SOAP request template we use includes 4 namespaces:

Abbrev	URL
xmlns:soap	http://www.w3.org/2003/05/soap-envelope
xmlns:ns	http://aamva.org/dldv/wsdl/2.1
xmlns:ns1	http://aamva.org/niem/extensions/1.0
xmlns:ns2	http://niem.gov/niem/niem-core/2.0

we could probably clean up those ns* abbreviations to be more like what they are.