In addition, an IP may choose to only allow a card to be
used at a speci?¬?c set of sites. By evaluating the site certi?¬?cate, it
could enforce this policy. This could be used by an IP to protect
high-value identities, limit where the card can be used, and
prevent malicious sites from being able to request the
information.
Because the IP is now responsible for doing the token encryption,
CardSpace will pass the token back to the website, unmodi
?¬?ed. This means that if for some reason the IP does not encrypt
the token, it will be sent to the site in the clear. This ?¬‚exibility
allows IPs and websites to agree upon their own encryption
strategies, which CardSpace does not need to understand.
Although this can be useful, it also puts an extra burden on
IPs to ensure they are doing the right thing and not sending data
in the clear that should be encrypted. See Chapter 6 for more
details.
Different security
assurances are
available to auditing
and nonauditing
IPs
248 CardSpace Implementation
Federation with CardSpace
The deployments covered so far are common for many websites.
In these cases, somebody acting as an individual wants to
access a site. A more advanced scenario is when somebody acts
as a member of an organization, and that person then wants to
access the resources maintained by another organization.
Pages:
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374