As was seen in the previous post, EnThinnai allows an individual to share digital information with others. Access to such shared information can be controlled by three parameters: individuals’ OpenIDs, responsibility tags administered by one or more authorized entities and interest tags. Additionally EnThinnai also provides real-time communication tools like text and voice chat. These tools also operate under a permission controlled scheme. Any permitted party can initiate a communication session with the user of EnThinnai.

Now let me take a specific use cases and describe how a customer can use EnThinnai to request a product or service. To this end, the customer has to create a “stream” as described in the previous post. Furthermore, the customer can identify individual know vendors in the “To” field. Alternatively, if the customer is soliciting proposal from a group of vendors nor previously known, the customer can use the “Responsibility tag”. Supposing the customer is interested in a plumbing job, she can use “Plumbers in 01234” as the responsibility tag with the authorizing agency to be Yellow Pages (or Yelp or Google Places or BBB). Once the customer creates such a stream, all the intended parties will be notified of this stream and they can opt to get the full content from the customer’s server. Since EnThinnai allows authorized parties to post replies and makes it part of the stream, both the customer and the vendors can get the full history of the transaction at any time.

Now consider the case of a customer who would like to post a review of a restaurant. He could create a stream containing the review and identify “Italian restaurant in 01234” as the interest tag within the community of Google Places (or Yelp or Superpages). Here again subsequent visitors can use the reply mechanism to add to the original review.

In a much earlier post Doc Searls has enumerated ten principles behind VRM. It is worth to calibrate EnThinnai against these principles and score how well it meets them.

1. VRM provides tools for customers to manage relationships with vendors. These tools are personal. They can also be social, but they are personal first.

A stream in EnThinnai need not be shared with anyone. It could be just a record for the benefit of the customer. In this respect it is a personal tool. Of course it also allows the customer to share with one or more specific or loosely defined group of vendors and other customers.

2. VRM tools are are customer tools. They are driven by the customer, and not under vendor control. Nor to they work only inside any one vendor’s exclusive relationship environment.

EnThinnai is not controlled by a single vendor. Indeed even the operator of EnThinnai is not in control. The customer is at liberty to specify any individual or authorizing agency.

3. VRM tools relate. This means they engage vendors’ systems (e.g. CRM) in ways that work for both sides.

Since streams are accessed using standard HTTP protocol, any browser based CRM can easily incorporate ways to access streams that it gets notified.

4. VRM tools support transaction and conversation as well as relationship.

As noted, EnThinnai allows permission based real-time communications enabling conversation.

5. With VRM, customers are the central “points of integration” for their own data.

Data is in only one place, at the customers’ server.

6. With VRM, customers control their own data. They control the data they share, and the terms on which that data is shared.

Nominally data is stored only at the customers’ server. It is expected that others who are allowed to access the data will adhere to this principle. It will be a breach of trust otherwise.

7. With VRM, customers can assert many things. Among these are requests for products or services, preferences, memberships, transaction histories and terms of service.

This was described in the use case.

8. There is no limit on the variety of data and data types customers can hold — and choose to share with vendors and others on grounds that the customer controls.

True.

9. VRM turns the customer, and productive customer-vendor relationships, into platforms for many kinds of businesses.

Need operational evidence and so will take time.

10. VRM is based on open standards, open APIs and open code. This will support a rising tide of activity that will lift an infinite variety of business boats, and other social goods.

EnThinnai uses open standards. We have yet to define APIs, but when we do it will be open. We have not made the code open and at this time there are no plans for opening the code.

It is apparent that EnThinnai meets almost all of the principles set forward for VRM. The way EnThinnai is setup, no single entity can have a dominant control. Since we use OpenID and third party authorization, artificial network effect is removed. The whole Internet could be part of every individual customer’s network.

Access Control: Publisher vs. Consumer:
The first defining characteristic that Boyd identifies is the “asymmetric relationship” widely attributed to Twitter. But he points out that this is derived from the public blogging model. Interestingly he dismisses the limit of character count, another characteristic of Twitter as not the most productive distinction. He makes it clear that the real focus should be on the way content is published and consumed. Content creators publish with no specific intended recipients. Content consumers have their own way to filter from this vast collection of content with no a priori agreement with the publishers. Certainly, the publishers can facilitate consumers’ filtering process with other techniques like hashtags. But the critical thing is that the publishing and consumption processes are independent.

