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, SignOn.com stipulates that first name, last name, and email address are required fields within a registered card. But, Sign.com 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 SignOn.com - including the email address that SignOn.com 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 SignOn.com 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 SignOn.com 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).
Tags:
No comments:
Post a Comment