RE: Final outstanding issues with the OpenID 2.0 Authenticationspecification

> I'm sure that this will break a few implementations It certainly will break PHP-OpenID. Regards, Dmitry =damnian ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs

RE: RFC: Final outstanding issues with the OpenID 2.0Authenticationspecification

David, See, here's the problem. When I'm saying "productive conversations", I usually mean they yield something. Getting no replies or replies such as "it should be done the way that it's intended" is counterproductive. Everybody who finds my questions/suggestions stupid, please speak up. Regar

RE: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification

> Is it critical? No. Could we drop the constraint as you list it? Yes, > I think. Now that I'm rethinking it, "the entire document" in (c) and (d) should be replaced with "the form"... Regards, Dmitry =damnian ___ specs mailing list specs@openid.net

RE: RFC: Final outstanding issues with the OpenID 2.0 Authenticationspecification

> As a relative newcomer to the OpenID community, I realize this may have > been debated endlessly already, and I may just be shouted down. It definitely has been debated endlessly. > Or am I alone here? No, you aren't. There are many who agree with this entirely, some of whom have expressed the

RE: Final outstanding issues with the OpenID 2.0 Authenticationspecification

7.3.3. HTML-Based Discovery A tag MUST be included with attributes "rel" set to openid2.provider" and "href" set to an OP Endpoint URL A tag MAY be included with attributes "rel" set to "openid2.local_id" and "href" set to the end user's OP-Local Identifier Could somebody please enlighten me

RE: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification

Oh my, I'm still asleep... Here's a better formulation. The form field: a. MUST have "openid" as a substring of its "name" attribute's value, b. SHOULD have "openid_identifier" as its "name" attribute's value, c. SHOULD be the only form field in the entire document to satisfy (a) and d. MUST be

RE: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification

> As of today browsers are forced to make untenable assumptions to > detect OPs or RPs. Read > http://openid.net/specs/openid-authentication-2_0-11.html#initiation: > "The form field's "name" attribute SHOULD have the value > "openid_identifier" is the only point for a browser to grip the > protoco

RE: RFC: Final outstanding issues with the OpenID 2.0 Authenticationspecification

> -1. If XRI is to be included, it should be done the way that it's > intended. In that case, count my vote against including XRI in OpenID 2.0. Please note that this has nothing to do with #6. Regards, Dmitry =damnian ___ specs mailing list specs@ope

RE: RFC: Final outstanding issues with the OpenID 2.0 Authenticationspecification

> There is a proposed solution that we had consensus on (Dick's > "fragment" proposal.) Would you please specify whom you are referring to by "we"? I understand that various matters are being discussed outside of this list, but shouldn't the whole community be part of the decisions made? I didn't

RE: RFC: Final outstanding issues with the OpenID 2.0 Authenticationspecification

> I think this argument is bogus. There is hardly any additional > complexity aside from XRI and Yadis. I'm willing to entertain > suggestions for simplifying the handling of those discovery > mechanisms. The specification is significantly *longer*, but that's > primarily because it's much more rig

Re: Proposal for Recycling Identifiers in OpenID 2.0

Dick, This is definitely an interesting proposal. However, it only attempts to solve the recycling problem, whereas canonical IDs would solve this and several more. Will this break existing OpenID 1.1 RPs? Which ones? Is this going to be an issue for them? As far as I can tell, this would b

Re: Proposition: possible anti-phishing solution

Boris, Did you look at the Identity Manager proposal? < http://blog.phpbb.cc/2007/01/20/identity-manager-a-browser-based-solution-to-openid-phishing/ Regards, Dmitry =damnian ___ specs mailing list specs@openid.net http://openid.net/mailman/listin

RE: Conventions for encoding email-address localparts?

There is no standardized way of transforming email addresses to URIs. In fact, email addresses are already URIs. Two draft proposals exist, which allow transforming email addresses to URLs:

RE: Proposal for Modularizing Auth 2.0 Discovery

> I own markbaker.ca., and publish http URIs in that namespace. I might > (I don't) also have email addresses there, say [EMAIL PROTECTED] If > a public standard were crafted which defined a mapping for > mailto:[EMAIL PROTECTED] to something under http://markbaker.ca (say, > http://markbaker.ca/

RE: Proposal for Modularizing Auth 2.0 Discovery

I'd agree on specifying HTTP as the only resolution method required. Unfortunately, I have a conflict of interests with the SMTP service extension... Regards, Dmitry =damnian ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/sp

RE: Modularizing Auth 2.0 Discovery

> My proposal is that we make the core Auth 2.0 spec scheme-agnostic. It > would just state that an identifier is "a URI". +1 > Then we'd publish in parallel the following two ancillary specifications: > * OpenID Discovery for HTTP and HTTPS URIs > * OpenID Discovery for XRI URIs. The l

RE: Wiki page: Attempting to document the "Email Address as OpenId"debate.

Since it seemed that you hadn't noticed the proposed SMTP Extension for Yadis Discovery (which happened to predate the one mentioned on the page), I took the liberty of referencing it as well. I have also made a few formatting improvements en route. Regards, Dmitry =damnian