OpenID Trusted Authentication Extension

[James Henstridge]

On 26/08/07, John Ehn <john at extremeswank.com> wrote:
> I have created a draft of a new specification that I think will help to fill
> a gap in OpenID functionality.
>
> What appears to be a newer productivity feature of many websites is the
> ability to import and utilize information from other sites.  For instance,
> Basecamp provides an API that allows other systems to access user data.
> This is a great feature, but it currently cannot be done with OpenID, due to
> the dependence on end-user interaction during the authentication process.
>
> The Trusted Authentication Extension provides for the ability for an OpenID
> Consumer to log in to another OpenID Consumer without user interaction.  The
> end user will be able to create a trusted connection between two OpenID
> enabled sites, which will allow a client site to access a destination site
> using the end user's Identity.
>
> Please provide your comments and feedback, as they are most appreciated.
>
> http://extremeswank.com/openid_trusted_auth.html

I think things would be a bit clearer if you made the data provider
into a form of OpenID Provider.

I think it helps to first consider the case where the data provider is
not an OpenID Relying party but instead has its own user account
database.

If the site acted as an OpenID provider, it would be pretty simple to
use an extension to negotiate an auth token to acess data for the
user.  Simply start an OpenID authentication request, including some
field stating that you want access to data.  The provider would then
include an authentication token in the response that could be used to
access the web services.


Now lets consider the case where the data provider identifies users by
an OpenID.  What would happen if the data provider continued to
implement an OP, and the data consumer started an OpenID
authentication request with it using the user's data provider.

This would let us use the same sort of OpenID extension to negotiate
the auth token.  The data provider could even turn around and perform
its own authentication request to verify that the user is who they say
they are, since it received the identity URL from the data consumer.

So the full workflow might go like this:

DC: Data Consumer
DP: Data Provider
OP: User's OpenID Provider

1. DC sends checkid_setup request to DP for user's identity URL, with
an extension asking to negotiate an auth token.
2. DP initiates OpenID authentication for user's identity URL
3. OP verifies user's identity and sends idres reply to DP.
4. DP sends idres reply to DC, including the auth token as an
extension in the response.

This seems to give similar results to your protocol while introducing
fewer new concepts.  What do you think?

James.