ZDNet Japan Builder Techday: Open API & Beyond - 2) Open ID
Second Speaker was Kazuya Ishikawa from Verisign Japan, talking about the Open ID initiative. Verisign is one of the corporate members of the Japan chapter of the OpenID Foundation.
He was explaining OpenID as User-centric ID Management, enabled by logically separating the ID provider from the provider of the service being logged into.
The benefits of Open ID are:
- Easy to remember than multiple passwords
- Not centralised (you may have multiple providers as a fallback)
- User can control what personal information is exposed to which services
- Simple and lightweight
- Easy to use and implement (I can attest to that, it took all of half an hour to implement on this blog!)
Open ID does not specify the authentication mechanism, and enables the OpenID provider to use stronger authentication if they wish. This is where Verisign have applied their technology, with a device that can be used to generate a number that the user must input in addition to their username and password, to give that additional security.
Verisign also provide an OpenID management service, which allows you to monitor all your OpenID providers from one location. I didn't understand how this works, as being a decentralised system, how can Verisign know when I have authenticated against say MyOpenID.com? Sounds like there is more to that story ... anyone?
http://openid.net/specs/openid-provider-authentica...
It's a draft extension created for the sole purpose of an Identity Provider affirming that a user is "still there". IIRC the application was high trust/high security web sites (banking, confidential, etc. type applications). It forces the user to re-auth even if they do the "Automatically Log Me In" thing; and after re-authenticating, the IdP asserts that it had been done.
It sends openid.ns.pape, telling the IdP to speak PAPE proper, the RP asks the IdP to ensure the user has logged in within the last <x> seconds, that is the openid.pape.max_auth_age parameter, then the RP asks the IdP to ensure it challenged the user with a certain level of authentication, this is openid.pape.preferred_auth_policies
The IdP then carries out action as necessary. Requesting the user's OTP token, or whatever the minimum requirement by the RP was. The IdP speaks back what authentication it enforced on the user, passed ( openid.pape.auth_policies), how long ago the user authed (openid.pape.auth_age, this way, if the user logged into one site 5 minutes ago, went and logged into this new site, and the new RP only requires a user to have logged in within the last 30 minutes, the check will pass automatically).
If this is not what Mr. Ishikawa was talking about, then it's something even beyond me. PAPE is just what I've heard of from spec-masters and developers, and seemed to fit your description.
PAPE isn't anything superbly amazing. The RP asks the IdP about the strength a user logged in with, and when they last did it, and the IdP responds, or challenges the user if they didn't meet the RPs requirements.