Server-to-server channel

Dick Hardt dick at sxip.com
Tue Apr 3 23:20:16 UTC 2007


On 3-Apr-07, at 3:05 PM, Anders Feder wrote:

> Dick Hardt wrote:
>> There are two common client server design patterns. Request /  
>> Response
>> and Publish / Subscribe.
>
> I see - I was not aware that the latter model was so well- 
> understood in
> the client/server paradigm.
>
>> 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.
>
> It is, but will automated transactions not make up a significant  
> portion
> of the communications on the service-oriented Web?
>
>>> * 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.
>
> I see the merits of user-centricism, but what happens if a user do  
> want
> an RP to receive an update but the RP is unavailable?

The OP can try again later. The reverse would need to be true if the  
OP was not available when the RP wanted to get the data.

>
>>> * 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.
>
> And rightfully so, because the user selects his OP based on his trust
> that its address structure will not change - this is the key principle
> in OpenID.

The user can change OPs if they are using delegation.

>
>> Well, the OP would be responsible for responding to all the myriad
>> useless RP requests for updated data if a pull model.
>
> Good point :) In most cases you are probably right, but one can  
> imagine
> attributes, especially in futuristic scenarios, which are almost
> inherently 'pull' (like GPS data) such that translating them into
> 'pushes' are immensely ineffective. But I guess 'push' is per- 
> attribute
> optional, in that case?

Who has access to my GPS data is something I will want to tightly  
control!

>
>>> information to RP's it has no direct interest in. A malicious RP may
>>> even exploit this storage space for own purposes.
>> * The OP must donate storage space to support the distribution of
>>
>> The alternative would be the OP would need to donate storage to
>> support which RPs are allowed to ask for data.
>
> Only if the user actually wish to restrict access - and the RP  
> would not
> have access to this storage.

I think we all learned the negative aspects of having our data  
publicly searchable with email and spam.
The FOAF camp was rolling along with the Pull model until they  
realized the issues around access control of the data.

>
> Anyway, I'm convinced you have thought it through. "Pull" relates to
> "push" as quantum mechanics relates to relativistic physics - but very
> often quantum mechanics is overkill.

Not sure I follow the analogy.

Push is actually much simpler then Pull for any kind of sensitive  
data, which is most of the useful attribute data.





More information about the specs mailing list