Strong AuthN

Convener: Michael Sprague

Notes-taker: Michael Sprague

Tags:

Strong Authentication / OpenID / SASS

Discussion notes:

The discussion presented the existence of OP's that provided a higher level of authentication than simple password login. This includes services that use the Trusted Platform Module, SMS challenge, key fob's and others.

The question was posed whether there is value in this… are there business cases for it.

First there was the concern that based on this morning’s openid security discussion, adding strong authentication to a protocol with so many holes has significantly diminished value.

Google provided insight on systems using SAML federation between a company's Google apps environment and their (the company's) authentication server. This offers a way for a company to bring their mail environment under corporate authentication. It was noted, however, that when using SAML for federation to external sites, best practice calls for the association cert to be rotated, which rarely happens. OpenID could offer a better approach.

This presented on opportunity for market demand for relying parties by introducing a system that better enables a company to manage their employee relationships to external sites.

Google pointed out that the cost of recovery for compromised accounts represented a significant issue for them as well as others such as AOL, Yahoo and Microsoft. Even with the holes in OpenID, it is considerably better than the status quo. Simple enhancement beyond username/password helps limit the problem.

Google also discussed that a big issue with moving to alternative sign-in methods beyond username password is the legacy of desktop apps that did not anticipate any other identification method. This needs to change first but will take significant time.

Some of the discussion focussed on whether strong authentication should happen at the relying party, rather than the id provider. However the potential cases for this were deemed to be rare.

The group was asked whether there would be value to having a single identity come with different levels of assurance, so that a relying party could only enable sensitive features (bank transfers for example), based on sign-in profile. The concensus was that it's hard enough to get relying parties, that to introduce a level of complexity was not a good idea.

In all though, the whole ecosystem needs to grow and mature for the benefit of strong authentication to kick in... but it's coming.