Re: Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL] Handle"http://[EMAIL PROTECTED]" Style Identifiers)
On 10-Nov-06, at 10:05 AM, David Fuelling wrote: >> -Original Message- >> From: Dick Hardt [mailto:[EMAIL PROTECTED] >> Sent: Friday, November 10, 2006 11:28 AM >> To: David Fuelling >> Cc: specs@openid.net; [EMAIL PROTECTED] >> Subject: Re: Map/Normalize Email Address to IdP/OP URL (Was >> [PROPOSAL] >> Handle"http://[EMAIL PROTECTED]" Style Identifiers) >> >> I strongly have the view that [EMAIL PROTECTED] is a really bad idea. >> >> Your dad is not providing his password to the RP, and should not be >> prompted for his username there. >> >> He should be prompted for the site he wants to get sent to where he >> can then enter his credentials. >> >> This model is something your dad is likely even more familiar with, >> typing in hostname into the address bar. Typing in the site where he >> logs in is what he does at the OpenID prompt. >> >> btw: why is this thread cross posted? >> >> -- Dick > > Dick, > > Valid points. I'm curious to know: > > 1.) Do you think 'email address normalizing to IdP URL [ignore > userid]' > would qualify as an OpenId extension (i.e., could it "ride on top" > of the > current protocol)? > > 2.) Would you have the same objections if this were an extension, > but not in > the formal spec? I think it is far to contentious to even consider putting into OpenID Authentication. I'd like to hear counter points to the issues I brought up. Technically we could do the address normalization etc., but the issues are primarily the User Experience at the RP. Perhaps you can show the screen shot that a user will see when they are going to login and we can approach it from that perspective? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: IdP's Advertising Both http and https
On 9-Nov-06, at 7:45 AM, Rowan Kerr wrote: > On Wed, 2006-11-08 at 00:42 -0800, Dick Hardt wrote: >>> -Original Message- >>> From: Recordon, David >>> >>> But the security warnings will still exist: >>> - RP redirects me to http on IdP >>> - IdP redirects me to https on IdP for login page (warning) >> >> no warning on GET redirects > > If GET is going to be an acceptable method for responses, the spec > should be updated. Section 5.2.1. HTTP Redirect states: > > This method is deprecated as of OpenID Authentication version > 2.0 though is still required for implementation to aide in > backwards compatibility. To clarify, the GET redirect that I am referring to is one to is to the same host. We moved to a POST between RP and OP so that we could move more data. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)
I've been tracking OpenID auth from 1.0 with great interest. Last summer Johannes Ernst explained to me how it was that one might use openid to authenticate a non-interactive user agent such as a REST API consumer by intercepting the RP's redirect and providing the info from the IdP itself. Given OpenID's design goals (decentralized, lightweight, flexible identity management), and its seemingly inevitable adoption into the mashup-minded web 2.0 ecosystem (God help me I'm buzzwording!), it seems to me that OpenID's value is significantly enhanced if the identities it enables can be used to authenticate to SOAP and REST APIs as well as interactive web sites. Having said that, I was surprised to note in draft 10 of OpenID Auth 2.0 that the HTTP redirect method of communication between the RP and the IdP is deprecated in favor of an HTML forms-based approach. This suggests to me that OpenID Auth 2.0 is not compatible with REST or SOAP or any other binding that doesn't involve the exchange, parsing, and submission of HTML forms. I'm curious why this decision was made, and if its implications have been fully considered. Has there been any thought given to an alternative means of authentication, perhaps via custom HTTP headers or some other non-HTML means? If not, does this mean OpenID is not intended to support authentication to programmatic APIs? Thanks, Adam ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)
Hi Adam The switch from GET to POST was made so that we were not constrained by the URL parameter payload limit. As you point out, HTTP headers can be used for moving messages as well, but there was no clear mechanism to do that without modifying all the widely available browsers. I think REST support is a really useful feature, and have described how that might happen in the past, but right now we are pretty focussed on getting browser based auth finalized, and I think the mechanisms for rich clients will be related, but slightly different. -- Dick On 12-Nov-06, at 5:24 PM, Adam Nelson wrote: > I've been tracking OpenID auth from 1.0 with great interest. Last > summer Johannes Ernst explained to me how it was that one might use > openid to authenticate a non-interactive user agent such as a REST API > consumer by intercepting the RP's redirect and providing the info from > the IdP itself. Given OpenID's design goals (decentralized, > lightweight, flexible identity management), and its seemingly > inevitable adoption into the mashup-minded web 2.0 ecosystem (God help > me I'm buzzwording!), it seems to me that OpenID's value is > significantly enhanced if the identities it enables can be used to > authenticate to SOAP and REST APIs as well as interactive web sites. > > Having said that, I was surprised to note in draft 10 of OpenID Auth > 2.0 that the HTTP redirect method of communication between the RP and > the IdP is deprecated in favor of an HTML forms-based approach. This > suggests to me that OpenID Auth 2.0 is not compatible with REST or > SOAP or any other binding that doesn't involve the exchange, parsing, > and submission of HTML forms. > > I'm curious why this decision was made, and if its implications have > been fully considered. Has there been any thought given to an > alternative means of authentication, perhaps via custom HTTP headers > or some other non-HTML means? If not, does this mean OpenID is not > intended to support authentication to programmatic APIs? > > Thanks, > Adam > ___ > 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: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)
Hi Dick: > I think REST support is a really useful feature, and have described > how that might happen in the past, but right now we are pretty > focussed on getting browser based auth finalized, and I think the > mechanisms for rich clients will be related, but slightly different. That all makes sense, thanks. Is that to say that rich client support isn't a goal of v2.0 of the spec, or just a goal subsequent to the conclusion of browser-based auth? Adam ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)
On 12-Nov-06, at 8:19 PM, Adam Nelson wrote: > Hi Dick: > >> I think REST support is a really useful feature, and have described >> how that might happen in the past, but right now we are pretty >> focussed on getting browser based auth finalized, and I think the >> mechanisms for rich clients will be related, but slightly different. > > That all makes sense, thanks. Is that to say that rich client support > isn't a goal of v2.0 of the spec, or just a goal subsequent to the > conclusion of browser-based auth? Not a goal of OpenID Authentication 2.0 I think it would make sense to make it a separate document, and would value your involvement! -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
