1

2 Telecom SOA Requirements Version 1.0
3Committee                 Draft 01
416     February 2010
 5
 6Specification URI...
42
43
44Status:
45        This document was last revised or approved by the OASIS SOA for Telecom (SOA-Tel) TC on
46      ...
58Notices

 59Copyright © OASIS® 2009-2010. All Rights Reserved.
 60All capitalized terms in the following text have the m...
103Table            of Contents
1041   Introduction..........................................................................
146    4.1.1 Identification of Use Case Text.................................................................................
165Table          of Figures
166
167Figure 1: Example for SOAP nodes interaction (1).........................................
1731    Introduction
174
175Part of the work being undertaken by the OASIS SOA-TEL TC is to understand how SOA-related
176...
2151.2 Normative References
216    [RFC2119]                   S. Bradner, Key words for use in RFCs to Indicate Requireme...
2602    Requirements on Intermediaries Handling
261
262This section gathers a collection of requirements related to the sa...
299In complex scenarios involving more than 3 nodes, the generic node N that receives a message may not
300be conscious of...
340

               Node_1                Node_2



               Node_n                N._n-1




341
342               ...
356

               Node_1                Node_2             Node_i          N._i+1



               Node_n              ...
370

              Node_1                 Node_2             Node_i          N._i+1



              Node_n               ...
405
406Conversely, the NotificationProducer must able to send a notification addressed to a
407NotificationConsumer to an ...
452
453The syntax of the subscription request and that of the notification should be extended so that it becomes
454possib...
464
      <s:Envelope ... >
        <s:Header>
          <wsa:Action>
             http://docs.oasis-open.org/wsn/bw-2/Int...
469
470
      <s:Envelope ... >
        <s:Header>
          <wsa:Action>
            http://docs.oasis-
      open.org/ws...
475
      <s:Envelope ... >
        <s:Header>
          <wsa:Action>
             http://docs.oasis-open.org/wsn/bw-2/Int...
483In this way the subscriber could specify both the NotificationProducer and the NotificationConsumer as
484final destina...
491As a consequence, the NotificationProducer knows the endpoints of the NotificationConsumer and of the
492intermediary t...
4972.3 Requirements on SOAP

4982.3.1 Identification of Use Case Text
499Extract from [SOA-TEL 1.0] (rows 405 to 414):
500...
538To the best knowledge within OASIS SOA-TEL TC, the requirements presented hereafter could be
539addressed by the W3C “X...
560Moreover, table 3 in section 2.7.1 should be modified as follows:
561
                   Table 3: SOAP Nodes Forwarding...
5633    Requirements on Security
564

5653.1 Requirements on Security Token Correlation

5663.1.1 Identification of Use Ca...
598[WS-S 1.1] defines three types of security tokens and how they are attached to messages (“user name
599token”, “binary ...
626the timestamp value present in the security header from which the related token derive. Examples of
627other significan...
654In this case a new AssociatedToken element could be added into the SAML syntax, so the related token
655could be includ...
User                                               SP                                             IdP
            Device

...
711a backchannel) a message to the IdP indicating that from now on the IdP should use the “real identifier”
712instead of ...
756                              Format="urn:oasis:names:tc:SAML:1.1:nameid-
757                              format:unspe...
7983.3 SAML Attribute Management Request

7993.3.1 Identification of Use Case Text
800Section 5.3.2 in [SOA-TEL 1.0] descr...
User                                   Service                            Identity
          Device                       ...
854                  <saml:NameID
855                            Format="urn:oasis:names:tc:SAML:1.1:nameidformat:X50
856 ...
896         IssueInstant="2006-07-17T20:31:40Z">
897         <saml:Assertion
898                  MajorVersion="1" MinorVe...
938                                      </saml:AttributeValue>
939                             </saml:Attribute>
940     ...
975
 976To the best knowledge within OASIS SOA-TEL TC, the requirements presented hereafter could be
 977addressed by the ...
1006in the present document. Thus a common approach in modifying the WS-Security specifications could be
1007adopted to ad...
10084        Requirements on Management
10094.1 Cardinality of a Service Interface

10104.1.1 Identification of Use Case T...
1033
1034
1035                                     Figure 6: TM Forum SDF Reference Model

10364.1.3 Description
1037As do...
t-soa-req-01-cd-01.doc
t-soa-req-01-cd-01.doc
t-soa-req-01-cd-01.doc
t-soa-req-01-cd-01.doc
t-soa-req-01-cd-01.doc
t-soa-req-01-cd-01.doc
t-soa-req-01-cd-01.doc
t-soa-req-01-cd-01.doc
Upcoming SlideShare
Loading in...5
×

t-soa-req-01-cd-01.doc

593

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
593
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