Boyd contrasts this to email where the publisher determines and selects the set of consumers. For him this is a critical flaw. If streams are elective on the consumers’ side, email is elective on the publishers’ side. If streams are inherently more distributed and bottom-up, email is inherently more centralized and top-down.

But I am uncomfortable with this categorical dichotomy. If Twitter is a prototype of Streams, it may be instructive to note how it is being used by its users, especially because Twitter users are well known to develop adhoc conventions to overcome some of the limitations. Even though Twitter streams are public and anybody can access them, users feel certain tweets are private and meant for a single individual. This is met by “direct message” (DM). In a business environment, the need for privacy is more acute. Businesses have fiducial and legal requirements to keep certain messages confidential. Only the publisher can know the level of restriction. Secondly, the general understanding in Twitter is that it is possible for a person to miss a particular tweet. It is well known that tweets are phatic. To ensure that a particular person reads a tweet, publisher usually uses an “@message”. Twitter’s web interface and almost all third party clients list @messages (”mentions”). This is a call for a specific consumer to pay attention to a particular tweet, but decided by the publisher. Thirdly, as Boyd notes, publishers can use hashtags to telegraph the intended audience for a tweet. All these point to the need for “elective on the publisher’s side” as well.

To summarize, Streams must allow for different level of access restriction: all the way from free access to free within a domain to restricted to people with a certain responsibility to a set of identified people.

Tummlers: Individuals and Tags too:
Kevin Marks talks about the role played by “Tummlers” in expanding the conversation. Since one routinely reads tweets from only a set of people, it is possible to be stranded in a Twitter island. But so called Tummlers play the role of bridging these islands. Usually Tummlers retweet to spread information from one island to another. But ever inventive Twitter users have found another way – hashtags. Publishers attach hashtags to their tweets and others, even non-followers can search for a specific hashtag term. These tags can be viewed as “interest tags” as expressed by consumers. In other words, a publisher is saying that a tweet will be of interest to those who are interested in the tags identified in the tweet. But business context requires another kind of tags. In keeping with the requirement that businesses may have to control access, publishers may have to control access to only those whose area of responsibility includes those identified in what I call “responsibility tags”.

Accordingly, in the new service access rights will be determined by three parameters: A “To” list as in the traditional email, a list of responsibility tags along with the identification of the authority that issued the responsibility and finally a list of interest tags. A publisher has to identify these three parameters and the specific logical combination that should be applied.

Let me elaborate with a few examples. If the publisher has put Aswath in the To list, acme.com/marketing in the responsibility tag and VoIP in the interest tag and the logical combination, is “AND”, then Aswath can access this post only if acme.com has asserts that Aswath has marketing responsibility AND Aswath has expressed an interest in VoIP. On the other hand if the logical combination is “OR”, then Aswath or anybody who has marketing responsibility according to acme.com or anybody who is interested in VoIP can get access to this post. Of course the logical combination can be a bit more involved.

Anatomy of a Stream:
As was pointed out earlier, Boyd states that Twitter’s size restriction may not be relevant for businesses. Dave Winer has been lobbying for a long time that Twitter should allow for metadata. He points out that shortened URLs are attaching pictures or other media via URLs are examples of metadata. Twitter itself has announced plans to introduce a new feature called Annotated Tweets. Not withstanding all that, there is a real benefit in capturing the main idea of a post in a pithy comment. This allows the reader to quickly scan many messages before deciding to select a subset of them to dig deeper.

So Streams should adopt “Subject” field used in email, but restrict the length of Subject field to 140 characters. Furthermore, the recipients will first see only the Subject and possibly an initial segment of the post, but no more than 140 characters. A recipient can access the full post if so desired.

Distribution of Streams:
email and Streams differ in how they distribute messages. In email the sender explicitly identifies the list of recipients. Then the sender’s server distributes the message each of the recipients’ servers individually. On the other hand distributed systems like XMPP use Pubsub like mechanism. More recently, this mechanism is further refined with PubsubHubBub. In this mechanism the originating server uses intermediary Hubs to reach the ultimate servers. In a business environment either of the schemes have some undesirable qualities. Since the email system delivers the complete message to the recipients, one of them can forward it further down the line. The originator has no control or record of such distribution down the line. In the case of PubSubHubBub, the intermediary nodes have access to the message. even if the message is encoded, the mere fact that two enterprises/individuals are communicating itself may be potentially sensitive information. So an alternative, efficient mechanism must be used that takes into consideration privacy concerns.

