I-Tag Specification Working Draft 03

From ITags

Working Draft 03, 30 April 2006

Document identifier: i-tag-working-draft-03
Location: http://itags.net

Editors:
Drummond Reed, Cordance, http://xri.net/=drummond.reed
Mary Hodder, Dabble.com, http://xri.net/=mary.hodder
Andy Dale, ooTao, http://xri.net/=andy.dale
Kaliya Hamlin, PlaNetwork, http://xri.net/=kaliya

Contributors:
Gabe Wachob, http://xri.net/=gabew

Abstract
This document specifies a format for a new type of structured tag called an i-tag (identity tag). I-tags, like standard tags, are identifiers used to describe and categorize blog posts, images, songs, videos, or other digital objects. However, i-tags use a simple structured format that uses URIs, IRIs, or XRIs to make simple RDF statements. So i-tags can be extended, can be persistent, can be verified, and can be separated from the digital object they describe without losing any information or verifiability.

Status
This is a working draft document that is expected to continue to evolve. It is produced is produced by volunteer contributors to the i-tags project at http://www.itags.net.

Review and contributions are welcome from anyone interested in the project.

Comments should be posted to an appropriate page of the i-tag wiki at http://www.itags.net or may be submitted to the editors via their contact pages listed above. A dedicated mailing list is also planned; watch the i-tags wiki for details.

IPR
This is an open, public, royalty-free specification. To the best of the knowledge of the editors and contributors, use or implementation of this specification does not infringe on any intellectual property rights.

Table of Contents

Contents 1 Introduction 1.1 Purpose 1.2 Scope 1.3 Terminology and Notation 1.4 Keywords 2 Design Specifications 3 I-Tag Model and Formats 3.1 Microformat Definition 3.2 Example 4 Identifier Formats 5 Verification 5.1 I-Tag Verification 5.2 Publisher Verification 5.3 Author Verification 5.3.1 Direct Authentication 5.3.2 Third-Party Verification 5.4 Scope of Proof

Introduction

Purpose

The purpose of the i-tag specification is to define an open, interoperable tagging format that meets the following requirements:

• Tag independence: enable a tag to be used and verified even if it is independent from the digital object it describes.

• Verifiability: enable authorship of the tag to be verified in order to prevent tag spoofing and tag spamming.

• Resolvability: enable tag authors to control resolution of the tag via any tag dictionary, including the author’s own dictionary(s) (e.g., blog, website, or dictionary server); other author’s tag dictionary(s); a shared community or global tag dictionary such as Wikipedia or XDI.org.

• Dictionary services: enable tag dictionaries (individual, community, or global) to provide services for helping both tag authors and tag searchers identify the intended meaning of a tag and find potential synonyms, both in the original language and optionally in other languages.

• URI, IRI, and XRI support: enable tag authors, publications, and tags themselves to be uniquely identified by either URIs (e.g., HTTP URIs, often called URLs), IRIs (internationalized URIs) or XRIs (often called i-names and i-numbers).

• Extensibility: enable tags to be extended to describe any property of a digital object, i.e., not just the topic(s) to which it relates, but also other types of relationships, such as licensing terms, ratings, etc.

• Compatability: enable tags to be backwards compatabile with existing tagging technology and specifications such as Rel-Tag, Rel-License, and Structured Blogging.

Scope

This specification covers the overall format of i-tags and i-tag verifiability. It also specifies some very limited initial i-tag dictionaries.

Since i-tags may be extended to any type of statement or assertion about a digital object, including ratings, reputations, distribution channels, and so on, each of these uses will generally require a specified static or dynamic dictionary. These will be left to future specifications. See the Future Work section.

Terminology and Notation

This specification uses the XRI glossary as specified in Appendix C of XRI Syntax 2.0.

Keywords

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY” and “OPTIONAL” in this document are to be interpreted as described in RFC2119. When these words are not capitalized in this document, they are meant in their natural language sense.

Design Specifications

Editor’s Note: Use cases, wireframes, and other design specifications will be forthcoming in a subsequent Working Draft.

I-Tag Model and Formats

The underlying model of i-tags is based on the subject-predicate-object metadata model employed by RDF (Resource Description Framework). This logical model is independent of any particular serialization format, i.e., a specific XHTML or XML rendering. However the binding of the logical model to specific format definitions also must be specified interoperability.

The first format definition below is based on the microformat design patterns from microformats.org. However we expect a subsequent Working Draft to also specify i-tags in the microcontent format specified by structuredblogging.org.

We invite anyone associated with the microcontent format to post here or contact the authors about publishing i-tags in microcontent format.

In addition Marco Barulli suggests in his blog entry iTags and RSS feeds how i-tags may be adapted directly to RSS. We invite more feedback and specific suggestions as to how to best accomplish this.

