http://permalink.gmane.org/gmane.comp.web.openid.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.web.openid.general/8076 Excellent news! Integrating users' social identity and leveraging that on an automatically updated basis (daily, weekly, whenever the user tries to authenticate again and their Friend/Community status is rechecked) sets a good example. Might need more communication between OP and hosting provider to duplicate without using an internal (same-site) mechanism, but that's one of the things AX can be used for, or perhaps the site's API if it has one? I hope to see many other sites adopt this - Yahoo!, for instance, though it might not have Friends lists (Flickr?) or Communities, it does have *lists*, and since many of those have private membership, an anonymous way to prove "I am a subscriber to this list." would be *excellent* (speaking from a Relying Party standpoint). -Shade SitG Admin 2008-08-20T15:43:33 http://permalink.gmane.org/gmane.comp.web.openid.general/8075 _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general Nat Sakimura 2008-08-20T11:15:18 http://permalink.gmane.org/gmane.comp.web.openid.general/8074 Anyone care to recount their _technical_ interworking (and/or _policy_ accreditation) stories here, against Microsoft's OpenID RP? https://account.healthvault.com/OpenIdLogin.aspx?rmproc=true Notice that Microsoft (corporately) disclaims any "endorsement" of OpenID (the general "initiative", I assume) "Important: Microsoft does not provide OpenIDs, and does not endorse OpenID or any particular OpenID provider. Before you choose to use OpenID with HealthVault, we recommend that you evaluate the security and privacy commitments offered by the OpenID issuer and decide if they are appropriate for your HealthVault account. Guard the identity you use to sign in to your HealthVault account. Your OpenID or Windows Live ID is like a key to a safe. The safe may have many security features, but anyone who has the key can open it." It will be interesting to see if this disclaimer carries any legal weight, given the nature of the personal privacy information involved, especially since the corporation is evidently o Peter Williams 2008-08-19T17:21:13 http://permalink.gmane.org/gmane.comp.web.openid.general/8073 _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general Susanedoherty< at >aol.com 2008-08-19T11:25:33 http://permalink.gmane.org/gmane.comp.web.openid.general/8072 _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general Paul 2008-08-19T00:28:34 http://permalink.gmane.org/gmane.comp.web.openid.general/8071 As this year's Google Summer of Code pencils down date has passed, with great pleasure I announce that CL-OpenID version 1.0 Release Candidate 1 is out. Cl-OpenID is an implementation of OpenID protocol in Common Lisp. It implements OpenID Authentication 2.0 standard and is compatible with OpenID Authentication 1.1. Both Relying Party (formerly called OpenID Consumer), and OpenID Provider are implemented. CL-OpenID is available on terms of GNU Lesser General Public License version 2.1 with Franz Inc.'s preamble, also known as LLGPL (Lisp Lesser General Public License). The project has been developed as a Google Summer of Code 2008 project, developed by Maciej Pasternacki and mentored by Anton Vodonosov. Original application is published at. CL-OpenID home page is at http://common-lisp.net/project/cl-openid/ Current code is in darcs repository http://common-lisp.net/project/cl-openid/darcs/cl-openid/ The 1.0 Release Candidate 1 version is tagged 1_0_rc1 in darcs, and is also downloadable from http: Maciek Pasternacki 2008-08-18T20:06:06 http://permalink.gmane.org/gmane.comp.web.openid.general/8070 _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general Andrew Arnott 2008-08-18T19:56:14 http://permalink.gmane.org/gmane.comp.web.openid.general/8069 _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general Tara Kelly 2008-08-18T08:09:24 http://permalink.gmane.org/gmane.comp.web.openid.general/8068 _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general Andrew Arnott 2008-08-15T09:04:57 http://permalink.gmane.org/gmane.comp.web.openid.general/8067 _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general Andrew Arnott 2008-08-15T08:28:50 http://permalink.gmane.org/gmane.comp.web.openid.general/8066 _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general Uday Subbarayan 2008-08-14T17:27:39 http://permalink.gmane.org/gmane.comp.web.openid.general/8065 _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general Andrew Arnott 2008-08-13T23:41:56 http://permalink.gmane.org/gmane.comp.web.openid.general/8062 _______________________________________________ general mailing list general< at >openid.net http://openid.net/mailman/listinfo/general Andrew Arnott 2008-08-12T14:16:25 http://permalink.gmane.org/gmane.comp.web.openid.general/8061 On Tue, Aug 12, 2008 at 9:55 AM, Clausen, Martin (DK - Copenhagen) <mclausen< at >deloitte.dk> wrote: Browser plugins do not assist RPs. Ben Laurie 2008-08-12T13:31:00 http://permalink.gmane.org/gmane.comp.web.openid.general/8060 Yes, I do mostly look at this issue from the OP/IdP site. Which is a huge problem, IMHO. As I said, I would most likely prefer a solution like that; at the same time it seems easier to me to only allow a simple mapping between http and https versions. I'd rather have a quick and dirty solution to problem that can be ultimately extended to a more graceful solution, than engineer the problem for 6 months and leave the security hole open. Nevertheless, a generic identifier re-association would probably be the best solution. Yes. IMHO, for *any* future version of the protocol or its extensions, secure discovery should be REQUIRED--everything else leave the door open to more vulnerabilities. Best, Gerald Gerald Beuchelt 2008-08-12T13:09:59 http://permalink.gmane.org/gmane.comp.web.openid.general/8058 Ben Laurie: On behalf of openid.net.nz (as I am "just" a service supplier to the company), I can confirm that the weak/compromised SSL certificate used by openid.net.nz has been replaced by a strong certificate. Apologies for the delay here, it has as usual co-incided with important people being off the net for extended periods of time (aka "holiday"). However, given that openid.net.nz uses a self-signed certificate, the threat mechanism suggested by Ben probably does not materially change the "security level" of this service, which is not high. Most of his points are around the types of authentication implicitly and explicitly accepted/used by the OpenID implementations around the net, and I can't address them from here, but if anyone has any specific recommendation I'll be pleased to hear them :-) -jim http://inode.co.nz/ Jim Cheetham 2008-08-12T04:58:57 http://permalink.gmane.org/gmane.comp.web.openid.general/8057 Doesn't SAML have specific support for the very use case of migrating one id to another? Isn't this the name mapping feature - wherein an SP can record a new SP-Identifier (that can be shared across an affiliation of SPs)? I fear my memory is failing me, on the actual details. Sounds like we could be borrowing the use case analysis of the OASIS folk, at least - even if the service is ultimately expressed using openid-framework protocols. What matters in standards making is getting common service adopted and put into commodity form. This might be something the academic SAML folks and openid folks could cooperate on. The academic folk don't seem to be too interested in that particular SAML feature - perhaps lacking a strong, practical use case that the openid view on the world finally opens up, as folks see a need to easily swap out their login openid, across 10 web2.0 sites? -----Original Message----- From: general-bounces< at >openid.net [mailto:general-bounces< at >openid.net] On Behalf Of SitG Admin Sent: Monda Peter Williams 2008-08-12T03:11:04 http://permalink.gmane.org/gmane.comp.web.openid.general/8056 It might be easier to convince them if there were a standard for letting both URI's (old and new alike) "claim" the other. More like the reverse of claiming, though, since that's dangerous from either end; "I am willing to be associated with this URI." Something that could be automated by Relying Parties. -Shade SitG Admin 2008-08-12T00:36:06 http://permalink.gmane.org/gmane.comp.web.openid.general/8055 Point taken, Eric - therefore I will try to remember, in future, that when I want to make something theoretical easier to grasp by giving it an imaginary practical form, I should use YOUR name in the example :P -Shade SitG Admin 2008-08-12T00:31:17 http://permalink.gmane.org/gmane.comp.web.openid.general/8054 I apologise for the fact that I misunderstood what you were doing in my initial response; I thought you were coming at this from the RP's perspective, not the OP's. Really this is a specific form of the general problem of how to automatically migrate from one identifier to another. Manually updating all RPs you've used can be an arduous process, and some RPs don't even allow the identifier(s) associated with an account to be changed. However, I really don't like the idea of OpenID contradicting the established rules for URI normalization. I think if RPs are going to have to change anyway, it'd be better to introduce some explicit and general mechanism for automatic identifier switching on login. However, until most RPs are updated, neither approach is going to be very useful. What we could really do with is a way to work around this where only the OP would have to change. One approach could be to have the identifier URL *not* redirect to the https: version, but have the OP UI give the user th Martin Atkins 2008-08-11T23:01:18 http://permalink.gmane.org/gmane.comp.web.openid.general/8053 On Aug 11, 2008, at 4:42 PM, SitG Admin wrote: What if? Then I would say that you're a lot more interested in demonstrating your cleverness and trickiness than you are in providing something that users can understand and use. "Crazy" is the right adjective. Eric Norman Eric Norman 2008-08-11T22:26:01 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.web.openid.general