David RR Webber wrote:
>Farrukh,
>
>Surely if people are looking to sign content - the ebMS interface
>already provides all that functionality - no need to re-invent the
>wheel here.
>
>
Hi David,
ebRR specs have requires signing content (and metadata) since 1.0.
This feature has to be supported on ebMS and SOAP which is also
a long standing requirement.
We are talking about replacing our wheels after 60,000 miles with
a brand of tires that is likely to be achieving a monopoly in the tire
market and if we choose different tires then we will not be able
to race with the other cars ;-)
>DW.
>
>----- Original Message -----
>From: "Farrukh Najmi" <>
>To: "Chiusano Joseph" <>
>Cc: <>
>Sent: Wednesday, March 10, 2004 9:20 AM
>Subject: Re: [regrep] Alignment with Web Services Security
>
>
>
>
>>Chiusano Joseph wrote:
>>
>>
>>
>>>Thanks Farrukh. Could you please elaborate more concretely as to how
>>>this would affect any use of WSS with our Registry specs? On the surface
>>>I'm not seeing the connection...
>>>
>>>IOW, how would wsu:Id be used within a WSS Security SOAP header to refer
>>>to an entity that is registered within an ebXML Registry? I see it
>>>referring to security tokens - are you leaving open the possibility that
>>>the Registry could serve as a certificate store, perhaps?
>>>
>>>
>>>
>>>
>>Thanks Joe. You are correct that in many cases the use of wsu:Id would
>>be limited
>>to referencing security tokens and there is no concern in such cases
>>since registry
>>objects and their ids are not involved.
>>
>>But as I understand things, that is not all that is possible....
>>
>>The "Web Services Security: SOAP Message Security 1.0" spec at line 375
>>states:
>>
>>"There are many situations where elements within SOAP messages need to
>>be referenced. For example, when signing a SOAP message, selected
>>elements are included in the scope of the signature."
>>
>>I am assuming that if we specify which elements in our soap body are
>>signed using their id then
>>we would run into this problem. There may be other situations that we
>>cannot see right now
>>as well.
>>
>>
>>
>>
>>>Joe
>>>
>>>Farrukh Najmi wrote:
>>>
>>>
>>>
>>>
>>>>Chiusano Joseph wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Here is some additional information on wsu:Id which may or may not
>>>>>change our perspective:
>>>>>
>>>>>- The wsu:Id attribute is defined so that recipients don't have to
>>>>>understand the full schema of the message for processing of the
>>>>>
>>>>>
>security
>
>
>>>>>elements;
>>>>>
>>>>>- The wsu:Id attribute provides a well-known attribute for specifying
>>>>>the *local ID* of an element - that is, the ID of an element within an
>>>>>XML document;
>>>>>
>>>>>- The WSS SOAP Message Security specification does not specify how this
>>>>>attribute will be used, and "it is expected that other specifications
>>>>>MAY add additional semantics (or restrictions) for their usage of this
>>>>>attribute."
>>>>>
>>>>>- There are multiple places in the WSS SOAP Message Security spec in
>>>>>which the wsu:Id attribute is defined as a "string label" (ex: line
>>>>>
>>>>>
>528)
>
>
>>>>>rather than as type xsd:ID - not sure if a URI would be considered a
>>>>>"string label";
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>The bottom line is the definition:
>>>>
>>>><xsd:attribute name="Id" type="xsd:ID">
>>>>
>>>>within http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-
>>>>wss-wssecurity-utility-1.0.xsd
>>>>
>>>>which makes it quite unusable for us.
>>>>
>>>>A simple fix would be to change above to:
>>>>
>>>><xsd:attribute name="Id" type="xsd:string">
>>>>
>>>>That would addres my main concern with this spec.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Joe
>>>>>
>>>>>
>>>>>Farrukh Najmi wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Team,
>>>>>>
>>>>>>The Web Services Security 1.0 specs are in OASIS member review for
>>>>>>becoming an OASIS standard
>>>>>>(see announcement below from earlier this month).
>>>>>>
>>>>>>I would like to propose that we consider the issue of whether we
>>>>>>
>>>>>>
>should
>
>
>>>>>>align V3 with the WSS
>>>>>>specs.
>>>>>>
>>>>>>I have read the specs and have found one small but significant issue
>>>>>>
>>>>>>
>for
>
>
>>>>>>its use by us.
>>>>>>
>>>>>>Section 4 of the The " Web Services Security: SOAP Message Security
>>>>>>
>>>>>>
>1.0"
>
>
>>>>>>spec
>>>>>>specifies wsu:Id as an xsd:ID type. This prevents the possibility of
>>>>>>using URI or UUID as an id.
>>>>>>This is an unfortunate restriction because many systems (including
>>>>>>
>>>>>>
>ebXML
>
>
>>>>>>Registry) use urn:uuid based ids and also other
>>>>>>URNs as ids.
>>>>>>
>>>>>>Recall that we ran into this exact situation in ebXML Registry specs
>>>>>>
>>>>>>
>and
>
>
>>>>>>decided to change the type of our id attribute
>>>>>>to string from xsd:ID.
>>>>>>
>>>>>>This issue need to be addressed IMO by the WSS TC in order for us to
>>>>>>
>>>>>>
>use
>
>
>>>>>>the WSS specs.
>>>>>>If it were addressed then I would be in favour of aliging with this
>>>>>>
>>>>>>
>spec
>
>
>>>>>>for ebXML Registry version 3.
>>>>>>
>>>>>>Thoughts.
>>>>>>
>>>>>>--
>>>>>>Regards,
>>>>>>Farrukh
>>>>>>
>>>>>>-------- Original Message --------
>>>>>>
>>>>>>Subject: [OASIS members] WSS specification submitted for OASIS
>>>>>>
>>>>>>
>Standard
>
>
>>>>>>Date: Mon, 01 Mar 2004 08:31:59 -0500
>>>>>>From: Karl F. Best <>
>>>>>>Reply-To:
>>>>>>Organization: OASIS
>>>>>>To: ,
>>>>>>
>>>>>>OASIS members:
>>>>>>
>>>>>>The OASIS Web Services Security TC (WSS TC) has submitted the Web
>>>>>>Services Security v1.0 specification, which is an approved Committee
>>>>>>Draft, for review and consideration for approval by OASIS members to
>>>>>>become an OASIS Standard. The TC's submission is attached below.
>>>>>>
>>>>>>In accordance with the OASIS Technical Process, the specification has
>>>>>>already gone through a 30 day public review period. OASIS members now
>>>>>>have 15 days to familiarize themselves with the submission. By the
>>>>>>
>>>>>>
>16th
>
>
>>>>>>of the month I will send out a Call For Vote to the voting
>>>>>>representative of each OASIS member organization, who will have until
>>>>>>the end of the month to cast their ballots on whether this Committee
>>>>>>Draft should be approved as an OASIS Standard. OASIS members should
>>>>>>
>>>>>>
>give
>
>
>>>>>>their input on this question to the voting reps of their respective
>>>>>>organizations.
>>>>>>
>>>>>>The normative TC Process for approval of Committee Drafts as OASIS
>>>>>>Standards is found at
>>>>>>http://www.oasis-open.org/committees/process.php#standard
>>>>>>
>>>>>>Please note that statements related to the IPR of this specification
>>>>>>
>>>>>>
>are
>
>
>>>>>>posted at http://www.oasis-open.org/committees/wss/ipr.php
>>>>>>
>>>>>>-Karl
>>>>>>
>>>>>>=================================================================
>>>>>>Karl F. Best
>>>>>>Vice President, OASIS
>>>>>>office +1 978.667.5115 x206 mobile +1 978.761.1648
>>>>>> http://www.oasis-open.org
>>>>>>
>>>>>>To unsubscribe from this mailing list (and be removed from the roster
>>>>>>
>>>>>>
>of the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
>
>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>To unsubscribe from this mailing list (and be removed from the roster
>>>>>
>>>>>
>of the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
>
>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>--
>>>>Regards,
>>>>Farrukh
>>>>
>>>>
>>>>
>>>>
>>>To unsubscribe from this mailing list (and be removed from the roster of
>>>
>>>
>the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
>
>
>>>
>>>
>>>
>>--
>>Regards,
>>Farrukh
>>
>>
>>
>>To unsubscribe from this mailing list (and be removed from the roster of
>>
>>
>the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
>
>
>>
>>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
>
>
>
--
Regards,
Farrukh
