A user navigates to a new recipe website in an Agent connected browser. The website requires an account and prompts the user for a connection. The user approves the connection, and the Agent connected browser generates a new DID and submits it to the website. The website requests permission to access the user’s allergy, basic data storage, and messaging Agent Extensions. The user atomically approves these during login.
The recipe website queries the user’s allergies and recommends recipes. The user favorites a few. On logout, this favorites list is submitted to the user’s Agent for storage. On return visits, this list is queried for a continuation of experience.
A week later, the recipe website identifies a new recommended recipe. A message is sent via the user’s Agent notifying the user of that fact.
- The DID created for this website is unique, and correlation is avoided.
- Messaging is easily controlled. Spamming websites/apps can be identified and shut off.
- Frictionless signup and experience bootstrapping.
- No storage of passwords
- Message channel with the user that is not email.
- User stored data: allows sites to not pay to store user data when not needed or required.
- Inactive users can simply be deleted from the database: on a return visit, retrieving the user’s data from the Agent can restore experience data.
- ‘requires an account’ is not great language here, as the meaning of an ‘account’ changes dramatically.
- The website validates the DID by checking a signature presented alongside the DID.
- The DID points to a DDO, which contains a service pointer to the Agent. That service pointer is also unique and is routed to the user’s agent by their Agency.
- At no point was an email address used in this interaction. Email has become the defacto username, simply because it combines a unique, provable identifier that also functions as a communication channel.