How does the STS encrypt the token?

It's unclear to me how the STS is supposed to encrypt the token for the Relying Party, in the RSTR. Specifically, how does the STS obtain the RP's encryption key or certificate The Integration Guide talks about an endpoint reference augmented with identity data in the form of an X509v3 certificate:

<wsa:EndpointReference>

but I haven't seen anything like this coming from CardSpace -- all my STS receives is the wsa:Address for the RP (inside the AppliesTo element), without the wsa:Identity. So, my STS does not encrypt the token, but this causes problems with RPs that expect the token to be encrypted. What am I missing here Is there something I need to put into the STS's security policy

In most of MS samples with federation, the STS signs the SAML token and encrypts the signature part with the RP public key.

I think the same set of questions applies to signature. Actually in samples, the IP has the RP key to encrypt the signature. So

- how the IP can know which RP key use if the IP issues tokens for multiple RP's

- how the IP can retrieve the RP key to encrypt signature and token

- etc....

Is the AppliesTo statement can be used to solve the first question

How is CardSpace being invoked

Per the Tech Ref ( http://msdn2.microsoft.com/en-us/library/bb298802.aspx ), if the RP has included an AppliesTo element in its RST template, you will get that. Otherwise, you will get the RP endpoint data, including the x509 cert.

It looks to me like the RP is providing its own AppliesTo element. In this case, I would expect either a) the RP and the IP/STS to have a business relationship which would enable the IP/STS to look up the public key to encrypt to or b) the RP would include an x509 cert to encrypt to.

Don Isenor wrote:

No response, so I will ask this in a different way... it appears to me that the STS has the option of encrypting the token, or sending it in the clear.

The tech ref seems to say that STSes should encrypt tokens IF they are given any identity information from the AppliesTo tag. If they are not given identity information, I believe CardSpace will encrypt it for them. There is some middle ground here -- if they are given identity information and do not encrypt the token, CardSpace will not encrypt it either -- but what do you gain from this

Don Isenor wrote:

I have noticed that some Relying Parties out there (e.g. Opinity, Pamela Project) expect the token to be encrypted, and throw an exception if is sent in the clear. Which raises several questions for me: 1) Should a RP be able to accept both encrypted and unencrypted tokens

Unlikely. It's possible if they can find STSes which will serve cleartext tokens -- but is this a good idea I'm not convinced.

Don Isenor wrote:

2) Is it ok to implement a RP that accepts ONLY unencrypted tokens

It's ok in the sense that if you had STSes which produced unencrypted tokens, then sure it's technically feasible. But what does it get you

Don Isenor wrote:

2) How is the STS supposed to know which RPs require encrypted tokens, and which don't

If you had some legacy need to support this case, I would expect a business relationship between the STS and the RP. The STS would examine the AppliesTo to make this decision.

Don Isenor wrote:

3) For those RPs that require encrypted tokens, how is the STS supposed to obtain the RP's public RSA key (Keeping in mind that the STS may not have any sort of business relationship with the RP, and vice versa.)

See my response later in this thread.

Answered the question myself.........I have all the information i need in the X509Certificate element!

Dan