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 Tuesday, 20 September 2005 17:45:16 UTC