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

[Peter Williams]

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

 

[Nat Sakimura]

Perhaps you can join Account Chooser WG and give your formal feedback so that the WG can incorporate them? 

Nat

_______________________________________________
general mailing list
gen...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general

--
Nat Sakimura (=nat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

[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.

[Peter Williams]

Thankyou but no. General comment is my limit, given the wider implications of membership, etc. General comment is what this list is for.

 

But, to be fair to Google, I did conclude my original idea (simply making wordpress talk to an IDP, leveraging the Account Chooser intermediation, with auto-account creation). I wrote up my own little efforts at a trial at http://wp.me/p1fcz8-30a. It says... the technology works. Then some of the implications of “working” integration are explored, without being academic.

 

If I was more sociable, perhaps Id have been on some Account Chooser or wordpress plugin list that could have given direction, earlier. At the same time, by operating blind, its been useful to view the integration very skeptically. Questioning the policy implications of the intermediation service came about from the nature of the technology integration itself, being obvious. I’m left with a stronger question to now ask: would I want it (now it works)?

 

Its been a little unfair to target to Google and so publicly be critical - since their enforcement technology is so clearly well done (and its all probably still formally a beta rollout). Clearly, national-scale mandatory security policy enforcement via websso has take a strong leap forward.  The questions now are: are the TTPs policy rules right? Where is involvement of a TTP-class IDP or IDP trust broker even appropriate?

 

Do any other vendors have public trials? Id like to figure if the policy enforcement is essential to the opened connect concept, or its just a google value add (for its business model).  If I think back to our  first efforts with SAML, the VERY first thing we did was abandon the Shibboleth community’s policy control concept...the abandonment of which turned out crucial for the adoption of websso in a more decentralized (and economically vital) community with a strong aversion to centralized policy management ... of ANY kind. The same kinds of questions are increasingly pertinent for opened connect, evidently.

 

Sent from Windows Mail

 

From: Nat Sakimura
Sent: ‎October‎ ‎17‎, ‎2012 ‎6‎:‎44‎ ‎PM
To: Peter Williams
CC: openid-...@lists.openid.net
Subject: Re: [OpenID] One developer's first encounter with account chooser (openid connect?)

 

Perhaps you can join Account Chooser WG and give your formal feedback so that the WG can incorporate them? 

Nat

On Thu, Oct 18, 2012 at 4:03 AM, Peter Williams <hom...@msn.com> wrote:

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

 

_______________________________________________
general mailing list
gen...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general

[Nat Sakimura]

You do not need a membership of OIDF to join a work group. 

For a work group to take up any technical content, the author of the content has to sign the IPR Contribution Agreement, and that is the only requirement. I am sure you understand we need the contribution agreement, since otherwise it may cause IPR pollution and cause a lot of problems down the road. As such, the WG cannot incorporate any comments made in General list, as it is not IPR protected. 

Wrt the implementations, the AC WG is working on the spec that people can implement independent of Google toolkits. 

So, eventually, you will start to see other implementations from other people than Google. 

Nat

[Peter Williams]

Well I should give apologies to Google, as there IS a local login function in its account creator wordpress integration. Though ...it did take a week to find it. If you type a local account name into the box labeled "email", it does a classical local login (with local password challenge).
 
So of the two parties I wacked as wrong, both were actually right. So much for Peter.
 
OK,  so for my penance at wronging Microsoft, I taught myself to use the firms asp.net website hosted in its azure cloud platform, that comes with OAUTH consumer  capabilities, etc. And it was good. It's consumer friendly, targeting the typical webmaster/mistress. I paid my dues by constructing an open source plugin, that allows any site to talk to an OAUTH v1.0a provider plugin in any suitably-enhanced wordpress instance deployment. This also helps me with work on Mozilla's persona, since they are thinking about oauth (which I now finally dominate, at least up to OAUTH v1.0a).
 
For my penance with Google, Ill now add the GIT (aka account chooser) toolkit to the wordpress site that is acting as my IDP (i.e. oauth provider). I will now allow users to register via the account chooser experience, too. I think this means that the site will rely on the "verified email" id during registration  for those who use account choose registration means - and will then issue its own oauth protocol messages to its own downstream consumers who do a "local login", if the user is able to also cite the local password. In effect, Ill be saying saying: I relied on the assurance of opened connect, and you might rely on my act of reliance, should you wish. This is semantically similar to what SAML called an "SP affiliation".
 
Or so think I - as confused as ever, now having 4 websso standards to choose from.

---

Subject: One developer's first encounter with account chooser (openid connect?)
To: openid-...@lists.openid.net
Date: Wed, 17 Oct 2012 19:03:55 +0000
From: hom...@msn.com