Last time I wrote about the “three facets” of OpenID service authentication. LukasRos has been writing about a slight variation on the theme: some service operating on my behalf over an extended period. The example he uses is a web-based feed reader that can authenticate on my behalf to retrieve a secure feed. This has caused me to reconsider my distinctions a little.
After pondering this a bit, it appears that with the exception of OpenID Exchange (which is special because of its unique UI requirements) the mechanics of all of these mechanisms are the same: the caller needs to obtain a signature that indicates permission to operate on a particular resource. This signature should ideally be constrained to a particular operation (for example, an HTTP method) on a particular URI, with an expiry date. It is only the mechanism for obtaining this signature which differs between cases:
- Service/application authenticating as itself: service acts as its own provider and generates signature internally
- Local application authenticating as user: obtained from user's OP, ideally via some system-wide service that will prompt the user for approval using local UI.
- Web service authenticating as user: obtained from user's OP, probably via an OpenID Exchange transaction. OpenID Exchange then acts as the approval step.
Once the signature has been obtained, OpenID HTTP Authentication can be used to authenticate with it. The required fields in the signature already include the request URI, so it just needs to be augmented with a request method and optional expiry date to support all three cases above. The two cases where an app needs to fetch a signature on the user's behalf could potentially share the same Signature Request Protocol endpoint with different authentication schemes: OpenID Exchange is itself a funny sort of HTTP authentication, so it can be made available at the same endpoint as other authentication mechanisms running in parallel.
I believe that this sort of scheme would provide a good infrastructure for the various cases of service authentication under OpenID, and is well worth consideration for inclusion, at least in part, in OpenID Authentication 2.0.