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
