For the purposes of the charter I am OK with leaving this as an issue for the WG to decide on.
But in general, less is more. Remember that the cleverness of the Web was as much what was left out as what what went in. Rather than designing things for the uber technical to lash together, I would prioritize making things as easy as possible for the naive user who has only barely graduated from AOL. Whatever I might want to do myself, what causes me most annoyance is calls for tech support from naive users. I want to simplify their lives for my own selfish interests. The set of use cases I have simply never understood the justification for are the alleged technical users who are not very technical. As a rule of thumb I think that attempting to make any IdP technology easier to configure or deploy than an inbound mail server is a futile mission. No new server software is going to be as well tested as a mail server. Deploying a mail server is relatively straightforward these days, but not something that most Internet users would want to do. I am also interested in what we can do to leverage the DNS registrars. Standing up an IdP that their customers have the option of using is a great way to increase the value of a DNS name to their customers. I doubt they could charge extra for doing that, but they have a competitive advantage. I am much less interested in persuading people to run their own IdP as I am in persuading them that they should control their own name. That in my view means that every Internet user should have a domain name of their own. On Wed, Apr 14, 2010 at 9:14 PM, John Bradley <[email protected]> wrote: > There is a valid architectural point Phillip makes regarding the hierarchy of > authority. > > If you want to resolve meta data for an email address or ftp endpoint you > should not assume http://www.google.com is authoritative over > ftp://ftp.google.com. It may well be but in many environments they may be > controlled by entirely different parts of the organization. It breaks web > architecture and may have bad security side effects. > > I think that using link headers to point to a XRD for a URI is > uncontroversial, though there is an issue of if you should look for a link > header first or go strait to host-meta and use a link template to find the > XRD. There are both philosophical and practical considerations to this > choice. > > Where there is the most disagreement is on how to find host-meta and what the > subject of host-meta should be. > > This has gotten any number of us into heated debates. > > In a more ideal world DNS is authoritative for resolving hosts and service > addresses for a DNS authority. > XMPP and other protocols use SRV records to accomplish this. > > Things inside particular URI schemes can have a hierarchy, but one scheme > cannot be authoritative for another. > > There is also the principal of not reserving names in other peoples address > space. robots.txt and other well known location files in http violate this, > in the name of the greater good. > > Putting the host-meta at a well known location and treating it authoritative > across URI schemes breaks these rules. > > The authors of LRDD made the choice to use a well known location file fully > understanding the issues. > They have concluded that the adoption benefits of breaking the W3C rules > outweigh the negative consequences. > > I think that signed XRD mitigate a number of the issues if people actually > check the signature. > > Some people see this as a small thing, others as yet another step towards the > destruction of the web. > > Personally I argued for the DNS SRV record approach, I lost that debate. (I > am used to that) > > If others want to take it up that is fine with me, but I am not going to > hold up moving forward on discovery on this point. > > The LRDD group did not make there choice out of ignorance, it was quite > deliberate. > > So what Identifier types are you thinking of? > > http:/https: URL > acct: email looking identifiers > XRI > other? > > Do you think some should be MTI (Mandatory to Implement) and others optional? > > Regards > John B. > > On 2010-04-14, at 8:36 PM, SitG Admin wrote: > >>> Shade, is there specific language that you would like in the charter? >> >> I *would* like to see OpenID open to more than one discovery mechanism; you >> already have this outlined in the charter ("or family of discovery >> specifications"). >> >> The point Phillip made (that drew my attention to this thread) was about DNS >> support for fitting into the internet architecture, but other discovery >> methods being "in addition to" DNS; since DNS has been supporting the >> browser redirects OpenID uses for discovery so far (not RP's discovering >> OP's, but users aren't redirected to an IP address), it seems to be that the >> charter directs its WG to come up with a viable alternative to DNS. >> >> Is the non-goal of v2.0 compatibility an abdication to another WG, or is >> OpenID v.Next intended to be a complete replacement for OpenID v2.0? >> >> I think that requiring IDP's to be able to adjust (and, requisitely, *have*) >> SRV records restricts ordinary users from being able to create/control their >> own URI endpoints; if the user is to have any power in this regard, *they* >> should be able to declare that their IDP is reliable enough *for them*. Not >> trusting it would be RP's choice, not a restriction of the spec. >> >> I do not want to see OpenID reliant upon the centralized DNS system. If it >> bootstraps from there and then switches to Web of Trust, ambivalence; if it >> can try alternate DNS systems (*cough* Tor) instead / alternatively / in >> parallel, happiness. I would conditionally extend that, *if* DNS support is >> written into the charter, I would like it to be treated no differently from >> other discovery methods. >> >> -Shade > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
