Re: [OpenID] OpenID IPR Policy Draft
On 12/6/06, Recordon, David [EMAIL PROTECTED] wrote: Hey guys, Been working with Gabe, and others, on starting to draft an IPR Policy for OpenID specifications. We'd appreciate feedback in terms of if what is written captures the correct intent of the community? We realize the language isn't technically as tight as it needs to be, though first want to make sure it is saying the right thing. It is largely based on the IPR Policy for Microformats. http://openid.net/wiki/index.php/IPR_Policy A problem with saying you MUST offer ... a royalty free license is that in order to be open-source-friendly the licence has to be automatic - otherwise potentially each user of the s/w has to jump through hoops to get the licence. Thanks, --David ___ general mailing list [EMAIL PROTECTED] http://openid.net/mailman/listinfo/general ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor's Draft 11
On 1/19/07, Recordon, David [EMAIL PROTECTED] wrote: So with great pleasure I get to announce the culmination of about nine months of work between the OpenID, XRI, Sxip, and LID communities in the drafting of OpenID Authentication 2.0. This evening the editors have published the final draft of the spec, which we now feel is in a solid state for public implementations. There are already implementations in various languages (http://svn.apache.org/repos/asf/incubator/heraldry/libraries/, http://code.google.com/p/openid4java/, http://code.google.com/p/openid4perl/) supporting this spec and more will emerge over the next few weeks. There will be another draft of the spec before it is considered final, though unless unforeseen implementation problems emerge these changes will be further wordsmithing and cleanup. http://openid.net/specs/openid-authentication-2_0-11.html (dated today) Cool? Cool! Still totally unhappy about the phishing issues, which I blogged about here: http://www.links.org/?p=187 --David ___ general mailing list [EMAIL PROTECTED] http://openid.net/mailman/listinfo/general ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor's Draft 11
On 1/19/07, Dick Hardt [EMAIL PROTECTED] wrote: On 19-Jan-07, at 6:19 AM, Ben Laurie wrote: Still totally unhappy about the phishing issues, which I blogged about here: http://www.links.org/?p=187 There are numerous ways of solving this. Several standard methods can solve it. It is a relationship between the user and the OP and the RP is not party, so I don't think it belongs in the OpenID Authentication specification. That does not mean it is not important, just that *this* spec is not the right place. I think that's entirely wrong. The RP doesn't care at all about the OP - all the RP cares about is the end user. More importantly, I think I have a solution that will make both of us happy, but I now have to go and ride my motorbike fast, so I'll detail it later. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor'sDraft 11
On 1/22/07, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: [mailto:[EMAIL PROTECTED] On Behalf Of Ben Laurie More importantly, I think I have a solution that will make both of us happy, but I now have to go and ride my motorbike fast, so I'll detail it later. Now there is an exit line to tempt the Gods. The only way that I can see that you are going to circumvent an attempt using existing browser capabilities is to introduce a malicious login page is through use of some form of shared secret such as a picture of a cuddly animal chosen by the user or Secure Letterhead. How is this kind of shared secret a defence against a MitM? Letterhead requires a browser upgrade so it breaks the 'existing capabilities' constraint. If you change the browser you might as well really change the browser and use a strong authentication mechanism based on PKI I'm sure you meant to say based on asymmetric cryptography. I think we need to take another look at the 'change the browser' case and make sure that we can take full advantage if the browser is changed. Damn straight. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Announcing OpenID Authentication 2.0 - Implementor'sDraft 11
On 1/22/07, Stephane Bortzmeyer [EMAIL PROTECTED] wrote: On Mon, Jan 22, 2007 at 03:36:44PM +, Ben Laurie [EMAIL PROTECTED] wrote a message of 28 lines which said: The only way that I can see that you are going to circumvent an attempt using existing browser capabilities is to introduce a malicious login page is through use of some form of shared secret such as a picture of a cuddly animal chosen by the user or Secure Letterhead. How is this kind of shared secret a defence against a MitM? If you see the cuddly animal as the background image of the login screen, you know you see the authentic login form. If you see an ugly beast, it means there is a Man in the Middle. The MitM cannot fake the login screen because he does not know the animal you choosed (the shared secret). Why not? The man in the middle sees what you would see, surely? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor'sDraft 11
On 1/22/07, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: From: Ben Laurie [mailto:[EMAIL PROTECTED] The only way that I can see that you are going to circumvent an attempt using existing browser capabilities is to introduce a malicious login page is through use of some form of shared secret such as a picture of a cuddly animal chosen by the user or Secure Letterhead. How is this kind of shared secret a defence against a MitM? Good question to address to those vendors selling such schemes. There are controls that can be put in place to control attempts to capture the shared secret but these rely on a lot of active defense infrastructure that it is dangerous to assume could be deployed by low end IdPs. The bigger problem is getting users to insist on the display of their secret before entering their details. Witness the recent rash of phishing attacks against these schemes. Letterhead requires a browser upgrade so it breaks the 'existing capabilities' constraint. If you change the browser you might as well really change the browser and use a strong authentication mechanism based on PKI I'm sure you meant to say based on asymmetric cryptography. No, any time you have a trusted key you have an infrastructure. Well, if you count give a copy of the public key to the OP as infrastructure, then sure. Some infrastructures have much higher costs than others. Support for offline verification as the Kohnfelder architecture attempts is very expensive. Key centric architectures are much lighter weight. The reason I state PKI is not to say 'it must be X.509', its because PKIX got the way it did largely because people underspecified and underarchitected in the beginning and then a bunch of folk resisted necessary features rather than working out early on how to accommodate them. The result being a series of extensions on extensions and no overall coherence. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor's Draft 11
On 1/22/07, Ben Laurie [EMAIL PROTECTED] wrote: On 1/22/07, Josh Hoyt [EMAIL PROTECTED] wrote: On 1/22/07, Ben Laurie [EMAIL PROTECTED] wrote: On 1/22/07, Ben Laurie [EMAIL PROTECTED] wrote: OK, the idea is pretty simple. Rather like the OpenID Authentication Security Profiles you have a profile where the RP states what kind of End User/OP authentication is acceptable to it. Sites with low/zero value attached to the login can accept any kind of EU/OP auth, whereas high value sites can require unphishable auth. I like the sound of this proposal, but I don't see how the RP could know whether the OP is actually using unphishable authentication when that kind of authentication is requested. Is it necessary for the RP to be able to tell for sure, and if so, how could it tell? No, I don't think it is necessary. If users want to trust their identity to OPs that lie, that's their decision. In that case, I think this could just be part of the Assertion Quality Extension. [1] I haven't been involved in that specification at all, but my understanding is that it provides a way of expressing what kind of authentication the RP would like to have when a request is made to the OP. Actually, it appears to allow the RP to tell the OP what kind of authentication was used, which is backwards. Sorry, I mean the OP to tell the RP! It also seems to be rather lacking in meat. Still, a step in the right direction. Josh 1. http://openid.net/specs/openid-assertion-quality-extension-1_0-01.html ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
