Update Authorization description to allow authentication

[pierre-bouffort]

Explain pull request

In the Policy API section, this PR updates the Authorization description to allow for authentication when use-cases justify it.

Is this a breaking change

• No, not breaking

Impacted Spec

Which spec(s) will this pull request impact?

• policy

Additional context

Relates to #915

[CLAassistant]

All committers have signed the CLA.

[schnuerle]

Adding @geneorama's detailed and valid points from the Issue here:

Capturing some arguments against allowing authorization:

• Providing a provision for authorization risks casting it as "should" have authorization
• Adding authorization adds another layer of maintenance
• Adding authorization adds a barrier for would be civic developers in the public, who (assuming there is a process for obtaining keys) are faced with navigating a system that is opaque and bureaucratic, and may not be supported across administrations

If it's used during development a temporary measure, it is exceptionally risky that the service will never be open:

• A service can't be properly tested in development without authentication because it would require significant changes to the changing the code base
• Funding will almost certainly be reluctant to cover development work to remove authentication once a project is complete
• Fundamentally if a service is to be open, then it needs to be designed and tested in the open form.

There ways to address many, if not all, of the justifications for authentication

• Use IP whitelisting for pilots
• Require vendor identification for API calls
• Provide and require use private codes for requests to avoid spoofing, if that is a concern
• Employ security and load balancing systems for the open API just as you would any other open API