Comment Roundup I

A quick roundup of recent comments on entries in the blog.

Sundeep asks about UsernameToken Key Generation:

The label is "WS-Security". What difference is there between it's UTF-8 representation and its ASCII representation ? My understanding is that ASCII is a subset of UTF-8 and since the string is already in ASCII, it's already in UTF-8.

The token specified in Zulu time using xsd:DateTime format is similarly an ASCII string. Why do you warn us to put it in UTF-8 format?

Clearly, you see some difference. Could you please explain it?

My comments are generally an echo of the material in the WS-Trust specification. With particular regard to the label, WSE 2.0 will allow users to set their own label and thus conversion to UTF-8 may be important.

Rich Salz asks about SignedXml:

Any chance of putting back support for standard XML canonicalization? One of our customers found out the hard way -- from their customers -- what WSE 1.0 SP1 only supports exclusive canonicalization.

Sorry Rich, at this time we're not planning to add support for standard ( a.k.a. Inclusive) canonicalization back into WSE 1.0 or WSE 2.0. This form of canonicalization has some limitations and the WSS specification strongly recommends the use of Exclusive canonicalization.

Gia asks about Recipient:

I'm curious to hear what sort of business scenarios do you have in mind that make it essential to be able to select pipeline, target service and policies based on a full set of reference properties instead of single wsa:To header :)

It's no so much about selecting different pipelines or policies as much as about being able to select a specific instance of the target service. The ReferenceProperties in an EndpointReference can behave like cookies if they are reflected back and forth correctly. By way of an example, consider a simple P2P chat program, where every conversation is represented by an instance of the same receiver. By placing information related to the sender in the ReferenceProperties it would be possible to direct messages to different receiver instances (appearing as windows on the display) and thus keep conversations separate. In the same fashion, WS-RM defines Sequences with Identifiers and managing this in a similar means might be desirable. This could be generalized to business conversations between two endpoints. In the end, it becomes a means of maintaining state between two active instances. Now, I'm not saying you *must* use this approach, only that it is there if you needed it.

David ask about SecurityContextToken:

Have you looked at the Caching Application Block the patterns and practices team develops as a means to cache the tokens on the server? That way there would not be another provider interface for caching things, but people could just use the providers that are developed for the caching block already.

Yes, we did look at this pattern. If fact, the design we arrived at does not generally expose the cache object itself at all, only the Add operation. Caches are held within SecurityTokenManagers and the handling of them is therefore the responsibility of the STM, so you should be able to use whatever pattern you prefer.

Posted by herveyw at February 12, 2004 10:22 PM