OpenID Trusted Authentication Extension

[John Ehn]

On 8/31/07, James Henstridge <james at jamesh.id.au> wrote:
>
>
> 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.


Yes, granting the secret must be done using the traditional User Agent, as
the user must be logged in using their normal credentials in order for the
OP to deliver the secret to the requesting RP.

Considering it's an Extension, this isn't really any sort of change that
limits what the OP can do.  It simply codes a standard credential format
that is only used for when a site wishes to log into another site using a
specific OpenID.

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?


Trusted Authentication doesn't require the destination site (the DP) to
implement any changes at all.  One would hope that the DP is offering some
valuable service other than just providing data to client sites.

As for the client site, yes, functionality will be lost if the OP doesn't
support the extension that would allow them to log in to another site.  If
the extension becomes popular, it would be in the best interest of the OP to
implement the extension if they wanted to keep users from switching to a
different provider that does support the extension.

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


Why not?  They would be able to support this, and if the OP doesn't support
the extension, they can continue using those very insecure "API key"
implementations that are being used today.  Or, they can even suggest that
the user switch to a supporting provider.

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?
>

Well, as above, no changes are needed at the DP.  I think it would be much
easier to simply modify the hand-full of OPs and the Client RPs that want to
support the spec, which is expected with any OpenID extension.

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


Well, it really is up to the DP to determine how long it wants its sessions
open, just with any other website.  For instance, banks will automatically
expire the session if there is no activity for 15 minutes.  In this case,
the DP will simply force the Client RP to authenticate again with the OP.

As stated in the spec, it's not my intention to mandate how user data (and
the data session) is managed between the client RP and the DP.

Your feedback is always welcome.

Thanks,

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20070901/d2baeeaa/attachment-0002.htm>