One aspect of the InfoCard design is the separation between self-issued card interactions, in which the user generates a card and types in their claims values to be sent to the relying party, and managed card interactions, in which an identity provider stores and (indirectly) transfers the values of claims to the relying party. In the self-issued interaction, no identity provider is involved, and the claim values are known only to the user and the relying party. When an identity provider is involved, claims may be made "on behalf" of the user.
I don't think Mark is alone in this confusion.
Here's what I think an IdP does. An IdP provides testimony regarding the accuracy of claims. An IdP does not function as some sort of repository where users create, store, and manage information about themselves. It's the IdP (managed card case) that creates and maintains these records about users. It consults those records as a means to back up the testimony it provides. That is not to say that an IdP will not provide a process by which a user can review and correct any of those records; any reasonable IdP will. However, an IdP (of managed, not self-asserted, cards) isn't going to modify its records or change its testimony just on a user's say-so.
One of the consequences of Law 3 is that it makes most sense for an IdP to provide testimony regarding the accuracy of claims if it's already their business to know. For example, it's my employer's business to know my employment status, so they can testify about that; it's a university's business to know a student's grade point average, so they can testify about that; it's my bank's business to know about my ability to pay, so they can provide that testimony; and so on ...
What Information Card technology does as far as user control is concerned is provide the user with the choice about who gets to see that testimony.
In the OpenID community, some try to use the phrase "OpenID Provider (OP)" in an attempt to discourage such confusion.
0 comments:
Post a Comment