Page 1 of 1

A LDS Account API would be great.

Posted: Sun Jul 08, 2012 7:51 pm
by moonman239
I was just browsing LDS.net. I thought to myself, "It would be great if I could use my LDS Account instead of creating an account on the forum."

Think of the possibilities:

1) The administrator of an LDS forum can use the LDS Account system to determine whether someone is a member or not.
2) The senior patrol leader or troop historian can create a blog and allow the leaders and/or youth to contribute to the blog using their LDS account.

Posted: Sun Jul 08, 2012 8:19 pm
by russellhltn
It has been proposed before. As far as I can tell, the church has absolutely no interest in authenticating members to anyone outside of the church. It may even run afoul of local privacy laws.

Posted: Sun Jul 08, 2012 8:53 pm
by moonman239
RussellHltn wrote:It has been proposed before. As far as I can tell, the church has absolutely no interest in authenticating members to anyone outside of the church. It may even run afoul of local privacy laws.

I can see that there are risks associated with allowing such access. For example, someone's account could be compromised or the Church could be negatively affected by a post someone makes using their LDS account.

To mitigate thoe risks, the Church could implement a policy regarding how the LDS Account system is to be used. For example, they could require that the LDS Account system be used only in a religious forum or quorum/Scout unit/ward/stake blog. They could also require that the app obtain permission from the user, just like a Website with a Facebook login needs permission to access the user's profile.

I have a question. How would it violate local privacy laws? By using the LDS Account on a third-party Website, the user is authorizing the Website to use information from their LDS Account.

Posted: Sun Jul 08, 2012 11:22 pm
by russellhltn
moonman239 wrote:I can see that there are risks associated with allowing such access.
Question - what benefit to the church would there be in that? I can't think of any. In fact, it would probably promote members being more insular instead of being examples to non-members. I don't see how the church has any interest in helping, say, lds.net run their site.

If there is risks and no benefit to the church, then this idea will end up at the bottom of the priority stack.
moonman239 wrote:I have a question. How would it violate local privacy laws? By using the LDS Account on a third-party Website, the user is authorizing the Website to use information from their LDS Account.

I was thinking along the lines of the church disclosing membership against the member's wishes. Since they are using the LDS Account, it might not be a problem. But then there are many different laws in different countries.

Posted: Mon Jul 09, 2012 3:00 pm
by cognifloyd
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.

Posted: Mon Jul 09, 2012 4:11 pm
by russellhltn
Unless I've missed something, this thread is focused on allowing 3rd party websites to use LDS Account authentication. (Which frankly I don't see happening.) What is the best technology for the church to use for their various websites (including subsidiaries) is a different matter.