OpenID Trusted Authentication Extension

[John Ehn]

Well, I've slept on it.  I think we have a difference in philosophy.

The other Extesions - AX, Simple Registration, etc. - follow the same data
flow methodology:

RP -> UA -> OP
RP <- UA <- OP

I believe I'm sticking to the same principles in my spec.  We are doing the
very same thing when we collect the authentication key (see above).  We are
even doing the very same thing when we have the sites authenticate with each
other.  It's just we have a non-human operating the User Agent.  In this
case, the RP is the "destination" site, the UA is the "client" site:

RP -> UA -> OP
RP <- UA <- OP

I think this fits well with what people expect.  I also have no problem with
having OPs incrementally improve their systems to make them compatible with
new extensions.  Since there will (eventually) be far more RPs out there
than OPs, I think it's reasonable for them to support the bulk of the
extension implementation.

In this case, however, there really isn't all that much to implement.  The
following code changes will need to happen at the site that wants access to
information at another site (the CC):

* The form where the user submits their OpenID to grant permission to
another site
* Logic that builds a simple OpenID login request with the Trusted
Authentication data included, and a redirect to the OP
* A branch to the "id_res" checker that parses the OP response and stores
the shared secret
* An automated script that performs OpenID authentication to the DC and
retreives data

The OP needs to implement the following:

* When receiving a check_id request with Trusted Authentication arguments,
send an X-OPENID-TrustedAuthentication HTTP header in the response, and be
able to accept a SHA-256 hash as a response  - This is not a big deal, and
isn't any form of deviation, because this is the "gray area" in the spec
where the UA is supposed to be verified that it's already logged in, or is
prompted for credentials
* Add a logic branch that generates a shared secret when requested, stores
it, and sends it in the authentication response
* Some form of user interface to manage the stored secrets - very easy

All but one of these steps would be needed to implement ANY OpenID extension
out there.  And the only change that is "out of spec" is accepting an
SHA-256 hash as an authentication key - which is trivial to implement at an
OP.

Conservatively, (with distractions) I think an OP can implement the data
passing in less than a couple of hours, and the user interface in a couple
of days.

Although your implementation is sound, and I like a lot of the ideas, they
shift a lot of the responsibility to the party receiving the authentication
request.  I'm not sure I like the idea of having the burden of implementing
both an API and a special pseudo-OP.  This also removes the power of having
a single Identity management interface at the OP, meaning the user will have
to log on to the destination site to invalidate the token.  What if the user
has 50 of these API connections set up?  That's 50 sites to visit in order
to manage these tokens.

Like I said, nothing technically wrong with the idea (it's novel), but it
just doesn't fit with me.

Thank you!

John Ehn

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/. <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/. <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/20070831/929792ea/attachment-0002.htm>