XRI Wiki($and/ <==do note remove - switch for preventing MathML interpretation of dollar signs)
Contents
About
This page contains the minutes of the XRI TC face-to-face meeting held Nov. 13-14 in Mountain View, CA (following the Internet Identity Workshop). The conversation was intensive on many topics and did not always follow the planned agenda, however these minutes try to capture the key points and conclusions in the order of the original agenda items.
Attendees
- Drummond Reed
- John Bradley
- Eran Hammer-Lahav (Thursday)
- Tatsuki Sakushima
- Nat Sakimura
- Markus Sabadello
- Mike Mell
- Nika Jones (Thursday)
- Les Chasen (Thursday morning phone)
- Peter Davis (Thursday and Friday phone)
Goals of XRI 3.0
Following are the proposed goals for our third generation of specifications:
Draft a new suite of XRI specifications based on the XRI-as-relative-URI proposal and the XRD proposal from Eran.
- Make these specifications as simple, short, and complete as possible.
- Produce a white paper explaining the XRI problem space, the evolutionary steps from the W3C TAG discussions, the XRI 3.0 suite of specifications, and example usage scenarios.
- Hold a public review as soon as possible after the materials above are complete.
- Make any necessary revisions and take to an OASIS Standard vote.
Deliverables and Editing Teams
Following are the results of a long discussion about the best way to package the XRI 3G specs and deliverables, and who volunteered to be an editor or contributor to each.
#1: XRD 1.0 (OASIS Standard Track)
This will be the new discovery format/protocol spec. It would be a single spec voted on independently as an OASIS Standard.
Editors:
- Eran
- Nat
Contributors:
- John
- Drummond
- Nika
- Peter
- Nick
#2: XRI 3.0 (OASIS Standard Track)
This is a multi-part specification that would encompass what was formerly XRI Syntax and XRI Resolution. All the parts will be considered one specification for purposes of an OASIS Standard vote.
Part 1: Syntax
This document will cover XRI 3.0 syntax. Major sections will include:
- Intro
- ABNF
- Forms and Transformations
- Binding Requirements
- Security Considerations
Editors:
- Drummond
- John
Contributors:
- Nika
- Nat
- Mike
- Markus
Part 2: Resolution
This will be shorter than XRI Resolution 2.0 because it will be a profile of XRD 1.0. It will define the "abstract resolution" requirements for all resolution bindings.
Editors:
- John
- Drummond
Contributors:
- Nat
- Mike
- Markus
- Nika
- Peter
Part 3: http: and https: Binding
This spec will cover both the ABNF for the syntax binding and the restful API for the resolution binding.
Editors:
- Drummond
- John
Part 4: info: Binding
This spec will cover the ABNF for the syntax binding. It will not define a separate resolution binding but will refer to the http/https resolution binding.
Editors:
- Drummond
- John
#3: XRI White Paper (Informative)
This is the white paper that will accompany the XRI 3.0 suite.
Editors:
- Nika
- Drummond
- Tatsuki
#4: XRI Implementer's Guide (Informative)
This is a new document designed specifically to aid developers in understanding and deploying XRI infrastructure and applications.
Editors:
- Markus
- Mike
XRD 1.0
Eran led a review of the major points of the XRD proposal that he had covered in a 3.5 hour IIW session on Tuesday. Because XRI TC members are generally more steeped in many of the issues that others who attended the IIW sessions, this meant we dove almost immediately into the remaining questions and issues about the XRD proposal. Following are the major points of the discussion.
- XRD should be a standalone spec that will specify both the discovery "workflow" (protocol) and the XRD schema and service selection.
- Due to the new approach, it will work equally with URIs and XRIs. XRI 3.0 resolution will be a profile of this spec.
Discovery Workflow/Protocol
We covered some of the more advanced points Eran made in his HTTP and Discovery blog post.
The overall solution Eran is recommending is a combination of Link headers and dynamic mapping using the draft site-meta proposal.
- The key addition to the site-meta proposal is a simple template format for defining the transformation of the source URI to the target URI for the associated XRD file.
- With regard to security and trusted discovery, the consensus was that the spec should include this as long it can be simple and short.
XRD Schema
Eran explained the new interpretation that immediate child elements of the XRD element (except Service) describe the resource itself, while the Service element and its children describe linked or related resources. The rest of the TC members agreed with this analysis.
One result is that the Service/Type element really describes the relationship of the described resource to the linked resource, and not the type of the linked resource directly.
- Another result is that a second round trip may be necessary to obtain the XRD for the linked resource if further discovery of that resource is necessary.
There was consensus that the spec identified by the URI value of the Service/Type element MUST define whether a second discovery step MUST/SHOULD/MAY be taken (e.g., OAuth), or whether the URI value of the Service/URI element can be assumed (e.g., OpenID Authentication 2.0).
- We did a review of existing XRD elements to determine:
- Which were appropriate for this new XRD spec.
- Which were specific to XRI.
- Which could be dropped altogether.
Only Status, ServerStatus, and Query fell into the "specific to XRI" bucket.
Query may no longer be needed even in XRI resolution.
Redirect can be dropped altogether because it is subsumed by the new interpretation of the URI element as well as the Ref element.
Ref can be generalized for all XRDs, but will be constrained to one hop.
ProviderID should no longer be needed as it will be replaced by either the CanonicalID or URI elements depending on context.
With regard to synonym elements, at the XRD level the proposal is to constrain them to CanonicalID (cardinality zero-or-one) and URI (cardinality zero-or-more). We will investigate whether LocalID or CanonicalEquivID are still needed.
Service/LocalID is still under discussion.
Service/Path should no longer be needed.
Service/MediaType will remain, and MediaType will be added to the XRD level.
Use of the XRDS wrapper element for a sequence of multiple XRDs will be defined at the end of the XRD spec so it can be used by any other spec (e.g., XRI 3.0 Resolution) that needs it.
Service Endpoint Selection
- It will be covered in the spec, but the selection criteria will be very simple.
This means the XriThree/SuperSimpleSepSelection proposal may be able to be contained entirely in this spec.
We ran out of time to discuss the XriThree/SuperSimpleSepSelection proposal in any depth.
XRI 3.0 Part 2: Resolution
This specification can now be much shorter because it will basically describe an abstract resolution protocol as a profile of the XRD spec.
- This profile will then be used by XRI bindings, e.g., the http(s): binding.
- DNS resolution under xri.net should be defined in the http(s): binding.
- We did not have time to discuss simple static transformation for discovery (e.g., append question mark).
Community Root Resolution Proposal
We discussed the original proposal at XriThree/CommunityRootResolution (since revised to reflect this discussion).
Nat suggested that in addition to supporting the $(uri) form of community root identifier that requires either an http: or https: URI, we should also support a $function(string) pattern where $function is a defined resolution function and (string) is the parameter upon which that function acts to produce the community root XRD. See the examples at XriThree/CommunityRootResolution.
Simple Sign Proposal
We reviewed Nat's Simple Sign proposal at XriThree/SimpleSign.
There was a long discussion about the various options, but the configuration shown on the XriThree/SimpleSign wiki page is the consensus of the group attending Friday's meeting (Nat, Tatsuki, Mike, John, Markus, Drummond).
- This needs review by a larger group.
- There was consensus that this should be the method for doing signature-based trusted resolution in XRI 3.0.
- The view of this group is that this proposal is simple enough to be included in XRD 1.0, and that XRI 3.0 Part 2: Resolution will only need to specify this (and HTTPS) as the trusted resolution options for XRI 3.0.
XRI 3.0 Part 1: Syntax
This part of the XRI 3.0 spec will be refactored to reflect the XriAsRelativeUri proposal, and to separate out bindings into other parts. Besides that, the only major proposed change is the GCS Delimiter proposal.
GCS Delimiter Proposal
There was a long discussion on Friday about what was originally titled the "Global Cross-Reference" proposal.
The first conclusion is that "global cross-reference" was not the best term, since this is really more about the rules for XRI composition. We retitled the issue GCS Delimiter and subsequently posted a new writeup at XriThree/GcsDelimiter.
- There was consensus that the key issue is that XRI 2.0 syntax has a restriction on the use of global context symbols (GCS) that prevents composite XRIs from being composed directly from a an ordered set of component XRIs.
This is a major problem for XDI 1.0, as explained in the XriThree/GcsDelimiter writeup.
- It is also a problem in XRI resolution today, since the path portion of a QXRI cannot contain a GCS character without being in parens.
- It will also be a problem for any other future use of XRI syntax that wants to treat the path "transparently".
The conclusion was that removing this syntactic restriction and specifying that GCS characters are treated as subsegment delimiters just like * and ! solves all of these problems.
It also produces a cleaner, shorter ABNF with fewer rules as shown at XriThree/SyntaxAbnf.
XRI 3.0 White Paper
We had a high-level discussion about the goals of this white paper:
- To properly position XRI and XRD in the marketplace.
- To explain the history of the W3C TAG interaction.
- To explain the rationale of the XRI-as-relative-URI architecture.
- To provide specific use cases and examples of XRI shared semantics.
- To explain the role of XRD in metadata discovery.
- To provide specific examples of how XRD is used with technologies like OpenID, OAuth, and information cards.
- To explain the relationship of the XRI TC and XRI infrastructure providers.
The audience is:
- OASIS members (specifically voters on the XRI 3.0 specifications)
- Other standards bodies (specifically W3C, IETF, ITU)
- Web architects and developers
- Semantic Web architects and developers
- Enterprise IDM architects
We also discussed being able to use XDI x.0 as an example of how XRIs may be used for shared semantics.