OpenID Trusted Authentication Extension

[John Ehn]

Ahhh, I see what you're going for.  It's a very interesting idea.

On 8/30/07, James Henstridge <james at jamesh.id.au> wrote:
>
> On 30/08/2007, John Ehn <john at extremeswank.com> wrote:
> > James,
> >
> > 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?
>
> Okay.  The basic idea was that instead of creating a special protocol
> for two OpenID relying parties to communicate with each other was for
> the web services data provider to act as an OpenID provider.
>
> So, lets assume that the data consumer wants an auth token for the
> user identified by http://user.identifier.url.  With normal OpenID
> authentication, you'd perform discovery to find the user's OpenID
> provider.  To request an auth token though we need to talk to the data
> provider, so instead we skip discovery and perform an authentication
> request to the data provider's endpoint.  The parameters might look
> something like this:
>
> * openid.mode = checkid_setup
> * openid.claimed_id = http://user.identifier.url
> * openid.identity = http://user.identifier.url
> * openid.return_to = http://data.consumer/...
> * openid.ns.auth = ...
> * (additional parameters related to the auth token request)
>
> The data provider would then decide whether to grant the auth token
> (possibly by performing OpenID authentication against
> http://user.identifier.url, and/or asking the user), then send a
> response back like:
>
> * openid.mode = id_res
> * openid.claimed_id = http://user.identifier.url
> * openid.identity = http://user.identifier.url
> * openid.return_to = http://data.consumer/...
> * openid.ns.auth = ...
> * openid.auth.token = ...
> * openid.auth.secret = ...
>
> The data consumer knows that the request came from the data provider
> due to the signature on the OpenID response.  The data provider knows
> which user to create the token for because it was present in the
> OpenID request.  The data provider can verify that the web browser
> user is that user because control gets transferred to the data
> provider during the authentication process.
>
> This all assumes that the data consumer has already authenticated the
> user, so knows which identity URL to request a token for from the data
> provider.
>
> > 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.
>
> Well, OpenID authentication requests are designed to let the OP
> perform whatever checking they want before sending a response.  So by
> making the data provider act as an OP, it has the same freedom
> (including the freedom to issue its own OpenID authentication request
> to the user's actual OP).
>
> > 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 think that this makes things more complicated than need be.  If you
> want an auth token from the data provider it seems better to ask the
> data provider for the key directly, giving it the chance to
> authenticate the user before responding.
>
> This also has the benefit that it does not require any special
> features from the user's OP -- the extension is purely concerned with
> the interaction between data consumer and provider.
>
>
> > 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:
>
> Sure.  I doubt my suggested workflow would help with those use cases
> either (at least without some additional components).
>
> James.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20070830/0d3692cf/attachment-0002.htm>