Authorities are identified while assertions are created.
Their authority is derived from the organization, usually through the organization chart. But the list of authorities in an assertion model is not the org chart.
However if an organization is implementing an assertion model a mapping to the org chart is required. In fact it is part of the implementation. If your organization is not going to take on the responsibilities defined by the AM then you are not implementing the business described by the assertion model.
The responsibilities for an authority are clearly stated in its assertions. In fact they can comprise the job description. Building an assertion model is organizational design.
Assertions are wide ranging, from occasional governance and managerial assertions to automatic, operational assertions implemented in code. So the scope of Authorities is wide ranging. It can be a CEO expressing the organizational vision to the calculation of tax by the system defined by the Sales Manager.
Authorities do not imply one person. A number of employees can be assigned an authority, either shared, or divided by time or subdivided by workload.
Effort for an authority can be determined from the authorities they are responsible for. Those assertions include time effort and repetition over time. The sum of these values gives an overall approximation of yearly hours for the authority.
When assertions are implemented within an environment the access to this implementation for the person holding the authority must be available.
Dual nature of auth
