Who own's the parent work item

The PBI is assigned to the entire Scrum Team as everyone is responsible for the value it provides. If I were the one involved in this as a Scrum Master, I would take this as a coaching moment to help everyone understand and appreciate that concept.

What purpose does assigning stories provide? Why do you have to assign anything?  Can't the Development Team discuss who is working on what in the Daily Scrum and not assign tasks in VSTS? The team should agree that the story is done based upon the acceptance criteria provided with the story statememt. And who is actually assigning this work?  

It has been a while since I used VSTS but I don't remember that you have to assign tasks or stories.  So you should be able to complete all of the work without assigning anything in the tool. 

We / our team seems to have differing opinions on on who is assigned the Product Backlog Item.

Who has it to begin with?

I've run into this situation quite often, as most tools (VSTS now Azure Devops, Jira, etc) have a mechanism for assigning tasks.

The short answer is that it doesn't matter who is assigned the task, so long as it works for the Development Team and that they understand the boundaries of Scrum.

One of the largest risks in adding assignees is causing confusion between assignment (who's name appears next to a work item in a visual tool) and accountability (who is responsible for the work?). The Development Team needs to understand that the Scrum Guide is very clear on who is accountable for the work:

Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

If assigning a Product Backlog Item to an individual in any way (implicitly or explicitly) assigns accountability to that individual alone, then it might be best to leave an empty assignee or apply an understood default assignee. I've seen Development Teams decide to assign all items to the Product Owner, the Scrum Master, or even someone outside of the Scrum Team. The teams understood that the accountability to complete each item was held by the Development Team as a whole and not by the designated assignee, of course, but by having a 'known' default there was no temptation to even implicitly hold a specific individual of the Development Team accountable. In this scenario their would often be work items added as "tasks" linking to the PBI that aid the Development Team in planning and managing the work across team members.

I've also seen Development Teams that use the assignee field on the PBI to manage the work across the team. One team member may work on the item for a few hours, for instance, and then assign it to another member of the Development Team later to indicate that the remaining work could benefit from their skill set.

What I would recommend is to ask the Development Team to look at the trade-offs and the value that each path brings in both executing the work and supporting the Scrum framework. The Development Team can then make the decision and, if they ever find upon inspection that the chosen course is contributing to a misunderstanding of accountability, they can make the decision to adjust course.