OK. An API is not necessarily for external apps.
I think it would be excellent to implement an LDSAccount OpenID or OAuth server (it's a freebie if they'd use OpenAM instead of Oracle's products). One of the interesting things with OAuth is the API Key. Every application requires a key to use the service. Then, there would have to be some kind of provisioning process to give Keys to the various applications. tech.lds.org would get one, and cdol.lds.org another. lds.org/directory would have one, and lds.org/calendar would have another. Mormon.org would have one, and MormonChannel.org would have another.
The problem with WAM, is that it requires that all websites be on the lds.org domain. Mormon.org, MormonChannel.org, MormonNewsroom.org, FamilySearch.org, and I'm sure many other future internet properties do *not* make sense as part of lds.org. They are unique, and require their own domain. However, that means that every time a new site is launched outside of lds.org, they have to re-implement the authorization+authentication system. It involves creating yet another direct connection to the LDAP directory where LDSAccount information is stored. Every link to that LDAP directory, the central system, opens additional security risks that could be mitigated if a separate--but central--auth server were employed.
As it is, every time another website is launched outside of lds.org, the LDSTech community *cannot* participate in the development of that website, because it includes code that directly accesses the LDAP directory. The application itself must accept usernames and passwords, acting as an authentication proxy to pass the credentials to the LDAP server. If, however, a separate OpenID and/or OAuth server were added to the authentication/authorization stack, then *ALL* of those applications would be more secure. That way, each application would send the user to a login page (similar to the current lds.org login) that would interact *only* with the Auth server. The Auth server would verify identity and then send the user back to the requesting application/website. The Auth server would provide that site with any required authorization parameters, including active unit numbers and callings. And then the application can go on its merry way, serving the user the appropriate content, without ever being exposed to the password.
As it is, if a malicious community member were to participate in the development of a site like mormon.org (there are no current community projects), they could add some evil code that could intercept any passwords and send it off somewhere else. It's awesome the tech.lds.org is finally using the WAM system, because, before, it was susceptible to this type of attack.
Now, I have not heard of any malicious community members. However, I understand the security implications of community participation, and so it baffles me when there is so much internal resistance to the idea of having an Auth server. I suspect that these internal folks (I don't know who) simply do not understand the power of volunteer work, even though this church gets so much done through a lay ministry. I support whatever the 70s in charge of this project feel is best. I just wonder if anyone's taken the time to explain the benefits of such an Auth server.
None of what I've said applies to 3rd party apps. It's conceivable that Deseret Book could apply for and receive an API Key and perhaps authenticate people with LDSAccount. Perhaps other 3rd parties will be able to as well in the future, BUT, that depends on policy and nothing else. An Auth server that relies an API Keys to allow/disallow specific applications--just like the Google Maps API, or the Facebook API, or any number of other APIs--is not required to give keys to any applications. I expect such a server would be used for official internal church projects (that hopefully also include the LDSTech community). If, and when, such a policy allows third party developers to use LDSAccount, then I'm sure thought will be invested in how to do so without exposing inappropriate data. Until then, I wish that such an auth server were at least available for internal projects.
To any employee that might be reading this, and knows who to talk to to get such a server approved I have this to say: "Please! Pretty, pretty please! With a cherry on top!
These are my thoughts and opinions and do not represent the thoughts or opinions of anyone else, including the church, LDSTech, any church employees, etc.