You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are pros and cons benefits to going with proposed did:web: approach as opposed to did:mailto: I'll try to enumerate ones that I see:
💚 did:web is already standard so we don't need to do spec did:mailto to be on our marry path.
💔 Unlike did:mailto approach with did:web it is name mapping convention and it would make little sense for anyone outside of web3.storage to recognize those.
- did:mailto clearly states that web3.storage is not the authority, domain in the email is.
💔 We can not upgrade / integrate DKIM based stuff as alluded in account spec. Whole point for did:mailto was that we can get away from our email validation flow and make it universal that anyone could support.
Note that our current ./update capability is more of a way to capture our verification so we don't have to do it again.
Even with DKIM we need to resolve mail server keys to verify proofs in UCAN and ./update will continue to allow us to store that we have performed this verification so we don't have to do it on every request.
Other host may not recognize our ./update delegations, but they could still do the DKIM based verification.
In https://github.com/web3-storage/ucanto/pull/168/files#r1046597704 @gobengo made a point that perhaps we should be using
did:web:web3.storage:account:[email protected]
instead ofdid:mailto:[email protected]
, which is worth considering & discussingThe text was updated successfully, but these errors were encountered: