The relevant Story for Artisan being able to update an Artisan's data, from the earlier collection of stories is:

• As an Artisan, I need to be able to update my own Artisan object so that I can manage my information at the HMS Central Office.

No matter what the eventual shape of the processes surrounding the queue_id and signing_key properties of an Artisan turns out to be, those values, as secrets, should never be sent across the open internet without some protection—encrypting them while in motion, at a minimum. Without those values, changes to Artisan data by Artisan users can travel unencrypted, so the base message structure for Artisan updates is nearly a duplicate of the equivalent in the Central Office's namespace:

    def to_message_data(self) -> (dict,):
        """
Creates and returns a dictionary representation of the instance 
that is safe to be passed to a DaemonMessage instance during or 
after creation as the data of that message.
"""
        return {
            'oid':str(self.oid),
            # - BaseArtisan-derived items
            'address':self.address.to_dict() if self.address else None,
            'company_name':self.company_name,
            'contact_email':self.contact_email,
            'contact_name':self.contact_name,
            'website':self.website, 
            # - BaseDataObject-derived items
            'created':datetime.strftime(
                self.created, self.__class__._data_time_string
            ),
            'modified':datetime.strftime(
                self.modified, self.__class__._data_time_string
            )
        }

Between the Central Office and Artisan code-bases, we're allowing either user type to alter most of an Artisan's data. The majority of it is some variation of contact information, none of which has any functional implications, and the balance has policies that have already been set down, if not implemented yet (oid), or is still pending further definition (queue_id and signing_key). The worst risk that seems even remotely likely with both user types having full control over these properties is either simultaneous conflicting changes (probably best handled at the UI level), or ongoing conflicting changes (one user changing a value, the other changing it back, the first changing it again, and so on).