in talking about how to design an "escape hatch" which is more simple to implement than the needs_user_verification channel. john suggested adding an "out of band" request state which would indicate to the AA that the request's state is being moved through other channels. The CB would still be on the hook to update the request state in the DRP API but at this point the request would be served/managed/etc over email or in person comms or whatever. the processing_details field would be set to something which the AA can see and say "oh this request is happening via email" and maybe message that to the consumer or so.
this would allow a CB to move communication directly to the consumer and disintermediate the AA from the interactions, which feels ... vaguely uneasy to me & easy to subvert the goals of the protocol, but not much more than NUV already does.
in talking about how to design an "escape hatch" which is more simple to implement than the
needs_user_verificationchannel. john suggested adding an "out of band" request state which would indicate to the AA that the request's state is being moved through other channels. The CB would still be on the hook to update the request state in the DRP API but at this point the request would be served/managed/etc over email or in person comms or whatever. theprocessing_detailsfield would be set to something which the AA can see and say "oh this request is happening via email" and maybe message that to the consumer or so.this would allow a CB to move communication directly to the consumer and disintermediate the AA from the interactions, which feels ... vaguely uneasy to me & easy to subvert the goals of the protocol, but not much more than NUV already does.