[OpenID] Trust + Security @ OpenID

[Peter Williams]

Lets take head-on this issue from last week, too:-
 
---------------------

Issue: OpenID was never intended to provide an assurance that an OpenID 
doesn't belong to a spammer. That's OK; neither are regular accounts 
created with a username and password. If you want to prevent automated 
spammers from signing in to your blog/forum using OpenID, you need to 
present a user with a CAPTCHA the first time they sign in with a 
specific OpenID. 

Response: So I don't need OpenID therefore, right? No benefit for me as site operator and relying party...why bother...?


----------------------
 
For those trained in military comsec design doctrine, lets re-iterate the classical conceptual framework into which OpenIP protocol familry OUGHT TO FIT. Lets see where it fails to fit. Lets ask, should we make it fit (by re-aligning our use of technical language; should we market the issue set in a uniform manner?)
 
----------------------
 
To Identification (I) one adds Authentication (An). The result is I&A, often meaning by presenting sufficient I&A crednetials one can pass a terminal/web logon "control policy". 
 
To I&A one adds Authorization (Az). The result is support for such as confidentiality policies, often meaning that messages are encrypted on the wire, or a the file system of the distributed system controls access to resources. If one passes access controls enforced by encryption or access control applied by the distributed system after logon, release of data as cleartext or usable resouces is subject to the confidentiality policy rules. The tehcnical policy rules may be the usual mandatory or discretionary varieties. Where the sensitive resources are messages themselves, confidentiality policies can differentiate handling policies and privileges from the more classical schemes of labels, caveats and markings.
 
-----------------------
 
ok. that nice, pristine miltiary-B2B worldview existed before the notion of identity theft, spam, and phishing came along - in the B2C world. As US military system designers dominate IETF (and always have, via academic funding), the internet's security model is a really poor fit for realworld B2C at almost every layer.
 
If we retain the military comsec model (that is also present in all the ISO and ITU-T standards, note, and about half of the ANSI X12 standards), where do we place OpenID, where do we place OpenID's anti-phishing claims (or at least certain OpenID-vendor's claims), where do we place OpenID wiki's level 1 and level 2 OP distinction?
 
------------------------
 
In the comsec model, OpenID is an I&A mechanism; its in the "webSSO" class.  Microsoft passport-protocol (ws-fed) and SAML sit alongside, in the same class.
 
However, the wiki's object in distinguishing between level 1 and level 2 are however authorization Az policy goals (controlling release of names (of the OP)). Conventionally, when Az policies are applied WITHIN an I&A mechanism, pseudonym sub-protocols are used in the I&A mechanism design. Lots of name server research has dealt with this issue over the years, getting the name management right and orchestrating a handoff to the A in I&A. OpenID Auth + Yadis fits into this sub-class. The combination of sp-initiated websso + name server discovery by parsing the XRDS stream provides (simplistically) all the necessary components of : name resolution logic, name server access-point discovery , and pseudo-naming.
 
----------------------
 
But where do we put anti-phishing and spam-protection?
 
 
At the outset, I think I agree with the original poster - these are not part of the DESIGN of the OpenID protocol Family.
 
Lets contrast with OpenID's peers. SAML has makes no claims on these goals. Microsoft Passport makes no claims either (the small-p passport protocol that is, contrasting with the "service" that goes by the big-P Passport name). The various cookie-based SSO protocols didnt either. WebAuth doesnt, either.
 
------------------------
 
So how do we analyse these issue in OpenID land?
 
So, far we have seen the OPenID community react to design criticism on the anti-spam & anti-phishing fronts by (a) accepting its protocol suite design is weak in counter-measures (b) certain vendors adding value to their "implementations" (c) introducing level 1 and level 2 as an spam countermeasure.
 
(I'm an outsider looking in, so cut me some slack if I render an account of OpenID history incorrectly.)
 
--------------------------
 
These reactions, I'd argue, are all counter-productive. That the community went this way is entirely understandable, particularly as grassroots-led design gives way to vendor-led design - and (friendly) competition becomes an issue when positioning a vendor's-brand as controlling IP marketshare and mindshare.
 
If we make an analogy with Microsoft Passport's merchant community (mostly the old MSN services), yes the Passport-delivered I&A service added not only anti-phishing countermeasures for its web-based merchants, it added anti-spam for its hotmail merchant. It also added anti-virus to its IM merchants (messenger), having previously added it to hotmail during message submission and relaying. The latest hotmail merchant also controls UI even - controlling UI access to hyperlinked email gifs, attempting to deliver identity-theft countermeaures and IP-address location countermeausures.
 
Now are all of those value-adds part of the "passport" webSSO protocol? (which is just "ws-federation passive" these days?) No. They are part of the Passport service-bundle, where this mega-TTP-model I&A service was tuned up for each of the major SP spokes (IM, hotmail, web, video streaming, DRM music, DRM gaming etc)
 
---------------------
 
So, if I'm intimating that Passport made the right productization choices, and the right technical architectural choices in terms of comsec doctrine, should I change my opinion  and assert that OpenID vendors should quite properly add similar value-add(s) to each of the their implementations of the OPenID 1.1 family of protocols?
 
I think the answer is both yes and no.
 
Its yes - when a service operator (myopenid.com) takes an implementation and links the protocol claims with the value-add claims - and offers "anti-phishing enhanced version of OpenID". It markets its brand, MyOpenID to differentiate itself from others applying OpenID. Its yes, becuase unlike Passport, OP Providers are de-centralized and thus one of the n service operators may choose to take that bundling route, yet others may not.
 
It's no, if all Library-level or plug-in-level implementations feel obligated to protect the OPenID brand itself by adding such features to their libraries/plugins is - at the end of the day-  a trusted name server protocol design, for use in web I&A.
 
-----------------------
 
I'd argue as a conclusion, that (a) the working groups addressing the OpenID protocol suite specs need NOT address anti-phising, anti-spam, anti-virus; whereas (b) the marketing-focussed work group ought to formulate policies concerning obligatory vendor-messaging on these bundling issues, messaging to be used whenever a vendor chooses to cite the OpenID trademark while engaged in either technical marketing of its R&D Intellectual Property or when performing software/service sales activities.