issue: example in 3.2 has questionable use of UsernameToken

[Peter Dapkus <pdapkus@bea.com>]

I didn't see an issue covering this on today's issue list:

In section 3.2, the example message shows a signed message where the
signature's keyInfo references a UsernameToken via an STR.  This
suggests that there is some standard mechanism for deriving keys or
otherwise mapping a UsernameToken to a key.  

I think this makes the example questionable because:

1) Key derivation is defined as a non-goal for the standard.

2) The UsernameToken profile doesn't define a method of mapping
UsernameToken's to keys (i.e. no standard key derivation algorithm, no
mechanism for identifying a key derivation algorithm, no method for
mapping a username to a key name or identifier, etc).

While there are clearly a number of cool use cases for keys derived from
user passwords, it's just not something this standard supports.  So it's
odd to see it in the first example of the spec.

I think we should revise the example to use BinarySecurityToken
containing an X509Certificate.

-Pete

-- 
Peter Dapkus <pdapkus@bea.com>