It becomes
increasingly more complicated when the user attempts to do the
right thing but still fails to authenticate. Unlike the case in which
a username and password are used for authentication and the
user makes a mistake in typing in those credentials, if the token
is successfully submitted to the website, it is much less likely
that a mistake on the user??™s part has been made. Figure 5-6
shows the sign-in process.
When the user submits a security token by clicking the Sign In
button, selecting a card, and sending it to the website, the site
?¬?rst mechanically processes the token (decryption and validation).
When the website is con?¬?dent that the token is genuine,
the next step is to determine whether that card is associated with
Putting CardSpace to Work
?– Perspective: Why Show the Experience, Even When the
User Can??™t Use It?
In the beginning, end-user testing revealed that some of the early assumptions
about the presentation of authentication controls on the web page were
painfully counterproductive, and often left the user confused. The goal was to
not only introduce Information Cards to users who might not otherwise know
about them, but to also provide a fast, convenient way to use them in the long
term.
Pages:
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419