[OpenID] OpenID for non-HTTP applications?

Dick Hardt dick at sxip.com
Wed Jan 17 14:06:59 PST 2007

There was talk at IETF when we were proposing DIX of having  
authentication at the TLS layer which most protocols sit on top of.

Given the name/value approach of OpenID, it *may* not be that hard to  
adapt most of the model to support a TLS layer, but I am no TLS expert.

-- Dick

On 17-Jan-07, at 10:39 AM, Martin Atkins wrote:

> Bob Wyman wrote:
>> My apologies if I've missed the appropriate discussions somewhere...
>> But, I would appreciate it greatly if someone could comment on the
>> problem of getting non-HTTP applications to use OpenID. For instance,
>> I'd like to use OpenID for things like my identifier (JID, username,
>> etc.) in Jabber, POP, SMTP, FTP, Gopher, etc... But, many of these
>> protocols are well established and resistant to change. Also,  
>> protocols
>> like Jabber/XMPP and SMTP extract useful routing information from the
>> ids that they currently assign to me. To these applications,  
>> identifiers
>> are not simply opaque strings. (For instance, in both Jabber and  
>> SMTP,
>> my id includes the name of my server.)
>> My guess is that there is a small set of standard "patterns" that
>> non-HTTP applications would need to support in order to support  
>> OpenID.
>> Have these been defined or otherwise discussed?
> For entrenched things like email and Jabber, I think the best we'd be
> able to do is define a mechanism for an OpenID identifier to be  
> used as
> a login for a traditional email address or JID. The identifiers  
> used for
> email and XMPP are not syntax-compatible with OpenID's URLs.
> We've briefly discussed the possibility of defining a machine-grokable
> alternative to the HTML forms part of the OpenID process when we were
> talking about HTTP Authentication bindings for OpenID.[1]
> The main problem is figuring out how to replace the HTML forms that
> handle logging in and giving permission in a way that doesn't  
> depend on
> a web browser. The authentication problem isn't too hard — SASL  
> already
> provides a mechanism for "pluggable" authentication schemes — but  
> once
> you're outside of the web context the permission thing doesn't make  
> much
> sense since the apps could just say Yes on the user's behalf and  
> bypass
> the question entirely.
> -----------------------------------
> [1] http://openid.net/wiki/index.php/OpenIDHTTPAuth
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general

More information about the general mailing list