Deployment Profile Template
v1.1
For OASIS ebXML Collaboration-Protocol Profile and Agreement (CPP/A) 2.0 Standard
Public Review Draft 01, 04
December 2006
Artifact identifier:
ebXML_DPT-v1.1-ebCPPA2-template-pr-01
Location:
http://www.oasis-open.org/committees/documents.php?wg_abbrev=ebxml-iic
Artifact Type:
template
Technical Committee:
OASIS ebXML Implementation, Interoperability and Conformance (IIC) TC
Chair:
Jacques Durand, Fujitsu <jdurand@us.fujitsu.com>
Editors:
Jacques Durand, Fujitsu <jdurand@us.fujitsu.com>
Pete Wenzel, Sun Microsystems <pete.wenzel@sun.com>
Contributors:
Sacha Schlegel, Cyclone Commerce <sschlegel@cyclonecommerce.com>
Monica Martin, Sun Microsystems <Monica.Martin@sun.com>
Brian Hayes, Commerce One <brian.hayes@commerceone.com>
Abstract:
(Refer to Section 1.1, Purpose.)
Status:
This document was last revised or approved by the OASIS ebXML IIC TC on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule.
Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/ebxml-iic.
For information on whether any patents have
been disclosed that may be essential to implementing this specification, and
any offers of patent licensing terms, please refer to the Intellectual Property
Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/ebxml-iic/ipr.php).
Notices
OASIS takes no position regarding the validity or scope of
any intellectual property or other rights that might be claimed to pertain to
the implementation or use of the technology described in this document or the
extent to which any license under such rights might or might not be available;
neither does it represent that it has made any effort to identify any such
rights. Information on OASIS's procedures with respect to rights in OASIS
specifications can be found at the OASIS website. Copies of claims of rights
made available for publication and any assurances of licenses to be made
available, or the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or users of
this specification, can be obtained from the OASIS Executive Director.
OASIS invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to implement this
specification. Please address the information to the OASIS Executive Director.
Copyright © OASIS Open 2005. All Rights Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may not be modified
in any way, such as by removing the copyright notice or references to OASIS,
except as needed for the purpose of developing OASIS specifications, in which
case the procedures for copyrights defined in the OASIS Intellectual Property
Rights document must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will
not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is
provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Table of Contents
1.3
How to Use the Deployment Profile Template
2 Profiling the Modules of CPPA 2.0
3 Profile Requirements Details
3.2
Defining the CPA Profile Meta-Data
3.2.2
Profile Requirement Item: [name of CPA element / attribute]
3.3.2
Profile Requirement Item: [name of CPA element / attribute]
3.4
Profiling the Collaboration Roles
3.4.2
Profile Requirement Item: [name of CPA element / attribute]
3.4.3
Profile Requirement Item: [name of CPA element / attribute]
3.5
Profiling the Delivery Channels
3.5.2
Profile Requirement Item: [name of CPA element / attribute]
3.6
Profiling the Document Exchanges
3.6.2
Profile Requirement Item: tp:ReceiverDigitalEnvelope /tp:EncryptionAlgorithm
3.6.3
Profile Requirement Item: tp:ReceiverNonRepudiation /tp:SignatureAlgorithm
3.6.4
Profile Requirement Item: [name of CPA element / attribute]
3.7
Profiling the Transport Protocol
3.7.2
Profile Requirement Item: [name of CPA element / attribute]
4.1
Management Authority for CPPs and CPAs.
4.2
Deployment and Processing requirements for CPPs
4.3
Deployment and Processing requirements for CPAs
4.4
CPA Interpretation Options
4.6
Additional Agreement Aspects beyond CPPA Specification
4.7
Additional Deployment or Operational Requirements
1.1 Purpose
The ebXML CPPA 2.0 [ebCPPA] contains several configurable features and options. Any use of CPPA requires a certain amount of standardization within a trading community. In order to foster interoperability on multiple levels between participants, these communities will want to (1) document additional conventions on CPPA elements format and content, (2) define CPP or CPA templates that may be partially filled-in, and that represent an agreement baseline in the user community.
This Deployment Profile Template for CPPA 2.0 is intended to
be filled or instantiated by one or more user communities. Once instantiated
and optionally extended with material that is specific to this community, it becomes
a Deployment Profile, or Guide. It is
the intention of the OASIS ebXML IIC Technical Committee to collect and archive
examples of Deployment Profiles created from this Template, as an aid to user
communities whose standardization efforts involve the creation of ebXML CPPA
documents.
Business partners may define CPP that represent their capabilities and
roles they can assume. Another approach is for a business party to directly
start by defining a CPA profile that this party will pre-fill with its own data,
and that it will communicate to its partners for them to complete. The
partially created CPA (or CPA profile) will narrow the options that a CPP would
offer, down to a very specific way under which this party wishes to
interoperate. This is the approach suggested here.
A party may define a few of such CPA profiles that express different modes
of connectivity, different roles and collaborations and different QoS
attributes. The reason for doing so is that its business partners may have
different profiles (e.g. large business, small business, etc.).
1.2 Terminology
The keywords must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in [RFC2119].
Source Specification: The specification or standard that is being profiled.
Deployment Profile Template:
Document that lists the options in the source specification that may be
selected by a user community, that identifies content elements (e.g. message
headers, XML values) the format and/or value of which may be further
standardized by a community, and that also identifies typical operating
conditions under which the source specification may be used, and selected by a
user community.
User Community: A group of users, e.g. within a supply-chain industry, the members of which decide to make a similar usage of the source specification in order to be able to interoperate.
Deployment Profile (or
Deplyment Guide): Document that is an instance of the Deployment Profile
Template. It defines which options should / should not be used by this
community, which format or value some content elements should comply with, and
under which operating conditions the standard must be used by this community.
1.3 How to Use the Deployment Profile Template
There are three parts in the Deployment Profile Template that need to
be instantiated in order to generate a Deployment Profile:
- The
section on the source specification modules (see section 2 below)
- The
section on the profiling requirement details (see section 3 below)
- The section on operating conditions associated with the profile (see section 4 below)
Every feature from the source specification that is candidate for profiling is listed in a profiling table. Each profiling table corresponds to a functional subset of a CPA. In case a CPA element requires a detailed profiling recommendation, this will be specified in another table called a “profile requirement item” table, which is of the form:
|
Specification Feature |
<Description of the source
specification item to be profiled. This is pre-filled in the Deployment
Profile Template.> |
|
Specification Reference |
<Identifies the item in the source
specification. This is pre-filled in the Deployment Profile Template > |
|
Profiling |
<how the item is profiled: option
narrowing/selection, content formatting, |
|
Alignment |
<dependency / alignment with other
data, e.g. binding, either with other |
|
Test References |
<references to related test
requirements or test cases, that would verify |
|
Notes |
<Profile-specific comments.This is left for a Deployment Profile to fill in.> |
When no recommendation is made for a profile requirement
item of the template, one of the following values MUST be used in the
“profiling” and “alignment” fields of
the table:
- Not
Applicable: for items that are not relevant to the community.
- No
Recommendation: will indicate that there is no recommendation or requirement
for this feature item.
- Pending: for items that are still under study for a recommendation, and for which some recommendation is likely to be specified in future versions of the Deployment Profile (yet, the user community did not want to wait for these to be specified before publishing a current version of the Profile or Guide.)
For items that specify text values, it should also be noted
whether or not the values are case-sensitive.
Two classes of users would be expected to collaborate in the instantiation of this Template to produce a Deployment Guide (or Profile):
- Business Process Designers would detail the business-process specific requirements of the Message Service.
- Technical Architects in user communities or vertical industries would make the technical decisions necessary to implement the business processes most effectively.
Consumers of a Deployment Guide include:
- Business process implementers (IT departments), to deploy a Message Service solution according to the requirements of specific trading communities.
- Software solution vendors, to identify all areas in which business process specification bodies require software flexibility, and what specific configurations are necessary to support such standards.
In this section, users will only specify which modules of the source specification are used in this profile (i.e. modules that business partners need to use or support in order to comply with the profile and communicate with others who do comply). For each used module, users also specify whether the module has been profiled or not. If yes, some profiling details should be given for this module in section 3 or 4.
2.1 Core CPA Modules
|
Module Name and Reference |
CPA Template Info |
|
Profiling Status |
Usage: <required / optional / never used in this profile> Profiled: <yes / no> |
|
Notes |
|
|
Module Name and Reference |
CPA Party Info |
|
Profiling Status |
Usage: <required / optional / never used in this profile> Profiled: <yes / no> |
|
Notes |
|
|
Module Name and Reference |
CPA Collaboration Roles |
|
Profiling Status |
Usage: <required / optional / never used in this profile> Profiled: <yes / no> |
|
Notes |
|
|
Module Name and Reference |
CPA Delivery Channels |
|
Profiling Status |
Usage: <required / optional / never used in this profile> Profiled: <yes / no> |
|
Notes |
|
|
Module Name and Reference |
CPA Document Exchanges |
|
Profiling Status |
Usage: <required / optional / never used in this profile> Profiled: <yes / no> |
|
Notes |
|
|
Module Name and Reference |
CPA Transport protocol |
|
Profiling Status |
Usage: <required / optional / never used in this profile> Profiled: <yes / no> |
|
Notes |
|
2.2 Optional CPA Modules
|
Module Name and Reference |
|
|
Profiling Status |
Usage: <required / optional / never used in this profile> Profiled: <yes / no> |
|
Notes |
|
3.1 Introduction
The profiling and definition of CPA data (both instance and template) can
be facilitated using a set of forms.
Each element (or entry) in these forms map to a CPA element. Either the
name of the entry is explicit enough to refer to the corresponding CPA element,
or the name of the corresponding CPA element is mentioned in clear, usually
prefixed with the qualifier “tp:” (e.g. tp:channelID).
When entries in these forms must conform to some additional rule (e.g. map
to a value in a third party specification), it is indicated in the form entry.
When entries in these forms are left to the user to instantiate as s/he
wants to, the entry value is left empty (or just referring to the actual name
of the CPA element, e.g. tp:TransportID)
The way this section can be used for profiling is as
follows:
For each major part of a CPA / CPP (Party Info,
Collaboration Roles…), a general profiling table indicates all CPP/CPA elements
that belong to this part. If the value profile for some of these canbe
expressed shortly enough, it can be described in the table itself.
If the value profile for some table entry requires more
explanation (e.g. choice among several options, with comments, etc. as shown in
examples Section 3.6 “Document Exchanges”, then it is best to use a Profile
Requirement Item table, see examples
3.6.2, and 3.6.3. In that case,
the corresponding entry in the main table should refer to the Item table that
profiles it
3.2 Defining the CPA Profile Meta-Data
3.2.1 Profiling Table
This table or form is used to identify the CPA profile, and also any CPA
instance that is derived from a profile. The CPA profile is defined here as
specific to one business partner (the ID of which appears in the profile name)
though that is a user community choice. The form below recommends some naming
conventions for the CPA and its parts.
|
Form: CPA Profile Info |
||
|
CPA Profile Info |
Name |
[Provide a name for the
Collaboration Protocol Agreement profile,. The name should identify when
applicable: (a) the version of CPA, (b) the community sharing this profile,
(c) type of artifact (here a profile), (d) name of profile, (e) party ID if
this profile is attached to a party.] Example: “CPA2.0-ACMEgroup-Profile-“<profileID>”-“<partner1>”-“<string> Examples of names: CPA2.0-ACMEgroup-Profile-P15-myDUNS- CPA2.0-RosettaNet- Profile
-TP31-222222-TProfile2 |
|
File name |
[Provide a file name for the
Collaboration Protocol Agreement template file.] “CPA2.0-ACMEgroup- Profile -“<profileID>”-“<partner1>”-“<string>”-file” (followed by appropriate suffix
– e.g. .xml for the XML definition.) Examples: CPA2.0-ACMEgroup- Profile -P15-222222-PIP3A4-file.pdf CPA2.0-HL7- Profile
-TP31-222222-TProfile2-file.xml |
|
|
CPA Instance Info |
Name |
[Define the name format for the CPA instances resulting from using this profile. The name should identify when applicable: (a) the version of CPA, (b) the community sharing this instance, (c) type of artifact (here an instance), (d) name of instance, prefixed by profile it is derived from, (e) party IDs] Example: “CPA2.0-ACMEgroup-“< profileID >”-”<instID>”-”<partner1-partner2> Example: CPA2.0-ACMEgroup-instance-P15-001-222222-333333 CPA2.0-HL7-instance-TP2-004-222222-333333 |
|
File name |
[Define the file name format for a Collaboration Protocol Agreement instance.] Example: “CPA2.0-ACME-“< profileID
>”-”<instID>”-”<partner1-partner2>”-file” (followed by appropriate suffix – e.g. .xml for the XML definition.) Example: CPA2.0-ACME-P15-001-222222-333333-file.pdf CPA2.0-ACME-TP2-004-222222-333333-file.xml |
|
|
CPA Id |
[Define the format of the CPA Id. Must align with CPAId in message header.] Example: same as CPA name, i.e.: “CPA2.0-ACME-“< profileID
>”-”<instID>”-”<partner1-partner2> |
|
|
Lifetime of CPA |
Start: [The starting date and time of the agreement.] |
|
|
End: [The end date and time of the agreement. The start and end date/times define the
duration that the agreement is in effect.] |
||
|
Context of application |
ConversationLimit: [NONE or numeric value. The agreement is terminated (no longer
valid) when the conversation limit is reached.] |
|
|
Concurrent Conversation Limit: [NONE or numeric value. The maximum number of conversations that
can be in process at the same time.
Provide this value when there are constraints that limit the number of
business transactions that one or more of the parties can process
simultaneously. Note that this value must be aligned with what the process
definition (if ebBP is being used) allows.] |
||
3.2.2 Profile Requirement Item: [name of CPA element / attribute]
<If needed, any more detailed profiling recommendation
will be defined in such a table below, one for each CPA element that requires a
detailed profiling.>
|
Specification Feature |
|
|
Specification Reference |
CPPA V 2.0, section … |
|
Profiling |
|
|
Alignment |
|
|
Test References |
|
|
Notes |
|
3.3 Profiling the Party Info
3.3.1 Profiling Table
This form is used to identify the parties involve. A CPA template
will typically contain one of these fully instantiated. At least another one of
these will need to be filled by another business partner in order to produce a
complete CPA instance.
|
Form: Party Info |
|||
|
CPA Reference |
[CPA Profile name] |
||
|
[CPA Instance name, if used
for instantiating a particular CPA
profile] |
|||
|
Party element |
PartyId |
[The formal unique identifier for the organization. Must align with eb:PartyId in message header (section 4)] All Party ID elements present in
CPA must appear in the ebMS message header. |
|
|
Type |
[Must align with eb:PartyId/@type
in ebMS message header (section 4)] |
||
|
Reference |
[A URL or URI that points to a
location (e.g. web page or directory) where more information can be found on
the party.] |
||
|
Collaboration Roles elements |
[List the collaboration role
names that this party is expected to fulfill.
The role names need to be unique within this list. Each role will be
detailed in a CollaborationRole form. Note that a party could report several
of the roles allowed by a single business transaction, if it can be involved
in different instances of such a transaction, with a different role.] |
||
|
CollaborationRole 1 |
Process Name [maps to eb:Service I header] Role Name [maps to eb:Role in
header] |
||
|
CollaborationRole 2 |
Process Name [maps to eb:Service I header] Role Name [maps to eb:Role in
header] |
||
|
(others?) |
|
||
|
Certificates elements |
[List the certificates info and
ID.] |
||
|
Certificate 1 |
|
||
|
Certificate 2 |
|
||
|
(others?) |
|
||
|
DeliveryChannels elements |
[describes a Party's Message-receiving and Message-sending
characteristics. It consists of one document-exchange definition and one
transport definition. The details of each
DeliveryChannel element will be
specified in a different form.] |
||
|
DeliveryChannel 1 |
[give only the tp:channelId] |
||
|
DeliveryChannel 2 |
[give only the tp:channelId] |
||
|
(others?) |
|
||
|
Transports elements |
|
||
|
Transport ID |
[tp:TransportId] |
||
|
Documents Exchanges |
|
||
|
Exchange ID |
[tp:docExchangeId] |
||
3.3.2 Profile Requirement Item: [name of CPA element / attribute]
<If needed, any more detailed profiling recommendation
will be defined in such a table below, one for each CPA element that requires a
detailed profiling.>
|
Specification Feature |
|
|
Specification Reference |
CPPA V 2.0, section … |
|
Profiling |
|
|
Alignment |
|
|
Test References |
|
|
Notes |
|
3.4 Profiling the Collaboration Roles
3.4.1 Profiling Table
This form is used to identify the roles in which a party may be acting
under this CPA or CPA template. One form will be filled for each role.
|
Form: ColaborationRole Info |
||||
|
CPA Reference |
[CPA Profile name] |
|||
|
[CPA Instance name, if used
for instantiating a particular CPA
profile ] |
||||
|
Role Identification |
Name |
[maps to eb:Role] |
||
|
Type |
[xlink:type], e.g. “simple” |
|||
|
href |
[xlink:href] Example: xlink:href="http://www.rosettanet.org/processes/3A4.xml#Buyer"> |
|||
|
Application Certificate |
ID: |
|
||
|
Comments: |
|
|||
|
Process Specification |
name |
|
||
|
Short description |
|
|||
|
version |
[Version of the business process specification] |
|||
|
type |
|
|||
|
Uuid |
tradingpartner uuid ŕ attribute uuid of BPSS definition when
present (attr in process specification
top element) (Example= "urn:icann:rosettanet.org:bpid:3A4$2.0") |
|||
|
Service Binding item (One for every Action or Signal message) |
Associated Service name |
[tp:ServiceBinding/tp:Service value] Maps to eb:Service (see Section 4
Message Description) |
||
|
Action direction |
[send / receive ] |
|||
|
Action Binding |
[tp:id] example: companyA_ABID1
(to be used for further references. Unique) |
|||
|
[tp:action] example: "Purchase Order Request Action" maps to eb:Action (see Section 4, Message Description)(e.g. ="PurchaseOrderRequestAction") |
||||
|
[tp:packageId] Example: tp:packageId="CompanyA_RequestPackage". Refers to MIME structure of payload. |
||||
|
Business Transaction Characteristics |
tp:isNonRepudiationRequired |
|
||
|
tp:isNonRepudiationReceiptRequired
|
|
|||
|
tp:isConfidential |
(using SSL or digital envelope) |
|||
|
tp:isAuthenticated |
|
|||
|
tp:isTamperProof |
|
|||
|
tp:isAuthorizationRequired |
|
|||
|
tp:timeToAcknowledgeReceipt |
|
|||
|
tp:timeToPerform |
|
|||
|
Tp: isIntelligibleCheckRequired |
|
|||
|
Tp: timeToAcknowledgeReceipt |
|
|||
|
Tp: timeToAcknowledgeAcceptance |
|
|||
|
Tp: retryCount |
|
|||
3.4.2 Profile Requirement Item: [name of CPA element / attribute]
<This is an example of profile requirement item that is
dedicated to the customization of collaborations, in case some user-defined
signals are being used for which XML schemas need be agreed upon and shared.>
|
Specification Feature |
Tp:ProcessSpecification |
|
Specification Reference |
CPPA V 2.0, section 9.12 |
|
Profiling |
The process specification of tp:name = “ABC3A4RequestPurchaseOrder” must
use the ad-hoc signal “ABC”. The CPA extensibility point “XYZ” must be set to
the XML schema URI of this signal. |
|
Alignment |
The schema URI for the signal
“ABC” is: (…) |
|
Test References |
|
|
Notes |
|
3.4.3 Profile Requirement Item: [name of CPA element / attribute]
<If needed, any more detailed profiling recommendation
will be defined in such a table below, one for each CPA element that requires a
detailed profiling.>
|
Specification Feature |
|
|
Specification Reference |
CPPA V 2.0, section … |
|
Profiling |
|
|
Alignment |
|
|
Test References |
|
|
Notes |
|
3.5 Profiling the Delivery Channels
3.5.1 Profiling Table
Delivery Channels - A
delivery channel describes a Party's Message-receiving and Message-sending characteristics. It
consists of one document-exchange definition and one transport definition. When
defining a CPA for use with ebMS, one delivery channel will not depend on
parties involved and wil be used for MSH-to-MSH signaling: the default MSH channel (see the
DefaultMSHChannelId in [ebCPPA]),
|
Form: Delivery Channel Info |
|||
|
CPA Reference |
[CPA Profile name] |
||
|
[CPA Instance name, if used
for instantiating a particular CPA
profile] |
|||
|
Identity and Components |
channelId |
|
|
|
transportId |
|
||
|
docExchangeId |
|
||
|
Messaging Characteristics |
|
||
|
syncReplyMode |
|
||
|
ackRequested |
Reliable Messaging parameter for
Guaranteed Delivery (At Least Once) |
||
|
ackSignatureRequested |
NOTE: this form of
non-repudiation of Receipt may not be sufficient. |
||
|
duplicateElimination |
Reliable Messaging parameter for
No Duplicate Delivery (At Most Once) |
||
|
actor |
|
||
3.5.2 Profile Requirement Item: [name of CPA element / attribute]
<If needed, any more detailed profiling recommendation
will be defined in such a table below, one for each CPA element that requires a
detailed profiling.>
|
Specification Feature |
|
|
Specification Reference |
CPPA V 2.0, section … |
|
Profiling |
|
|
Alignment |
|
|
Test References |
|
|
Notes |
|
3.6 Profiling the Document Exchanges
3.6.1 Profiling Table
Document Exchange - The
Document-exchange layer specifies processing of the business documents by the
Message-exchange function. Properties specified include encryption, digital
signature, and reliable-messaging characteristics. The options selected for the
Document-exchange layer are complementary to those selected for the transport
layer. For example, if Message security is desired and the selected transport
protocol does not provide Message encryption, then Message
encryption must be specified in the Document-exchange layer.
|
Form: Document Exchange Info |
|||
|
CPA Reference |
[CPA Profile name] |
||
|
[CPA Instance name, if used
for instantiating a particular CPA
profile] |
|||
|
Doc Exchange ID |
[tp:docExchangeId] |
||
|
Sender Binding |
Reliable Messaging |
[tp:ReliableMessaging] tp:Retries: [maps to “Retry Count“ column
6 in above tables.] tp:RetryInterval: [Example: <tp:RetryInterval>PT2H</tp:RetryInterval>] tp:MessageOrderSemantics:
[Example: “Guaranteed”] |
|
|
Persist Duration |
[tp:PersistDuration] |
||
|
Non Repudiation of Origin |
[tp:SenderNonRepudiation] tp:NonRepudiationProtocol tp:HashFunction tp:SignatureAlgorithm tp:SigningCertificateRef |
||
|
Digital Envelope |
[tp:SenderDigitalEnvelope] tp:DigitalEnvelopeProtocol tp:EncryptionAlgorithm tp:EncryptionSecurityDetailsRef |
||
|
Nemespaces |
[tp:NamespaceSupported] |
||
|
Receiver Binding |
|
||
|
Reliable Messaging |
[tp:ReliableMessaging] tp:Retries tp:RetryInterval tp:MessageOrderSemantics |
||
|
Persist Duration |
[tp:PersistDuration] |
||
|
Non Repudiation of Receipt |
[tp:ReceiverNonRepudiation] tp:NonRepudiationProtocol tp:HashFunction tp:SignatureAlgorithm [see
3.6.3] tp:SigningSecurityDetailsRef |
||
|
Digital Envelope |
[tp:ReceiverDigitalEnvelope] tp:DigitalEnvelopeProtocol tp:EncryptionAlgorithm [see
3.6.2] tp:EncryptionCertificateRef |
||
|
Nemespaces |
[tp:NamespaceSupported] |
||
3.6.2 Profile Requirement Item: tp:ReceiverDigitalEnvelope /tp:EncryptionAlgorithm
<This is an example of detailed profiling for this
element. Here, the profiling consists of a restricted set of values for this
item .>
|
Specification Feature |
Tp:DocExchange/…/tp:ReceiverDigitalEnvelope/
tp:EncryptionAlgorithm |
|
Specification Reference |
CPPA V 2.0, section 8.4.56 |
|
Profiling |
The algorithm used MUST be one of the
following: http://www.w3.org/2001/04/xmlenc#tripledes-cbc http://www.w3.org/2001/04/xmlenc#aes128-cbc http://www.w3.org/2001/04/xmlenc#aes192-cbc http://www.w3.org/2001/04/xmlenc#aes256-cbc |
|
Alignment |
|
|
Test References |
|
|
Notes |
|
3.6.3 Profile Requirement Item: tp:ReceiverNonRepudiation /tp:SignatureAlgorithm
<This is an example of detailed profiling for this
element. Here, the profiling consists of a restricted set of values for this
item .>
|
Specification Feature |
Tp:DocExchange/…/tp:ReceiverNonRepudiation/
tp:SignatureAlgorithm |
|
Specification Reference |
CPPA V 2.0, section 8.4.54 |
|
Profiling |
The algorithm used MUST be one of the
following: http://www.w3.org/2000/09/xmldsig#dsa-sha1 http://www.w3.org/2000/09/xmldsig#rsa-sha1 (the referenced certificates must
support RSA or DSA respectively.) |
|
Alignment |
|
|
Test References |
|
|
Notes |
|
3.6.4 Profile Requirement Item: [name of CPA element / attribute]
<If needed, any more detailed profiling recommendation
will be defined in such a table below, one for each CPA element that requires a
detailed profiling.>
|
Specification Feature |
|
|
Specification Reference |
CPPA V 2.0, section … |
|
Profiling |
|
|
Alignment |
|
|
Test References |
|
|
Notes |
|
3.7 Profiling the Transport Protocol
3.7.1 Profiling Table
The transport layer identifies the transport protocol to be
used in sending messages through the network and defines the endpoint
addresses, along with various other properties of the transport protocol.
Choices of properties in the transport layer are complementary to those in the
document-exchange layer (see "Document-Exchange Layer" directly
above.)
|
Form: Transport Info |
|||
|
CPA Reference |
[CPA Profile name] |
||
|
[CPA Instance name, if used
for instantiating a particular CPA
profile] |
|||
|
Transport Sender |
protocol |
[tp: TransportProtocol] |
|
|
Client security |
[tp:TransportSecurityProtocol] |
||
|
[tp:ClientCertificateRef] |
|||
|
Transport Receiver |
protocol |
[tp: TransportProtocol] |
|
|
End Point |
[tp:Endpoint/@uri,
tp:Endpoint/@type] |
||
|
Server security |
[tp:TransportSecurityProtocol] |
||
|
[tp:ServerCertificateRef] |
|||
|
[tp:ClientSecurityDetailsRef] |
|||
3.7.2 Profile Requirement Item: [name of CPA element / attribute]
<If needed, any more detailed profiling recommendation
will be defined in such a table below, one for each CPA element that requires a
detailed profiling.>
|
Specification Feature |
|
|
Specification Reference |
CPPA V 2.0, section … |
|
Profiling |
|
|
Alignment |
|
|
Test References |
|
|
Notes |
|
<Section that defines the operational aspect of the profile: type of deployment that the above profile is supposed to be operated with, expected or required conditions of operations, usage context, etc.>
4.1 Management Authority for CPPs and CPAs
|
CPPA management authorities |
Profile requirements |
|
Who is (are) the authority(ies) in charge of managing CPPs? Who has the authority and responsibility for: Creation Storage Update Distribution/Notification |
(e.g. each party could store and
manage CPPs, or they could be stored and managed in a third-party repository,
e.g. in an ebXML registry/repository with a standardized user authenticated
interface to query and retrieve them.) |
|
Who is the authority in charge of managing CPA templates? Who has the authority and responsibility for: Creation Storage Update Distribution/Notification |
|
|
Who is the authority in charge of managing CPA instances? Who has the authority and responsibility for: Creation Storage Update Distribution/Notification |
|
|
Others |
|
4.2 Deployment and Processing requirements for CPPs
|
CPP Management Process |
Profile requirements |
|
Is a specific registry or
repository for storing CPPs required? What is its accessibility? If so, provide
access details. |
|
|
Is there a set of predefined CPP profiles, that users should comply with? |
|
|
How are CPPs generated? (E.g.
are they generated from templates? Are
they reverse-engineered from a source CPA? From other sources?) |
|
|
What is the validation process for CPPs? |
|
|
Others |
|
4.3 Deployment and Processing requirements for CPAs
|
CPA Management Process |
Profile requirements |
|
Storage: Is a specific registry or repository for storing CPAs or
CPA artifacts required? What is its accessibility? If so, provide access
details. |
|
|
CPA creation: Is there a set of predefined CPA profiles that should be used to create given Parties’ CPAs? How were they created? Should CPPs be used for this, and how? |
(e.g. CPAs skeletons could be generated from ebBP definitions.) |
|
Security: How will certificates be managed and distributed? (procedure) |
|
|
Validation: What is the validation process for CPAs that must conform to this template? validation expected at import /
configuration time? validation expected at run-time? |
|
|
Others |
|
4.4 CPA Interpretation Options
Some CPA content may be interpreted differently by different
partners. This may be due to some redundancy or overlap between CPA fields that
actually support different scopes of application of QoS requirements. In case
two scopes of application are conflicting, the precedence rules remain to be
established. An agreement on which QoS scope prevails must be specified for the
sake of interoperability.
|
Additional Agreement |
Profile requirements |
|
The tp:SenderDigitalEnvelope /
tp:EncryptionAlgorithm in the Document Exchange part of a CPA may conflict
with the tp:Confidential element in the Business Transaction Characteristics
part (Collaboration Roles, Service Binding) of the CPA. Which one will prevail to govern
persistent encryption? |
|
|
The tp:SenderNonRepudiation
element in the Document Exchange part of a CPA (Sender binding) may conflict
with the tp:isNonRepudiationRequired element in the Business Transaction
Characteristics part (Collaboration Roles, Service Binding) of the CPA. Which one will prevail to govern
non-repudiation policy? |
|
|
The tp:ReceiverNonRepudiation
element in the Document Exchange part of a CPA (Receiver binding) may
conflict with the tp:isNonRepudiationReceiptRequired element in the Business
Transaction Characteristics part (Collaboration Roles, Service Binding) of
the CPA. Which one will prevail to govern
non-repudiation policy? |
|
|
When used with ebXML ebBP
specification, some process definitions created by the user community may
override some values in this CPA. For which ones of these is it the case? |
|
|
Other? |
|
4.5 Hub and Spoke Environment
|
CPA and Hub |
Profile requirements |
|
In case of a Hub configuration,
is there any specific handling of the delivery channels that may differ from
one hop to the other? Any additional CPA or subset of it required by the Hub
as a party? |
|
|
List of hubs trusted certificate
authorities? (so the spoke knows from where to get a signed certificate.) |
|
|
|
|
|
Others |
|
4.6 Additional Agreement Aspects beyond CPPA Specification
|
Additional Agreement |
Profile requirements |
|
Are there additional profiling
aspects (e.g. business-related) out of specification scope, that this CPA
profile is part of, and that should be associated with it? |
|
|
|
|
4.7 Additional Deployment or Operational Requirements
|
Operational or Deployment
Conditions |
Profile requirements |
|
Operational or deployment
aspects that are object to further requirements or recommendations. |
Recommended or required practices. |
|
|
|
5.1 Normative
[ebCPPA] OASIS, ebXML Collaboration-Protocol Profile and Agreement Specification
Version 2.0, http://www.oasis-open.org/committees/download.php/204/ebcpp-2.0.pdf,
[ebMS] OASIS, ebXML Message Service Specification Version 2.0, http://www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v2_0.pdf,
[ebBP] ebXML,
ebXML Business Process Specification
Schema Version 1.0.1, http://www.ebxml.org/specs/ebBPSS.pdf,
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.
5.2 Non-Normative
[ebDPT] OASIS, Metadata for Deployment Profile Templates, http://www.oasis-open.org/committees/download.php/19253/ebxml-iic-Deployment_Profile_Template-CD.doc.
In addition to editors or direct contributors, the following individuals were members of the committee during the development of this specification or of a previous version of it:
|
Rev |
Date |
By Whom |
What |
|
0.1 |
March, 2005 |
P. Wenzel J. Durand |
Initial Draft. |
|
0.6 |
|
|
Add some editorial corrections, and content corrections based on feedback. |