OpenID Inline Authentication Extension 1.0 Draft 1

2007-09-01 Thread John Ehn
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


Re: OpenID Inline Authentication Extension 1.0 Draft 1

2007-09-01 Thread Hans Granqvist
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


Re: OpenID Inline Authentication Extension 1.0 Draft 1

2007-09-01 Thread John Ehn
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 Trusted Authentication Extension

2007-09-01 Thread John Ehn
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