Server-to-server channel
Johnny Bufu
johnny at sxip.com
Mon Apr 2 19:18:05 UTC 2007
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
More information about the specs
mailing list