B to C (user attributes exchange)

Let's say a user is registered in an online DVD rental store. 3 web sites, this DVD rental store, a pizza dilevery store and an online book store, are already configured with Eunomia mechanism.

The user accesses the pizza delivery store 's website to order a pizza after renting a DVD at the online DVD rental store. The DVD rental store sends the uid, telephone number and address information of the user to the pizza site according to the requests received.

After that, the user accesses the online book store to buy a book, so the DVD rental store sends the uid and a DVD rental history of the user so the online book store can create a customized recommendation list for the user.

In this case, the user's information is registered neither in the pizza store nor in the book store. Yet, the user experience is just like as if the user's information was stored in all the above mentioned websites. Adding servers and services can easily be done at each site, because the only thing that needs to be done is to configure the Eunomia mechanism of the new server with the public keys of other sites.

overview

B to B (consolidation, coalition)/ Across universities

There is no need for an integrated user registry or a user management system when configuring an interoperable system between companies , simply because there is no need to share user information .

We can implement simple authorization mechanisms with realm names, and we can implement more complex mechanisms using user attributes.

overview

Cloud/SaaS

Cloud/SAAS applications (ex. Web meeting application) can provide their own services without user registries. They can distinguish same user IDs from other sites (meaning other realms), and if necessary, they can authorize user's requests with user attributes.

For example, they can implement simple authorization policies like "users can gain access only if their attribute values are appropriate ", and unique policies like "user's requests which don't contain necessary attributes are not permitted ".

In the case of the web conference application, the application can distinguish userA from realmA and userA from realmB and authorize their access according to their job titles.

overview

Disaster-resistant coalition

Because Eunomia can realize a distributed authentication system, even if one system goes down, other systems can work. For example, even if a disaster happens and headquarter systems crash, other systems can work without the headquarter's main user registry or services and conduct businesses by communicating each other. Of course these days most systems have backup systems in case of disasters, but not all the services are in the backup ones. Moreover, because such backup systems often have less capacity, companies want to use them for their main business processes and don't want to allow other systems to access them. In such a case, at least other systems can direct their bisinesses/services those don't require the headquarter services.

overview