What are the options/best practices for authorizing individual Web Service
methods that are being made under the protection of WS-SecureConversation?

The pattern I have in mind is:

1) The web service client is initially authenticated using a custom
username/password (stored in a backend database) while the
WS-SecureConversation machinery is being set up. (No problems in this part).

2) Subsequent web service calls made by the client are now secured and
authenticated, but how can authorization checks be performed on them at call
time, since different web service calls may have different privilege
requirements?

In particular, I can't see how to obtain a Principal/Identity from the
DerivedKeyToken that is being used to encrypt the subsequent web service
requests.

This seems like it should be a fairly common usage pattern, but everything
I've read so far appears to discuss WS-SecureConversation and authorization
separately, and I can't seem to get my head around how these should be made
to work together.

Should I be exploring:

i) A solution based on custom security tokens?  Binary or XML?
ii) Adding some sort of custom SOAP header?
iii) Some sort of session state based solution?
iv) Something else altogether?

I'm still holding out hope that this problem is straightforward and I've
just managed to miss some key point... Regardless, any insights much
appreciated!

tim