[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