When Streams identifies an individual recipient, then it should first determine whether that recipient is a Streams user. If so, the Subject of the post along with the URL to retrieve the complete post will be posted to the recipient’s server using webhooks. If the recipient is not a Streams user, then the creator will be notified to inform the recipient using some other method like an independent mode of communication. The address resolution algorithm may resolve to a group of people identified by a Responsibility tag under a domain. In this case, the domain may not revel the individuals associated with the Responsibility tag since that could be a sensitive information. In this case, the Subject of the post and the retrieve URL will be deposited to the domain which in turn will distribute to the relevant individuals. Finally if a group is identified by an Interest tag under a domain it is possible that the group may be a large number. So in this case, the Subject of the post and the retrieve URL will be deposited to the domain, which will distribute to the individuals.

Threaded Stream:
Traditionally email systems treated messages individually. Then Google introduced the concept of threaded messages in GMail. Still it is from the perspective of the recipients. If one person is excluded from the reply then that person looses the threaded view. We should also note that an email thread captures organizational memory. This organizational memory would be of help to a new person joining the group.But current email systems are not very effective in facilitating transfer of knowledge base. Streams musty endeavor to provide this.

Accordingly, Streams should keep responses to a message along with the original message, identifying the author of each of the responses. Further, the original creator of a message must be able to add new recipients at a later time.

Summary:
1. Publisher can specify the audience for a stream using three parameters: Individuals identified by “To” field, Responsibility Tags and Interest Tags.
2. A stream will contain a Subject field that summarizes the content of the stream and is of limited length.
3. Stream will also contain a field called Body. It can contain arbitrary digital content and can be of arbitrary size.
4. Recipients can be individuals or a group whose members can only be determined by a third party domain.
5. Individuals and third party domains will be given the contents of the Subject field and an URL to retrieve the stream. When somebody tries to access the URL, the user will be authenticated to maintain the integrity of the access control stipulated by the publisher.
6. Any followup exchange to a stream will be appended to the Body of the stream.

Shameless Self-promotion: These and other thoughts were the motivational forces for EnThinnai. A showcase implementation has captured all of the requirements except for Responsibility and Interest Tags.

Presence service is universally designed as a Push service. Typically, User Clients report the user’s network connectivity and keyboard status to a central server which in turn pushes to all the buddies of that user. Some services further allow users to customize the status info, either globally or to a particular buddy. I contend that this is not a preferable method as it is insecure and introduces anti-social behavior.

Consider the following scenario: Abel and Betty are buddies with each other. This allows Betty to constantly monitor Abel’s Presence status, so much so can reconstruct Abel’s timeline. In real life, even if Abel and Betty are close friends, Betty’s behavior will be considered abnormal as dramatized by Lucy and Holden:

Indeed the situation is worse. The real comparison would be the case where Betty were to observe Abel using a periscope without Abel knowin about it. That would be a real anti-social behavior. But that is exactly what the Push system allows.

This problem further compounds when Presence information is shared between federated networks. How does one network ensure that the other network maintains the confidentiality of the shared information? Specifically, if Abel is sharing different status information with Betty and Charles belonging to the same federated network, the expectation is that Charles will not be able to access the information shared with Betty. What about all other members belonging to the federated network who are not Abel’s buddies? Andy Zmolek points out this scenario in one of his blog posts.

This can be ensured only after extensive testing, leading to a time consuming routine before two networks can federate. But this is counter to the objectives Unified Communications and Collaboration (UCC) of which Presence is a component.

Given these issues, I wonder why Push system is still being used. I have raised this point with a few people. The consistent response is Push is considered to be an efficient way of distributing seldom changing Presence info; otherwise all the clients will be polling all of their buddies’ Presence info, overloading all the servers. This is true only because they have fixed a specific use case scenario where the user is able to ascertain the Presence info of all of their buddies with a single glance. For this small convenience, we are paying a huge price.

But there is an alternative that addresses the concerns described earlier with a small change to the user interface. The alternative is for Betty to query Abel’s Presence server whenever she needs that information. Since Abel’s server will log all such requests, Betty will be discouraged from stalking Abel, except when she is desperately trying to contact Abel.

