[OpenID] Comment on new Draft host-meta

Sun Oct 25 18:42:19 UTC 2009

Interesting.

But the I-D didn't say much or any of that clearly in the introduction. It
did use words like scheme, etc, and authority. But it didn't disclose the
purpose, the intent or the (openid) problem. It did everything other than
state the topic. It was almost trying NOT to state the topic, in the
introduction!

So, let's summarize what folks like me in  the bottom half of the class now
know "a bit about" (so we can write about it in our security 101
assignments).

We have XRD 1.0. It does everything that the XRI-linked XRD data structure
we are familiar does/did. Some field names have changed - which changes the
XRD's orientation a little (to the wider, modern view of what an XRD is
for). But, if you had internalized XRD of old, XRD of new is the same thing.
It's a file of pointers between (optionally named) metadata documents. The
revision allows those who view XRI as web heresy (a mix of W3C and the DNS
crowds) to avoid getting upset with XRD itself.

We have an IETF I-D on host-meta that profiles XRD 1.0's generic format. Not
that there is any working group in openid with a question on YADIS or XRI
replacement in openid auth v2, the host-meta profile of XRD might be thought
of as a update to YADIS+XRD. 

What is notable is the choice of forum: IETF. IETF is the vehicle by which
IAB guides and enforces what is in the interest of the internet (according
to it and its sponsors). Its tends to be DNS centric, but with DNS comes
lots of politics (including international politics). Names and name
resolution is always political, since they are a "control" structure.

Now, what was YADIS formally? It was a protocol for retrieving a particular
class of XRD - an "early profile of XRI v2" if you like In that profile, the
XRD addresses identifiers that were http URI rather than XRI, and some of
the SEP fields (e.g. localid) had unusual semantics (compared to their role
in XRI).

If one analyzes the old XRI V2 spec carefully, one can see how the worlds of
XRI identifier resolution and http URI identifier resolution were "mashed
up" (not entirely cleanly). I always assumed this was a result of the "XRI
and openid" political pact - which resulted in http identifiers being "added
into" the XRI resolution spec. The mashup of ideas was not entirely clean -
and indicated to me that the underlying XRI concept did not originally have
a mission of accommodating multiple classes of identifiers. At the same time
the merger worked, perhaps showing that the logical basis for XRD/XRI (as
perhaps more clearly showcased in the XDI work) was all along identifier
scheme independent.

That said, we learn from blogs and twitter and even some documents drafts
that the identity gang is innovating again (mostly in forums OTHER than WGs
of the openid foundation). Openid and OAUTH seem to be the major intended
applications, in today's world. Host-meta updates the XRD profile that a
successor to YADIS might access - and that YADIS successor (an HTTP-based
access protocol, remember) seems to be LRDD.

Whereas openid specs implicitly specified the XRD profile for YADIS, and
YADIS itself specified the (pretty simplistic) access protocol based on
browser-centric notions of HTTP headers, now IETF will specify the host-meta
profile formally. If I guess, LRDD will specify a YADIS access protocol
replacement.

In this question of "openid upgrade" (not that there is an openid Foundation
WG with any such question to decide) DNS control constructs appear to rear
their ugly head. In this, the handling of openid identifiers may be tied to
"scheme mapping controls" (which is not the ugly part). Given the
introduction of DNS security controls into the handling of identifiers
(something not present in openid1 or openid2), this seems to bring with an
inherited governance structure (based on "scheme authorities" that are now
being tied to DNS registration entities, and DNS's own internal governance
mechanisms). This topic is obviously relevant to the mission of the openid
(de-centralized, user centric) etc - a mission that MAY be changing on us as
we speak, given the introduction into the equation of a role for DNS
[governance] that did not exist before. 

In general, the notion of a need for TTP services engaged in "scheme
mapping" seems to be an application of synonym handling - so openid3
(particularly under Google's leadership) can migrate to user-friendly email
addresses in the UI (which map onto http URIs under the hood, upon "scheme
mapping"). However, that mapping needs to be "authoritative". In this way,
consumers get what they will consume (email addresses), but one stays
compatible with the semweb technically (based on http URIs). Jurisdictional
issues about who controls what schemes in which authority spaces... seem
tied up with DNS issues, and address the authoritiveness questions. The
purposes of trusted XRD (signed XRDs with subjects) appear orthogonal to
this core authoritativeness issue set.

-------

What DARPA are upto in projecting US-centric controls via DNS needs
monitoring (as always). But, none of it sounds particularly evil. In fact,
its sounds a quite exciting upgrade path - even if I have only got it 30%
right. 

Former-outsider "Openid" joins and influences core internet/web
infrastructure, say the mock PR. 

Wow! 

-----Original Message-----
From: John Bradley [mailto:ve7jtb at ve7jtb.com] 
Sent: Sunday, October 25, 2009 4:52 AM
To: SitG Admin
Cc: Peter Williams; openid-general at lists.openid.net
Subject: Re: [OpenID] Comment on new Draft host-meta

The point of host-meta is to provide a way to resolve the XRD for non  
http: URI that the author who controls the DNS authority may wish to  
have resolved.

As an example the email address john at example.com is not a http URI.

Example.com may or may not want to provide XRD for there email  
addresses.

Being explicit about what URI schemes the host-meta XRD covers allows  
the XRD author more control.

What the host-meta people are doing is creating a extension element so  
that the host-meta XRD can be explicit about what additional non http- 
schemes  they want to provide identifier to meta-data mapping for.

LRDD/Webfinger/host-meta should be thought of as the the next  
generation of Yadis not XRI.

There will be a XRI resolution spec.  It has been decoupled from the  
XRD spec so that any issues the W3C may have with XRI won't hold up  
XRD for use in other resolution protocols.

John B.

On 2009-10-25, at 12:36 AM, SitG Admin wrote:

>> The example however speaks for itself and (formal writing issues  
>> aside)
>> seems obvious and useful.
>
> Now . . . silly question, here, but it's been bugging me for a  
> while, so:
>
> Why can't the XRD file simply *contain*, in some (optional) element 
> (s), the very information that would normally be documented in  
> whatever page it was pointing at with the Subject field? In other  
> words, if it is (implicitly) its *own* Subject, what (other than  
> more bandwidth usage) can result in embedding the rules it will  
> abide by?
>
> I'm overstepping my understanding of XR* here, though, and  
> speculating on what Subject is there for.
>
> -Shade
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general