Closed rrix closed 2 years ago
curious if anyone has thoughts on how that flow should/would best work from consumer perspective, and how the AA could best handle that information; i guess from the consumer's perspective they just get a notification that the extension is being "requested" and then the CB is free to do so, no?
so perhaps it's an optional thing which can be added to an IN_PROGRESS request with a "due date" on it, and then the AA can audit that those due dates match the CCPA regs or follow up on requests after the 45+45 window?
i guess from the consumer's perspective they just get a notification that the extension
Yeah it's just a notification requirement (not a request), and the CB needs to provide a reason for the delay
In Section 15 of the CPRA (diffed against CCPA): "A time period for a business to respond to a consumer for any verifiable consumer request may be extended by up to a total of 90 additional days where necessary, taking into account the complexity and number of the requests. The business shall inform the consumer of any such extension within 45 days of receipt of the request, together with the reasons for the delay."
And this applies to access, erasure, and correction requests.
I've created the most-generic mechanism i could think of for this in #38 by letting the legal regime in the submitted DRR control the semantics of it rather than try to express these sorts of extensions in the protocol specification itself.
IMO we can develop normative standards for these things in the context of the governance of the trust network rather than technical WG when we need to. for now the counter-parties could/would/should just make sure the expected_by dates are reasonable and not being fiddled with...
per conversation with @ginnyfahs:
we should encode this as part of the access milestone....