Re: OpenID Inline Authentication Extension 1.0 Draft 1
John Ehn wrote: Martin, Thanks for the response! I'm looking at those specs now, and I really like the flow of the HTTP Authentication spec, because it looks like it's solving the problem of passing the OpenID Identifier to the RP in an automated way, which is really cool. Looks like it needs to be fleshed out in some parts, though. Both of these specs need work. What you see up there on the wiki is really just a brain dump wanting to be turned into a spec. I've not really had much time to work on them, though. As for the Signature Request protocol, I'm not quite sure what it does yet, but I'll let you know my opinion once I've digested it. The HTTP Authentication spec has a part in it where it says the client must get a signature from somewhere. When I originally specced it my only answer here was that non-human agents can act as their own OP and therefore they could just compute the signature themselves, but realising that this protocol had applications for humans authenticating to services inside specialised rich clients (Last.fm's Audioscrobbler API, for example, or JOSM for OpenStreetMap) I added Signature Request Protocol as a standard mechanism for rich client RPs to obtain a signature from the user's OP. As I think it notes somewhere in the copy, I'm imagining in the ideal case a desktop service or at least a shared library that does the SRP bit on behalf of all of the user's applications, so that each application does not need to be given the user's OP credentials. It was my hope that it could theoretically be integrated with systems like Apple's Keychain. However, SRP is still very rough-and-ready and still has lots of outstanding issues. I think Inline Authentication might have the answer to some of these issues. Cheers, Martin ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Inline Authentication Extension 1.0 Draft 1
Has anyone done a comparison between this spec and OAuth? It really seems like an unnecessary duplication of work given the 8 months we've put into it so far... Chris Sent from my iPhone On Sep 3, 2007, at 2:22 PM, Martin Atkins [EMAIL PROTECTED] wrote: John Ehn wrote: Martin, Thanks for the response! I'm looking at those specs now, and I really like the flow of the HTTP Authentication spec, because it looks like it's solving the problem of passing the OpenID Identifier to the RP in an automated way, which is really cool. Looks like it needs to be fleshed out in some parts, though. Both of these specs need work. What you see up there on the wiki is really just a brain dump wanting to be turned into a spec. I've not really had much time to work on them, though. As for the Signature Request protocol, I'm not quite sure what it does yet, but I'll let you know my opinion once I've digested it. The HTTP Authentication spec has a part in it where it says the client must get a signature from somewhere. When I originally specced it my only answer here was that non-human agents can act as their own OP and therefore they could just compute the signature themselves, but realising that this protocol had applications for humans authenticating to services inside specialised rich clients (Last.fm's Audioscrobbler API, for example, or JOSM for OpenStreetMap) I added Signature Request Protocol as a standard mechanism for rich client RPs to obtain a signature from the user's OP. As I think it notes somewhere in the copy, I'm imagining in the ideal case a desktop service or at least a shared library that does the SRP bit on behalf of all of the user's applications, so that each application does not need to be given the user's OP credentials. It was my hope that it could theoretically be integrated with systems like Apple's Keychain. However, SRP is still very rough-and-ready and still has lots of outstanding issues. I think Inline Authentication might have the answer to some of these issues. Cheers, Martin ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ 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
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
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
