RE: ID-typed attribute on WS-Addressing EPRs?

ID-typed attributes have known problems.  They can't be recognized
generically as identifiers unless a validation step has performed type
assignment (ID for DTDs, xs:ID for XSD, etc.).  SOAP messages aren't
traditionally validated, as it's deemed too costly and of marginal
value.  Therefore, the best form of identifier for SOAP headers would
not require validation.

WS-Security has overcome this by defining the wsu:Id, which can be
recognized by the security layer as an ID without generic type
assignment.

An even more generic mechanism addressing the problem is xml:id, which
seems a better choice in this context than even a local attribute.  

A local id would require such validation unless a convention was agreed
to with the consumer.  In this case, there already is a convention
recommended - xml:id, as the convention is wider than just
WS-Addressing.  I personally don't see what we'd have to, or could, do
to our spec to allow or encourage xml:id to be used, but am open to a
proposal.

> -----Original Message-----
> From: public-ws-addressing-request@w3.org [mailto:public-ws-
> addressing-request@w3.org] On Behalf Of Jonathan Marsh
> Sent: Wednesday, September 21, 2005 4:37 PM
> To: John Kemp
> Cc: W3C WS-Addressing Public List
> Subject: RE: ID-typed attribute on WS-Addressing EPRs?
> 
> 
> Forwarding to the discussion list.
> 
> > -----Original Message-----
> > From: John Kemp [mailto:john.kemp@nokia.com]
> > Sent: Tuesday, September 20, 2005 10:44 AM
> > To: Jonathan Marsh
> > Cc: public-ws-addressing-comments@w3.org
> > Subject: Re: ID-typed attribute on WS-Addressing EPRs?
> >
> > Jonathan,
> >
> > Thanks very much for your considered response and the attention of
> the
> > working group on this issue.
> >
> > I understand your position to be that the security layer should be
> > responsible for id processing, and thus should define the name of id
> > to
> > be used on WS-Addressing elements, be it wsu:Id or xml:id.
> >
> > My point, however, is that, as you noted below, it is possible to
> > extend
> > WS-Addressing. It is already possible to send arbitrary content in
> the
> > body of a SOAP message. Such arbitrary content, not to mention
> content
> > as defined by the WS-A working group, or WS-A content extended by
> some
> > other party may contain an arbitrary ID-typed attribute for the
> > purposes
> > of signing. As you note, WS-A allows "anyAttribute". This
> > extensibility,
> > however, means that not only is it possible to extend WS-A, but it
> is
> > the case that anyone wishing to interoperate reliably using WS-A,
> and
> > sign WS-A EPRs (for example) *must* extend WS-A, by agreeing to
> > interoperate using some specific ID-type attribute in restricting
> the
> > attribute wildcard allowed by WS-A.
> >
> > In summary, I do not think it is presumptous of the working group to
> > choose a named attribute to identify elements such that the security
> > layer can rely on all WS-A defined content appearing in messages
> with
> > a
> > known ID-typed attribute. It is simply an opportunity to increase
> the
> > chances of interoperability between base implementations of this
> > specification.
> >
> > Regards,
> >
> > - John Kemp
> >
> > ext Jonathan Marsh wrote:
> > > EPRs are attribute-extensible, allowing one to put xml:id or
> wsu:Id
> > on
> > > an EPR for purposes of signing.  I agree xml:id is a good choice
> for
> > > identifying elements, but current security infrastructure based on
> > > WS-Security is probably looking for wsu:Id.  I have argued in the
> WG
> > > that it would be presumptuous of us to tell the security layer
> which
> > > form of ID it should look for.  A convention for ID is good, but
> > will be
> > > most interoperable when the convention is promoted by the security
> > > layer, and not by WS-Addressing in possibly incompatible ways.
> > >
> > > The Working Group agreed with this assessment (at least the verbal
> > > version!) and decided to close the issue with no change.  The
> issue
> > > itself was recorded at [1], which will also have links to the
> > resolution
> > > when the issues list is next updated.
> > >
> > > Thanks for your comment, and the opportunity to explore this topic
> > in
> > > more depth.
> > >
> > > Jonathan Marsh
> > > Microsoft
> > >
> > > [1]
> > > http://lists.w3.org/Archives/Public/public-ws-desc-
> > comments/2005Sep/0014
> > > .html
> > >
> > >
> > >>-----Original Message-----
> > >>From: public-ws-addressing-comments-request@w3.org [mailto:public-
> > ws-
> > >>addressing-comments-request@w3.org] On Behalf Of John Kemp
> > >>Sent: Monday, September 05, 2005 6:32 AM
> > >>To: public-ws-addressing-comments@w3.org
> > >>Subject: ID-typed attribute on WS-Addressing EPRs?
> > >>
> > >>
> > >>Hello,
> > >>
> > >>I notice that WS-Addressing [1] has security recommendations that
> > >>include the signing of elements by those producing EPRs (and
> message
> > >>addressing properties). Such signing usually requires the presence
> > of
> > >>an
> > >>identifying attribute on each signed element. I note that WS-
> > >>Addressing
> > >>does not define any such attribute, but relies on a wildcard for
> > this
> > >>and other attribute definitions. This seems to require that users
> of
> > >>WS-Addressing must define the use of such an attribute themselves,
> > >>prior
> > >>to being able to implement the security considerations recommended
> > by
> > >>WS-A. This implies that one cannot use the basic EPR and MAP
> > >>definitions
> > >>directly from the WS-Addressing specification (if one wishes to
> sign
> > >>EPRs and be interoperable with anyone else.)
> > >>
> > >>In order to aid interoperability of this specification, and
> > >>implementation of the security considerations within, would it be
> > >>possible to specify the use of an ID attribute within the WS-
> > >>Addressing
> > >>specification?
> > >>
> > >>Perhaps best would be to use the recommendation specified in the
> > >>xml:id
> > >>specification [2].
> > >>
> > >>Regards,
> > >>
> > >>- JohnK
> > >>
> > >>John Kemp
> > >>Nokia Corp.
> > >>
> > >>[1] http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/
> > >>[2] http://www.w3.org/TR/xml-id/
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> >
>

Received on Thursday, 22 September 2005 00:09:12 UTC