Microformat Definition

An i-tag in microformat XHTML MUST conform to the following definition:

<div class="i-tag">
  <!-- i-tag header metadata describing the i-tag itself -->
  <div>
    <a class="id" href="[identifier]">[contents]</a>
    <a class="subject" href="[identifier]">[contents]</a>
    <a class="author" href="[identifier]">[contents]</a>
    <a class="publisher" href="[identifier]">[contents]</a>
    <a class="verifier" href="[identifier]">[contents]</a>
    <a class="date" href="[identifier]">[contents]</a>
  </div>
  <!-- i-tag body metadata describing the subject identified above-->
  <div>
    <a class="predicate" href="[identifier]">[contents]</a>
    <div>
      <a class="object" rel="[rel]" href="[identifier]">[contents]</a>
    </div>
  </div>
</div>

In this format:

• All terms in [brackets] are variables.
• All terms in "quotes" without brackets are literal XHTML attribute values.
• All other text is XHTML markup.

The following rules apply to this format:

1. An i-tag MUST include exactly one link of class id. Its [identifier] value MUST be a globally unique identifier (see Identifier Formats below) that identifies the i-tag itself (NOT the digital object being described, which is the value of the subject link discussed below). This link is REQUIRED in order for an i-tag to be verified.
2. An i-tag MAY include one or more links of class subject. If present, its [identifier] value MUST identify the subject of the RDF statement asserted by the i-tag, i.e., the digital object (blog post, web page, photo, song, video, etc.) being tagged. This link is OPTIONAL if the i-tag is "inline" (i.e., included within the digital object it describes) but REQUIRED if the i-tag is or will be processed independently from the digital object it describes. It is RECOMMENDED to always include this link.
3. An i-tag MUST include one or more links of class author. Its [identifier] value identifies the author of the i-tag (NOT the author of the digital object being described EXCEPT in the case of self-tags – see the Verification section below). This link is REQUIRED in order for an i-tag to be verified.
4. An i-tag MUST include one or more links of class publisher. Its [identifier] value identifies the digital publication where the i-tag is published (NOT the network location of the digital object being described). This link is REQUIRED in order for an i-tag to be verified. See also the additional requirements of a publisher identifier in the Verification section below.
5. An i-tag MAY include zero or more links of class verifier. Its [identifier] value identifies a third party verification authority for the i-tag. This link is OPTIONAL for manual i-tag verification but REQUIRED for automated i-tag verification. See the Verification section below.
6. An i-tag MAY include exactly one link of class date. Its [identifier] value MUST be an XRI identifying the datetime instant the i-tag was published (NOT the datetime the digital object being described was published). It is RECOMMENDED to always include this link.
7. An i-tag MAY include zero or more links of class predicate. Its [identifier] value identifies the predicate of the RDF statement asserted by the i-tag, i.e., the type of tag being applied (a topic tag, license tag, ratings tag, etc.) Note that the only time an i-tag might not include a link of class predicate is a self-tag used to assert authorship. See Verification.
8. For each link of class predicate, an i-tag MUST include exactly one "div" child element containing one or more links of class object. In each of these links, the [identifier] value identifies the object of the RDF statement asserted by the containing predicate, i.e., the topic identifier, license identifier, rating value, etc. Also, the [rel] value is reserved for use by links that conform to other tag specifications that define this value, e.g., Rel-Tag and Rel-License.

For all link classes in an i-tag:

1. The [identifier] value MUST be a valid absolute URI, IRI, or XRI. See below.
2. If more than one link of the same class type is included in the same division, all [identifiers] MUST be interpreted as synonymous identifiers, i.e., identifiers that all identify the same resource.
3. The [content] value is the human-readable display label for the link.

Example

This example shows an i-tag that asserts two rel-tags and one rel-license for a Napsterization blog post by Mary Hodder.

<div class="i-tag">
  <!-- i-tag header metadata describing the i-tag itself -->
  <div>
    <a class="id" href="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6">I-Tag</a>
    <a class="subject" href="http://napsterization.org/stories/archives/000597.html">Title: Creative Commons Upheld!</a>
    <a class="author" href="http://xri.net/=mary.hodder">Author: Mary Hodder</a>
    <a class="publisher" href="http://www.napsterization.org/">Napsterization</a>
    <a class="verifier" href="https://verify.opinity.com/">I-Tag Verifier: Opinity</a>
    <a class="date" href="http://xri.net/($d*2006-01-12T12:13:14Z)">Tag Date: 2006/03/22 08:19</a>
  </div>
  <!-- i-tag body metadata describing the subject identified above-->
  <div>
    <a class="predicate" href="http://microformats.org/wiki/rel-tag">Tags</a>
    <div>
      <a class="object" rel="tag" href="http://xri.net/+law/law">Law</a>
      <a class="object" rel="tag" href="http://napsterization.org/stories/Creative%20Commons">Creative Commons</a>
    </div>
  </div>
  <div>
    <a class="predicate" href="http://microformats.org/wiki/rel-license">Licenses</a>
    <div>
      <a class="object" rel="license" href="http://creativecommons.org/licenses/by/2.5/">Creative Commons Attribution 2.0</a>
    </div>
  </div>
