| RE: [higgins-dev] AppliesTo in the RST |
|
Thanks Andy,
I was looking the
WS-Trust specs which don't have such requirement.
If this is required for
CardsSpace and if Mike is adding support for encrypted tokens, then I am sure he
will do it
in a configurable manner
so we, the non-cardspace users of Higgins can turn it off :-)
George From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Andrew Hodgkinson Sent: Friday, March 07, 2008 2:42 PM To: Higgins (Trust Framework) Project developer discussions Subject: RE: [higgins-dev] AppliesTo in the RST Hi George, Section 7.2 of the icard tech ref states "One of the significant goals of the Windows CardSpace system is to ensure that any claims the system releases are exposed only to the Relying Party intended by the user. For this reason, the system encrypts the self-issued token under the key of the Relying Party before sending it. This guarantees that a token intended for one relying party cannot be decoded by (or be meaningful to) any other." This paragraph, of course, pertains to the SIP. I don't see anything in the spec that requires the STS to encrypt the token, but it seems like it should be a best practice, or at very least, an option that can be configured. If the STS doesn't require the appliesTo information, the selector will extract the token from the RSTR and encrypt it prior to passing it to the relying party. If appliesTo is sent to the STS, the selector will pass the token to the relying party without performing any encryption. Thanks, Andy Hi Daniel,
Where in the specs does it state that if AppliesTo is present, the token must be encrypted?
G eorge Mike,
It doesn't look like the STS encrypts a token when the AppliesTo element is sent in the RST. The specification says that it is the responsibility of the STS to encrypt the token in this case. Is that how you understand it? If so, is there some configuration option I need to set to ensure that this happens? If it is not currently implemented, do you have any plans to implement this anytime soon?
Thanks,
Daniel
********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. **********************************************************************
|