Is there a pattern to support the use case where we (a service provider) want the individual to own the original record (model instance) but for that owner to delegate on some long term basis the ability of a our service to update that record? I’ve scanned the forum and found discussion around CACAO and session expiry etc, but wondering what the pattern would be for a backend to do user sanctioned updates to their data records on longer timescales than a single session. Thanks
I know @spencer might have some thoughts/hesitancies around this, but my mind immediately goes to two options.
The first would be what you already mentioned - altering the default session expiry and persisting those sessions in your backend to make eventual updates after the user has left the interactive session. Of course, once the session eventually expires, you’d need the user to create a new one to continue using this pattern. (happy to dig up some code samples showing how to alter the default expiration time)
The second option that might be more secure would be to have each model instance (owned by the individual) define a relation between that model and a separate model instance that your backend owns. That way, there’s no need for the user to refresh sessions, and your backend can make updates to the model instances it owns whenever it wants while still being able to query based on a relationship between the individual-owned model and the app-owned model.
@mzk , I appreciate your response and ideas here. I like the sounds of option 2 (a form of sanctioned delegation). I’ll think about how we incorporate that approach into our data model.
It would be handy if CACAO’s weren’t tied to sessions and instead just delegating permissions to specific streams to wallets…but I don’t yet understand the stack enough probably.
CACAOs can theoretically support this kind of delegation, but the work hasn’t been done to actually build that support yet. Longer term we imagine much more sophisticated delegation capability in CACAOs, but for now something like what Mark suggested is probably best.
1 Like