[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] Alignment with Web Services Security
With some help from Eve Maler and a few other folks I understand better why WSS chose xsd:ID as type for wsu:Id. The reason wsu:Id needs to be an ID is because of backward compatibility with XML Signature which expects the signature target to be referenced via an ID attribute. The only other alternative is to use an XPath expresson which is more complicated and inefficient. The real source of the problem is that the xsd:ID attribute definition restricts xsd:NCName which does not allow ':' as a character which eliminates the possibility of using a URN as an id. So it seems that WSS cannot "fix" this problem. The question is how does is impact our use of WSS? Farrukh Najmi wrote: > Chiusano Joseph wrote: > >> Farrukh Najmi wrote: >> >> >>> 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. >>> >> >> >> Ah - now I see the issue more clearly; the case above involves signed >> registry requests being used in conjunction with WSS. Would there still >> be a problem, however, with using wsu:Id in this case if it is only to >> denote which elements in the SOAP body are signed? We are still not >> accessing registry contents in this case. >> >> > I am not certain if there is a problem or not. We use id attribute as > contentId > within mime attachments which MUST be signed. To refer to them we would > like to use the same ids. > > Would you have some time to look into what changes it would take to move > our specs to support WSS and see where the fault lines are w.r.t this > issue? > >> Joe >> >> >> >>>> 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 <karl.best@oasis-open.org> >>>>>>> Reply-To: karl.best@oasis-open.org >>>>>>> Organization: OASIS >>>>>>> To: members@lists.oasis-open.org, >>>>>>> tc-announce@lists.oasis-open.org >>>>>>> >>>>>>> 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 >>>>>>> karl.best@oasis-open.org 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. >> >> >> >> > > -- Regards, Farrukh
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]