[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-sx] new WS-SX work item for discussion
First of all, thank you for your comments. As to the descriptive language focusing on the health care application, we are open to re-shaping the content of this document into something more suitable to the topic of WS-Trust. Your other comments are all good corrections. As to providing more information on section 4.1.4 we will draft a more complete reply this week. We hope to impart a good understanding of the exchange so that we can use your experience in WS-Trust to optimize the exchange of information in our profile.
David Staggs, JD, CISSP (SAIC)
From: Greg Carpenter
I looked through the attached Trust profile. Here are some initial comments.
A lot of the document describes aspects of the health care application that are not directly related to use of WS-Trust. Most of that information is useful for putting the Trust profile in context but I’m not sure that an XSPA WS-Trust Profile is the best place for it. I assume this level of understanding of the health care application would be equally useful to XSPA profiling efforts other than WS-Trust. It might make sense to factor the “end-to-end” application description out into a separate document that could motivate, and be referenced by, the XSPA profiles.
Regarding section 4, which does delve specifically into WS-Trust:
section 4.1.4: Request/Reponse – Cross Enterprise Patient lookup.
Patient search across enterprises may only require a coarse grain approach to authorization where an access control decision can be made without the evaluation of subject attributes. In this case the responders services interface may execute the lookup without having to interact with the ACS this a result of trust between two STSs.
In order to understand this better I’d like to see what trusted data actually drives the access control decision at the service interface.
line 417 Request
Line 417 indicates the following sections will describe a “request” but is immediately followed by an example of a WS-Trust Request Security Token Response. This caught me by surprise. I expected this section to show the RST as well as the RSTR.
Line 513 Response
This section appears to describe the content of an application response (patient record). If there is some important relationship between the Trust protocol exchanges and the application response payload that requires the application response be described here, that relationship should be made clear. Otherwise I think this section could be safely removed (see my general comment above)
Section 1.1.1 Request / Response – Medical Record Access
Sane issues as with section 4.1.4 above. The description of the “Request” starts with an RSTR and the RST is not described. In this case, the application(?) level response is absent.
Section 4.1.6 Masking of Clinical Data
“The response in this case will need to contain an obligation defining which object must be hidden from the requesting user. The consuming ACS and its service interface must enforce this obligation”
What response is this section referring to? Is the application-level response, or the WS-Trust RSTR?
Section 4.1.6 Enforcement Cross