Reconciliation.NET

I've long enjoyed Vittorio's Vibro.NET, so I was interested to see him post a comment on a thread between Ashish and I on how a Cardspace (or more generally, any ID system) RP might reconcile the profile data they already have with that they might ask for through a card.

Vittorio links to a long piece of his called 'The Tao of Claims' in which he

describe(s) why claims are important for every developer and architect (not just the security expert), and I provide some heuristics for helping everybody to reason about claim based systems

Vittorio proposes a principle of

You want to receive in form of claims what you'd have an hard time finding out by yourself

Applied to the issue of whether an RP should be asking for profile data, Vittorio identifies three scenarios and uses the above principle to assess the relevance of the RP asking for profile data through card claims.

1) the RP can't store the profile data
2) the RP can store the profile data
3) the RP can store the profile data but wants to ensure that it has the freshest

For the 1st and 3rd, Vittorio argues that the RP can legitimately ask for the profile data each time through claims in a card. I agree.

For the 2nd, Vittorio asserts that it doesn't make sense for the RP to ask each time, rather it should just authenticate the user and get the other data from the existing profile. I agree.

SignOn.com is Case 2 and so, by Vottorio's criteria, should not be asking for profile data in the card each time. But I think Ashish will agree that they shouldn't be doing this, but rather that they feel they need to to get the UI functionality they want for the account page.

Note: Of course, Ashish can also argue that Vittorio's principle 'ask through cards only if you can't otherwise determine' gives SignOn.com the moral authority it needs - it wants a human recognizable card mnemonic, and can't get it otherwise.