MOVED TO NEW LOCATION
Use Case Examples
A company already uses a SaaS vendor like Salesforce, Microsoft's hosted Exchange, Google Apps, etc. The company wants to build a custom IT app on a PaaS/IaaS environment like Force.com/Azure/GoogleAppEngine/AmazonWebService. The IT app needs to have access to some data about the company's employees such as office location, manager, department, spoken language. If such an app were built on-premise it would normally get that information from an on-premise LDAP server. So the company would like their SaaS vendor to provide an equivalent CloudLDAP service to expose that data.
That same company has subscribed an Enterprise SaaS service that managers their corporate gift matching service. That service needs to know the salary, office location, & manager of each employee so it knows what level of gift matching the company allows, and in which cases a manager's approval is needed. Currently the company's HR department uploads a spreadsheet file manually to that SaaS vendor with this information every Friday. The company would prefer to have a central SaaS vendor store that information in a CloudLDAP service and enable specific other SaaS vendors to access it. However the company wants to closely control what LDAP fields the SaaS vendor can read.
The company has subscribed to another Enterprise SaaS service that tracks desk locations for all their employees because desk moves happen so frequently. Currently the company's HR department downloads a spreadsheet file manually from that SaaS vendor with this information every Friday which is then manually uploaded into the corporate HR system which in turn syncs with an on-premise LDAP server. The company would prefer to have a central SaaS vendor store that information in a CloudLDAP service and enable specific other SaaS vendors to access it. However the company wants to closely control what LDAP fields the SaaS vendor can read and which ones they can write.
In examples 2 and 3 the specialized Enterprise SaaS vendor would like to avoid have to write one-off code for different CloudLDAP type services, and would instead prefer an industry standard. Even in example 1 the IT developer would like to use common client-libraries to access the CloudLDAP service.
Technical Issues
REST+OAuth: The market appears to strongly prefer a REST based solution for this LDAP API that uses OAuth (primarily "2-legged-OAuth") for API security
Custom XML: The market does not appear ready to pick a specific data format for data collections such as ATOM/GData/OData, nor is the market ready to completely move to a non-XML data formal like JSON. While those things might happen in the future, the market appears to prefer a one-off, simple, optimized, XML data format
PortableContacts: The PoCo standard is the most frequently referenced exaple of such a one-off, simple, XML data format. In addition, PoCo is already designed to returns sets of "users" and meta-data about users, so that is probably a good starting point. Individual service providers can choose to support multiple other formats (JSON, OData, GData, etc.) but will hopefully provide well defined mappings of fields to the common standard
LDAP: The market clearly wants well defined fields where possible, with well defined mappings to common LDAP fields such as location, manager, etc. So we should probably look at PoCo fields and LDAP fields and see how to build from there
Query features: LDAP queries can be very complex, but most queries can be supported just using exact field matches, possibly AND'd together. Individual service providers can obviously provide additional support for more complex queries.
Update technique: It is probably acceptable for the standard to support a lowest-common denominator update approach where the API caller must send their "current view of the object" plus the new fields values they want to change. If the CloudLDAP server finds the "current view of the object" is out of date, it will fail, otherwise it will perform the update (assuming an ACL/authorization check is passed)
No push based notifications of changes: It appears sufficient to require API callers to pull down updates as opposed to define a push based system that notifies a client-system about updates in the CloudLDAP server. Individual service providers can obviously add on notification schemes as a value add.
Basic provisioning: A CloudLDAP service also has high overlap with basic user provisioning which allows an application (either an IT app or SaaS vendor) to download (or update) a list of current/new/ex employees as well as group membership.
ACLs: Some CloudLDAP service providers may only support read access to attributes, but we should define a standard approach with OAuth for a specific client app to authenticate itself to a CloudLDAP server in cases where the CloudLDAP server supports more complex ACLs.