Sorry, but I'm having problems following the flow.  It seems like an
interesting idea, though.  Can you provide with a little more information on
how these components would interact?

I was really trying to keep everything dumb and simple.  The concept I was
going for was "piggy-back on OpenID, but include a way to programmatically
log on to the OpenID Provider".  The problem I saw with OpenID was that
there are about a million different ways to authenticate with an OpenID
Provider, from HTML forms to digital certificates.  Most require the User
Agent to be a web browser.  However, there is no standard way to just pass a
credential that can prove that you are who you say you are.

Trusted Connection Request:
User Agent gives OpenID to Client Consumer
Client Consumer -> User Agent -> OpenID Provider

Trusted Connection Response (with key):
Client Consumer <- User Agent <- OpenID Provider

Trusted Logon:
Client Consumer gives OpenID Identity to Destination Consumer
Destination Consumer -> Client Consumer -> OpenID Provider
Destination Consumer <- Client Consumer <- OpenID Provider

I was trying to solve the problem by coming up with an automatable (if
that's a word) way to authenticate with an OpenID Provider.  If we have
that, there's no need to pass around a special token, because we can
just use standard OpenID authentication if we want to log on to another
system.  So, I proposed just having the Consumer get a key from the OpenID
Provider that it can use to automatically authenticate with the Provider in
the future.  The key is passed through the user when it's granted, because
you need the user to approve the whole thing anyway.

I don't expect this extension to fix all problems.  It's only intended to
solve a specific use case (website to website info sharing).  I am working
on two additional extensions which will solve the other problems I see:

* Inline Authentication - Provide support for legacy and real-time
interactive systems that can't launch a web browser, and are protecting
their own data (Telnet, etc).  This will involve manually-typed verification
* Desktop Authentication - Provide for desktop applications
authenticating with and accessing data behind third-party systems (RSS
readers, chat, etc).

I appreciate any feedback you can give me.

Thank you!

John Ehn

On 8/30/07, James Henstridge <[EMAIL PROTECTED]> wrote:
> On 26/08/07, John Ehn <[EMAIL PROTECTED]> 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.
specs mailing list

Reply via email to