Chris, On 2-Apr-07, at 11:50 AM, Chris Drake wrote:
> I've also noticed a lot of discussion about attributes, which begs the > question about how to handle things that change (eg: If I've given out > my email address to a dozen web sites, and then I change it, how does > my OpenID server propagate that change to all those sites?) > > "User Centric" implies that sites don't store anything about me, and > that whenever they need to know stuff (eg: my email), they instead ask > my OpenID server, which returns them the answer (unless I've since > revoked permission or whatever). Again - server-to-server (although > this time in the reverse direction) applies here. I'm not sure I fully agree on you reasoning above (about sites not storing anything about me). OpenID Attribute Exchange deals with the attribute updates - see the "update_url" parameter in fetch requests [1]. The flow would be: - RP informs the OP where the RP can be updated of changes in attribute values - user changes the value of an attribute - OP prompts the user with the list of RP who 'registered' for change notifications for that attribute - if the user approves, the OP pushes the new values to the selected RPs. This is basically a push approach, as opposed to the pull approach you were suggesting. The pull approach would add (unneeded) complexity with authorization management. Also I don't see how the user-centricity could be enforced -- the user / OP can't restrict RPs from storing the data they need, once the data is released. Is there a use case / feature that can be accomplished with the pull model, that cannot fit within what I've described above / current AX draft? Johnny [1] http://openid.net/specs/openid-attribute- exchange-1_0-04.html#fetch_request _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs