This is a framework API implementation for Identity technology (similar to Java framework APIs like JDBC, JMS, etc) which will allow people to provides plugins to their respective systems (just like database vendors provide JDBC implementations or MOM vendors provide JMS implementation) which can perform the following functions on the specific implementation of the application (like LDAP, Email Server, ERP system, Network Access Control systems, etc) -
- Authentication of credentials for access - this means that the framework would provide APIs (guess better than JAAS??) to allow framework users to pass the user identity and password and thus authenticate the user to the framework. So basically the idea being that just to use the services you will have to authenticate at the system level.
- Authentication of each facet within the context - which I guess means that any "Higgins" enabled system (i.e. system for which the "plugin" is available) will provide interface to accept the credential provided by the caller through framework and return whether the authentication against that "Higgins" enabled system was successful.
- Authorization of access to facet profile data using role-based access control lists - so based on RBAC List (which roles- framework or "Higgins" enabled system??, what granularity of access control, is there are rule based access control, why not MAC) the "authenticated " user (guess authenticated against the framework or "Higgins" Enabled system) would be able to view and edit his or somebody else's Identity data (which will consist of what? - name value data pairs, binary photo, biometric data, medical record??).
- Facet search and editing functions - Basically a CRUD +Search functionality for IDentity and associated data (the Creation and Deletion function is not explicitly said to be part of the system, what gives??)
- Support for adding tag properties to facets and on the links between facets - what is a tag property? Where is information on link between the facets (identity) stored? Is it something like random schema extension i.e. for example the system supports just User ID, password, comments, homedirectory but even then the "Higgins " enabling of the system would require it to support any generic data which a user would like to associate with the identity of the system (like an account GUID or telephone number). Doesn't this requirement seem to be too wierd or did I get it wrong? Hopefully the framework itself would provide services which "Higgins" enabled system's plugin can leaverage to store the data.
- Replication/distribution of context data to Higgins clients - Hmm.. seems close to the idea of data synchronization which is very popular in the provisioning world.
- Synchronization of context data - Well I am not sure how the "Higgins" Enabled system can provide such facility. The basic facility would most probably be provided by framework and the system's plugin would need to provide the capability to perform bulk identity data extraction or retrieve incremental changes.
- Persistence and encryption of context data - Last but not the least security is important w.r.t. to identity data, but how can we expect legacy systems to provide encryption capabilities. But I am assumming it would be more like an option available if provided by "Higgins" enabled system.
Higgins & Infocard
Now lets try to analyze how this framework and Infocard work.
- Infocard as I understand is a desktop technology which allows people to manage cards (self-issued or thirdparty issued containing Identity and associated data) on their desktops. So, it seems that the concept of context matches Identity Provider while facet seems to match the concept of card. (Am I trying to over simplify here?). The "Higgins" framework seems something that can be leveraged on both client and server side but assuming it being part of Eclipse (mostly java), it seems it will find home on server side similar to the diagram shown on the website.
- I am assuming that people would be able to use the InfoCard interface itself to manage the data that is stored on identity providers website. If this is not the case then, I guess, they will have to go to Identity Provider site to do the same work. Incase of "Higgins" integrated clients (if they are present on desktop), the Clients would be able to use the Higgins framework either on the client side or on server side (invoked through webservice) to perform the same operation. Does that mean Higgins would be the alternative to Microsoft products on server side to get the same job done? Seems like Eric came to same conclusion.
- Infocard seems to be a technology on the desktop which will be integrated with Internet Explorer (and may be Firefox and other third party application) to generate the authentication credential for a specific website which will be used by website for authentication. Now this component of being able to generate Token seems to be completely missing from the Higgins (did I miss something??). May be I am being completely naive here but I see some humor in the thought that Higgins a trust framework would not support something similar to WS-Trust :)