There are whitelists motivated by business interoperability, i.e. those providers with which the list maintainer is willing to participate in federated identity transactions, and there are whitelists motivated by protocol interoperability, i.e. those providers with which the list maintainer is able to participate in federated identity transactions.
As an example of the first sort of whitelist, Japan's Pookmark social bookmark service lists the OPs it will accept assertions from. While some believe that doing so is counter to the OpenID philosophy, the fact remains that RPs can always choose to do so (and will, as long as there are no other assurance mechanisms by which they can control their perceived risk).
As an example of the second sort of whitelist, Clickpass lists those RPs that work with the Clickpass service. While there may be some business relationship between Clickpass and these RPs, the fundamental criteria for inclusion on the list is that the RP supports Clickpass's proprietary message API.
Standards are designed to make the second sort of whitelist as large as possible, thereby allowing providers to focus on the first.
Perhaps there is a third type of whitelist? Merely implementing the same identity protocol by two parties may be insufficient to guarantee that that they can do business. Flexibility in the protocol specification, inevitably interpreted differently by different implementations, means that a more meaningful whitelist is to track providers with which you have deployment interoperability.
No comments:
Post a Comment