Good questions to tease out the logic behind the architecture Anders, responses to each of your points below ...
On 3-Apr-07, at 6:18 AM, Anders Feder wrote: > Johnny Bufu wrote: >> This is basically a push approach, as opposed to the pull approach >> you were suggesting. > > I'm new to OpenID, and no engineer, but I have to say that I have a > bad > feeling about this 'push' approach. It inverts the relationship > between > client and server and seems entirely contrary to the stateless > spirit of > the Web: There are two common client server design patterns. Request / Response and Publish / Subscribe. > > * The RP can't know the status of the information it is working with - > it just have to assume that the attributes it has in store are up- > to-date. The RP has what ever the user last gave the RP. If the user is involved in the transaction, the RP may ask the user for up to date information. Note that your concern is constrained to situations where the user is not involved. > * If an OP fails to update an attribute, the RP will never know - no > fall-backs can be implemented. When the data changes, the user then decides if the RP gets the data. If the user did not want the RP to get, well that is what the user decided. This is user centric after all. > * When updating, the OP impose a previous address structure upon the > Web, regardless of how it is actually organized now. The converse would be the RP imposes an address structure on the OP on where to get the updated data. > * While the RP's requests the information, the OP is made responsible > for doing the work associated with distributing it. Well, the OP would be responsible for responding to all the myriad useless RP requests for updated data if a pull model. Now the OP and RP only need to move data if the data has changed and the user wants to push the update to the RP. > * The OP must donate storage space to support the distribution of > information to RP's it has no direct interest in. A malicious RP may > even exploit this storage space for own purposes. The alternative would be the OP would need to donate storage to support which RPs are allowed to ask for data. > * Attributes are not easily referenced to, say, sub-contractors of an > RP. The model impose limits upon the complexity of the services > that may > be derived from it. The same flow could happen between the RP and dependent services. _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
