CapabilityStatement security options

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Not Persuasive
    • Priority: Medium
    • FHIR Core (FHIR)
    • STU3
    • FHIR Infrastructure
    • Normative
    • CapabilityStatement (Conformance)
      • You can talk about multiple services since CapabilityStatement.rest.service is 0..*
      • Security around messaging is likely to be deal with outside of CapabilityStatement, and is part of ongoing trial use.
    • Grahame Grieve/John Moehrke: 11-0-0
    • Enhancement

      Seems a FHIR Server could offer multiple security models... Thus wouldn't the CapabilityStatement.rest.security need to be 0..* with each having a security service type, and associated other elements?

      Also, why is this not in the messaging section? Messaging woud be more critical to know as most security models around messaging don't have inline negoations (where most RESTful models leverage TLS an OAuth ability to negotiate). Yes, messaging can use these inline negotiations, but are often asynchronous and not able to leverage inline negotiations.

      I recommend the security section be promoted to the root of CapabilityStatement and be 0..*

            Assignee:
            Unassigned
            Reporter:
            John Moehrke
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: