Re: Google OpenID is now live
I think that kind of misses the point. The *namespace* that google manages is now open for business as an OpenID provider. It's an unanticipated side-effect of the APIs. I think it's kind of a big deal, actually, in terms of how OpenID is right from an engineering perspective and how it can spread in unexpected ways. If only login were so easy. Vinay -- Vinay Gupta - Designer, Hexayurt Project - an excellent public domain refugee shelter system Gizmo Project VOIP: 775-743-1851 (usually works!) http://hexayurt.com/ Cell: Iceland (+354) 869-4605 Skype/Gizmo/Gtalk: hexayurt People with courage and character always seem sinister to the rest Herman Hesse On Apr 9, 2008, at 7:45 PM, John Ehn wrote: I agree. I think this is an excellent technology demonstration, but it is a third-party, not Google, that is enabling the ID. John 2008/4/9 Immad Akhund [EMAIL PROTECTED]: When Google eventually does make a proper OpenID provider all the OpenIDs provided by openid-provider.appspot.com would not match. Would get very confusing apart from advanced users that understand the distinction. Immad On Wed, Apr 9, 2008 at 12:49 PM, Paul Madsen [EMAIL PROTECTED] wrote: I expect Google might have a (legal) opinion on characterizing this application as 'Google OpenID' I think I'll wait for Google itself to enable my Gmail as an OpenID. paul Vinay Gupta wrote: http://openid-provider.appspot.com/ Somebody used their app hosting service and implemented an OpenID provider. That kind of changes things, doesn't it? Vinay -- Vinay Gupta - Designer, Hexayurt Project - an excellent public domain refugee shelter system Gizmo Project VOIP: 775-743-1851 (usually works!) http://hexayurt.com/ Cell: Iceland (+354) 869-4605 Skype/Gizmo/Gtalk: hexayurt People with courage and character always seem sinister to the rest Herman Hesse -- -- ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- -- No virus found in this incoming message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.9/1365 - Release Date: 4/8/2008 7:30 AM -- Paul Madsene:paulmadsen @ ntt-at.com NTTp:613-482-0432 m:613-282-8647 aim:PaulMdsn5 web:connectid.blogspot.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Cell: +1 617 460 7271 Skype: i.akhund Blog: http://immadsnewworld.com Clickpass, CTO ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel (now: Kerberos, Phishing)
One further thought on Kerberos: as far as I know, Kerberos is a minimal implementation - nothing simpler than this actually works in the real world, and the Kerberos operating environment is a bit simpler than what is being discussed in some instances here, in terms of managing the language of what access permissions are being granted by this sign-on event. One thing I'd like to suggest we examine is personal customization as a way to prevent Phishing. For example, say that my OpenID service provider serves pages to me over HTTPS, and furthermore allows me to upload my own color preference and background images. Now, nobody who isn't logged in as me can see my image and colors, so if somebody tries to mount Man In The Middle, they can't get access to my images etc. and the page will look all wrong. Sounds dumb but it might actually work pretty well in practice... But the key is that those images have to be private, so that they foe can't spider the page and show you a copy. Vinay -- Vinay Gupta - Designer, Hexayurt Project - an excellent public domain refugee shelter system Gizmo Project VOIP: 775-743-1851 (usually works!) Cell: Iceland (+354) 869-4605 http://howtolivewiki.com/hexayurt - old http://appropedia.org/ Hexayurt_Project - new Skype/Gizmo/Gtalk: hexayurt I have a proof which unfortunately this signature is too short ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On Apr 4, 2007, at 6:13 PM, Douglas Otis wrote: This may seem to be off topic, but I really don't see reluctance in using public key cryptography. DKIM would be one such example. Nearly every gateway, and access point can utilize this means of authentication. Think of this as yet another means to control an account without relying upon OpenID. OpenID opens the door, where you then hand them your public key. One might also wish to specifically define attributes containing public keys used by the identity. This would be information uploaded by the individual after creating their id_rsa.pub key information using either system tools or specialized applications. This would provide an alternative access method that would not rely upon OpenID exchanges. Here again, an expiry might prove handy, and so would a means to revoke the key. Perhaps this would be done by overlaying it. There could be keys used to authorize some other automated service, or to act as a replacement for OpenID once the key has been established. One might be defined for email, IM, VoIP, etc. It's not the public key management in a scheme like this that concerns me... Two issues: private key management - are the keys scattered, like your VOIP key lives in Gizmo, and your SSH key lives in your .ssh, and so on? Or do we by logical extension begin to impose some order here and have one key pair per person... you see where this goes, right? Secondly X509 certificates are very, very broken in terms of delegation semantics and certification semantics (at least in many people's eyes, mine included.) So.. SPKI? (yes, I've been over this territory and that's pretty much what I'm doing here.) Vinay -- Vinay Gupta - Designer, Hexayurt Project - an excellent public domain refugee shelter system Gizmo Project VOIP: 775-743-1851 (usually works!) Cell: Iceland (+354) 869-4605 http://howtolivewiki.com/hexayurt - old http://appropedia.org/ Hexayurt_Project - new Skype/Gizmo/Gtalk: hexayurt I have a proof which unfortunately this signature is too short ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On Apr 4, 2007, at 7:43 PM, Douglas Otis wrote: Related services that can be enabled by using OpenID as a key distribution scheme. Keys would need to relate to services handled by the consumer or RP. A sub-attribute could help facilitate correct placement of the keys and to allow different keys for different purposes. Secondly X509 certificates are very, very broken in terms of delegation semantics and certification semantics (at least in many people's eyes, mine included.) So.. SPKI? (yes, I've been over this territory and that's pretty much what I'm doing here.) How these keys are handled internally could be left to the consumer or RP. Either the OpenID server or the Consumer or RP could fashion their own certs based upon this information where it is administered and integrated with other services. The individual end-user would only need to submit their set of public keys for this to become possible. Hm. Well, I don't to suggest that we tear off fixing or expressing the whole semantics of PKI, but I do think that some care should be taken to make sure that it's clear what the security status of a returned key is. Problems like Confused Deputy can easily arise when you start dealing with registry systems which aren't under really tight control. I don't have a neatly packaged solution for this, but we're dealing with situations which can have very significant legal repercussions: digital signatures are legal for some kinds of transactions in some jurisdictions, and however this is handled is has to have some approach to the questions of what is they key good for, and who says it's OK for this purpose? Vinay -- Vinay Gupta - Designer, Hexayurt Project - an excellent public domain refugee shelter system Gizmo Project VOIP: 775-743-1851 (usually works!) Cell: Iceland (+354) 869-4605 http://howtolivewiki.com/hexayurt - old http://appropedia.org/ Hexayurt_Project - new Skype/Gizmo/Gtalk: hexayurt I have a proof which unfortunately this signature is too short ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On Apr 3, 2007, at 9:14 PM, Wayne Pierce wrote: One could say that OpenID should not be relied on to exchange sensitive information like bank account numbers, but 1) I think its a shame to limit a technology with such great potential, and 2) chances are that OpenID will be relied upon anyway - the sensitive transactions will just be performed longer down the chain, where they can't be checked. It will happen. I already have plans to share data far more sensitive than bank accounts and have brought the idea up to a few organizations that are at least interested in the concept. So far I have looked at layers of encryption, authorization and authentication on top of OpenID to solve this though. I'd like to second this. I'm looking at using OpenID in the developing world, in the context of helping communities to transition out of being refugee camps. The hardware is a few years away from being cheap enough to use, but has many billion-dollar companies working on it (cellphones, wimax, etc.) The software, however, is much less well examined, so that's where I'm currently focussing. In these contexts, your OpenID, accessed by your cellphone, may be the hardest identity credential you have - much more trustworthy than your government issued ID, given to you by a state you fled years ago - or the interim credentials your host country provided you with. I should be getting some OSD funding to work on this idea in the next few weeks. Vinay -- Vinay Gupta - Designer, Hexayurt Project - an excellent public domain refugee shelter system Gizmo Project VOIP: 775-743-1851 (usually works!) Cell: Iceland (+354) 869-4605 http://howtolivewiki.com/hexayurt - old http://appropedia.org/ Hexayurt_Project - new Skype/Gizmo/Gtalk: hexayurt I have a proof which unfortunately this signature is too short ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
