OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Interesting XRID bootstrap twist


In section 2.2.3 of the Resolution spec we recommend the following about the
root XRID for an identifier community:

"The root XRID, or its location, is known a priori and is part of the
configuration of a resolver, similar to the specification of root DNS
servers in a DNS resolver. (Note that is not strictly necessary to publish
this information in an XRID-it may be supplied in any format that enables
configuration of the XRI resolvers in the community-but providing an XRID at
a known location simplifies the process.)"

XDI.ORG is doing this now for the community roots it plans to offer, and in
writing the specs an interesting bootstrap twist has come up. According to
section 2.2.2, the xrid:Resolved element is required, as is the AuthorityID
element. But these take on an interesting role in the root XRID because the
Authority being described can be the same Authority publishing the
description. In other words, the XRID may be entirely self-describing.

To illustrate, look at the following hypothetical root XRID for the
community "xri://(http://example.org)":

<XRIDescriptors xmlns="xri://$res*schema/XRIDescriptor*($v%2F2.0)">
    <XRIDescriptor xrid:id="first">
        <Resolved>(http://example.org)</Resolved>
		<AuthorityID>(http://example.org)</AuthorityID>
        <Expires>2005-09-30T00:00:00Z</Expires>
        <Authority>
            <AuthorityID>(http://example.org)</AuthorityID>
            <Type>xri://$res*auth.res/XRIA</Type>  
            <URI>http://example.org/resolve</URI>
            <URI>https://example.org/resolve</URI>
        </Authority>
        <TrustMechanism>xri://$res*trusted/None</TrustMechanism>
    </XRIDescriptor>
</XRIDescriptors>

In this case the Resolved element, the describing AuthorityID element, and
the described AuthorityID element all end out being the same. Of course, the
AuthorityID value could be different than the Resolved value. For example,
this alternative uses a UUID for the AuthorityID:

<XRIDescriptors xmlns="xri://$res*schema/XRIDescriptor*($v%2F2.0)">
    <XRIDescriptor xrid:id="first">
        <Resolved>(http://example.org)</Resolved>
		<AuthorityID>
urn:uuid:c9f812f3-6544-4e3c-874e-d3ae79f4ef7b</AuthorityID>
        <Expires>2005-09-30T00:00:00Z</Expires>
        <Authority>
            <AuthorityID>
urn:uuid:c9f812f3-6544-4e3c-874e-d3ae79f4ef7b</AuthorityID>
            <Type>xri://$res*auth.res/XRIA</Type>  
            <URI>http://example.org/resolve</URI>
            <URI>https://example.org/resolve</URI>
        </Authority>
        <TrustMechanism>xri://$res*trusted/None</TrustMechanism>
    </XRIDescriptor>
</XRIDescriptors>

But it still ends out that the AuthorityID of the describing Authority and
the described Authority are the same because it's a self description. Sort
of like saying, "Bob says his name is Bob."

I believe this is all consistent, but I just wanted to check with Gabe to be
sure this is the way he forsaw root XRIDs working. And with Chetan to make
sure this is what he forsaw with root XRIDs in trusted resolution.

=Drummond 





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]