- From: Andrei Sambra <andrei@fcns.eu>
- Date: Thu, 05 Jul 2012 16:08:33 +0200
- To: nathan@webr3.org
- CC: public-webid <public-webid@w3.org>, Read-Write-Web <public-rww@w3.org>
Hey Nathan, On 07/05/2012 04:04 PM, Nathan wrote: > Hi Andrei, > > I've been looking at the MyProfile use case for delegated auth, and have > one primary question, why is MyProfile doing the requesting and caching, > could the user themselves, via a js application, not fulfil this roll, > levering standard browser caching where needed - I'm unsure why the > man-in-the-middle is needed? > Because if a user with 200 friends logs back again after a long period of time (long after the cache has expired), it will trigger a cache refresh for all of his 200 friends in the same time. Also, a cache refresh can also be triggered by an external event (i.e. someone updating a profile and notifying all his/her friends). In this case, the user would have to login and manually refresh the cache through a button/link. > This has no bearing on whether a delegated auth is required or not > generally, just interested to look at whether it's the only solution, > and keen not to push traditional "app on the server" mentality when it > isn't required, especially in a RWW context. > > Best, > > Nathan > > Andrei Sambra wrote: >> Hello everyone, >> >> After yesterday's discussion with Henry and Mike Jones during the >> teleconf, we decided to continue the thread "delegated authentication" >> by providing real use cases, in order to better identify what needs to >> be done. On the other hand, the issue of delegated authentication is >> not specific to WebID, as it rather concerns access control. I am sure >> there are more W3C groups (e.g. RRW) interested by this, so please try >> forward this message to whom it may concern. >> >> I have added a use case specific to MyProfile to the existing >> "Delegation" wiki page [1]. Please feel free to add more use cases >> corresponding to your needs. >> >> Andrei >> >> [1] http://www.w3.org/wiki/WebID/Delegation#Use_cases >> >> >
Received on Thursday, 5 July 2012 14:09:04 UTC