OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: Draft attached this time. RE: [ebxml-cppa] Proposed schemachanges, plus illustrative example


Dale:

Sorry I forgot to attach the marked up Word document.

-Arvola

-----Original Message-----
From: Arvola Chan <arvola@tibco.com>
To: ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>
Date: Tuesday, October 23, 2001 2:03 PM
Subject: Re: Draft attached this time. RE: [ebxml-cppa] Proposed schema
changes, plus illustrative example


> I am somewhat confused by the element hierarchy you are using here, with
>TrustAnchor, SecurityPolicy, and AuthenticationCredential as children
>elements of SecurityDetails. In the ebXML Technical Architecture Security
>document, the SecurityPolicy element is the parent of TrustAnchors,
>Profiles, WillUse, and WillAccept.
>
> Why are you defining a complex type as opposed to another element that can
>be referenced, in place of CertificateRef? If you really want to define a
>complexType, can you explicitly name this type?
>
> Why are you showing the attribute certId here? Since you are referencing
>another top-level element, I don’t think you need to explicitly identify
the
>attributes of the referenced element.
>
> Similar comment to [a3].
>
> If you add a keypairUsage attribute to CertificateRef, you would not be
>imposing any constraint on the expected value of this attribute, to
>correspond to the context where the CertificateRef element is used. Since
>you have defined a complex type that encompasses CertificateRef and
>SecurityRef, is it possible to name subelements under CollaborationRole,
>TransportSecurity, NonRepudiation, and DocumentEnvelope that are of this
>complex type in such a way that the key usage information is conveyed in
the
>element name?
>
> This assumes that the possible values of keypairUsage are enumerated.
>
> This conflicts with the assumption that keypairUsage values are
enumerated.
>
> It is possible to name the element in such a way that the multiple keypair
>usages at an existing CertificateRef location is conveyed.
>
> The ebXML Technical Architecture Security paper proposes a TrustAnchors
>element but not a TrustAnchor element. Your proposal is the other way
round.
>
> Need both ClientSide and ServerSide certificates.
>
> Would this be redundant? Is the CertificateRef under NonRepudiation
already
>used for this purpose?
>
> Hasn’t this been mentioned earlier? Why is this an addition?
>
>-----Original Message-----
>From: Dale Moberg <dmoberg@cyclonecommerce.com>
>To: Arvola Chan <arvola@tibco.com>; ebxml-cppa@lists.oasis-open.org
><ebxml-cppa@lists.oasis-open.org>
>Date: Tuesday, October 23, 2001 8:17 AM
>Subject: Draft attached this time. RE: [ebxml-cppa] Proposed schema
changes,
>plus illustrative example
>
>
>Omitted in reply
>
>

Draft Proposal for Changes Related to Security (1).doc



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC