mkmurray wrote:I'm not sure I understand your expectations for how these web services are to be secured. How do you propose securing the web services beyond the LDSAccount credentials so that only community projects would have access? I suppose some kind of public shared key and private key thing could be used like is used in many encryption algorithms, but I don't understand the necessity.
What is wrong with relying on LDSAccount credentials? It has sufficient membership info and calling info associated with it on the Church's servers so as to make the right decisions about who to authenticate and what type of data to authorize the requester to have. What am I missing? Please explain further.
My assumption governed by two things:
First, I and others understood that a big part of the rationale for migrating apps to web services from MLS exports was to bring the applications such as Ward Tools inside the Community tent for enhanced security and centralized official control. I know that hearing that case was part of what persuaded Ward Tools developers to hand over their product to the Church and work inside the tent instead.
Second, there obviously has been a higher level of safeguard imposed on the MRN recently. It has been dropped from the MLS exports, even though those exports already require the highest level of permission inside MLS under local priesthood control. Also, the MRN has recently been dropped from the LDS Account-authenticated download of the geoceoded membership records available to ward leaders. From this and what comments have been made by Church employees on this forum I gather that for policy or legal reasons it is no longer considered reliable to trust local priesthood leaders to download this particular data element, only to view it. While I think that is lamentable, I am seeking to honor that principle while ensuring that these leaders at least regain view-access to the MRN (and any other data element considered this sensitive in the future) in the expanded version of LDS Tools. If the API is not locked down, then the data is effectively just as exportable as it used to be from MLS or maps.lds.org, so the same general privacy concern might force such data to be dropped altogether. I would much rather see the API restricted than to have local leaders denied access to view the data in the future LDS Tools. As local priesthood leaders have lost access to the MRN in Ward Tools (and I presume other third-party products) this crippling has already hurt the users. These priesthood leaders need a secure way to capture the data on their handheld app.
As for the question of how this might be done, I am aware that it would not be easy to lock down the API in an absolutely bulletproof way so that approved clients could never be spoofed, sniffed or reverse-engineered. But some kind of handshake, perhaps involving public-key tokens to help enforce some legal license and policy, would be much better than nothing. As my grandfather used to say, a good lock will keep an honest man out. The goal can be to prevent priesthood leaders from inadvertently running some tool to export the sensitive data, or be taken advantage of by third-party developers who do not honor policy unless they are compelled to do so.