Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Proposed for LC consideration; not yet approved

URI Naming in Technical Specifications

Requirements

Kantara Work Groups that produce Technical Specifications often need to give unique labels to various components in those specifications, such as XML namespace names, or identifiers for fields in XRD descriptive data. Although these labels are intended to be temporary until the specs are eventually completed at a standards development organization (SDO), software implementers often need to code features that use these draft labels in the interim.

Uniform Resource Identifiers (URIs), most often Uniform Resource Locators (URLs) using the http: scheme, are typically used for such labels. In some cases, it's desirable to allow machine-readable metadata, such as a schema, to be retrieved from the URL.

Kantara Work Groups have control of URLs that reside in the wiki area assigned to them (for example, http://kantarainitiative.org/confluence/display/uma/... for the UMA Work Group), but using such URLs has two downsides:

  • Wiki areas are managed by the Confluence software in a proprietary fashion, and it's difficult to place "unencumbered" metadata at such locations.
  • The URLs are longer than strictly necessary, making code examples difficult to read.

Following is an example from the UMA 1.0 Core Protocol illustrating the need for labels in its XRD formats (using entirely made-up URLs):

<!-- Applies to both hosts and requesters -->

<Property
  type="http://kantarainitiative.org/ns/uma/1.0/token_formats">artifact
</Property>
<Property
  type="http://kantarainitiative.org/ns/uma/1.0/claim_formats">claims2
</Property>

<!-- Host protection API -->

<!-- AM as authorization server to host-as-client -->
<Link
  rel="http://kantarainitiative.org/ns/uma/1.0/host_token_uri"
  href="https://am.example.com/host/token_uri">
</Link>
<Link
  rel="http://kantarainitiative.org/ns/uma/1.0/host_user_uri"
  href="https://am.example.com/host/user_uri">
</Link>
...

LC Guideline Proposal

Kantara should make available the following area on its site that Work Groups can use for URL-based labels and, optionally, web resources that correspond to these labels: http://docs.kantarainitiative.org/.

Each Work Group should, by request to Kantara staff, be given the opportunity to control URLs and content in an area named with the same affix given to their Confluence wiki area (or a modified affix by mutual arrangement). For example, the UMA Work Group could request http://docs.kantarainitiative.org/umawg/ or http://docs.kantarainitiative.org/uma/.

Within such an area, the Work Group would have the opportunity to manage the namespace as it sees fit, for example, including version or date numbers or spec module names as URL path components.

Technical Specifications that make use of such URLs must make clear that they are to be considered temporary until such time as the specification is finalized in an SDO.

Work Groups could choose to use some other system of labeling, such as URNs, or URLs in a non-Kantara-related domain (with permission of the domain owner), but if they want to use the kantarainitiative.org domain, it must be as prescribed in this policy.

References

For somewhat similar policies, see:

  • No labels