OpenID in desktop apps

[Martin Atkins]

Christopher St John wrote:
> 
>> I don't see a big
>> detriment in the user workflow for even a mobile app that pops up the
>> browser and, after auth, returns to the custom protocol of the app (i.e.
>> facebook:///mygarden_is_now_authed), which communicates back to the app the
>> output.
>>
> 
> Well, "current thinking" seems to be that the delegated authc/authz
> dance is a detriment, so saying it's not is controversial (and ref
> evidence that even small impediments to usability can significantly
> reduce user acceptance of security enhancements)
> 

Furthermore, this custom protocol approach bothers me on a few different 
levels:

* From a purely theoretical perspective, making global system 
configuration changes in order to support a local app issue is troublesome.

* I'm concerned about the performance implications of having dozens of 
protocol handlers registered. It's possible that the underlying platform 
was not designed to be used in this way; it'd be good to figure out what 
the impact is.

* I'm nervous about what happens if some random webapp accesses that 
custom protocol. While I'm sure there are ways to mitigate this rather 
more scary variant of "cross-site scripting", if this were to become 
standard practice I'd be concerned about the ability of your average 
developer to implement their custom protocol handlers securely. After 
all, many sites still haven't got regular old-fashioned cross-site 
scripting figured out yet.

Given that a local app already has all sorts of access to my system, 
personally I have no problem with it embedding the web view. In the 
grand scheme of things, I'm more confident about that than I am about 
custom protocol handlers where the concern is not malicious developers 
but rather incompetent developers; the latter of these being much harder 
to detect and potentially more damaging in the long run.