Agent Use Case: App/Website login


#1

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.

User Benefits

  • 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.

Website/App Benefits

  • 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.

Issues

  • ‘requires an account’ is not great language here, as the meaning of an ‘account’ changes dramatically.

Detail Notes

  • 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.

#2

I really like this description @TelegramSam. The idea that the recipe site’s “account” could be just a cache of data provided by the agent is an important idea and, as you point out, dramatically changes the notion of what an account is.

When you say “agent-connected browser” I’m envisioning an agent that is separate from the browser so that I get the same experience at the recipe site from any browser I connect with. Any thoughts about how that would work?


#3

@TelegramSam Great scenario! This is exactly what we’ve been envisioning for Sovrin login—which, as you say, doesn’t really feel like “login” any more, since it’s really about connection between two peers.

@phil 100% agree that the agent is separate from the browser so that you can use any browser. Ideally where we are going is what I call agent-aware browsers. Today, browsers know how to deal with: a) websites, and b) plug-ins or extensions. The websites are remote, in a different security and privacy domain, and interact a standard protocol like HTTP/S. The plug-ins are local, in the browser’s own security and privacy domain, and interact with using the extension’s local APIs.

I see agents becoming the third type of entity that browsers know how to deal with—an entity that is a hybrid of the other two because: a) the browser speaks to the agent via a standard protocol much like it speaks to a website, BUT b) unlike a website, the agent operates within the security and privacy perimeter of the browser (i.e., it is trusted by the user), and c) the agent exposes a set of API extensions that can do much more than the API extension (plug-ins) that live only in the browser.

Make sense?


#4

Mechanically, it can either happen via direct browser support or a browser extension. A browser extension is the likely first step.

The actual mechanics here are important to work out, but unimportant for the website example. From the website operators perspective, all this works the same, and that is the beauty.
Initially, the awareness will be built into the browser via a browser extension. The ‘agent-ness’ of the browser extension is a good current debate topic.

I really like the term agent-aware as well as agent-connected.


#5

A browser extension would be cool but is it necessary? An agent can be connected by openid and DID service discovery, no?


#6

Yes, that’s how I am thinking about this as well. We’re dead in the water if we’re asking consumers to install and configure a browser plugin…


#7

I think there is a much bigger opportunity hinted at here. The new user has an interest in baking and the site offers a selection of categories. The user, Peter, selects the baking section. An offer pops up that asks Peter permission to Push out recipes when they become available. The offer provides a residual for a piece of Peter’s time. The Peter’s agent handles all the details of the permissions and provides a channel for the micro payments. Since Peter is in control of his identities, if he gets tired of the recipe notifications, he can unsubscribe HIMSELF and does not need to worry about trusting that the website has sold he email address. They do not even have his email address. If the permission is turned off, all communication through that channel is discarded by Peter’s agent.
This also provides an opportunity for a relationship to build between the site and Peter. As Peter becomes a renowned pastry chef, the site wants to include his certification of their recipe and can use that in pushes to other website followers. Or perhaps one of Peter’s creations can be used to stimulate interest in the site, with a kickback to Peter or a link to Peter’s new website.
An architecture of trust is built from the Sovrin Foundation created in the simple act of signing up on a website.