CardSpace introduces a different model, one called user-centric
federation. RPs can request a token with speci?¬?c kinds of
claims, and any Information Card the user has that satis?¬?es those
claims can be used. The RP requires no prior knowledge of the
IP (however, to trust anything in the token, the RP should know
the IP??™s identity, such as the IP??™s public key), and the IP doesn??™t
have to con?¬?gure anything else to work with another RP.
User-centric federation changes the story somewhat; instead of
having the IP and the RP make all the decisions as to what identity
a user uses in a particular context, it allows the user to make
the choice of which identity to use. Exactly what kind of information
is provided, and under what circumstances, depends
entirely on the situation. Let??™s look at some examples of where
user-centric federation using CardSpace could be used:
Connecting to sites in partner programs.
Airlines already create alliances between them where
customers can use their frequent-?¬‚yer accounts with
other airlines in the alliance and collect points in a
single account. Taking this to the next logical step, an
airline website could allow a customer to sign in with an
Information Card provided by any other airline in the
alliance and receive all the relevant information needed
to book a trip from a security token.
Pages:
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471