Echoing Kevin's comments from October on this (http://openid.net/pipermail/specs/2006-October/000223.html)
This model will only fly in the general case when the user or some other non-RP agent is willing to assume all risk/liability for the transaction the user's identity is requesting. Barring this, I think it is reasonable to expect the RP to place some conditions, call them suggestions if you want, that they expect will be followed in order to increase their trust of the asserted identity. I'm not suggesting a change in the spec, just an acknowledgment that the RP has some rights as well in this user-centric design and may not choose to participate in the general model based on only an essentially user-backed assertion . RPs that bear risk will likely only accept identities from IdPs or associations of IdPs that they have agreements in place with that cover exactly how these situations will be handled. Use case example: RP sees activity from an identity that is anomalous to their normal actions. Before the RP processes a risk-bearing transaction, they want to be sure the user is 'really there' and they didn't walk away from their system or have their session stolen - so the RP requests that the user be re-authenticated. We're all familiar with this exact process from credit card companies today when buying patterns change, they are bearing the risk so it is reasonable to expect that they can put in controls to mitigate that risk. -Justin Martin Atkins wrote: > Paul Madsen wrote: > >> Is there not a potential contradiction between an RP expressing both of >> 'this is very very important to me' and 'I leave it to you as to the >> specifics'? >> >> > > Perhaps, but that is the case in both the "IdP reports" and the "RP > suggests" case: either way the IdP is calling the shots, but the "RP > suggests" case is more honest about who is in control. > > > _______________________________________________ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