Federation is not a big problem anymore since the server belonging to the federating network is not involved in this transaction. Of course Betty and Charles can exchange and compare the information they received. But that happens in real life as well. We as social beings have developed social norms to handle such situations.

Finally if the User clients have a simple mechanism for a user to query Presence information of a single or a group of buddy, then this would be an acceptable compromise for other benefits. But there is one technical issue. Since Betty will be querying Abel’s server, it must be able to authenticate Betty. Here my suggestion is to use OpenID/OAuth. By the way this is how EnThinnai serves Presence information of its users.

Pulling of a user’s Presence information can be further enhanced by allowing for Betty to subscribe to Abel’s Presence information. For example Betty would like to be informed when Abel’s Presence info changes or it contains a specific string and the like. Of course such a subscription needs to be approved by Abel before the updated information is delivered to Betty. Of course this mirrors what happens in real life interactions.

In summary, we should not push a user’s Presence information, but instead buddies must be allowed to pull after they are properly authenticated. Servers should also accept subscription requests which will be responded to after the user has given permission. Finally, the server should log all requests and make it available to the user.

The set of JP’s posts that are relevant to this analysis are:

1. Facebook and the enterprise: Part 1
2. The Facebookisation of the enterprise
3. More on the Facebookisation of the enterprise
4. Walls and bridges: even more on Facebookisation

Even though you will enjoy and benefit from reading these original posts, let me capture the main points here for ease of reference.

1. Tomorrow’s workforce is experiencing and learning social skills in Facebook, which seem to have different collaboration philosophy than what is traditionally practiced in the corporate world. Just as corporations have supplied old world social facilitators like watercoolers and canteens, modern corporations must supply social network platforms. In his opinion the platform must support publishing, search, fulfillment and conversation. He calls them Four Pillars.
2. An enterprise worker would prefer to see all theses things for a quick review: news events, a unified inbox, appointments, communities, consulting and sharing views and opinions.
3. The unified inbox is enabled with both a white list and a blacklist.
4. Colleagues’ presence information
5. Search and discoverability tools
6. Easy to mash-up third party applications
7. Ability to federate with customers, partners and supply chain
8. Total flexibility in privacy and access control

Given these broad objectives, the Manifesto also identifies a specific set of features:

1. A personal token that can be used for all the activities in the company
2. A place to create personal profile that allows for discoverability
3. Create and maintain a social graph
4. PIM – Address book, calendar and to do list
5. Real-time communication with the members of the social graph
6. Publication platform
7. News feed

EnThinnai uses company supplied OpenID for authentication. So this can be used for other activities both within the company and also at external sites. Additionally, we can use the Attribute Exchange mechanism used in OpenID to convey HR supplied authorization information like Job Title, scope of control and the like.

EnThinnai allows for its users to create a rudimentary profile and also a set of contact information. There is no address book in the traditional sense. EnThinnai maintains a list of Contacts, their OpenID and the name of their EnThinnai server. When a user would like to access the contact information of a specific person, it will retrieve the information in real time. The current version does not have Calendar, but it is in our road-map.

EnThinnai has its own version of social graph but it is very different from the normal one. Unlike many other social graphs, in EnThinnai the concept of buddy is unilateral. If B is in the social graph of A does not mean that A is in B’s. Indeed, B may not even know that she is in A’s social graph. B may not even be a member of EnThinnai. Of course B is identified by her OpenID; so it requires that she have an OpenID. (Though the “follower” relationship in Twitter is also unilateral, there is a fundamental difference between these two.)

EnThinnai allows real-time communication with Availability status, text-chat and voice communication between users of EnThinnai and members of their social graph. It is to be noted that this is done with no requirement on pre-installing a client by either parties. Oh, we use a wideband codec for voice chat. The text chat is a persistent chat in the sense that the chat session can be continued at a later time and the whole session is saved.

The main objective of EnThinnai is to share digital information. Accordingly, users of EnThinnai can publish documents, share files with explicit access controls. Furthermore people allowed to access the published information can post comments. EnThinnai is planning to integrate recently open spurced Etherpad so it is possible to edit a document in real-time.

If two people are mutually in each others social graph, but are under different EnThinnai deployments, then the update information is exchanged between the servers using webhook technology. This simple mechanism is used to federate multiple EnThinnai deployments.

So over all we are very satisfied in how we meet the objectives of the Manifesto. Still we have lot more to do and we are very encouraged.

