Ignoring RSTs that are self-signed and induce creation of issuer-signed assertions bearing RSA public keys as proof-tokens (typically wrapped for access only by an intended recipient), we see the output of a WCF sample project:
Notice that the confirmation field bearing the proof token is just a cleartext RSA public key value (its not encrypted that is).
Similarly, note that the signature on the assertion is not supported by a reference or value to a certificate – but cites (the same) public key value.
We seem to be seeing a very early form of SAML, in its initially simple form.
To all intents and purposes , this is a self-signed certificate.
Now we see the programing model, in which the second or nth call reuses the assertion and RSA signing key stored in the credential structure. The first time, we see that the code can create the two. Of course, if we provide the values in the initiated credential, even the first web service call would use our own assertion and signing key.
This code provides a solid backgrounder behind the notion of the genericXmlSecurityToken – and we can see now clearly how things are supposed to work with proofkeys/securitykeys.
The puzzle pieces are falling into place. We learned to use issuertokenprovider to talk to an STS, using ws-trust suited to requesting asymmetric tokens. We have learned to make a saml credential, that drive ws-security interactions.