fission-codes
Add 'administer account' UCAN Resource
At the moment any app that a user connected to could send a POST https://runfission.net/user/email/resend.
Ideally this is only allowed for a approve list configured in the server's env.yaml (I think).
What would this approve list look like? Domains? What other mechanisms do we have for identifying apps?
Also, how does the testing story look like? Can I hit staging with my local development version dasbhoard?
I'd love input on this. Seems hard for me to figure out.
I think @expede suggested a UCAN permission?
Domains is what I was thinking. The app name is unique.
Yeah, UCAN permission for "can send me an email". Let the user control which apps can do this, is my thinking.
@expede I love that idea, but I think it might be separate/additional? Right now, any app could trigger re-send verification and a user could (in theory) tell badactor.fission.app "sure you can send me email" which would let badactor trigger re-verification.
@walkah yes that's true today. Since every app gets a UCAN, omit that resource from the delegation. Now that app won't be able to send email / password validation / whatever we want to make the resource.
Also, is it so bad if an app sends a reset code? I've received those emails before. It validates that you do in fact control that email address. Possibly confusing "why did I get this", but we already have wording about ignoring that in the email template.
but I think it might be separate/additional?
Ah, sorry, I think I see what you mean now!!
Yes, a separate "can reset email" or "administer account" resource something something. Yes, absolutely agreed :+1:
@expede yes, right. this case (and lots of dashboard cases) might need something finer grained than just "can send email". 🤝
@matheus23 how does this feel? https://whitepaper.fission.codes/access-control/ucan/webnative-attenuation/account
We can get more granular later; I agree with @bmann about starting "big" here