Re: OpenID Trusted Authentication Extension
On 8/31/07, James Henstridge <[EMAIL PROTECTED]> 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Inline Authentication Extension 1.0 Draft 1
Hans, Yes, the Client App is expected to implement all the important parts of an OpenID 2.0 Relying Party. This means it will support XRI, Yadis, and HTML discovery. It's unlikely systems will have clashing namespaces, but is possible (most corporate user accounts don't begin with "=", "@", "+", etc, and most don't use a format similar to URLs). For a PAM implementation, the system would likely give priority to all other authentication types, and fall back to OpenID if there are no matches. Or, the implementor may wish to prompt the user for the authentication type, or provide instructions to add a special prefix to the account name. As for the wording in step 4, oops. Thanks for catching that. It should be "The user is prompted for their verification key, which is typed in and submitted." I have never personally done a PAM module, so I'm not a good fit. I think it would work very well though. Know anyone who might want to give it a try? Thanks, John ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Inline Authentication Extension 1.0 Draft 1
Interesting. I like that it's short and technically well written. So in practice a Client App would need to be able to distinguish the classes of OpenID identifiers, so it know when to do the OpenID authn call, right? Does that mean some existing systems may have clashing namespaces (for instance, maybe someone has a local user "=hans" somewhere, and all of a sudden it's being interpreted as an iname.) I guess the Client App can try multiple means and hide that from the user. In 4. Theory of Operation / Technical Overview you say "The user is prompted for their verification key, which is typed into the supplied dialog box and submitted." --- I assume you mean "supplied entry field" or similar (for text apps)? Are you working on a PAM module for this? Thanks, Hans On 9/1/07, John Ehn <[EMAIL PROTECTED]> wrote: > > The Inline Authentication Extension attempts to solve the problem of > legacy and interactive applications (Telnet/SSH) that are unable to launch a > client Web Browser to perform an authentication request. > > http://extremeswank.com/openid_inline_auth.html > > This is done through the use of "verification keys", which are provided > either as needed by the OpenID Provider, or provided on a rotating basis > from a hardware crypto device, or a key generating token (SecurID). > > As always, your comments are appreciated! > > Thank you, > > John Ehn > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > -- Hans Granqvist CTO Phone: +1 (408) 524-1598 http://www.yubico.com/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID Inline Authentication Extension 1.0 Draft 1
The Inline Authentication Extension attempts to solve the problem of legacy and interactive applications (Telnet/SSH) that are unable to launch a client Web Browser to perform an authentication request. http://extremeswank.com/openid_inline_auth.html This is done through the use of "verification keys", which are provided either as needed by the OpenID Provider, or provided on a rotating basis from a hardware crypto device, or a key generating token (SecurID). As always, your comments are appreciated! Thank you, John Ehn ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
