Where the user gets the Assertion from ? IDP ? In the federated example/SSO it was clear what the relationship between user/SP/IDP was. with the Wsse I kind of don't get the full picture.
This has to be profiled within some other specifications. The SAML specifications profile a few cases such as browser based SSO, but do not profile a web services use case.
The Liberty Alliance ID-WSF specifications do profile this use case including defining an Authentication Service (which would typically be exposed by the SAML IdP), Discovery Service, and Application Service invocation framework.
The Service somehow will have to trust the Asserting party even though in different trust domains ? Or this means that the user can only be authenticated in his trust domain ?
The Service will need to accept ("trust") the statements made by the issuer of the assertion (assuming the client met the terms of the subject confirmation and conditions). I would say this means that the Service is in the same trust domain as the issuer (not necessarily the same as the client as it's the issuer that is important for the recipient).
The SAML message will need to contain all the information necessary to the Service A to make the decision. I mean Service A don't need to go somewhere else to check that the assertion is valid as he has got all the info he requires. I guess it's here where subject confirmation might come in place ?
I would not say this is a SAML message. I would say this is an application message that carries a SAML assertion within the security context for the message. The profile that I spoke about above would need to profile things like what are the requirements for binding the assertion to the message.
Note that Service A could validate the token itself, or could send it to some other party to do the validation (such as the issuer). I know of some implemetnations that have done this in order to ease the implementation at the recipients.
Another alternative, btw, if you are going to use non-signed messages, is to use the WSS SecurityTokenReference to carry a reference to the token so the SP can retrieve the token directly from the issuer (this can have substantial savings in processing as in many cases the token won't need to be signed since it is going directly from the issuer to the relying party rather than going through a third party.