Here is the discussion note that I wrote for Contract Exchange.

http://openid.net/pipermail/specs-cx/attachments/20090730/8d9862f8/attachment-0001.pdf

Hopefully, the concept is quite clear and it acts as the level setting ground for the participants at specs-cx.

According to the current XRI TC discussion, it is looking like this.

<xrd>
    <Subject set="beginswith">...</Subject>
    <Alias>...</Alias>
    <KeyDescriptor use="*">
        <ds:KeyInfo>
           ...
        </ds:KeyInfo>
    </KeyDescriptor>
    <ds:Signature>
        <ds:KeyInfo>
           ...
        </ds:KeyInfo>
    </ds:Signature>
    <link>
        <rel>...</rel>
        <uri>...</uri>
        <Subject>...</Subject>
        <ds:KeyInfo>
           ...
        </ds:KeyInfo>
    </link>
</xrd>

Description

xrd/Subject : Type=URI. Subject Identifier or portion of Subject Identifier. CanonicalID in XRDS.

xrd/Subject/@set : (Option) Can specify “beginswith” to signify that the URI is only partial and beginswith the string.

xrd/Alias: Alias URI for the Subject.

xrd/KeyDescriptor: Wrapper element for ds:KeyInfo for the Subject.

xrd/KeyDescriptor/@use : Specify the usage of the KeyInfo, e.g., Signature, Encription, etc.

xrd/ds:Signature: Expresses the Signatory and the Signature over this XRD.

xrd/link: Shows the relationship that this Subject perceives against other subject.

xrd/link/Subjct: the Subject of the linked XRD.
xrd/link/ds:KeyInfo: has the public key of the Signatory of the Subject of the linked XRD. The linked XRD will be signed by the private key that corresponds to this public key, users can verify that the link is actually an inteded one.

Discussion Points

1. Do we really need KeyDescriptor?
2. Do we really need xrd/link/Subject? Would not xrd/link/uri suffice?

In Identity Loss with OpenID 2.0, I have depicted the problem of the current spec. and shown a possible solution verbally. Now, I am presenting it graphically, and with more details.

Let:

OP:=OpenID Provider
RP:=Relying Party
DS:=Discovery Service
AN:=Authentication Service
AP:=Attribute Provider.

Then, in OpenID Authentication 2.0,

OP==DS+AN (+AP)

Final identifier of the user is issued by AN.
This is a source of various problem as I have written in the past.

We can try to separate them out and have the DS issue the final identifier. Here is the sequence diagram for such a case, for user specified user identifier, where

Case 1: User Specified Identifier

USID:=User Specified ID
RPID:=RP’s ID
RPSig:=RP’s Signature over the message
PPID:=Pairwise Pseudonymous ID
CoreID:=Permanent ID of the user, Canonical ID

(fig.1)User Specified Identifier Case (Note: I have omitted LRDD portion.)

Note: Here, I have used PPID, but it could as well be a conventional permanent ID.

Case 2: OP Identifier (identifier_select)

For the case of identifier_select, it would be preceded by:

(fig.2) OP Identifier Case

Replace PPID here with USID in (fig.1) and the rest follows.

XRD

FYI, the user’s XRD that is returned from DS would look like this:

<xrd>
    <subject>example.com/ppid/132435</subject>
    <link>
        <rel>http://example.openid.net/an/1.0</rel>
        <url>https://myop.com/</url>
        <ds :KeyInfo>
             ....
        </ds>
    </link>
    <ds :Signature>
          ....
    </ds>
</xrd>

In the above sequence diagram, there are two XRDs involved: i.e., User XRD, and the AN’s XRD. The authentication endpoint is not written in the user’s XRD. It just has the link to the Authentication Provider and the concrete end point must be obtained from the AN’s XRD.

There are some security features involved here as well.
First, the user’s XRD is signed. Who should sign this XRD is still an open question. It may be application specific. For the interest of privacy, in the above case, I think it should use example.com’s certificate.

You should also note XRD/Link/ds:KeyInfo.
It has a list of public keys in it.
It says that the XRD of the AN must be signed by the private key corresponding to one of the public key in the list. This makes sure that the AN is the service that this user has intended to use.