But this means that the codec we use must be freely distributable. This is the reason we decided to use Speex. Last week Skype announced that they will make their codec widely available. I am not sure whether this kind of use is allowed.

Our thoughts are different and our position is clear. The need for findability is real but it is out of scope for EnThinnai. EnThinnai is an application running on your server and serving your needs. Since it is individually focused and under individual control, we can not have a picture of the global social graph. So our users have to look elsewhere when a long lost friend is trying to reestablish a connection. A central component of un-social networks or user-centric social networks is user-centric identity. iName is one such identity scheme. Most of the iName providers offer a “contact” service. It “is a way for you to put a link on your web pages or on your business card that allows people to contact you, without exposing your email address to spammers.” Analogously other ID providers could also offer such a service as well. Armed with my OpenID, a new contact can contact me through this service, providing her EnThinnai particulars and adding me in her permission list. Then I will be able to visit her EnThinnai and initiate the communication. Subsequently, I could add her to my permission list and close the loop.

This method addresses the need for allowing contact establishment without violating the privacy model of EnThinnai and its distributed nature.

Tom states at the outset that in his thinking the concept of directory is complete inverse of the traditional directory. He says that instead of storing our friends’ contact information, he will store his contact information and will allow others to access it in real-time under the control of a permission based rules engine. This is EXACTLY what we do in EnThinnai and we had implemented it even in a mockup that is two years old.

Next he goes through the mechanics: “We now each have two entries in our personal directory. The contact entry I use to reach you has nothing but permissions in it and the address of your contact page (which I can’t see but can get connected to you through). The other entry is the permissions I granted you which are to a subset of the possible ways to reach me.” In EnThinnai, we will store for each contact information a permission list identifying the list of people who can access that contact information and the address of your contact page. But we do not store your permissions. It is not clear why he does it either. After all he suggests that you will be able to change the permissions dynamically. I suspect that it is an editorial mistake. So he is storing the same set of information as we do in EnThinnai.

The mechanics one will use in his description is also the same we do in EnThinnai: when I want to contact you, I will visit your contact page and after authenticating myself, I will receive all the modes of communication I am allowed to have with you for that time. Then I can pick one that is most agreeable for my purposes.

He promises to deliver on the upcoming nirvana. But the nirvana is here already and is operational now for a year. Furthermore we have been adding specific communication modes. From the beginning, we have provided an email equivalent, but with no spam. In Spring VON, I introduced the ability to do text chat. In a short order we will provide voice and video capability. In Fall VON, I even introduced what a future business card will look like.

But even in technical details, there some differences. EnThinnai does not require everybody to be running this application. If I want to share my contact information with you, it is not necessary that you also should have installed EnThinnai. It is enough that I have. Tom says that findability is also coming. EnThinnai does not offer that. It has to be done outside of EnThinnai. If I am going to share contact information only to identified persons, what good is it a third person finds out where my contact page is located? I suppose I could make one of the contact information public to the whole world. But that is not what we do in EnThinnai.

Of course there is one fundamental difference. I surmise from Dan’s comment FWD is planning on a central gatekeeper; we plan to license the software that can be installed in distributed servers. We truly believe that there is no need for a Middle.

However, Google’s revenue represents less than a third of what the declining telephone directories generate in the U.S. alone. Riches await the infocom company that achieves gatekeeper status for the Internet’s communications applications.

Let me repeat for emphasis. He thinks that there is an opportunity for a gatekeeper in IP Communications. EnThinnai is betting against that.

Dan suggests that traditional directories and their online versions can not handle currently available multiple communication modes. So he suggests that the optimal solution is “a user-generated directory in which individuals own and update their own listing.” EnThinnai, which has been operational for a year, does exactly that. He further states that the access to the directory needs to be restricted. He thinks, “[t]he social directory could implement an invite authentication process like any other social network.” Here again EnThinnai is ahead. EnThinnai users will have the ability to control who can access when and which contact information. However, we disagree that there will be a single or even handful of gatekeepers. We are striving to provide a mechanism for each individual to run their own EnThinnai and control their own directories. We do not just mouth “Intelligent at the End” mantra; we believe in it.

… [they] have made big press announcements about their support for OpenID, but haven’t done enough to actually implement it. … Putting my conspiracy theory hat on, it looks to me like these companies want all the positive press that comes from adopting this open standard, but none of the downside. … It’s all gain, no pain.

