Wednesday, October 17, 2007

Reconciliation allows you to use either a password or Infocard to authenticate (and can now (indirectly) distinguish between the two to SPs through PAPE).

Before you can use an Infocard to authenticate you must 'register' the card - which entails sending the card to SignOn while simultaneously authenticated through the password (effectively federating the new card to the existing password account, although you won't hear it called that).

The fact that the existing account already has profile information, and the card being registered into that account may have (not contain) some, creates some disconnects.

For instance, stipulates that first name, last name, and email address are required fields within a registered card. But, already has all 3 pieces of profile within my existing account - I provided them on the initial account set-up.

I was forced to edit the card before sending it to - including the email address that already had. Given that the user is necessarily logged in at registration time, couldn't the card registration page be dynamically built so as to present a customized list of required attributes?

The fact that asks again for the information rather than rely on that already in the existing profile creates its own problems, because the first & last name values I have 'in' the card is not the same as that already in the account profile. What's more, when I now see my profile page, the information I shared through the card has been discarded, or at least isn't been displayed.

My takeaway, SPs (as is acting as in this case) must be able to reconcile identity obtained from multiple sources - from the user themselves, and from different IdPs. And reconciliation includes not asking for the attribute if you already have it (unless the associated metadata like freshness and assurance is insufficient).

No comments: