We created some CardSpace (f.k.a. InfoCard) screen shots for our own purposes, and decided we might as well publish them for others who want to see how CardSpace has turned out in Microsoft .NET 3.0.

On the NetMesh Developer's Site at netmesh.org/odds-ends/cardspace-screenshots/.

What is wrong with this picture?

% dig myspace.com
...
;; QUESTION SECTION:
;myspace.com.                   IN      A

;; ANSWER SECTION:
myspace.com.            85833   IN      A       216.178.32.50
myspace.com.            85833   IN      A       216.178.32.51
myspace.com.            85833   IN      A       127.0.0.1
myspace.com.            85833   IN      A       216.178.32.48
myspace.com.            85833   IN      A       216.178.32.49

I tried from a couple of points on the internet, and I'm getting the same result. Sounds like somebody managed to insert themselves between a hapless user and MySpace. One can guess what they are up to ...

This is the kind of attack we'll have to watch out for around OpenID.

I asked on the OpenID/Yadis list about the OpenID trust_root parameter:

... I've never quite understood what the attack is that the OpenID trust_root [parameter] protects against. There seems to be no mechanism by which the user (or the IdP) could force the RP to only apply authentication to places covered by trust_root. And return_to already points to where the authentication assertion goes.

Josh Hoyt responded, and with his permission, I'll post our conversation here in case others have the same question:

Josh:

Having a trust root does not prevent an attack. It just provides an indication to the user of what the Relying Party intends to do with the decision. Its primary purpose is to make the user experience nicer, by being easier to understand than a full return_to URL. It also allows the IdP to help the user with authentication decisions for a site, even if the return_to changes (e.g. by adding query parameters)

Johannes:

So if it is only about the user interface, then why are we checking it on the IdP side?

Josh:

It's being checked to make sure (as much as we can) that the RP is not misrepresenting itself to the user. The checks are to make sure that the return_to actually *is* in the range that the RP is claiming and that the range is something sane.

This is a good explanation. Thanks, Josh. As a friend of minimalistic protocols, I'm still not sure it's really needed (e.g. do we really need to have return_to URLs that have incomprehensible parameters?) but the use that Josh suggests is a good one. I hope somebody will put a sentence into the upcoming OpenID 2.0 spec that explains this in a similar manner.

Thanks to some intense e-mail exchanges with Drummond Reed, CTO of Cordance, I now understand much better how XRI resolution works. With his permission, I'm blogging some of the highlights, in the hope that it will be useful for others as well:

Johannes:

Where in the OASIS docs does it say how one gets from an =example XRI to an http://xri.net/=example URL? Or should it be https://xri.net/=example?

Drummond:

In XRI Resolution 2.0 Working Draft 10, the overall definition of http proxy resolution are in section 7. That's where it specifies using a "xri.*" DNS prefix, either as a second level domain (of which there are a fixed number), or any third- or lower-level domain.

XDI.org registered xri.net to serve as the domain for its public XRI proxy resolution network, which is the only publicly supported XRI proxy res network that I know of so far ... companies can run their own.

The XDI.org XRI proxy resolution network specs are part of the XDI.org Global Services Specifications (GSS). Specifically they are section 5.1 and 5.3 in this PDF.

Hope this helps.

Johannes:

Right document, wrong version! (in which I looked) Thanks!

But now I'm more confused. (Sorry.) I had been working under the assumption that, say =Drummond or any other XRI would be a globally unique identifier. Is it? What you seem to say is that, say, Boeing, could define it to mean something else. Am I correct about that?

Drummond:

No, =drummond is a globally unique identifier. The power of XRIs (and XRI proxy resolution) is that globally unique XRIs can be syntactically understood in the context of OTHER globally unique XRIs (or URIs).

For example, when it comes to proxy resolution, every XRI proxy resolver works the same way. The formula is:

[http: / https: ] xri.* / qxri

The combination of the above is called an HXRI (HTTP XRI), and it consists of putting an http proxy resolver prefix in front of an XRI (called the "query XRI" or QXRI).

The XDI.org proxy resolver network responds to either http://xri.net or https://xri.net (the only difference is the access protocol).

So the following two are equivalent:

http://xri.net/=drummond.reed
https://xri.net/=drummond.reed

In both cases, the xri.net proxy resolver is simply resolving the XRI =drummond.reed and returning the result.

If a company brings up their own XRI proxy resolver service at xri.example.com, and offers both http and https, then it too can resolve =drummond.reed, and should return exactly the same result. In that case, all four of the below are equivalent:

http://xri.net/=drummond.reed
https://xri.net/=drummond.reed
http://xri.example.com/=drummond.reed
https://xri.example.com/=drummond.reed

In all four cases, the same globally-unique XRI is being resolved: =drummond.reed. The only difference is the XRI proxy resolver you are asking, and what protocol you are using.

Johannes:

Thanks for your patience in this.

So where does it say that all XRI strings must resolve to the exact same information, regardless which resolver is used? (And I think this must be a 'must', otherwise I don't see how the identifier can be globally unique?)

Drummond:

It says that in the XRI Resolution 2.0 Working Draft 10 spec, however in section 7.7 it points out:

7.7 Differences Between Proxy Resolution Servers

An XRI proxy resolution request may be sent to any proxy resolver that will accept it. All XRI proxy resolvers SHOULD attempt to deliver uniform responses given the same QXRI and input parameters. However because proxy resolvers may potentially need to make decisions about network errors, reference processing, and trust policies on behalf of the client they are proxying, and these decisions may be based on local policy, in some cases different proxy resolvers may return different results.

This is just reality -- the same thing can happen in DNS. The point is that that XRI resolvers always SHOULD do this even if they can't enforce perfection.

Johannes:

Ah, now I'm beginning to understand this. Just like I can set up a DNS server that returns different results than an "official" DNS server would ("don't do this at home, kids"), one could set up an XRI resolver that did something different, but it is frowned upon and might have bad consequences.

Then from a logical perspective, there is only one XRI resolution service. On a networking level, there are many for reliability, distributed processing etc. etc. kinds of reasons. All of which ultimately delegate to the central repository (which in turn may delegate).

The consequence is that it really doesn't matter which instance of the resolution service I resolve against, as long as I'm okay with the QoS that I'm getting from them. And if XRIs were to become as ubiquitous as DNS, then all sorts of funny policies would be implemented that would force people further out at the edges to use services close to them instead of everybody always going to the root servers.

Do I have it right this time? ;-)