Even though he quotes Bill Washburn, the Executive Director of OpenID Foundation and David Recordan, the Vice Chair of OpenID Foundation, he uses their equivocal remarks on this matter to admonish these companies “to do what’s right for the users and fully adopt OpenID as relying parties.” I, as an interested person in being a Relying Party, don’t agree with his analysis and for that matter do not share the general perception of the benefits of OpenID.

First a cheap shot: Michael, there are no downsides in being a Relying party and there are no pain points. If anything, OpenID simplifies the lives of Relying Parties. More seriously, the confusion is created by OpenID proponents themselves because they highlight unrealistic benefits.

A relying party that has decided to accept OpenID has no obligation to accept ID issued by one and all ID providers. For example one of the stated reasons for Sun to issue OpenID to its employees is that retailers who would like to give discount to Sun employees can use Sun issued OpenIDs as verification of employment. So it is conceivable that a retailer may decide to accept OpenIDs issued by Sun and nobody else. OpenID is a “Passport” and not a “Visa”. One of the implied casualties is the possibility of Single-Sign-On.

Secondly, there is a general perception that registration procedure is simplified because the Relying Parties could collect profile information from the ID providers. Even though the protocol allows for this exchange of information, there could be external reasons for Relying Parties to explicitly collect them from their users.

These are the top two claimed benefits of OpenID. But many of the OpenID proponents do not emphasize the real benefit of OpenID. We all the time joke that “in Internet, nobody will know you are a dog”. So if a Relying Party is interested in serving senior citizens, then it can look for an opened issued by AARP. If a social network meant for middle schoolers, then it can look for an OpenID issued by school districts. This is the benefit of OpenID. So as a proponent of OpenID, I would like to lobby AARP, AAA and school districts to issue OpenID to its members/students. Then as a Relying Party I will be able to target services to the appropriate audience.

Now let me defend the actions taken by the big Internet companies. As I reasoned earlier, it is not against the protocol for a company to only issue OpenIDs and not accept from others. It is not even detrimental to wider adoption of OpenID. Just this morning Alec Saunders (most assuredly a friend and a well wisher) discussed Michael’s post in his daily Sqwakbox. There he mentioned EnThinnai and laments that one of the reasons he is not trying it out is that none of his friends have OpenID. This suggests that as a Relying Party, I will benefit enormously if the Big Internet companies issue OpenID to their members and raise general awareness. What will be my benefit that they also accept OpenIDs from others? I am afraid not much. On the other hand if they talk up OpenID and people have general exposure to it then Alec will not have his reservation. So I would rather advocate the big Internet companies to educate their members of OpenID rather than expend my goodwill on them accepting OpenIDs issued by third parties.

I am passionate about the objectives of EnThinnai and it is not viable without the services of OpenID. I do not care so much as whether other sites accept OpenID or not; but it is imperative that there are enough OpenID issuers and that Internet users have pocketful of OpenIDs so that any two Internet citizens will have a mutually acceptable ID providers.

So if you are an OpenID proponent then i urge you to do the following:

1. Ask any and everyone who provides authentication services to issue OpenID.
2. Ask Internet citizens to amass as many OpenIDs as possible.
3. Give visibility (not suggesting you heap praise, but offer an objective review) to budding Relying Parties. This is from a personal hurt. Here is EnThinnai, whose service objectives are viable only with OpenID. But not a single OpenID proponent has analyzed or discussed EnThinnai. But there is no end to people talking about Plaxo et. al. who don’r particularly require all that exposure.

It also points to the adoption dynamic for relying parties: companies that believe to be the “gorilla” in their respective markets will push their business partners to accept OpenIDs from them, and preferably only from them. That will look like many closed federations for some time, but it’s inevitable that those will get opened — relying parties will see to that. This OpenID provider rush, and the push into closely affiliated relying parties, are going to be the primary business dynamics for OpenID for the next 18 months or so, in my view.

This is interesting because I am of the opinion that from the beginning the Relying Parties are in the driver’s seat as they get to decide which OpenID providers they will accept. That is why I am expecting OpenID providers to come up with some differentiating features. For example, Vidoop offers a revenue sharing plan for the relying parties. OpenIDs provided by Sun assures the relying parties that they are dealing with Sun employees. As I suggested in the previous post, schools can issue OpenIDs to its students. OpenID becomes useful if the OpenID providers mediate and help the Relying Parties to overcome the Internet dog problem.