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