t-soa-req-01-cd-01.doc

  1. 1. 1 2 Telecom SOA Requirements Version 1.0 3Committee Draft 01 416 February 2010 5 6Specification URIs: 7This Version: 8 http://docs.oasis-open.org/soa-tel/t-soa-req1.0/cd01/t-soa-req-01-cd-01.html 9 http://docs.oasis-open.org/soa-tel/t-soa-req1.0/cd01/t-soa-req-01-cd-01.pdf (Authoritative) 10 http://docs.oasis-open.org/soa-tel/t-soa-req1.0/cd01/t-soa-req-01-cd-01.doc 11Previous Version: 12 N/A 13Latest Version: 14 http://docs.oasis-open.org/soa-tel/t-soa-req1.0/t-soa-req-01.html 15 http://docs.oasis-open.org/soa-tel/t-soa-req1.0/t-soa-req-01.pdf (Authoritative) 16 http://docs.oasis-open.org/soa-tel/t-soa-req1.0/t-soa-req-01.doc 17Technical Committee: 18OASIS SOA for Telecom (SOA-Tel) TC 19 20Chair(s): 21 Mike Giordano, giordano@avaya.com, Chair 22Editor(s): 23 Enrico Ronco, enrico.ronco@telecomitalia.it 24Related work: 25 This specification replaces or supersedes: 26 • N/A 27 This specification is related to: 28 • OASIS Telecom Use Cases and Issues Version 1.0 29Declared XML Namespace(s): 30 • N/A 31Abstract: 32 This document is the second deliverable produced within the OASIS SOA-TEL TC and has the 33 objective of collecting requirements related to technical issues and gaps of SOA standards 34 (specified by OASIS and other SDOs) utilized within the context of Telecoms. Such technical 35 issues are documented in SOA-TEL’s TC first deliverable “Telecom Use Cases and Issues, 36 v.1.0”. 37 For each of the issues within the “Telecom Use Cases and Issues, v.1.0”, specific requirements 38 are provided within this document. Where possible, non prescriptive solution proposals to the 39 identified issues and requirements are also described, in order to possibly assist those Technical 40 Committees (within OASIS and other SDOs) responsible for the development and maintenance of 41 the SOA related standards. 1t-soa-req-01 16 February 2010 2Copyright © OASIS® 2009-2010. All Rights Reserved. Page 1 of 47
  2. 2. 42 43 44Status: 45 This document was last revised or approved by the OASIS SOA for Telecom (SOA-Tel) TC on 46 the above date. The level of approval is also listed above. Check the “Latest Version” or “Latest 47 Approved Version” location noted above for possible later revisions of this document. 48 Technical Committee members should send comments on this specification to the Technical 49 Committee’s email list. Others should send comments to the Technical Committee by using the 50 “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/ 51 committees/soa-tel/. 52 For information on whether any patents have been disclosed that may be essential to 53 implementing this specification, and any offers of patent licensing terms, please refer to the 54 Intellectual Property Rights section of the Technical Committee web page (http://www.oasis- 55 open.org/committees/soa-tel/ipr.php. 56 The non-normative errata page for this specification is located at http://www.oasis- 57 open.org/committees/soa-tel/. 4t-soa-req-01 16 February 2010 5Copyright © OASIS® 2009-2010. All Rights Reserved. Page 2 of 47
  3. 3. 58Notices 59Copyright © OASIS® 2009-2010. All Rights Reserved. 60All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual 61Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website. 62This document and translations of it may be copied and furnished to others, and derivative works that 63comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, 64and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice 65and this section are included on all such copies and derivative works. However, this document itself may 66not be modified in any way, including by removing the copyright notice or references to OASIS, except as 67needed for the purpose of developing any document or deliverable produced by an OASIS Technical 68Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must 69be followed) or as required to translate it into languages other than English. 70The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors 71or assigns. 72This document and the information contained herein is provided on an "AS IS" basis and OASIS 73DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 74WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 75OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 76PARTICULAR PURPOSE. 77OASIS requests that any OASIS Party or any other party that believes it has patent claims that would 78necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, 79to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to 80such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that 81produced this specification. 82OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of 83any patent claims that would necessarily be infringed by implementations of this specification by a patent 84holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR 85Mode of the OASIS Technical Committee that produced this specification. OASIS may include such 86claims on its website, but disclaims any obligation to do so. 87OASIS takes no position regarding the validity or scope of any intellectual property or other rights that 88might be claimed to pertain to the implementation or use of the technology described in this document or 89the extent to which any license under such rights might or might not be available; neither does it represent 90that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to 91rights in any document or deliverable produced by an OASIS Technical Committee can be found on the 92OASIS website. Copies of claims of rights made available for publication and any assurances of licenses 93to be made available, or the result of an attempt made to obtain a general license or permission for the 94use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS 95Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any 96information or list of intellectual property rights will at any time be complete, or that any claims in such list 97are, in fact, Essential Claims. 98The names "OASIS", “SOA-TEL” are trademarks of OASIS, the owner and developer of this specification, 99and should be used only to refer to the organization and its official outputs. OASIS welcomes reference 100to, and implementation and use of, specifications, while reserving the right to enforce its marks against 101misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance. 102 7t-soa-req-01 16 February 2010 8Copyright © OASIS® 2009-2010. All Rights Reserved. Page 3 of 47
  4. 4. 103Table of Contents 1041 Introduction..............................................................................................................................................7 105 1.1 Terminology......................................................................................................................................7 106 1.2 Normative References......................................................................................................................8 1072 Requirements on Intermediaries Handling...............................................................................................9 108 2.1 Requirements on Transaction Endpoints Specification....................................................................9 109 2.1.1 Identification of Use Case Text..................................................................................................9 110 2.1.2 Requirement(s)..........................................................................................................................9 111 2.1.3 Description................................................................................................................................9 112 2.1.4 Solution proposals...................................................................................................................10 113 2.2 Requirements on WS-Notification...................................................................................................13 114 2.2.1 Identification of Use Case Text................................................................................................13 115 2.2.2 Requirement(s)........................................................................................................................13 116 2.2.3 Description..............................................................................................................................13 117 2.2.4 Solution proposals...................................................................................................................14 118 2.3 Requirements on SOAP.................................................................................................................21 119 2.3.1 Identification of Use Case Text................................................................................................21 120 2.3.2 Requirement(s)........................................................................................................................21 121 2.3.3 Description ............................................................................................................................21 122 2.3.4 Solution proposals ..................................................................................................................21 1233 Requirements on Security......................................................................................................................24 124 3.1 Requirements on Security Token Correlation.................................................................................24 125 3.1.1 Identification of Use Case Text................................................................................................24 126 3.1.2 Requirement(s)........................................................................................................................24 127 3.1.3 Description..............................................................................................................................24 128 3.1.4 Solution proposals ..................................................................................................................24 129 3.2 SAML Name Identifier Request......................................................................................................27 130 3.2.1 Identification of Use Case Text................................................................................................27 131 3.2.2 Requirement(s)........................................................................................................................27 132 3.2.3 Solution proposal ....................................................................................................................29 133 3.3 SAML Attribute Management Request...........................................................................................31 134 3.3.1 Identification of Use Case Text................................................................................................31 135 3.3.2 Requirement(s)........................................................................................................................31 136 3.3.3 Description ............................................................................................................................31 137 3.3.4 Solution proposal ....................................................................................................................32 138 3.4 User ID Forwarding ........................................................................................................................35 139 3.4.1 Scenario/context......................................................................................................................35 140 3.4.2 Identification of Use Case Text................................................................................................35 141 3.4.3 Requirement(s)........................................................................................................................35 142 3.4.4 Description..............................................................................................................................35 143 3.4.5 Solution proposals .................................................................................................................35 1444 Requirements on Management..............................................................................................................38 145 4.1 Cardinality of a Service Interface....................................................................................................38 10t-soa-req-01 16 February 2010 11Copyright © OASIS® 2009-2010. All Rights Reserved. Page 4 of 47
  5. 5. 146 4.1.1 Identification of Use Case Text................................................................................................38 147 4.1.2 Requirement(s)........................................................................................................................38 148 4.1.3 Description ............................................................................................................................39 149 4.1.4 Solution proposals ..................................................................................................................39 150 4.2 Requirements on Metadata............................................................................................................39 151 4.2.1 Identification of Use Case Text................................................................................................39 152 4.2.2 Requirement(s)........................................................................................................................40 153 4.2.3 Description ............................................................................................................................40 154 4.2.4 Solution proposals ..................................................................................................................40 1555 Requirements on SOA collective standards usage................................................................................42 156 5.1 Common Patterns for Interoperable Service Based Communications............................................42 157 5.1.1 Identification of Use Case Text................................................................................................42 158 5.1.2 Requirement(s)........................................................................................................................42 159 5.1.3 Description..............................................................................................................................42 1606 Conformance.........................................................................................................................................43 161 Appendix A. Acknowledgements..............................................................................................................44 162 Appendix B. SOA-TEL Requirements......................................................................................................45 163 164 13t-soa-req-01 16 February 2010 14Copyright © OASIS® 2009-2010. All Rights Reserved. Page 5 of 47
  6. 6. 165Table of Figures 166 167Figure 1: Example for SOAP nodes interaction (1)....................................................................................11 168Figure 2: Example for SOAP nodes interaction (2)....................................................................................12 169Figure 3: Example for SOAP nodes interaction (3)....................................................................................13 170Figure 4: SAML Name Identifier request-response use case: pictorial representation...............................28 171Figure 5: SAML Attribute Management request-response use case: pictorial representation....................32 172Figure 6: TM Forum SDF Reference Model...............................................................................................39 16t-soa-req-01 16 February 2010 17Copyright © OASIS® 2009-2010. All Rights Reserved. Page 6 of 47
  7. 7. 1731 Introduction 174 175Part of the work being undertaken by the OASIS SOA-TEL TC is to understand how SOA-related 176specifications and standards are used within the scope of the telecommunications environment and 177determine if there are any issues when used in this manner. 178This is the second deliverable of the SOA-TEL TC, and its objective is to collect requirements to address 179technical issues and gaps of SOA standards (specified by OASIS and other SDOs) utilized within the 180context of Telecoms. Such issues are documented in SOA-TEL’s TC first deliverable “Telecom Use 181Cases and Issues, v.1.0”. 182For each of the issues within such document, specific requirements are provided. Where possible, non 183prescriptive solution proposals to the identified issues and requirements are also described, in order to 184possibly assist those Technical Committees (within OASIS and other SDOs) responsible for the 185development and maintenance of the SOA related standards. 186 187For each of the issues identified within “Telecom Use Cases and Issues, v.1.0”, a section composed of 188• “References”, 189• “Requirement”, 190• “Description”, 191• and “Proposed solution” 192is included in this Requirements document. 193In order to facilitate future activities, each requirement is identified by means of a reference, with the 194syntax [SOA-TEL Req. x.y]. 195 196The document is organized in the following sections: 197• Section 2, Issues on “Intermediaries Handling”; 198• Section 3, Issues on “Security”; 199• Section 4, Issues on “Management”; 200• Section 5, Issues on “SOA collective standards usage”. 201Moreover, Appendix B, SOA-TEL Requirements, groups all exposed requirements within one single view. 202 203The next steps related to this activity will be taken within the OASIS Telecom Member Section. Most 204likely, issues and related requirements will be grouped according to categories, and sent and presented to 205the TCs or Working Groups considered as “owners” of the affected specifications, in order to verify if such 206groups will want to analyze them and provide their solution. Other alternatives may also be evaluated on 207a case by case approach. Nevertheless the solution of identified issues and the addressing of the 208requirements hereafter listed is not to be considered as part of SOA-TEL’s TC Charter. 209 2101.1 Terminology 211The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD 212NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described 213in [RFC2119]. 214 19t-soa-req-01 16 February 2010 20Copyright © OASIS® 2009-2010. All Rights Reserved. Page 7 of 47
  8. 8. 2151.2 Normative References 216 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 217 http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. 218 219 [WSDL 1.1] W3C Note (15 March 2001): "Web Services Description Language (WSDL) 220 1.1". http://www.w3.org/TR/2001/NOTE-wsdl-20010315. 221 222 [SOAP 1.2] W3C SOAP v.1.2, available at http://www.w3.org/TR/soap12-part1/ 223 224 [SOA-TEL 1.0] OASIS Committee Specification 01, “Telecom SOA Use Cases and Issues 225 Version 1.0”, March 2010. http://docs.oasis-open.org/soa-tel/t-soa- 226 uci/v1.0/cs01/t-soa-uc-cs-01.html 227 228 [WS-N 1.3] OASIS Standard, “Web Services Base Notification 1.3 (WS-BaseNotification) 229 Version 1.3”, October 2006. http://docs.oasis-open.org/wsn/wsn- 230 ws_base_notification-1.3-spec-os.htm. 231 232 [WS-A 1.0] W3C Web Services Addressing 1.0 – Core W3C Recommendation 9 May 233 2006, http://www.w3.org/TR/2006/REC-ws-addr-core-20060509. 234 235 [WS-S 1.1] OASIS Standard, “Web Services Security Specification Version 1.1”, 236 February 2006. http://www.oasis-open.org/specs/index.php#wssv1.0 237 238 [WSDM-MOWS] OASIS Standard, “Web Services Distributed Management: Management of 239 Web Services (WSDM-MOWS) Version 1.1”, August 2006. http://docs.oasis- 240 open.org/wsdm/wsdm-mows-1.1-spec-os-01.htm 241 242 [SOA RM 1.0] OASIS Standard, “OASIS Reference Model for Service Oriented Architecture 243 1.0”, October 2006. http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf 244 245 [SCA Assembly 1.1] OASIS Committee Draft, “Service Component Architecture Assembly Model 246 Specification Version 1.1”, March 2009. http://docs.oasis- 247 open.org/opencsa/sca-assembly/sca-assembly-1.1-spec.pdf 248 249 [SOA RA 1.0] OASIS Committee Draft 01 Public Review 01, “Reference Architecture for 250 Service Oriented Architecture Version 1.0”, April 2008. http://docs.oasis- 251 open.org/soa-rm/soa-ra/v1.0/soa-ra-pr-01.pdf 252 253 [WSDL 2.0] W3C Web Services Description Language (WSDL) Version 2.0 Part 0: 254 Primer, http://www.w3.org/TR/2007/REC-wsdl20- 255 primer-20070626/Recommendation, June 2007 256 257 [SAML 2.0] OASIS Standard, “Security Assertion Markup Language (SAML) Version 258 2.0”, March 2005. http://www.oasis-open.org/specs/ #samlv20 259 22t-soa-req-01 16 February 2010 23Copyright © OASIS® 2009-2010. All Rights Reserved. Page 8 of 47
  9. 9. 2602 Requirements on Intermediaries Handling 261 262This section gathers a collection of requirements related to the same typology of issue. Some existing 263specifications upon which Service Oriented Architectures are currently based on and implemented (such 264as W3C’s WS-Addressing, W3C’s SOAP, OASIS’s WS-Notification) do not consider the presence of 265intermediaries in the specified message exchange patterns (in the transactions between the actors that 266implement the services), or they don’t consider the possible situations in which such intermediaries can 267be involved. 268For this reason, intermediaries handling within SOA implementations is currently achieved via 269workarounds or proprietary solutions. 270 271OASIS SOA-TEL TC considers that addressing the specific requirements provided in this section may be 272the first step for a more general revision of the SOA specifications in order to extend their coverage to 273include the management of intermediaries. 274 2752.1 Requirements on Transaction Endpoints Specification 2762.1.1 Identification of Use Case Text 277Refer to rows 189 – 192 of [SOA-TEL 1.0], in which the technical issue is documented. 278At the moment, a standard way to specify in a message (involved in a process/transaction) the endpoint 279to which the final result of a “process/transaction" should be sent, does not exist. 2802.1.2 Requirement(s) 281 [SOA-TEL Req. 1] 282The WS Addressing specifications, [WS-A 1.0], must include additional fields (in addition to the ones 283already present) containing remote destinations to which reply messages must be sent. 284• The sender of a message must assign the fields when it wants to specify the destination for the reply 285 message, but the node that has to use such destination information (i.e. the node that has to send the 286 reply message) may not necessarily be the direct receiver of the request message. 287• The receiver of a message, which needs of information on the endpoint destination to which send a 288 reply message, can obtain the information by these additional fields. 289• The receiver of a message has to forward to the next receiver all the additional destinations (present 290 in these additional fields) that it does not use. 2912.1.3 Description 292The [WS-A 1.0] must include additional information to indicate nodes to which messages replies should 293be sent (in addition to the one already present). 294Specific endpoints should be inserted when the message is part of a transaction involving more 295participants. Such endpoints must be forwarded, through the chain of invocations, to those nodes that will 296need to use these endpoints. 297The generic node that starts a transaction should be able to specify endpoints for the nodes following in 298the transaction, in addition to the (already available) “reply_to” endpoint for the message’s direct receiver. 25t-soa-req-01 16 February 2010 26Copyright © OASIS® 2009-2010. All Rights Reserved. Page 9 of 47
  10. 10. 299In complex scenarios involving more than 3 nodes, the generic node N that receives a message may not 300be conscious of the specific transaction of which it is part of, or of other participant nodes, but could 301obtain the endpoint to which it must send a reply message by fetching such new proposed endpoint 302element. 303Moreover, the current “reply to” element within the WS-A specification could not be utilized for this 304objective because even the direct sender to node N may not be aware of the final destination for the 305message. 3062.1.4 Solution proposals 307The following text is provided in order to illustrate some possible ways to address the Requirement. They 308are suggestions and are by no means to be considered as mandatory, as other possible options could be 309identified which are not represented hereafter. 310 311To the best knowledge within OASIS SOA-TEL TC, the requirements presented hereafter could be 312addressed by the W3C Web Services Addressing (WS-A) WG, which by the way is in status “Completed”. 313 314The WS-Addressing v1.0 specification [WS-A 1.0] defines the following elements: 315 316 wsa:To>xs:anyURI</wsa:To> ? 317 <wsa:From>wsa:EndpointReferenceType</wsa:From> ? 318 <wsa:ReplyTo>wsa:EndpointReferenceType</wsa:ReplyTo> ? 319 <wsa:FaultTo>wsa:EndpointReferenceType</wsa:FaultTo> ? 320 <wsa:Action>xs:anyURI</wsa:Action> 321 <wsa:MessageID>xs:anyURI</wsa:MessageID> ? 322 <wsa:RelatesTo RelationshipType="xs:anyURI"?>xs:anyURI</wsa:RelatesTo> * 323 <wsa:ReferenceParameters>xs:any*</wsa:ReferenceParameters> ? 324 325Another element could be added to contain a “remote” endpoint reference, named for example 326 327 <wsa:RemoteReplyTo> wsa:EndpointReferenceType</wsa:RemoteReplyTo> *. 328 329It should be possible to add more RemoteReplyTo elements, in a LIFO (Last In First Out) criteria. 330 331The generic receiver can use the last inserted endpoint and delete the element. 332 333The following example is provided. 334 335Suppose that node_1 calls node_2. 336node_1 states that the endpoint for the response is node_n, but it doesn’t know which node will be 337sending the final response to node_n at the end of the transaction, so it inserts the information (node_n 338endpoint) in the RemoteReply element, not in ReplyTo one. Figure 1 illustrates the example. 339 28t-soa-req-01 16 February 2010 29Copyright © OASIS® 2009-2010. All Rights Reserved. Page 10 of 47
  11. 11. 340 Node_1 Node_2 Node_n N._n-1 341 342 Figure 1: Example for SOAP nodes interaction (1) 343 344The following is an example of the resulting message (in red color the proposed addition to the WS-A 345specification). 346 347 348 <soap:Envelope...> <soap:Header> <wsa:To> http://host_a/node_2 </wsa:To> <wsa:RemoteReplyTo> <wsa:Address> http://host_b/node_n </wsa:Address> </wsa:RemoteReplyTo> ... </soap:Header> <soap:Body> ... </soap:Body> </soap:Envelope> 349 350 351Suppose now that node_i in the transaction, calling node_i+1, starts a nested transaction (with node_j as 352final destination) in the main transaction. Also in this case, node_i does not know which will produce the 353response for the node_j, so it adds a RemoteReply element, to the message. Figure 2 illustrates the 354example. 355 31t-soa-req-01 16 February 2010 32Copyright © OASIS® 2009-2010. All Rights Reserved. Page 11 of 47
  12. 12. 356 Node_1 Node_2 Node_i N._i+1 Node_n Node_j 357 Figure 2: Example for SOAP nodes interaction (2) 358 359The resulting message should be the following. 360 361 <soap:Envelope...> <soap:Header> <wsa:To> http://host_c/node_i+1 </wsa:To> <wsa:RemoteReplyTo> <wsa:Address> http://host_d/node_j </wsa:Address> </wsa: RemoteReplyTo> <wsa:RemoteReplyTo> <wsa:Address> http://host_b/node_n </wsa:Address> </wsa:RemoteReplyTo> ... </soap:Header> <soap:Body> ... </soap:Body> </soap:Envelope> 362 363Suppose now that node_j-1 ends the nested transaction. 364node_j-1 needs a reply destination, so it fetches the endpoint by the first RemoteReplyTo element, 365obtaining the information “http:// host_d/node_j”; it then deletes the element in the header and replies to 366node_j. 367node_n-1, last node of the main transaction, should perform in the same way with the remaining 368RemoteReplyTo element. Figure 3 illustrates the example. 369 34t-soa-req-01 16 February 2010 35Copyright © OASIS® 2009-2010. All Rights Reserved. Page 12 of 47
  13. 13. 370 Node_1 Node_2 Node_i N._i+1 Node_n N._n-1 Node_j N._j-1 371 Figure 3: Example for SOAP nodes interaction (3) 372 3732.2 Requirements on WS-Notification 3742.2.1 Identification of Use Case Text 375Refer to rows 270 – 272 of the SOA-TEL “Telecom Use Cases and Issues” document, in which the 376technical issue is documented. 377If adopting the WS-Notification specification, in presence of intermediaries, there is no formal way for the 378Provider to specify the endpoint to which the final notification should be sent. 3792.2.2 Requirement(s) 380 [SOA-TEL Req. 2] 381The WS-Notification specification must provide a mechanism to describe and regulate a scenario in which 382one or more intermediaries are present; it must standardize the terminology, concepts, operations, WSDL 383and XML needed to express the roles of the intermediaries (involved in publish and subscribe Web 384services for notification message exchange). 385According to the WS-Notification terminology, the standard must be extended and modified so that: 386• a Subscriber can require a Subscription to a NotificationProducer also in the case they do not 387 communicate directly but do so by means of one or more intermediaries; 388• likewise a NotificationProducer can send a Notification to a NotificationConsumer also in the case that 389 they do not communicate directly, but by means of one or more intermediaries. 3902.2.3 Description 391The WS-Notification specification must provide a well specified mechanism whereby a Subscriber can 392interact (by means of “subscribe”, “unsubscribe” and the other provided operations) with a 393NotificationProducer also in presence of one or more intermediaries between itself and the 394NotificationProducer. 395Moreover the WS-Notification specification must provide a well specified mechanism by which a 396NotificationProducer can send notifications to a given NotificationConsumer also via one or more 397intermediaries. 398 399In the new context, the Subscriber must be able to send a subscription message (different from the ones 400allowed by the current specification) to an intermediary; the intermediary must be able to request the 401subscription to the NotificationProducer or to send the request to the next intermediary. As a 402consequence an intermediary can receive a subscription request from another intermediary. 403Moreover the new subscription response message must be managed and forwarded by intermediaries in 404a similar way. 37t-soa-req-01 16 February 2010 38Copyright © OASIS® 2009-2010. All Rights Reserved. Page 13 of 47
  14. 14. 405 406Conversely, the NotificationProducer must able to send a notification addressed to a 407NotificationConsumer to an intermediary, and this intermediary must be able to forward the notification to 408the NotificationConsumer or to the next intermediary. In consequence of that an intermediary can receive 409a notification from another intermediary. 410 411This requirement is closely connected to the requirement over WS-Addressing, described in Section 2.1 412of this document (Requirements on Transaction Endpoints Specification) for two reasons: 413• the two requirements introduce and regulate ”intermediaries management” in the WS-Addressing and 414 WS-Notification specifications 415• WS-Notification specification characterizes and identifies the actors (such as Subscriber and 416 NotificationProducer) by means of the WS-Addressing standard. 4172.2.4 Solution proposals 418The following text is provided in order to illustrate some possible ways to address the requirement. They 419are suggestions and are by no means to be considered as mandatory, as other possible options could be 420identified which are not represented hereafter. 421To the best knowledge within OASIS SOA-TEL TC, the requirements presented hereafter could be 422addressed by the OASIS WS-Notification Technical Committee (WSN TC), which by the way is in status 423“Completed”, or possibly, by the W3C Web Services Addressing (WS-A) WG, which by the way is as well 424in status “Completed”. 425Another Working Group potentially interested to receive this requirement is W3C Resource Access since 426the topic dealt by the specifications (WS-Transfer, WS-ResourceTransfer, WS-Enumeration, WS- 427MetadataExchange and WS-Eventing Member Submissions) for which this group is responsible may 428potentially solve the present issues with WS-N specification. 429 430There are several approaches to solve the requirement: the solution to adopt depends on the chosen 431perspective, on the use cases that are to be covered, and on the scope to assign to the new specification. 432Two different lines of solution, not antithetical, but complementary, are provided below. In the first 433proposal the intermediary plays an active part in the notification services, while the second proposal is 434more general, and is based on the fact that WS-Notification is supported by WS-Addressing. 435 436First proposal (intermediary plays an active part in the notification services) 437The WS-Notification specification should define a new role in addition to the ones already defined 438(NotificationConsumer, NotificationProducer, SubscriptionManager, Subscriber). 439The new role could be named, for example, “Intermediary”, and its description could be: 440• an entity acting on behalf of a Subscriber; it receives a subscription request and asks for the 441 subscription to the NotificationConsumer specified in the request, or forwards the request the next 442 Intermediary; 443• an entity acting on behalf of a NotificationProducer; it receives a notification and sends it to the 444 NotificationConsumer specified in the notification message, or forwards the request to the next 445 Intermediary. 446To be noted that an Intermediary node could contemporarily have both behaviours: acting on behalf of a 447Subscriber to request a subscription to a NotificationProducer, and acting on behalf of a Notification 448Producer to send a notification message to a Subscriber. 449 450The protocol should be extended in such as way to define a new message exchange pattern in which 451even the Intermediary behaviour is comprised. 40t-soa-req-01 16 February 2010 41Copyright © OASIS® 2009-2010. All Rights Reserved. Page 14 of 47
  15. 15. 452 453The syntax of the subscription request and that of the notification should be extended so that it becomes 454possible to specify, in the new messages, one or more intermediary destinations and the final destination. 455 456For example, for the subscription operation, if the Subscriber knows the NotificationProvider location, it 457can make a subscription request in which it inserts an endpoint reference element for the 458NotificationProvider, and then sends the message to the Intermediary; the Intermediary consumes (reads 459and deletes) the reference and so it is able to send a subscribe request to the NotificationProvider. 460In the subscription request, the endpoint reference of the Intermediary to which notifications should be 461sent, could be also included. 462The subscribe message could be as the following: 463 43t-soa-req-01 16 February 2010 44Copyright © OASIS® 2009-2010. All Rights Reserved. Page 15 of 47
  16. 16. 464 <s:Envelope ... > <s:Header> <wsa:Action> http://docs.oasis-open.org/wsn/bw-2/Intermediary/SubscribeRequest </wsa:Action> ... </s:Header> <s:Body> <wsnt:Subscribe> <wsnt:ConsumerReference> <wsa:Address> http://www.example.org/NotificationConsumer </wsa:Address> </wsnt:ConsumerReference> <wsnt:ProducerReference> <wsa:Address> http://www.example.org/NotificationProducer </wsa:Address> </wsnt:ProducerReference> <wsnt: IntermediaryReference> <wsa:Address> http://www.example.org/Intermediary </wsa:Address> </wsnt: IntermediaryReference> <wsnt:Filter> <wsnt:TopicExpression Dialect= "http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple"> npex:SomeTopic </wsnt:TopicExpression> <wsnt:MessageContent Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116"> boolean(ncex:Producer="15") </wsnt:MessageContent> </wsnt:Filter> <wsnt:InitialTerminationTime> 2005-12-25T00:00:00.00000Z </wsnt:InitialTerminationTime> </wsnt:Subscribe> </s:Body> </s:Envelope> 465 466 467The Intermediary receives the above message and makes a subscription request to the notification 468consumer with the following message: 46t-soa-req-01 16 February 2010 47Copyright © OASIS® 2009-2010. All Rights Reserved. Page 16 of 47
  17. 17. 469 470 <s:Envelope ... > <s:Header> <wsa:Action> http://docs.oasis- open.org/wsn/bw-2/NotificationProducer/SubscribeRequest </wsa:Action> ... </s:Header> <s:Body> <wsnt:Subscribe> <wsnt:ConsumerReference> <wsa:Address> http://www.example.org/NotificationConsumer </wsa:Address> </wsnt:ConsumerReference> <wsnt: IntermediaryReference> <wsa:Address> http://www.example.org/Intermediary </wsa:Address> </wsnt: IntermediaryReference> <wsnt:Filter> <wsnt:TopicExpression Dialect= "http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple"> npex:SomeTopic </wsnt:TopicExpression> <wsnt:MessageContent Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116"> boolean(ncex:Producer="15") </wsnt:MessageContent> </wsnt:Filter> <wsnt:InitialTerminationTime> 2005-12-25T00:00:00.00000Z </wsnt:InitialTerminationTime> </wsnt:Subscribe> </s:Body> </s:Envelope> 471 472The notification message could be the similar to these defined with the current specification, but sent by 473the NotificationProducer to the Intermediary rather than directly to the NotificationConsumer, as showed 474in the next figure; in this message the final destination should be present. 49t-soa-req-01 16 February 2010 50Copyright © OASIS® 2009-2010. All Rights Reserved. Page 17 of 47
  18. 18. 475 <s:Envelope ... > <s:Header> <wsa:Action> http://docs.oasis-open.org/wsn/bw-2/Intermediary/Notify </wsa:Action> ... </s:Header> <s:Body> <wsnt:Notify> <wsnt:NotificationMessage> <wsnt:SubscriptionReference> <wsa:Address> http://www.example.org/SubscriptionManager </wsa:Address> </wsnt:SubscriptionReference> <wsnt:Topic Dialect= "http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple"> npex:SomeTopic </wsnt:Topic> <wsnt:ConsumerReference> <wsa:Address> http://www.example.org/NotificationConsumer </wsa:Address> </wsnt:ConsumerReference> <wsnt:ProducerReference> <wsa:Address> http://www.example.org/NotificationProducer </wsa:Address> </wsnt:ProducerReference> <wsnt:Message> <npex:NotifyContent>exampleNotifyContent</npex:NotifyContent> </wsnt:Message> <wsnt:NotificationMessage> </wsnt:Notify> </s:Body> </s:Envelope> 476 477Second proposal (more general proposal, is based on the fact that WS-Notification is supported by WS- 478Addressing) 479The WS-Addressing specification should be extended so that it expresses the concept of “final 480destination” of the message, by adding a new element, named for example <was:FinalTo>, in addition to 481those already present. 482 52t-soa-req-01 16 February 2010 53Copyright © OASIS® 2009-2010. All Rights Reserved. Page 18 of 47
  19. 19. 483In this way the subscriber could specify both the NotificationProducer and the NotificationConsumer as 484final destinations in the subscription message. 485 486 <s:Envelope ... > <s:Header> <wsa:Action> http://docs.oasis- open.org/wsn/bw-2/NotificationProducer/SubscribeRequest </wsa:Action> <wsa:FinalTo> <wsa:Address> http://www.example.org/NotificationProducer </wsa:Address> </wsa:FinalTo> ... </s:Header> <s:Body> <wsnt:Subscribe> <wsnt:ConsumerReference> <wsa:FinalTo> <wsa:Address> http://www.example.org/NotificationConsumer </wsa:Address> </wsa:FinalTo> </wsnt:ConsumerReference> <wsnt:Filter> <wsnt:TopicExpression Dialect= "http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple"> npex:SomeTopic </wsnt:TopicExpression> <wsnt:MessageContent Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116"> boolean(ncex:Producer="15") </wsnt:MessageContent> </wsnt:Filter> <wsnt:InitialTerminationTime> 2005-12-25T00:00:00.00000Z </wsnt:InitialTerminationTime> </wsnt:Subscribe> </s:Body> </s:Envelope> 487 488The intermediary can send the message to the NotificationProducer without the necessity to make any 489interpretation of the message. 490 55t-soa-req-01 16 February 2010 56Copyright © OASIS® 2009-2010. All Rights Reserved. Page 19 of 47
  20. 20. 491As a consequence, the NotificationProducer knows the endpoints of the NotificationConsumer and of the 492intermediary to which reply to; so it can send a notification to the intermediary, specifying the 493NotificationConsumer as final destination. 494 495 <s:Envelope ... > <s:Header> <wsa:Action> http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify </wsa:Action> <wsa:FinalTo> <wsa:Address> http://www.example.org/NotificationConsumer </wsa:Address> </wsa:FinalTo> ... </s:Header> <s:Body> <wsnt:Notify> <wsnt:NotificationMessage> <wsnt:SubscriptionReference> <wsa:Address> http://www.example.org/SubscriptionManager </wsa:Address> </wsnt:SubscriptionReference> <wsnt:Topic Dialect= "http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple"> npex:SomeTopic </wsnt:Topic> <wsnt:ProducerReference> <wsa:Address> http://www.example.org/NotificationProducer </wsa:Address> </wsnt:ProducerReference> <wsnt:Message> <npex:NotifyContent>exampleNotifyContent</npex:NotifyContent> </wsnt:Message> <wsnt:NotificationMessage> </wsnt:Notify> </s:Body> </s:Envelope> 496 58t-soa-req-01 16 February 2010 59Copyright © OASIS® 2009-2010. All Rights Reserved. Page 20 of 47
  21. 21. 4972.3 Requirements on SOAP 4982.3.1 Identification of Use Case Text 499Extract from [SOA-TEL 1.0] (rows 405 to 414): 500------ 501The perceived technical gap suggested is that the SOAP specification should be modified in order to 502enable a SOAP Intermediary node to “forward” the SOAP Header in automatic mode (thus without the 503Header reinsertion) even if such node performs some processing operation over the body of the SOAP 504message. 505Another way of expressing this perceived gap is to state that currently only 3 roles are allowed for a 506SOAP Node (i.e. initial SOAP Sender, SOAP intermediary, SOAP ultimate receiver – section 2.1 of the 507SOAP 1.2 specification), while a probable fourth role enabling the simultaneous body processing and 508header forwarding of a specific SOAP message may be needed. 509------ 5102.3.2 Requirement(s) 511 [SOA-TEL Req. 3] 512A new “Message Sender and Receiver concept” must be added in [SOAP 1.2] to model SOAP nodes 513which must forward the SOAP headers message, but also need to perform changes on the body of the 514message. 515A new SOAP protocol must be added to manage the behavior of such nodes. 5162.3.3 Description 517As documented in the SOA-TEL TC “Use Cases and Issues” document, some SOAP nodes can’t be 518classified as “Ultimate SOAP Receivers” because they aren’t the real providers of the service, but can’t be 519simple “SOAP Intermediaries”, because they need to perform changes on the body of the message: such 520nodes aren’t requestors or receivers, they need to process the SOAP header blocks, perform some 521changes on the body, and forward the message to the following node. 522 523Hereafter a proposal definition of the new “SOAP functional intermediary” (the name is provisional and 524could be different) concept is provided: 525• SOAP functional intermediary 526 - A SOAP functional intermediary is both a SOAP receiver and a SOAP sender and is targetable from 527 within a SOAP message. It processes the SOAP header blocks targeted at it and acts to forward a 528 SOAP message towards an ultimate SOAP receiver. Moreover a SOAP Functional Intermediary 529 can process the contents of the SOAP body. 530 531This new concept and its functionalities of both processing the body of a message and of forwarding 532headers as a usual “SOAP intermediary” are to be included in the SOAP specification. 5332.3.4 Solution proposals 534The following text is provided in order to illustrate some possible ways to address the Requirement. They 535are suggestions and are by no means to be considered as mandatory, as other possible options could be 536identified which are not represented hereafter. 537 61t-soa-req-01 16 February 2010 62Copyright © OASIS® 2009-2010. All Rights Reserved. Page 21 of 47
  22. 22. 538To the best knowledge within OASIS SOA-TEL TC, the requirements presented hereafter could be 539addressed by the W3C “XML Protocol” Working Group, which produced the SOAP specification. Currently 540such group is in status “Completed”. For such reason, should the requirement be accepted, some 541preliminary investigations with W3C representatives are suggested to identify if within this SDO there are 542some WGs willing to consider and solve the issue. 543Some modifications to [SOAP 1.2] are needed (but other parts of the specification may need to be revised 544and changed): 545• Include the new concept definition in Section 1.5.3; 546• Modify paragraphs 2.2 and 2.7 of [SOAP 1.2]. In particular, 2 cases are suggested. 547 548Case 1 549The SOAP functional intermediary typology is covered by the role “next”. In this case the SOAP 550intermediary and SOAP functional intermediary act in a very similar way. 551In this case Table 2 in section 2.2 should be modified as follows, while no changes should be required for 552table 3 at section 2.7.1. 553 Table 2: SOAP Roles defined by this specification Short-name Name Description Each SOAP intermediary, SOAP next "http://www.w3.org/2003/05/soap- functional intermediary, and the envelope/role/next" ultimate SOAP receiver MUST act in this role. none "http://www.w3.org/2003/05/soap- SOAP nodes MUST NOT act in envelope/role/none" this role. ultimateReceiver "http://www.w3.org/2003/05/soap- The ultimate receiver MUST act in envelope/role/ultimateReceiver" this role. 554 555Case 2 556The SOAP functional intermediary typology is covered by the role “ultimateReceiver”. In this case 557Table 2 should be modified as follows: 558 Table 2: SOAP Roles defined by this specification Short-name Name Description Each SOAP intermediary, and the next "http://www.w3.org/2003/05/soap- ultimate SOAP receiver MUST act envelope/role/next" in this role. none "http://www.w3.org/2003/05/soap- SOAP nodes MUST NOT act in envelope/role/none" this role. The ultimate receiver and SOAP ultimateReceiver "http://www.w3.org/2003/05/soap- functional intermediary, MUST act envelope/role/ultimateReceiver" in this role. 559 64t-soa-req-01 16 February 2010 65Copyright © OASIS® 2009-2010. All Rights Reserved. Page 22 of 47
  23. 23. 560Moreover, table 3 in section 2.7.1 should be modified as follows: 561 Table 3: SOAP Nodes Forwarding behavior Role Header block Short-name Assumed Understood & Processed Forwarded Yes No, unless reinserted next Yes No No, unless relay ="true" Yes No, unless reinserted Yes user-defined No No, unless relay ="true" No n/a Yes Yes No, unless reinserted ultimateReceiver Yes No No, unless relay ="true" none No n/a Yes 562 67t-soa-req-01 16 February 2010 68Copyright © OASIS® 2009-2010. All Rights Reserved. Page 23 of 47
  24. 24. 5633 Requirements on Security 564 5653.1 Requirements on Security Token Correlation 5663.1.1 Identification of Use Case Text 567Refer to rows 493 – 507 of [SOA-TEL 1.0], in which the technical issue is documented. 568Currently it is not possible to correlate a security token with another one, previously created. 5693.1.2 Requirement(s) 570 [SOA-TEL Req. 4] 571The WS Security specifications must enable to express a relation between two security tokens, a “main” 572token (e.g. named “token2”) and a “related” token (e.g. named “token1”). 573The characteristics of the relation are that, when the token correlation is used, 574• the “main” token can not be built without being in possession of the “related” token, 575• the WS-Sec header should not be considered valid if the “related” token is not present. 576This token correlation requirement defines a new token security model, in which a “main” token is 577syntactically and semantically meaningful if it is built and presented in relation with another “related” 578token. 579 [SOA-TEL Req. 4.1] 580It must be possible to express “token correlation” also into the SAML assertion. 5813.1.3 Description 582This token correlation requirement extends the message security models and enforces the security 583mechanism in environments where the message exchange pattern is more complex than the simple 584“requestor – provider” pattern. 585This model should be useful when the definition and the use of a “simple” token doesn’t guarantee a 586sufficient level of security, since the authorization to access a specific service also depends on the fact 587that a previous token was released. 588 589The possible “status” of the “related” token could be valid or expired (i.e. not valid anymore). 590In the new token typology to be introduced, the “related” token is not a simple “attribute”, inserted only for 591traceability purposes into the header, but instead is an integral part of the token. 592The identity provider should release the security token directly made up of two parts: the “main” and the 593“related” tokens. 5943.1.4 Solution proposals 595The following text is provided in order to illustrate some possible ways to address the Requirement. They 596are suggestions and are by no means to be considered as mandatory, as other possible options could be 597identified which are not represented hereafter. 70t-soa-req-01 16 February 2010 71Copyright © OASIS® 2009-2010. All Rights Reserved. Page 24 of 47
  25. 25. 598[WS-S 1.1] defines three types of security tokens and how they are attached to messages (“user name 599token”, “binary security token” and “XML token”), and furthermore the syntax provides 2 elements to 600include tokens in the security header: 601• <wsse:UsernameToken> 602• <wsse:BinarySecurityToken>. 603 604A new element should be added, named for example <wsse:AssociatedToken> to the previous ones. 605The <wsse: AssociatedToken> could contain (in a recursive manner) a username token, or a binary 606token, or a XML token element, or again a related token, for the “main” token. 607The same should be for the “related” token. 608 609This could be the syntax of the element: 610 611 <wsse: AssociatedToken> 612 <wsse:MainToken> 613 ……… 614 </wsse: MainToken> 615 <wsse:RelatedToken> 616 ……… 617 </wsse:RelatedToken> 618 </wsse:AssociatedToken> 619 620This is an example of associated token: 621 622 <?xml version="1.0" encoding="utf-8"?> <S11:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="..."> <S11:Header> <wsse:Security xmlns:wsse="..."> <wsse:AssociatedToken ValueType wsu:Id=" MyNewT"> <wsse:MainToken> <wsse:UsernameToken wsu:Id="MyMainT"> <wsse:Username>...</wsse:Username> </wsse:UsernameToken> < /wsse:MainToken> <wsse:RelatedToken> <wsse:BinarySecurityToken ValueType=" http://fabrikam123#CustomToken " EncodingType="...#Base64Binary" wsu:Id=" MyID "> FHUIORv... </wsse:BinarySecurityToken> </wsse:RelatedToken> 623 624The <wsse:AssociatedToken> element could have other significant elements (other than the related token 625value) useful to the definition of the context in which the main token was built; for example it could include 73t-soa-req-01 16 February 2010 74Copyright © OASIS® 2009-2010. All Rights Reserved. Page 25 of 47
  26. 26. 626the timestamp value present in the security header from which the related token derive. Examples of 627other significant elements may also be (but not limited to) the ones currently defined within the three 628above mentioned security tokens types. 629 630In other worlds if the related security token belonged to the following header: 631 632 <S11:Header> 633 <wsse:Security> 634 <wsu:Timestamp wsu:Id="T0"> 635 <wsu:Created> 636 2001-09-13T08:42:00Z</wsu:Created> 637 </wsu:Timestamp> 638 639 <wsse:BinarySecurityToken 640 ValueType="...#X509v3" 641 wsu:Id="X509Token" 642 EncodingType="...#Base64Binary"> 643 MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i... 644 </wsse:BinarySecurityToken> 645 646The AssociatedToken in the new header should be the following: 647 648 <?xml version="1.0" encoding="utf-8"?> <S11:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="..."> <S11:Header> <wsse:Security xmlns:wsse="..."> <wsse:AssociatedToken ValueType wsu:Id=" MyNewT"> <wsse:MainToken> <wsse:UsernameToken wsu:Id="MyMainT"> <wsse:Username>...</wsse:Username> </wsse:UsernameToken> </ wsse:MainToken> <wsse:RelatedToken> <wsu:Timestamp wsu:Id="T0"> <wsu:Created> 2001-09-13T08:42:00Z</wsu:Created> </wsu:Timestamp> <wsse:BinarySecurityToken ValueType="...#X509v3" 649 650Clearly this mechanism is particularly meaningful when the related token is a SAML assertion that 651supplies all the information to describe the context in which the main token was built, that is the objective 652of the requirement. 653In a similar way the SAML protocol could be extended to support the requirement. 76t-soa-req-01 16 February 2010 77Copyright © OASIS® 2009-2010. All Rights Reserved. Page 26 of 47
  27. 27. 654In this case a new AssociatedToken element could be added into the SAML syntax, so the related token 655could be included directly in the SAML assertion constituting the main token, without the necessity of 656express the relation to the Ws security header level. 657 6583.2 SAML Name Identifier Request 6593.2.1 Identification of Use Case Text 660Section 5.2.2 in [SOA-TEL 1.0] describes a use case for the proposed SAML Name Identifier Request- 661Response protocol. 662A user device, a Service Provider (SP) and an Identity Provider (IdP) are the actors of this use case. The 663SP is new to the circle of trust of the IdP. The IdP does not know a name identifier of the user device. The 664IdP requests a name identifier from the SP, who sends the desired name identifier to the IdP. 6653.2.2 Requirement(s) 666 [SOA-TEL Req. 5] 667In order to make the [SAML 2.0] support name identifier use cases such as that described in section 6683.2.1, the Security Services TC must specify a 669• <NameIdentifierRequest> message sent from an Identity Provider to a Service Provider to request a 670 name identifier for a User, and a 671• <NameIdentifierResponse> message sent from the Service Provider to the Identity Provider to return 672 such a name identifier to the Identity Provider. 673This requires extensions to the existing [SAML 2.0] core specification (saml-core-2.0-os) including the 674SAML 2.0 protocol schema. No modification of the existing SAML 2.0 assertion schema is necessary. 675Description provides a high-level message flow illustrating the proposed SAML Name Identifier request- 676respone protocol. Messages 4 and 6 belong to the proposed SAML Name Identifier Request protocol. 677These messages are interlaced into the SAML Authentication Request and Response exchange between 678SP and IdP and are not specified in SAML V2.0 yet (therefore, marked in red): 679 79t-soa-req-01 16 February 2010 80Copyright © OASIS® 2009-2010. All Rights Reserved. Page 27 of 47
  28. 28. User SP IdP Device 1. Service Access Request 2. Authentication Request 3. Check for Identifier 4. Name Identifier Request 5. Prompt User to login 6. Name Identifier Response 7. Authentication Response 8. Provide Requested Service 680 681 682 Figure 4: SAML Name Identifier request-response use case: pictorial representation 683 684The single steps of this use case are as follows: 685 6861) The user requests access to a service offered by a SP. The user device does not include any 687 authentication credentials. 6882) Since access to this service requires the User to be authenticated but the request in step 1 does not 689 include any authentication credentials, the SP sends an Authentication Request to the IdP. This 690 Authentication Request may be passed to the IdP via the user device using redirection. 6913) The IdP checks the Authentication Request received in step 2, and - as the SP is new to the IdP’s 692 circle of trust - the IdP determines that it does not have an identifier stored in its database for the User 693 for the given SP. 6944) This step is not defined in SAML V2.0: Since the IdP has realized in step 3 that it does not have an 695 identifier for the combination of the User and the SP, the IdP generates a message called Name 696 Identifier Request and sends it to the SP. 6975) Upon receipt of the Name Identifier Request, the SP recognises that the IdP does not have an 698 identifier for the combination of SP and User. Therefore, the SP prompts the User to log in to the SP. 6996) This step is also not defined in SAML V2.0: The SP sends a message called Name Identifier 700 Response to the IdP. This response message includes the identifier for the combination of User and 701 SP that the IdP is to use in any further communication and authentication processes. 7027) On receipt of the Name Identifier Response, the IdP stores the identifier contained in the Name 703 Identifier Response in its database. The IdP sends an Authentication Response to the SP, which 704 uses the identifier received in step 6. 7058) The SP grants the User access to the requested service. 706 707In step 3 of the message exchange illustrating a SAML Name Identifier use case above, conventionally, 708the IdP would respond to the Authentication Request (step 2) by issuing an error message or a randomly 709generated identifier. This, however, is problematic: In the former case, the service access request in step 7101 breaks down. In the latter case, the SP has to ask the user for his credentials and then send (usually via 82t-soa-req-01 16 February 2010 83Copyright © OASIS® 2009-2010. All Rights Reserved. Page 28 of 47
  29. 29. 711a backchannel) a message to the IdP indicating that from now on the IdP should use the “real identifier” 712instead of the random one for the given user (this could be done via the NameIdentifier Management 713Protocol). 714These issues can be resolved on SAML protocol level by defining <NameIdentifierRequest> and 715<NameIdentifierResponse> messages enabling the Identity Provider to request from a Service Provider a 716name identifier for a User and the Service Provider to send such a name identifier back to the Identity 717Provider. 7183.2.3 Solution proposal 719Extension of the SAML 2.0 protocol schema by <NameIdentifierRequest> and 720<NameIdentifierResponse> messages, instances of which are exemplified as follows: 721 722Name Identifier Request: 723 724<samlp:NameIdentifierRequest 725 xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 726 xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 727 ID="aaf23196-1773-2113-474a-fe114412ab72" 728 Version="2.0" 729 IssueInstant="2006-07-17T20:31:40Z"> 730 <saml:Issuer 731 Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"> 732 http://idm.nsn.com 733 </saml:Issuer> 734</samlp:NameIdentifierRequest> 735 736Name Identifier Response: 737 738<samlp:NameIdentifierResponse 739 xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 740 xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 741 ID="aaf23196-1773-2113-474a-fe114412ab72" 742 Version="2.0" 743 IssueInstant="2006-07-17T20:31:40Z"> 744 745 <saml:Assertion 746 MajorVersion="1" MinorVersion="0" 747 AssertionID="128.9.167.32.12345678" 748 Issuer="Smith Corporation"> 749 <saml:Issuer 750 Format="urn:oasis:names:tc:SAML:1.1:nameid- 751 format:X509SubjectName"> 752 C=US, O=NCSA-TEST, OU=User, CN=trscavo@uiuc.edu 753 </saml:Issuer> 754 <saml:Subject> 755 <saml:NameID 85t-soa-req-01 16 February 2010 86Copyright © OASIS® 2009-2010. All Rights Reserved. Page 29 of 47
  30. 30. 756 Format="urn:oasis:names:tc:SAML:1.1:nameid- 757 format:unspecified"> 758 tom.smith 759 </saml:NameID> 760 </saml:Subject> 761 762 <saml:AttributeStatement> 763 <saml:Attribute 764 xmlns:x500="urn:oasis:names:tc:SAML:2.0: 765 profiles:attribute:X500" 766 x500:Encoding="LDAP" 767 NameFormat="urn:oasis:names:tc:SAML:2.0: 768 attrname-format:uri" 769 Name="urn:oid:2.5.4.42" 770 FriendlyName="givenName"> 771 <saml:AttributeValue xsi:type="xs:string"> 772 Tom 773 </saml:AttributeValue> 774 </saml:Attribute> 775 776 <saml:Attribute 777 xmlns:x500="urn:oasis:names:tc:SAML:2.0: 778 profiles:attribute:X500" 779 x500:Encoding="LDAP" 780 NameFormat="urn:oasis:names:tc:SAML:2.0: 781 attrname-format:uri" 782 Name="urn:oid:1.3.6.1.4.1.1466.115.121.1.26" 783 FriendlyName="mail"> 784 <saml:AttributeValue xsi:type="xs:string"> 785 trscavo@gmail.com 786 </saml:AttributeValue> 787 </saml:Attribute> 788 </saml:AttributeStatement> 789 </saml:Assertion> 790 <samlp:Status xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"> 791 <samlp:StatusCode 792 xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 793 Value="urn:oasis:names:tc:SAML:2.0:status:Success"> 794 </samlp:StatusCode> 795 </samlp:Status> 796</samlp:NameIdentifierResponse> 797 88t-soa-req-01 16 February 2010 89Copyright © OASIS® 2009-2010. All Rights Reserved. Page 30 of 47
  31. 31. 7983.3 SAML Attribute Management Request 7993.3.1 Identification of Use Case Text 800Section 5.3.2 in [SOA-TEL 1.0] describes a use case for the proposed SAML Attribute Management 801Request-Response protocol. 802A user wishes to use his attribute information across multiple service providers. Such attribute information 803can be layout, preferred email address, etc. Today, these attributes are stored locally at each service 804provider. Thus, the user will have to enter and change the same attributes multiple times in order to 805ensure they are consistent for each of the different service providers the user has an account with, 806resulting in a bad user experience. 807The user creates a temporary or transient account. The service provider allows the user to set specific 808settings like coloring, text size, etc. But he/she does not want to set these setting again each time the 809user logs in because the service provider will not be able to link the attributes for a user’s temporary 810account with the user’s permanent account. This is because by the very nature of a temporary or transient 811account the next time the user logs on to the service provider the user will have a different user name and 812so the service provider will not be able to link the attributes for a user’s temporary account with the user’s 813permanent account. 8143.3.2 Requirement(s) 815 [SOA-TEL Req. 6] 816In order to make the [SAML 2.0] support attribute management use cases such as that described in 3.3.1, 817the Security Services TC must specify a 818• <ManageAttributeRequest> message sent from a Service Provider to an Identity Provider to request 819 a modification or the storage of an attribute, and a 820• <ManageAttributeResponse> message sent from the Identity Provider to the Service Provider to 821 return to the Service Provider the result of processing the received <ManageAttributeRequest> 822 message. 823This requires extensions to the existing SAML 2.0 core specification (saml-core-2.0-os) including the 824SAML 2.0 protocol schema. No modification of the existing SAML 2.0 assertion schema is necessary. 825 8263.3.3 Description 827Figure 5 provides a high-level message flow outlining the proposed SAML Attribute Management 828protocol: 91t-soa-req-01 16 February 2010 92Copyright © OASIS® 2009-2010. All Rights Reserved. Page 31 of 47
  32. 32. User Service Identity Device Provider Provider 1 . Request to cha nge attrib ute 2. Ma nageA ttribute Re quest 3. Store Attribute 4. Manag eAttrib ute Response 5. Verify 6 . Co nfi rma tion 829 830 Figure 5: SAML Attribute Management request-response use case: pictorial representation 831 832The Manage Attribute Request and Response messages are marked in red since the SAML 2.0 does not 833support such messages yet. The ManageAttribute Request allows the Service Provider to manage 834attributes stored on the Identity Provider side. 8353.3.4 Solution proposal 836Extension of the SAML 2.0 protocol schema by <ManageAttributeRequest> and 837<ManageAttributeResponse> messages, instances of which are exemplified as follows: 838 839Manage Attribute Request: 840 841<samlp:ManageAttributeRequest 842 xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 843 xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 844 ID="aaf23196-1773-2113-474a-fe114412ab72" 845 Version="2.0" 846 IssueInstant="2006-07-17T20:31:40Z"> 847 <saml:Issuer 848 Format="urn:oasis:names:tc:SAML:1.1:nameidformat: 849 X509SubjectName"> 850 C=US, O=NCSA-TEST, OU=User, CN=trscavo@uiuc.edu 851 </saml:Issuer> 852 853 <saml:Subject> 94t-soa-req-01 16 February 2010 95Copyright © OASIS® 2009-2010. All Rights Reserved. Page 32 of 47
  33. 33. 854 <saml:NameID 855 Format="urn:oasis:names:tc:SAML:1.1:nameidformat:X50 856 SubjectName"> 857 C=US, O=NCSA-TEST, OU=User, CN=trscavo@uiuc.edu 858 </saml:NameID> 859 </saml:Subject> 860 <saml:AttributeStatement> 861 <saml:Attribute 862 xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles: 863 attribute:X5 00" x500:Encoding="LDAP" 864 NameFormat="urn:oasis:names:tc:SAML:2.0: 865 attrname-format:uri" 866 Name="urn:oid:2.5.4.42" 867 FriendlyName="givenName"> 868 <saml:AttributeValue 869 xsi:type="xs:string"> 870 John 871 </saml:AttributeValue> 872 </saml:Attribute> 873 <saml:Attribute 874 xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles: 875 attribute:X500" x500:Encoding="LDAP" 876 NameFormat="urn:oasis:names:tc:SAML:2.0: 877 attrname-format:uri" 878 Name="urn:oid:1.3.6.1.4.1.1466.115.121.1.26" 879 FriendlyName="mail"> 880 <saml:AttributeValue 881 xsi:type="xs:string"> 882 johndoe@gmail.com 883 </saml:AttributeValue> 884 </saml:Attribute> 885 </saml:AttributeStatement> 886</samlp:ManageAttributeRequest> 887 888 889Manage Attribute Response: 890 891<samlp:ManageAttributeResponse 892 xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 893 xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 894 ID="aaf23196-1773-2113-474a-fe114412ab72" 895 Version="2.0" 97t-soa-req-01 16 February 2010 98Copyright © OASIS® 2009-2010. All Rights Reserved. Page 33 of 47
  34. 34. 896 IssueInstant="2006-07-17T20:31:40Z"> 897 <saml:Assertion 898 MajorVersion="1" MinorVersion="0" 899 AssertionID="128.9.167.32.12345678" 900 Issuer="Smith Corporation"> 901 <saml:Issuer 902 Format="urn:oasis:names:tc:SAML:1.1: 903 nameid-format:unspecified"> 904 http://idm.nsn.com 905 </saml:Issuer> 906 <saml:Subject> 907 <saml:NameID 908 Format="urn:oasis:names:tc:SAML:1.1: 909 nameid10format:X509SubjectName"> 910 C=US, O=NCSA-TEST, OU=User, CN=trscavo@uiuc.edu 911 </saml:NameID> 912 </saml:Subject> 913 <saml:AttributeStatement> 914 <saml:Attribute 915 xmlns:x500="urn:oasis:names:tc:SAML:2.0: 916 profiles:attribute:X500" 917 x500:Encoding="LDAP" 918 NameFormat="urn:oasis:names:tc:SAML:2.0: 919 attrname-format:uri" 920 Name="urn:oid:2.5.4.42" 921 FriendlyName="givenName"> 922 <saml:AttributeValue 923 xsi:type="xs:string"> 924 John 925 </saml:AttributeValue> 926 </saml:Attribute> 927 <saml:Attribute 928 xmlns:x500="urn:oasis:names:tc:SAML:2.0: 929 profiles:attribute:X500" 930 x500:Encoding="LDAP" 931 NameFormat="urn:oasis:names:tc:SAML:2.0: 932 attrname-format:uri" 933 Name="urn:oid:1.3.6.1.4.1.1466.115.121.1.26" 934 FriendlyName="mail"> 935 <saml:AttributeValue 936 xsi:type="xs:string"> 937 trscavo@gmail.com 100t-soa-req-01 16 February 2010 101Copyright © OASIS® 2009-2010. All Rights Reserved. Page 34 of 47
  35. 35. 938 </saml:AttributeValue> 939 </saml:Attribute> 940 </saml:AttributeStatement> 941 </saml:Assertion> 942 <samlp:Status 943 xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"> 944 <samlp:StatusCode 945 xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 946 Value="urn:oasis:names:tc:SAML:2.0:status:Success"> 947 </samlp:StatusCode> 948 </samlp:Status> 949</samlp:ManageAttributeResponse> 9503.4 User ID Forwarding 9513.4.1 Scenario/context 9523.4.2 Identification of Use Case Text 953Refer to rows 771 – 793 of [SOA-TEL 1.0], in which the technical issue is documented. 954Currently a standard way does not exist to add two (or more) credentials in one message. 9553.4.3 Requirement(s) 956 [SOA-TEL Req. 7] 957The WS Security specifications must enable to bring two security credentials in the security header: the 958“main” credential (e.g. named “credential2”) and a “secondary” credential (e.g. named “credential1”). 959The authentication and authorization process should be performed on the basis of the main credential; 960the secondary credential should be used to complete the security functionalities. 961 [SOA-TEL Req. 7.1] 962It must be possible to express “token correlation” also into the SAML assertion. 963 9643.4.4 Description 965The user-id forwarding requirement extends the message security models and enforces the security 966mechanism in environments where a second security credential is necessary to add functionalities to the 967basic security process. 968This model should be useful when the process of authentication and authorization on the base of the 969credential provided in the security header is not enough, and other security functionalities have to be 970executed on a second credential, for example to complete the authorization process or to profile the data. 9713.4.5 Solution proposals 972The following text is provided in order to illustrate some possible ways to address the Requirement. They 973are suggestions and are by no means to be considered as mandatory, as other possible options could be 974identified which are not represented hereafter. 103t-soa-req-01 16 February 2010 104Copyright © OASIS® 2009-2010. All Rights Reserved. Page 35 of 47
  36. 36. 975 976To the best knowledge within OASIS SOA-TEL TC, the requirements presented hereafter could be 977addressed by the OASIS Web Services Security (WSS) TC, which by the way is in status “Completed”, 978and possibly by the OASIS Security Services (SAML) TC. 979 980Hereafter some suggestions are proposed. 981The WS-Sec v1.1 specification defines the following elements: 982 /wsse:Security; 983 /wsse:Security/@S11:actor; 984 /wsse:Security/@S12:role; 985 /wsse:Security/@S11:mustUnderstand; 986 /wsse:Security/{any}; 987 /wsse:Security/@{any}; 988 989Another element should be added, named for example: 990/wsse:SecondaryCredential. This element should contain a security token, in particular one of the tokens 991provided by the current WS Security specification. 992 993This is an example of header with a secondary credential, when the main credential is represented by a 994binary token, and the secondary by a user name and password token: 995 996 997 998 999In a similar way the SAML protocol could be extended to support the requirement. 1000In this case the “secondary credential” element could be added into the SAML syntax. In this way the 1001related token could be included directly in the SAML assertion which constitutes the main token, without 1002the necessity of express the relation to the WS security header level. 1003 1004As an alternative path, the following hypothesis can be considered. This requirement (User-id forwarding 1005requirement) is “intrinsically” similar to the “Security token correlation” requirement, presented elsewhere 106t-soa-req-01 16 February 2010 107Copyright © OASIS® 2009-2010. All Rights Reserved. Page 36 of 47
  37. 37. 1006in the present document. Thus a common approach in modifying the WS-Security specifications could be 1007adopted to address both the requirements and, more in general, similar security issues. 109t-soa-req-01 16 February 2010 110Copyright © OASIS® 2009-2010. All Rights Reserved. Page 37 of 47
  38. 38. 10084 Requirements on Management 10094.1 Cardinality of a Service Interface 10104.1.1 Identification of Use Case Text 1011Extract from the [SOA-TEL 1.0] (rows 864 to 870 and rows 882 to 886): 1012------ 1013 [SOA-RM 1.0]: (Section 3.1) “A service is accessed by means of a service interface (see Section 1014 3.3.1.4), where the interface comprises the specifics of how to access the underlying capabilities.” 1015 [SOA-RM 1.0]: (Subsection 3.3.1.4) “The service interface is the means for interacting with a service.” 1016 [SCA Assembly 1.1]: “A Service represents an addressable interface of the implementation.” 1017 Note – SCA definition for Service may be a consequence of the SOA-RM definition, we do not know 1018------ 1019------ 1020 [SOA-RA 1.0] (3137 – 3140) “In fact, managing a service has quite a few similarities to using a 1021 service: suggesting that we can use the service oriented model to manage SOA-based systems as 1022 well as provide them. A management service would be distinguished from a non-management service 1023 more by the nature of the capabilities involved (i.e., capabilities that relate to managing services) than 1024 by any intrinsic difference. “ 1025------ 10264.1.2 Requirement(s) 1027 [SOA-TEL Req. 8] 1028The SOA Reference Model and Architecture must explain how a service separates and exposes its 1029manageability capabilities to allow other services to manage it. 1030The Service Delivery Framework specified by TM Forum and depicted below sets such requirement at the 1031SDF Service Management Interface (indicated in red in ). 1032 112t-soa-req-01 16 February 2010 113Copyright © OASIS® 2009-2010. All Rights Reserved. Page 38 of 47
  39. 39. 1033 1034 1035 Figure 6: TM Forum SDF Reference Model 10364.1.3 Description 1037As documented in the SOA-TEL TC “Use Cases and Issues”, interfaces are the ways to interact with and 1038between services and interfaces are the way to expose capabilities. At the same time, TM Forum SDF 1039requires that SDF Services expose both Functional and Management capabilities and recommends this 1040exposure to be made at separate interfaces attached to the SDF Service. 10414.1.4 Solution proposals 1042OASIS SCA Assembly Model specification v1.1 offers a solution to the multiple interfaces problem as well 1043as to “marking” an interface as being a management interface. 1044Updates to this specification (Committee Draft 03 rev 1.1 June 2009) offer also support for dynamic wiring 1045of “service references” with “services” at run time through “autowire”, policy sets and SCA runtime re- 1046evaluation of targets. 1047These proposals will be tested through TM Forum’s use case analysis and the results will be sent back to 1048OASIS SCA Assembly team for further discussion. 1049 1050Observations: 10511. SCA Assembly Model covers only design, deployment and runtime as manageable capabilities (or 1052 management operations) for software bundles that constitute SDF Services. Other aspects of service 1053 lifecycle management such as quality, charging are not part of OASIS charter and will be further 1054 investigated by TM Forum in collaboration with other industry organizations. 10552. SCA Assembly Model is not yet mapped to the OASIS SOA RA/RM. 10564.2 Requirements on Metadata 10574.2.1 Identification of Use Case Text 1058Extract from [SOA-TEL 1.0] (rows 924 to 928): 1059------ 1060Specialization in supporting and managing a service during its whole lifecycle requires finer granularity 1061knowledge about that service: properties, supported actions or operations, possible states as well as 1062contracts that may govern interactions with the service (including pre and post conditions for these 1063interactions), what is the “architectural” style for service “composability”, what are its dependencies or 1064what is the level of exposure for its functional capabilities. 115t-soa-req-01 16 February 2010 116Copyright © OASIS® 2009-2010. All Rights Reserved. Page 39 of 47

×