Not all data relating to the user will
be sent to the RP via the security token. Although current
systems tend to allow unrestricted access to the identity
store by the application??”they often share a common
database and service layer??”some information about the
user is better off left out of the token. In a scenario where
an online retailer issues Managed Cards for their users,
the retailer wouldn??™t embed information such as the purchase
history, search preferences, or shipping information
selections into the token.
Maintaining a consistent user experience. If the organization
is adding breadth to its user base by accepting
Information Cards from providers via federation??”in addition
to their own??”their own users would be issued
Information Cards, too, and once authenticated via their
own STS, all users would experience the site the same.
Changing certi?¬?cates. When an IP issues security tokens,
each token is signed with the private key of the certi?¬?-
cate that identi?¬?es the IP. The RP will need to have the
321
certi?¬?cates of the IPs whose tokens it accepts. To handle
the event where an IP gets a new certi?¬?cate, a communication
channel should exist between the IP and RP that
noti?¬?es the RP of changes to the certi?¬?cates.
Pages:
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462