One idea was to sketch out the value/depth of a relationship between a user and some service provider as a function of time. We posited that the depth would climb smoothly over time, starting from zero.
Over time, the depth of the relationship grows, one manifestation of which is the collection of user attributes by the SP.
Federated identity makes (perhaps theoretically) possible a model in which a relationship can be 'jump started' with identity, these attributes collected from an IDP rather than through successive transactions between the SP and the user.
From the PoV of the user, this step-function establishment of the relationship may feel artificial, as the depth (as determined by the attributes the SP has) does not reflect any shared history. It may also feel artificial to the SP.
An 'identity collection model' that better aligns to the 'slow growth' relationship curve is one in which the SP obtains the user's identity on a JIT basis. Rather than try to obtain identity attributes in anticipation of future need, the SP waits till it actually requires some attribute.
(Bob Blakly made the point in his relationship talk at IIW that, because of the associated risks, SPs will more and more think of identity as 'hand grenades', i.e. something you don't hang on to longer than absolutely necessary. The flip side of throwing the hand grenade as quick as possible is of course only asking for it when you really need it.)
For this to work, the SP & IDP will need the ability to reach out to the user on a JIT basis to both collect attributes and clarify consent, and not rely on the user's erratic surfing schedule.
No comments:
Post a Comment