Draft OpenID v.Next Discovery working group charter

Phillip Hallam-Baker hallam at gmail.com
Thu Apr 15 02:16:14 UTC 2010

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

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 <john.bradley at wingaa.com> 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
> 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
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs

New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,

More information about the specs mailing list