Draft OpenID v.Next Discovery working group charter

John Bradley john.bradley at wingaa.com
Thu Apr 15 01:14:41 UTC 2010


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



More information about the specs mailing list