You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
This is an outcome of the work on the Topologies Whitepaper.
This option allows a directory to support multiple perspectives, by explicitly defining which Endpoint resources are available to be used by particular clients of the directory. Note that this is informational, not a security mechanism; ultimately Endpoints and the resources they serve are protected through security mechanisms such as TLS, PKI, SAML, and OAuth.
Without this option, a community will need to externally specify policy or configuration if it needs to communicate constraints on the use of Endpoint resources in its directory.
Describe the solution you'd like
A client can tell exactly which Endpoints in a directory it is eligible to use. Ideally we would design this in a way where it could be incorporated in a directory not utilizing mCSD in its entirety.
Is your feature request related to a problem? Please describe.
This is an outcome of the work on the Topologies Whitepaper.
This option allows a directory to support multiple perspectives, by explicitly defining which Endpoint resources are available to be used by particular clients of the directory. Note that this is informational, not a security mechanism; ultimately Endpoints and the resources they serve are protected through security mechanisms such as TLS, PKI, SAML, and OAuth.
Without this option, a community will need to externally specify policy or configuration if it needs to communicate constraints on the use of Endpoint resources in its directory.
Describe the solution you'd like
A client can tell exactly which Endpoints in a directory it is eligible to use. Ideally we would design this in a way where it could be incorporated in a directory not utilizing mCSD in its entirety.
We should make the codes normative that were created in the Topologies whitepaper: HIEInitiator, HIEResponder, PartnerConnectivity, and define an option that makes use of these.
Describe alternatives you've considered
See scratchpad from the Topologies Whitepaper: IHE/ITI.Topologies@cc09b25
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: