How does a client determine which security protocols/standards/etc. a server supports

[pvretano]

From teleconference 12-FEB-2018:

• discussion between Peter and Chuck about security
• Chuck mentioned that the support path of geoapi security (i.e. OAuth and https) is not sufficient in a number of cases
• Peter asked what is the basic issue
• Chuck mentioned that there is no mechanism to allow a client to determine from the server what security protocols/standards/etc. are supported
• this is related to the TB12/TB13 work of putting this information in the capabilities document
• Peter thought that a new access path, something like /api/security could be used as an end point to get this information
• Chuck confirmed that there are no standards in this area yet but that he, in cooperation with others, is working on something

[cportele]

+1 to adding /api/security or similar in an extension, in case the OpenAPI security scheme declarations are not sufficient for common use cases.

Maybe this should then also be raised at https://github.com/OAI/OpenAPI-Specification/issues since this does not sound like a geo-specific requirement and would best be addressed by ICT standards, not by OGC standards?

[cmheazel]

Already done. See OAI/OpenAPI-Specification#1004 for part of the discussion. A number of other issues touch on updates to the security declarations as well. I have been working on a set of requirements based on the U.S. NIST taxonomy of security controls. Next step is to try to pull all of these issues together into a viable proposal. Frank Terpstra is playing as well so we can tag-team.

[cmheazel]

It appears that all of the security schemes commonly used by OGC implementations are supported by OpenAPI. Recommend closing this issue. Specific deficiencies in the OpenAPI Security Schemes should be tracked through their own issues.