Drummond:

Yes, you got it -- with the exception that we're hoping it's not so much "funny policies would be implemented that would force people further out at the edges" rather than good OpenXRI code that caches efficiently plus the inherent advantages of persistent i-numbers (which will appear primarily as CanonicalID values) that will not need to be looked up as often as DNS, where all the identifiers are reassignable.

In many ways, XRI infrastructure is DNS done at a higher layer -- a layer truly designed for the requirements of identity services rather than just host naming. The members of the XRI TC took about 18 months to arrive at that conclusion, and now that it's up and operating, it's a lot easier to start to share that worldview.

Since we have to start to produce a new round of XRI education/ evangelism documents this fall as we finish the XRI 2.0 suite, please do tell me if you have suggestions as to how we can better communicate about it. Many of us on the TC are WAY too close to it ;-)

Well, here is suggestion number 1: I blog it. I'm hoping it helps others to understand this as well. Many thanks, Drummond, for educating us!!

[Continued from this post that collects some of the questions/requirements]

Here are our thoughts on how a protocol to manage groups of REST-ful entities could look like. First, here are some design principles:

• Anybody can create a group of anything, at any time, there is no central "group registration service" or anything like that that's required.
• Any group is identified with a HTTP/HTTPS URL (or other identifier, such as XRI, that's resolvable into such a URL). To set up a group, all that's needed is that somebody declare that a particular URL represents a group. In the extreme case, that URL may not actually have any behavior — yep, there are some cases where that may be useful — but usually such a URL will support a few operations (see below).
• The members of the group are URLs themselves (or any other kind of identifier, such as e-mail addresses, etc. There are fewer restrictions on the contained identifiers because there's no need for those identifiers to be REST-ful).
• There are no restrictions between the location of that identifier, and the members that the group has. For example, URL http://example.com/mygroup could be a group that contains only members on netmesh.org, but no other host. There is no requirement that such a group would have to reside on netmesh.org as well. Anybody can group anything from anywhere on the web.
• There are a number of operations on that group (see below); it's very important to recognize that different clients may be allowed to perform different operations, so this ability — essentially ACLs on the various operations — must be designed in from the beginning. For example, only some clients may ever be allowed to see the entire membership list of a group.

Now, the operations. Recall that any of them may be subject to access control on a per-client basis and only some clients may be allowed to perform any one of them.

• Obtain a list of all members of the group.
• Add a member to the group. Not all groups may implement this. For example, a group such as "all users who blog commented at this site in the last 24 hours" should not have an addition operation.
• Remove a member from the group (not all groups may implement this).
• Determine whether or not a certain potential member of a group is actually a member of that group (return boolean).
• subscribe to the group, i.e. obtain change notification (think: e-mail) when the group changes.

Of course, there is no reason that a group http://example.com/mygroup could not be a "projected group" that takes its membership from other groups, such as "this group contains all members that are members of group http://example.net/joesgroup but not of http://spam.example.net/spammers".

Finally, a concrete implementation could look like this, where GROUPID is the group identifier (e.g. its HTTP URL). All these operations would be subject to an ACL defined for the GROUPID and clients would be required to authenticate first using OpenID or GPG-based authentication:

• GROUPID?action=groupid-list-members: return the list of members of the group. An optional format parameter, as we have it in LID, could specify a MIME type for the result, such as text/plain or text/html or RSS-FOAF.
• GROUPID?action=groupid-add&id=MEMBERID: add a new member with the identifier MEMBERID.
• GROUPID?action=groupid-remove&id=MEMBERID: remove a new member with the identifier MEMBERID.
• GROUPID?action=groupid-check-member&id=MEMBERID: determine whether or not MEMBERID is a member of the group.
• GROUPID?action=subscribe&id=SUBSCRIBERID: send change notifications to the subscriber with SUBSCRIBERID, which can be an e-mail address or a URL that supports the LID Authenticated Messaging protocol.
• GROUPID?action=unsubscribe&id=SUBSCRIBERID: cancel change notifications to SUBSCRIBERID.

While more complex capabilities can be envisioned, I think this is about all that's needed for most of the applications that we came across. (and one can always add operations)

The only other thing I'd add is to perform the operations only directly on the identifier GROUPID if GROUPID is an HTTP URL, and does not support Yadis meta-data discovery. If it does, more types of identifiers can be used, such as XRIs, and the actual implementation can be delegated. This is desirable largely for the same reasons as identity server delegation is desirable in OpenID. (If this paragraph makes no sense to you, don't worry about it, Yadis should be optional for this kind of thing and you don't need to understand Yadis to understand what I'm talking about here.)

In a future post, I will discuss a few of the really interesting capabilities that this kind of protocol will all give us. We first started thinking about this more than a year ago, and that's where my Rsfoaf proposal (later superseded by RSS-FOAF) came from, in case you have been following that and were wondering ... The groups in those feeds are exactly the kinds of groups that I'm discussing in this post.