Martin Atkins (mart) wrote in apparentlymart,
Martin Atkins

The Three Facets of Service Authentication for OpenID

OpenID is working great for authenticating humans to consumer sites, but several people have been trying to employ it for use in other protocols. In my case, I drafted Post In My Weblog and Send A Message — two very simple services built on the OpenID Infrastructure. This also includes, for example, applications like's app which reports back to the server on the music you listen to.

There are three different “modes” of operation for service authentication in OpenID:

  • Service-to-service (two-party): in this situation, some kind of agent is authenticating as itself to perform some action. For example, a social networking site may be authenticating to my Send A Message endpoint to deliver a notification message to me.
  • User-to-service (three-party): in this situation, a user (probably human) is authenticating as itself to perform some action. For example, the client logs in as me to log what I'm listening to. I have provided it with whatever information is necessary to do so.
  • User-accompanied service-to-service (four-party): this is like a combination of the above. Some kind of agent is doing an action the behalf of a user (probably human), so although it is the agent that performs the action, it is the user's credentials that are used. For example, with the Post In My Weblog protocol I can give one-time permission to Flickr to post a set of photos in my weblog.

So far I have drafted OpenID HTTP Authentication for the service-to-service case and OpenID Exchange (name is very likely to change) for user-accompanied service-to-service. These both use HTTP requests as the fundamental request primitive, which means that existing HTTP-based protocols can be easily re-oriented towards OpenID Authentication.

I do not yet have an answer for user-to-service, though my gut feeling right now is to build apon service-to-service by specifying a secure method by which a client app can retrieve a signature from a user's OP for use with OpenID HTTP Authentication. However, there is a standing issue that OpenID HTTP Authentication can currently only operate in “dumb mode”, which is vulnerable to man-in-the-middle attacks. Existing non-HTTP protocols can also benefit from this, as whatever we specify for user-to-service HTTP authentication is likely to be easy adapt to a SASL mechanism.

It is my belief that making the above possible is key to unlocking OpenID's potential an identity infrastructure rather than just a signle sign-on protocol. The above three authentication modes in addition to the existing browser-based OpenID Authentication protocol provide a good basis for a variety of interesting identity-related protocols and applications built apon the basic OpenID infrastructure.

Tags: authentication, openid

  • The next evolution for OpenID?

    This morning at IIW Dick Hardt presented his vision for solving the issue whereby a user is dependent on his OpenID provider being up and non-evil.…

  • HTML 5 vs. Yadis

    One of the ways that the Yadis specification allows for the XRDS document location to be declared is via the X-XRDS-Location header embedded via a…

  • On Discoverable Avatars

    Chris Messina has written about a possible new standard for avatar discovery. I agree with many of his premises, but few of his solutions. My…

  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 1 comment