[OpenID] One developer's first encounter with account chooser (openid connect?)

[Peter Williams]

Let me withdraw the Microsoft comment. The 2012 visual studio release tools showcasing OAUTH/openid interaction into webapps work just fine, *out of the box*. Certain patterns of using the tool’s “designers” for so-called user controls cause an automatic code generator to produce unlinkable code in oauth-related modules, as an HTML control is reflected in a so-called code-behind (designer) file. But that's my issue, not theirs. I have to master the tool, including its weirdisms. When machines start to think, they tend to confound me..

 

Out of the box and as I established all during the last year with the various beta releases of the tool chain, the visual studio templates for federated logon in the Microsoft  “showcase” webapp designs do a superb job of federated login - using opened/oauth (in addition to other protocols). This is what I would expect of Microsoft (after the passport debacle, and the wholesale rethinking of how to deal with the cryptopolitics on the SSO topic); and they delivered a politically-sensitive and technically flawless delivery of how to make your typically web app augment a local login with a federated login. This enables users to bind 1 or more IDPs names to a locally managed account (with a local “fallback” IDP, even). Of course, its very similar in concept to how openid plugins traditionally integrated with wordpress SP (similarly binding several openids to the wordpress account).

 

Now, I don't want to be an old, out-dated stick in the mud, prevent modern “apps” from app stores offering a much more device-centric and highly constrained interaction with users. A web-centric SSO-enabled “App” delivering an experience in the APP side of windows need not behave as does the traditional webapp in the traditional browser, now running in the so-called desktop-side of windows (8). Security features you have long had (but probably never used) may not be there, in app mode. You probably wont even miss them... in that constrained experience.

 

To lock down and secure the consumer (against now 2 decades worth of never-ending malware), I don't mind app stores - and design patterns for developers of apps -- enforcing VERY limited (web) app designs - that strip from consumers most of their security options (hard won, by years of cryptopolitics). And, there is no reason why a plugin to wordpress should not “constrain” a particular deployment of wordpress to fit into that APP-centric world, where the APP (i.e. wordpress) is in “total lockdown” mode (to fit with the rest of the App security concept). 

 

Google just needs to distribute and promote two version of its plugin for wordpress: one for locked-down APP deployments, and one for traditional wordpress hosting for traditional browsers. locked-down app-centric wordpress - seem now as just another easy to deploy “APP” plugged into a store - can be seen as projection of the store and its lockdown policies, rather than an independent site. Given such dependency, the moment you as a user lose status at the store, you will lose all your access to those 100 apps - too. And the APP-centric  wordpress-deployment can help enforce that rule. Whether consumers like his kind of managed web or not, we will see...

 

Personally, I have no time for the cryptopolitical extremists who would deny consumers the lock down APP experience, arguing that all the web must be the traditional (vulnerability-laden, malware-trust destroying) concept - merely to preserve crypto freedoms most of us only use 0.1% of time, if even that. So long as one can swap over into the freer but MUCH more vulnerable open mode, occasionally, I’m happy. 

 

Cryptopolitics is just politics and thus needs to keep pace with evolving social attitudes and priorities. Since we are now in the trust-finding phase for what is now the third decade of the personal crypto-era, I don't mind exploring the boundary between lockdown (no freedom) and traditional web (freedom, at the cost of suffering the cost of incessant malware). Microsoft seem to have done a wonderful job finding a political balance there, allowing a split-brain interaction with the web (windows 8 in locked-down app mode, vs windows 8 in traditional PC mode). And this include recommendations to site designers on just how you design your web app, to fit with both experiences of the web.

 


From: Peter Williams
Sent: ‎October‎ ‎17‎, ‎2012 ‎12‎:‎04‎ ‎PM
To: openid-general at lists.openid.net
Subject: [OpenID] One developer's first encounter with account chooser (openid connect?)





In a word: frustrating. http://wp.me/p1fcz8-2YW. It was frustrating on multiple levels.
 
Obviously the code is fixable, but one worries about the very "idea" - there seems a desperation in the desire to remove local IDPs - including those granting access to privileged administrator configuring (broken) federated logon!
 
To be fair, the default Microsoft ASP.NET web app project built by the released version of visual studio 20102 doesn't work, either - when taking up the federated (OAUTH/openid) login option and its display of a set of IDPs, configured locally. It doesn't even compile, link and load! Thus, I have not even so far as work with its attempt to showcase Openid Connect, or see if things interwork yet with Google's implementation, etc.
 

Sent from Windows Mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20121018/51ac1102/attachment.html>