Create common interface for accessing PII bundle in session#6054
Create common interface for accessing PII bundle in session#6054mitchellhenke merged 3 commits intomainfrom
Conversation
There was a problem hiding this comment.
for these .fetch.blank? and .fetch.present?, what if we added a method for that?
| Pii::Cacher.new(current_user, user_session).fetch.blank? | |
| Pii::Cacher.new(current_user, user_session).exists_in_session? |
There was a problem hiding this comment.
That's a great idea, it would allow us to defer decryption a bit further even since it could check for whether the value exists in either decrypted/encrypted form
There was a problem hiding this comment.
I think in the future it would let us defer decryption, but I think by the time we're here, we've already decrypted the whole session payload?
There was a problem hiding this comment.
Sorry, getting ahead of myself, but yeah exactly
app/services/pii/cacher.rb
Outdated
There was a problem hiding this comment.
Are you thinking of using this same tooling to handle the PII that is moving through the proofing flow? I'm curious what that looks like if so.
May be an irrelevant question in an FSMv2 world where we store the unverified PII on the client. But I suspect we'll want the changes to reduce KMS calls in place before we get there.
There was a problem hiding this comment.
Ideally, yeah. It kind of requires a more central way to manage which FSMv2 can hopefully bring.
We do know the top-level keys that are used (idv/doc_auth and idv), but one of those is probably accessed during each proofing step anyway? It may be easier to encrypt/decrypt those in their entirety during the proofing process.
changelog: Internal, Data, Create common interface for accessing PII bundle in session
Co-authored-by: Zach Margolis <zachmargolis@users.noreply.github.com>
mitchellhenke
force-pushed
the
mitchellhenke/standardize-pii-cache-fetch
branch
from
c1f6a1f to
ba75087
Compare
3 participants
On the road to different methods of encrypting/decrypting user data and being more precise in our usage of KMS, changing how we interface with accessing PII bundles opens up some more opportunities with how we can handle it.
With a common interface, it becomes possible for us to do things like lazily decrypt sensitive data, which will reduce the amount of time and number of times where a request is holding sensitive decrypted data.
These changes remove all of the instances where
decrypted_piiis checked in place of using thePii::Cacher#fetch. Some areas still need to use the decrypted string rather thanPii::Attributes, so afetch_stringmethod was added to support those cases.