Re: OpenID Trusted Authentication Extension

2007-08-31 Thread 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 [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 

Re: OpenID Trusted Authentication Extension

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

With my proposed workflow, it'd be going through the UA too.

The checkid_setup request and id_res response uses indirect
communication, so those calls do go through the user agent.  I did not
specify this explicitly in my previous email because it is implied.

So the workflow would look something like this if the data provider
needs to authenticate the user:

DC - UA - DP - UA - OP
DC - UA - DP - UA - OP

In the communication between DC and DP, the DC is the RP and the DP is
the OP.  In communication between the DP and OP, the DP is the RP and
the OP is the 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

You still want the user involved in the granting of an authentication
token though, right?  Trying to replace the UA in the authentication
workflow is quite a big change, and limits what the OP can do.


 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.

With your proposal, the user's OP needs to implement an extension.
This brings up a few questions:

1. Should the data provider only let users register if their OP
implements the extension?  What is the benefit to the data provider in
enforcing such an extension?

2. If only some users' OPs implement the extension, can the data
consumer rely on the protocol at all?

In contrast, both the data provider and consumer have an incentive to
implement an extension for auth token transfer, so a spec that only
requires modifications to those parties seems easier to roll out.
What do you think?


[snip]
 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.

I guess that is a concern.  But how often do you expect the data
provider to check the user's OP to see if the token is still valid?
If it doesn't check often, then revoking the token at the OP level
might take a while to take effect.

James.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs