Child pages
  • Temporary URL Labeling in Technical Specifications
Skip to end of metadata
Go to start of metadata

WGs 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. 

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.

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

a) Wiki areas are proprietarily managed by the Confluence software making it difficult to place "unencumbered" metadata at specific locations; and

b) The URLs are longer than strictly necessary, making code examples difficult to read. 

Following is an example from the UMA 1.0 Core Protocol as of 31 August 2011, illustrating the need for labels in its XRD formats (it had invented these URL strings in the absence of a Kantara Initiative policy):


<!‐‐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>
  • No labels