Re: [OpenID] OpenID Providers Invited to Join in an NSTIC Pilot Proposal

Peter,

While the social web use case continues to be important to the Foundation and it's members,  that is not the
only use case that needs to be addressed.

Before NSTIC came about it was clear to many people that having multiple protocols and identity providers
servicing smaller niches is not an ideal situation.

In our redesign of openID we embrace both the important Authorization role of OAuth 2.0 has on the web as well
as allowing for a a number of formal security profiles.

This in principal will allow an account at an IdP to be used in applications from social gaming to tax filing.  
That is if the IdP chooses to support the more advanced profiles with signing and encryption for privacy.

Users getting more value from accounts will be more interested in securing them with better primary
authenticators like smart cards or more likely mobile device secondary factors.

So the message is that OpenID Connect, and Connect providers are not just for low value transactions any more.

There are things like trust frameworks for Identity and Attributes that need to be put into place.  

I am no stranger to the R&E community.  There are people looking at how openID Connect can be added to products
like SimpleSAMLphp and others to better integrate with GRID and cloud environments.

I don't think SAML is going to be displaced any time soon (yes as a SAML contributed I play both sides) However
it is not currently growing into the Social Web and NSTIC space.  

That is mostly due to vender incompetence in my opinion. 

There will certainly be additional plots and intrigue for you to uncover as this plays out:)

What is safe to say, is that openID is not rolling over and giving up the fight any time soon.

Regards
John B.
On 2012-02-14, at 2:55 PM, Peter Williams wrote:

> 
> what is news to me is that the foundation took upon itself to break free of the somewhat-specious buckets -
that openid (the approach) was inherently unassurable (and thus LOA1).A lot of political energy went
into characterizing openid - the brand - as only for "that which doesnt matter".
> 
> 
> 
> Remember, consumers dont think in terms of formal technical definitions, or NIST criteria. They think in
terms of rough classes of assurance. 
> 
> 
> 
> 1 There is me when being a pill on a blogging site, ranting on a topic I know nothing about after a beer
(wishing I hadnt, the next day). There may even be me writing a blog, on something half adult. There is also
me payign subscription using a credit card to 100 media outlets.
> 
> 
> 
> 2 there is me doing paperwork when I get a job and do tax deductions (that hurt my pay cheque), or pay the road
tax, or get a smog certificate for a vehicle; or licensing my shotgun for use in my extensive backyard. 
> 
> 
> 
> 3 there is me signing and certifying my annual tax form (under penalty of perjury), or registering a baby
for a passport; or seeking government benefits (based on elgibility)
> 
> 
> 
> 4 And there is me playing james bond, with instant, tamperpoof satellite communciations, all used to save
the planet just in the nick of time.
> 
> 
> 
> The last one has yet to happen for me (and probably wont). The other three are 80:15:5 percent of my arrangements.
> 
> 
> 
> that openid intends - as a brand - to address the 2nd and 3rd categories is what is news (to me) - but remember
Im not a foundation member. That there are bits and bytes of "more evolved" security protocols in the works
was not (having seen all the same stuff done several times with different bit formats, over the years).
> 
> 
> 
> if it helps, I can tell a story that may align with what the foundation has been doing. It may even mean the
story is "resonating" (generally).
> 
> 
> 
> lets week a really good engineer came to be and said: look, we cannot stand any more the fact that the web site
farm talks to the web services (and the database) [farms] using trusted accounts. We want the user
identity to drive what the (data center) web services does, and limit its access in the backroom. Its just
too risky.
> 
> 
> 
> I nearly fell of my seat, at hearing this (having said what we HERE all know is "proper" for years).
Previously, the de facto and loud response was: its just not "important" (or economic). Go away, and talk
to academics about stuff 15 years down the road.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  		 	   		  

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general

Re: [OpenID] OpenID Providers Invited to Join in an NSTIC Pilot Proposal

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general

Re: [OpenID] OpenID Providers Invited to Join in an NSTIC Pilot Proposal

typically, the PC (and thus the browser, of any vendor) is regarded as untrusted - in the assurance controls world.

First, the home PC controlled by the user (who is also not considered a trustworthy agent, formally, even
when managing his/her OWN identity/attributes (!) ). yes, this distinguishes between trust and
trustworthiness. Only the cloud vendors are trusted, to guage trustworthiness. The subscriber is NOT
trustworthy, per se, and his/her equipment is usually unmanaged. Only other vendors are trustworthy as
measured against a common standard, and common auditing standard. This is the whole "certification and
accreditation" line of attack, not seen since the world of comsec controls and CCI equipment died
(outside military circles) in the mid 90s.

In a mandatory security/audit world (nomininally addressing the end-end privacy problem issue), one
cannot have an untrustworth component contaminate the assurance betweten IDP and RP. Its a lowest common
assurance level definition, and the PC brings the assurance level down to zero - since the user goes and
installs some PC-proxy that intercepts and sends it an RP that is NOT on the IDP's governance list.

so bearer-tokens are fine for websso, but not attribute exchange, under formal assurance doctrine. if
there is end-end token encryption (and not 2 TLS tunnels connected at a PC) as in SAML2, the user/PC has
little opportunity to interfere.