The
GetBrowserToken
call is used indirectly
by websites
268 CardSpace Implementation
Summary
CardSpace can accommodate a wide range of deployment scenarios.
These range from the simple self-issued token cases,
used for logon to a website, to the more advanced case federation
and Web services scenarios. Less-user-friendly, yet powerful,
direct API calls are available for managed and native
applications.
Regardless of the type of application, the interaction with
CardSpace follows a consistent pattern:
1. Relying party speci?¬?es token requirements.
2. CardSpace is shown.
3. User selects a card that meets the requirements.
4. A token is sent to the relying party.
When the relying party receives the token validation, and
processing also follows a similar pattern:
1. Token is decrypted.
2. Token signature is veri?¬?ed.
3. Token expiration time and other properties are veri?¬?ed.
4. Claims retrieved and used.
The consistency of use across the wide number of scenarios is
part of the power of the Information Card model. This allows the
application or Web developer to look at identity in the same
way and implement consistent rules across applications.
5
Guidance for a Relying
Party
As the previous chapters have made clear, in a variety of situations
it is appropriate for a relying party (RP) to use CardSpace.
Pages:
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399