RE: Went Through it With Brad
Thought about that, though the request differs between 1.x and 2.0. :-\ --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Monday, November 13, 2006 7:38 PM To: specs@openid.net Subject: Re: Went Through it With Brad The problem with that proposal is that the maintenance of the HTML file and the maintenance of the server version is performed by different people, and that means it is impossible that they are consistent ;-) What about adding a version parameter to each response from the endpoint? On Nov 13, 2006, at 16:18, Recordon, David wrote: > Solution 1 seems like the most simple. "openid2" is a bit ugly, but > does resolve the problem. Otherwise we'd have to do something like > Yadis discovery against the server endpoint which would make things > more complicated and meta. > > --David > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh > Hoyt > Sent: Monday, November 13, 2006 4:15 PM > To: Recordon, David > Cc: specs@openid.net > Subject: Re: Went Through it With Brad > > On 11/8/06, Recordon, David <[EMAIL PROTECTED]> wrote: >> 2) 7.3.3 basically deprecates HTML-based discovery, saying that it is >> a way to know that the IdP is using Auth 1.1. While I know we >> believe > >> Yadis will be used in most applications, I hypothesize that the >> simplicity of HTML-based discovery will have it continue to prevail. >> I thus would propose we remove the sentence saying that this is a way >> to know that an IdP is running version 1.1. > > Yeah, it does. The justification for this is that there is no way to > specify a version for the server, so we have to assume something, and > since HTML discovery already used in 1.1, that's the only reasonable > assumption to make. I see two ways out of this: > > 1. Add another "rel" value to the HTML discovery for OpenID 2: > > > 2. Add some way of doing discovery on the endpoint URL for determining > the version, so it doesn't have to be part of the user's XRDS or HTML > document > > Either one of these would let us keep the nice, simple HTML discovery > mechanism for 2.0. > > Thoughts or ideas? > > Josh > > ___ > 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: Went Through it With Brad
The problem with that proposal is that the maintenance of the HTML file and the maintenance of the server version is performed by different people, and that means it is impossible that they are consistent ;-) What about adding a version parameter to each response from the endpoint? On Nov 13, 2006, at 16:18, Recordon, David wrote: > Solution 1 seems like the most simple. "openid2" is a bit ugly, but > does resolve the problem. Otherwise we'd have to do something like > Yadis discovery against the server endpoint which would make things > more > complicated and meta. > > --David > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh > Hoyt > Sent: Monday, November 13, 2006 4:15 PM > To: Recordon, David > Cc: specs@openid.net > Subject: Re: Went Through it With Brad > > On 11/8/06, Recordon, David <[EMAIL PROTECTED]> wrote: >> 2) 7.3.3 basically deprecates HTML-based discovery, saying that it is >> a way to know that the IdP is using Auth 1.1. While I know we >> believe > >> Yadis will be used in most applications, I hypothesize that the >> simplicity of HTML-based discovery will have it continue to prevail. >> I thus would propose we remove the sentence saying that this is a way >> to know that an IdP is running version 1.1. > > Yeah, it does. The justification for this is that there is no way to > specify a version for the server, so we have to assume something, and > since HTML discovery already used in 1.1, that's the only reasonable > assumption to make. I see two ways out of this: > > 1. Add another "rel" value to the HTML discovery for OpenID 2: > > > 2. Add some way of doing discovery on the endpoint URL for determining > the version, so it doesn't have to be part of the user's XRDS or HTML > document > > Either one of these would let us keep the nice, simple HTML discovery > mechanism for 2.0. > > Thoughts or ideas? > > Josh > > ___ > 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)
> retrieve more data via OpenID DTP as a back-channel request. So lots to > think about... Indeed. I'll play around with some ideas and maybe propose another doc as Dick suggested... Adam ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Went Through it With Brad
Solution 1 seems like the most simple. "openid2" is a bit ugly, but does resolve the problem. Otherwise we'd have to do something like Yadis discovery against the server endpoint which would make things more complicated and meta. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Monday, November 13, 2006 4:15 PM To: Recordon, David Cc: specs@openid.net Subject: Re: Went Through it With Brad On 11/8/06, Recordon, David <[EMAIL PROTECTED]> wrote: > 2) 7.3.3 basically deprecates HTML-based discovery, saying that it is > a way to know that the IdP is using Auth 1.1. While I know we believe > Yadis will be used in most applications, I hypothesize that the > simplicity of HTML-based discovery will have it continue to prevail. > I thus would propose we remove the sentence saying that this is a way > to know that an IdP is running version 1.1. Yeah, it does. The justification for this is that there is no way to specify a version for the server, so we have to assume something, and since HTML discovery already used in 1.1, that's the only reasonable assumption to make. I see two ways out of this: 1. Add another "rel" value to the HTML discovery for OpenID 2: 2. Add some way of doing discovery on the endpoint URL for determining the version, so it doesn't have to be part of the user's XRDS or HTML document Either one of these would let us keep the nice, simple HTML discovery mechanism for 2.0. Thoughts or ideas? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Went Through it With Brad
On 11/8/06, Recordon, David <[EMAIL PROTECTED]> wrote: > 2) 7.3.3 basically deprecates HTML-based discovery, saying that it is a > way to know that the IdP is using Auth 1.1. While I know we believe > Yadis will be used in most applications, I hypothesize that the > simplicity of HTML-based discovery will have it continue to prevail. I > thus would propose we remove the sentence saying that this is a way to > know that an IdP is running version 1.1. Yeah, it does. The justification for this is that there is no way to specify a version for the server, so we have to assume something, and since HTML discovery already used in 1.1, that's the only reasonable assumption to make. I see two ways out of this: 1. Add another "rel" value to the HTML discovery for OpenID 2: 2. Add some way of doing discovery on the endpoint URL for determining the version, so it doesn't have to be part of the user's XRDS or HTML document Either one of these would let us keep the nice, simple HTML discovery mechanism for 2.0. Thoughts or ideas? Josh ___ 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)
Hey Adam, Thanks for the insight! I know, as Dick described, there was a design decision made in terms of enabling payloads larger than 2Kb within OpenID Authentication requests and responses. With that said, there are other approaches, such as using GET requests and including a token to retrieve more data via OpenID DTP as a back-channel request. So lots to think about... --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Nelson Sent: Sunday, November 12, 2006 5:25 PM To: specs@openid.net Subject: 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL] Handle"http://[EMAIL PROTECTED]" Style Identifiers)
I'm not sure if it would necessarily be thrown away, I guess it is really up to the IdP. With two identifiers, it is pretty easy to pass to the IdP and let it decide what it wants to do. 1) I enter "[EMAIL PROTECTED]" as my identifier on the RP 2) RP does discovery on "recordon.name" and finds my IdP 3) RP constructs authentication request with openid.disco_id being "[EMAIL PROTECTED]" and openid.identifier being "http://openid.net/identifier_select/2.0"; That was all I was looking for describing in my initial proposal. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rowan Kerr Sent: Friday, November 10, 2006 11:23 AM To: specs@openid.net Subject: Re: Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL] Handle"http://[EMAIL PROTECTED]" Style Identifiers) On 11/9/06, David Fuelling <[EMAIL PROTECTED]> wrote: > So, '[EMAIL PROTECTED]' would be treated as if the User had entered > 'http://any.edu' (the URL of their IdP/OP) into the OpenId login form. I don't like the idea of telling people to enter their username, and then throwing it away. As mentioned below, [EMAIL PROTECTED] can map to a valid http url. This really, I suppose, is a matter of choice on the part of an IdP as to what sorts of instructions they give to their users about identifying themselves to RPs. Verisign's PIP does userx.pip.verisign.com Somone might do example.com/user/x Someone else might do [EMAIL PROTECTED] Discovery would be performed identically on all the above ... and we're left with a problem of user education. -Rowan ___ 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)
Well, as I've said before, I strongly believe that tying authentication to one particular HTTP verb is a bad idea, and unnecessary. I also believe that involving JavaScript in what is fundamentally an HTTP-level kind of protocol is a hack. It very likely is either unnecessary or points to a flaw in the conceptual model of the protocol, or both. The same may be true about having different protocols for thin-client and rich-client. Having said that, I am not making this point more strongly than I have because I don't think these issues are fatal and I don't want to raise more issues that delay OpenID 2.0 auth further. So I will log this as a bug against auth 2.0 as soon as it is published (and as soon as there is a place where to file bugs against the spec ;-)) but will bite my tongue in the meantime. On Nov 12, 2006, at 20:29, Dick Hardt wrote: 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 Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
