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

Reply via email to