W.r.t. following issue:
>5. The NamespaceSupported element description refers to
S2ML. Is this superseded
>by SAML (developed under the auspices of OASIS)? Should
we reference SAML
>instead?
I
reviewed the ebXML CPP/CPA spec and I agree that we should not reference S2ML.
Rather
we should reference SAML 1.0 specification which is available
at:
If
you're interested in including an example of an optional namespace suipported
element
for SAML, the SAML Assertion schema is defined at:
However, final version of SAML schema most likely (not confirmed
yet)
will be
at:
http://www.oasis-open.org/committees/security/saml/1.0/saml-assertion.xsd
Obviously, the real issue is that in ebXML 2.0 Messaging, CPP/CPA specs
we do
not explicitly call out how SAML assertion and protocols could
be used in by ebXML's
authentication and authorization components of an MSH. I hope we will be
able to
address that in next version of ebXML, fopr example, ebXML v.
3.0.
thanks,
Zahid
- NamespaceSupported element
The OPTIONAL NamespaceSupported element identifies the
namespaces supported by the messaging service implementation and by the business
application. Examples are Security Services Markup Language[S2ML] and
Transaction Authority Markup Language[XAML]. For example, support for the S2ML
namespace would be defined as follows:
<tp:NamespaceSupported
tp:location="http://www.s2ml.org/s2ml.xsd"
tp:version="0.8">http://www.s2ml.org/s2ml
</tp:NamespaceSupported>
While working on my contributions to the 1.07 draft, I
come across the following issues that I like to see discussed in tomorrow's
CC if possible:
- We agreed at the F2F that all version attributes should
be REQUIRED. However, In the NonRepudiationProtocol element example, I
have a hard time figuring out what would be an appropriate version
attribute value. The example is currently using "http://www.w3.org/2000/09/xmldsig#"
as the string value for NonRepudiationProtocol.
- It is not clear to me if the attributes under
BusinessProcessCharacteristics should be REQUIRED or IMPLIED. We say
that these attributes can be used to override parameters specified in
the business process. In that sense, I would think that if an attribute
is omitted, the default value should be obtained from the business
process. However, we try to describe consistency contraints between
various attributes. It would be much simpler for a CPA composition tool
to check for consistency if all attributes are directly available from
the CPA, rather than having to retrieve default values from the BPSS
instance.
- In the ProcessSpecification element, we have an
existing REQUIRED xlink:href attribute and we are trying to add a uuid
attribute. One reason for adding a uuid attribute is that it may not be
always possible to provide a resolvable xlink:href for the business
process document. If so, then we should not have made xlink:href
REQUIRED in the first place. It also seems inappropriate to make uuid
REQUIRED. What if the BPSS spec is not being used? There may not be a
usable uuid. One argument in favor of making xlink:href REQUIRED is that
its absence would make it impossible to attach one or more signatures on
CPPs and CPAs.
- In order to describe which parts of business message is
to be signed by the ebXML MSH, I suggest adding an IMPLIED boolean
excludedFromSignature attribute to the Constituent element. This
attribute is only applicable to those Constitutents that comprise the
top-level multipart ebXML message. By default, this attribute is
"false", meaning that the Constituent will be included in the
ds:Signature. Those Constituents that have this attribute explicitly set
to "false" would be excluded from the signature.
- The NamespaceSupported element description refers to
S2ML. Is this superseded by SAML (developed under the auspices of
OASIS)? Should we reference SAML instead?
- Is it acceptable to allow PartyRef to occur multiple
times, in order to accommodate the reference to context information?
What are appropriate values for the type attribute? Would it be
appropriate to use URNs like
"urn:oasis:names:tc:ebxml-cppa:contact-information" and
"urn:oasis:names:tc:ebxml-cppa:context"?
- We need to decide on how CPAs should be versioned.
Should the Appendix on ebMS/CPPA element mapping state that the cpaid
and version attibutes in the CollaborationProtocolAgreement element
should be concatenated to populate the CPAId element in ebMS message
header?
- For extensibility, which elements should accept
#wildcards?
Thanks,
-Arvola
The following are the changes I plan to contribute to the 1.07
draft. I will start working on the schema and example changes and wait
for the 1.06 draft from Tony on Monday before updating the
specification.
-Arvola
Schema (and corresponding spec) changes:
- Factor out PersistDuration as an element as sibling
of the ReliableMessaging element
- Rename the WillInitiate element as CanSend; rename
the WillRespond element as CanReceive
- Add isTamperProof, isIntelligibleCheckRequired, timeToAcknowledgeReceipt,
timeToAcknowledgeAcceptance, timeToPerform attributes to the
BusinessProcessCharacteristics element
- Remove defaultSignalChannelId attribute from the
ServiceBinding element and require explicit action bindings for
signals if they are to be used
- Replace confidentiality.type with
tns:confidentiality.type in schema
- Add optional schemaLocation attribute to PartyRef
element
- Allow an action binding to specify multiple
delivery channels to provide for the use of different transport
protocols; the same Packaging would be used regardless of
DeliveryChannels
- Add uuid attribute to
ProcessSpecification
- Make the cpaid attribute within the
CollaborationProtocolAgreement element required rather than
optional
- Add AccessAuthentication element to TransportSender
and TransportReceiver
- Add cppid attribute to
CollaborationProtocolProfile
- Require CollaborationProtocolAgreement to have
exactly two PartyInfo
- Make all version attributes required
- Make id attribute in SimplePart required rather
than optional because it is no longer nested under Packaging and can
be referenced from multiple Packaging elements
- Propose schema change to allow identification of
SimpleParts that are to be excluded from signature
Spec only changes:
- Clarify relationships between
BusinessProcessCharacteristics and MessagingCharacteristics
attributes and sub-elements of Transport and DocExchange; state
consistency requirements among attribute values
- Clarify that NRR can be supported either through MSH level
signed Acknowledgment or business level Receipt Acknowlegment
signals. In the latter case, the ServiceBinding must have action
binding specified for the Receipt Acknowledgment signal.
- Clarify that the short-form action names used by
the two collaborating parties may not be identical; recommend that
the RequestingBusinessActivity and RespondingBusinessActivity names
be used in the absence of reuse of the same BusinessTransaction in
multiple BusinessTransactionActivities
- Clarify that the short-form action name needs to be unique
across CollaborationRoles (if a Party has multiple
CollaborationRoles)
- Clarify that the Service element for non piggybacked Signal
messages should be equal to the Service element used in the original
business message being acknowledged
- Clarify that the sync reply mode
"responseOnly" means that no signals are to be used at
all; and that the sync reply mode "signalsAndResponse"
means that the requester must also return the Receipt Acknowledgment
signal for the response over the same HTTP connection
- Change BPSS example to use different values for the
name and nameID attributes for InitiatingRole and
RespondingRole
- Require the use of multiple ServiceBindings if both
sync and async reply modes are to be supported because different
Packaging would have to be used for synchronous versus asynchronous
response
- Clarify that in a SimplePart element, the first
NamespaceSupported sub-element identifies the schema for the
SimplePart
- Incorporate S/MIME encryption example into
Packaging section
- Clarify that timeToPerform is to be used for HTTP
connection timeout
- Clarify in normative appendix that RefToMessageId
can be used for correlating response with request
- Update CPP/CPA examples with valid ds:KeyInfo elements
- Line 814: type attribute in PartyId is of type
"anyURI", not "string"
- Line 2616: CollaborationProtocolAgreement must have
0 to 3 signatures, not one or more signatures
-Arvola
|