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 [EMAIL PROTECTED] wrote:
On 30/08/2007, John Ehn [EMAIL PROTECTED] 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
