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/
>>
>>
>>
>>
>>
>
>