</div>

Identifier Formats

For maximum interoperability, the value of any [identifier] specified above may be a valid instance of any of the following open standard Web identifier formats:

1. A URI as specified in RFC 3986.
2. An IRI as specified in RFC 3987.
3. An XRI as specified in XRI Syntax 2.0.
4. An HTTP XRI (HXRI) as specified in XRI Resolution 2.0.

Note that some specific additional features are supported with the XRI (Extensible Resource Identifier) and HXRI formats for abstract structured identifiers defined by the OASIS XRI Technical Committee, however use of this format for any identifier is optional.

Note that in order for click-through behavior of an i-tag to be predictable, it is RECOMMENDED to always represent an XRI in HXRI format unless it is known that the i-tag will only be consumed in a context that supports native XRI resolution.

Verification

Verification is the process of a relying party (a general term for anyone who needs to verify the authenticity of an online assertion) obtaining assurance that the i-tag was in fact published by the author identified in the i-tag. It is the online equivalent of calling up the author on the telephone and asking, "Did you really say this about that?" This is necessary not just to prevent tag spoofing and tag spamming, but to enable the development of reliable author reputation services.

From a computational standpoint, verification is a matter of proving the following three RDF statements:

1. Real-world author (subject) is authoritiative for (predicate) author-identifier (object).
2. Author-identifier (subject) is authoritiative for (predicate) publisher-identifier (object).
3. Publisher-identifier (subject) is authoritiative for (predicate) i-tag-identifier (object).

The following sections will cover these in reverse order.

I-Tag Verification

Verification that a publisher is authoritative for an i-tag is very straightforward: the relying party simply needs to request a copy of the i-tag from the publisher asserted in the i-tag. To support this, publishers and publications (e.g., blogs, websites, aggregators) offering i-tag verification MUST respond to an HTTP(S) GET request composed according to the following algorithm:

[publisher-identifier]/(+i-tag)/([i-tag-identifier])

In this algorithm:

• [publisher-identifer] is the value of the identifier specified in the i-tag link of class publisher. In order to support verification, this identifier MUST be either an HTTP or HTTPS URI or an XRI that can be dereferenced to an HTTP or HTTPS URI.
• [i-tag-identifer] is the value of the identifier specified in the i-tag link of class id.

The response MUST be an XHTML document whose BODY element consists of only the i-tag. Any other response MUST be interpreted as failure. Note that to prevent partial spoofing (replacing just the body portion of an i-tag), the entire i-tag returned as a result of such a verification request MUST be considered the authoritative i-tag.

For example, to verify the example i-tag given above, a verifying party would perform a GET on:

http://www.napsterization.org/(+i-tag)/(urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6)

Verification is successful if the response is an XHTML document containing the example i-tag above.

Publisher Verification

The second step after verifying that a publication is authoritative for an i-tag is to verify that the author asserted in the i-tag is authoritative for the publication. For example, to verify the example i-tag above, a relying party would need to verify that "http://xri.net/=mary.hodder" is in fact the author of "http://www.napsterization.org/". This prevents spoofing of an i-tag, e.g., a blogger posting an i-tag in their own blog (such a positive review) purporting to be from another blogger.

The process of verifying authorship of a digital publication (often called "blog claiming" in the blogosphere) currently uses a variety of proprietary methods. I-tags enable this process to be standardized, whether for a blog or any other type of Web-accessible publication.

The first step in the process is to publish a special form of an i-tag called a "self-tag". A self-tag is simply an i-tag that describes the entire publication in which it appears, including its author(s). The following rules apply to self-tags:

1. A self-tag MUST include exactly one instance of a link of class id, exactly one instance of a link of class subject, and exactly one instance of a link of class publisher. The value of the [identifier] for all three of these links MUST be identical. The means the i-tag describes the publication it in which it appears.
2. A self-tag MUST include one or more links of class author. If the publication has multiple authors (such as a community blog), there MUST be one link in the self-tag for each author whose i-tags can be verified via this publication.

Note that self-tag MAY contain a body section with makes additional assertions about the publication as a whole (such as its date of origin, or overall licensing terms). However those assertions follow the same rules as i-tags in general and are not otherwise relevant to publisher verification.

Following is an example of a self-tag that Mary could apply to her Napsterization blog:

<div class="i-tag">
  <div>
    <a class="id" href="http://www.napsterization.org/">Self-Tag</a>
    <a class="subject" href="http://www.napsterization.org/">Title: Napsterization</a>
    <a class="author" href="http://xri.net/=mary.hodder">Author: Mary Hodder</a>
    <a class="publisher" href="http://www.napsterization.org/">Publisher: Napsterization</a>
    <a class="verifier" href="https://verify.opinity.com/">Verifier: Opinity</a>
    <a class="date" href="http://xri.net/($d*2006-03-22T12:13:14Z)">Self-Tag Date: 2006/03/22 12:13</a>
  </div>
</div>

Verification of this self-tag is exactly the same as any other i-tag, i.e., a relying party would do a GET on:

http://www.napsterization.org/(+i-tag)/(http://www.napsterization.org)

If the response to this GET is the self-tag for Mary's Napsterization blog given above, the relying party has the proof that a publisher asserts it is authoritative for an author. However the relying party does NOT yet have proof that the author asserts she is authoritative for the publication. This requires the final step of author verification.

Author Verification

To prevent spoofing, a relying party ultimately needs proof that a real-world author is authoritative for a publication. For example, an attacker could try to impersonate Mary Hodder by creating a fake blog and publishing the self-tag described above. However if a relying party requires the attacker to authenticate the identifier "http://xri.net/=mary.hodder" before the relying party will accept i-tags from "http://www.napsterization.org/" using that author identifier, the attack will not succeed.

There are two options for author verification: direct authentication and third-party verification.

Direct Authentication

The advantage of direct authentication is that it does not involve reliance on a third-party verification authority. The disadvantage is that it requires the relying party to have a direct relationship with the author so it can perform real-time authentication of the author identifier.

To do this, the relying party MAY use any authentication protocol supported by both the author and the relying party. To facilitate this process, authors SHOULD obtain an identifier that supports the open standard Yadis identity service discovery protocol, such as an OpenID or LID URL or an XRI i-name. In addition authors or their i-brokers SHOULD publish the authentication protocols they support in their Yadis XRDS document. For i-tag verification, at least one and preferably both of the following authentication protocols SHOULD be supported:

• The OpenID protocol currently published by SixApart.
• The SAML 2.0 SSO profile published by XDI.org on the XDI.org I-Services wiki based on the SAML standard from OASIS.

If the relying party is able to successfully authenticate the author identifier AND the author verifies his/her self-tagged publications, verification is complete. (See also the Scope of Proof section below.)

Third-Party Verification

The second option for author verification is a third-party verification authority. The advantages of this method are:

• The relying party does not need a direct relationship with the i-tag author.
• Verification can be done automatically.

Third party verification is very easy because it is simply a matter of the verification authority publishing the self-tag instead of the publisher. This use of a self-tag is called a verification tag. To provide third party verification service, the verifying authority MUST perform the following steps:

1. Verify the author's self-tag for each publication to be verified as described above.
2. Authenticate the author's identifier(s) asserted in a self-tag as described above.

Once these steps are performed, the verification authority MAY offer i-tag verification service for any self-tag published by this author. To do this, the verification authority MUST:

1. Instruct the author to add a link of class verifier to each of the author's self-tag(s) for which the author desires third-party verification service. This is called the verification link.
2. Provide the author with an HTTPS URI for the verifier to use as the [identifier] for the verification link.
3. Publish each verification tag at this HTTPS address.

To verify a self-tag, a relying party simply needs to request a copy of the verification tag following the same verification formula as any other i-tag, i.e.:

[verifier-identifier]/(+i-tag)/([verification-i-tag-identifier])

For example, to verify Mary's example self-tag above, a relying party would do a HTTPS GET on:

https://verifier.opinity.com/(+i-tag)/(http://www.napsterization.org)

If the response to this GET is a verification tag identical to Mary's self-tag for her Napsterization blog given above, the relying party has proof that the verification authority has authenticated this author and verified that the author is authoritative for the identified publication(s).

Scope of Proof

Once a relying party has successfully verified an i-tag, the relying party MAY trust i-tags using that same author identifier and publisher identifier. Note that this trust does NOT extend to:

• Different author identifiers from the same publisher identifier. A relying party MUST independently authenticate each author in the context of each publisher.
• The same author identifier from different publisher identifiers. Again, a relying party MUST independently verify that each publisher is authorized by the author.

In addition, due to the fact that many identifiers are reassignable, a relying party SHOULD limit the period of time for which verification is assumed to be valid. For example, for direct authentication, relying parties SHOULD require reauthentication at least annually. For third party verification, relying parties SHOULD reconfirm verification at least every six months.