Qworum Digital Rights Management (DRM) specification, version 1.0

Table of contents
  1. Introduction
    1. Purpose
    2. Requirements
  2. Concept
    1. Service ownership
    2. Restricting access to pay services
    3. User agent implementation
  3. Protocol
    1. Authorizing calls
      1. When caller is an internet website
      2. When caller is an intranet website
      3. When caller is an RPC client
    2. Traffic regulation
      1. Server-initiated
      2. Client-initiated
  4. Implementations
  5. Appendices
    1. References
    2. Revision history
    3. Copyright and disclaimer

1. Introduction

1.1. Purpose

Providers of internet Qworum services need to purchase a Qworum Service Provider license for the domain on which the service is hosted. The present specification describes how user agents check whether a service call is permitted.

1.2. Requirements

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 RFC 2119 [Keywords].

2. Concept

2.1. Restricting access to services

If a call to an internet Qworum service isn't authorized, then user agents MUST raise an authorization fault instead of performing the call.

The DRM system controls access to services on the internet

User agents can check call authorizations through the Digital Rights Management (DRM) service located at http://user-agent.qworum.com/mediator/drm.

2.2. User agent implementation

User agents MUST maintain an internal cache where authorization information received from the DRM service is stored. The cache MUST have at least 100 entries, where each entry can contain the subcription information for a service and its caller (internet website, intranet or RPC client). When the cache is full, entries MUST be emptied on a LRU (least recently used) basis in order to make place for received information.

The user agent uses the local DRM cache for taking authorization decisions

When the user agent receives a Qworum message, it proceeds as follows:

  1. For each call or goto statement contained in the message, it checks whether the cache information is enough to take an authorization decision for the call or redirection. The user agent then MUST query the DRM service in order to add the missing information to the cache, as needed.
  2. It starts evaluating the message. It does not need to wait for the reception of the DRM service response, which helps the responsiveness of the user agent. The user agent queries the DRM cache when evaluating a call or goto statement. If the cache cannot satisfactorily answer the query, then the user agent MUST take an authorization decision that does not prevent legitimate calls.

3. Protocol

The user agent sends a POST request to the DRM service and receives a response with the status code 200. The content type of both the request body and the response body is application/xml [XML].

3.1. Authorizating calls

3.1.1. When caller is an internet website

In order to check whether an internet website is authorized to call a set of services, the user agent might send a message such as the following to the DRM service:

<message>
  <head>
    <!--
    The user-agent element identifies the Qworum implementation,  
    which may be a web browser, a web browser add-on, an RPC client, etc. 
    -->
    <user-agent>internet.explorer@qworum.com</user-agent>
    <probability>1.0</probability>
  </head>
  <body>
    <website domain='www.service-consumer.com'> <!-- Contains one or more service elements. -->
      <service url="http://www.service-provider.com/service" />
      <service url="http://www.service-provider2.com/service" />
    </website>
  </body>
</message>

The user agent might then receive the following response message:

<message>
  <head>
    <probability>1.0</probability>
    <!-- The user agent's current IP address, as seen by the DRM service. -->
    <address>208.77.188.164</address>
  </head>
  <body>
    <website domain='www.service-consumer.com'>
      <service url="http://www.service-provider.com/service">
        <!-- 
        The website is currently authorized to use this service; 
        the authorization expires after 2015.11.22 local time. 
        -->
        <subscription>2015.11.22</subscription> 
      </service>
      <service url="http://www.service-provider2.com/service">
        <!-- The website is currently not authorized to use this service.  -->
        <subscription>none</subscription>
      </service>
    </website>
  </body>
</message>

3.1.2. When caller is an intranet website

In order to check whether a web application hosted inside a private network is authorized to call a Qworum service hosted on the internet, the user agent might send a message such as the following to the DRM service:

<message>
  <head>
    <user-agent>firefox@qworum.com</user-agent>
    <probability>1.0</probability>
  </head>
  <body>
    <intranet> <!-- Contains one or more service elements. -->
      <service url="http://www.service-provider.com/service" />
      <service url="http://www.service-provider2.com/service" />
    </intranet>
  </body>
</message>

The DRM service then searches its database for the intranet (as represented by its IP address block) where the user agent is currently located. If it is found, then the user agent might receive a response message such as the following (notice the cidr attribute which contains the intranet's IP address block in [CIDR] notation):

<message>
  <head>
    <probability>1.0</probability>
    <!-- The user agent's current IP address, as seen by the DRM service. -->
    <address>208.77.188.164</address>
  </head>
  <body>
    <intranet cidr='208.77.188.166/29'>
      <service url="http://www.service-provider.com/service">
        <!-- 
        The intranet is currently authorized to use this service; 
        the authorization expires after 2015.11.22 local time. 
        -->
        <subscription>2015.11.22</subscription> 
      </service>
      <service url="http://www.service-provider2.com/service">
        <!-- The intranet is currently not authorized to use this service.  -->
        <subscription>none</subscription>
      </service>
    </intranet>
  </body>
</message>

If the intranet is not in the database, then the user agent might receive a response message such as the following:

<message>
  <head>
    <probability>1.0</probability>
    <address>208.77.188.164</address>
  </head>
  <body>
    <!-- 
    The DRM service assumes that the private network has a single 
    internet IP address assigned to it. 
    -->
    <intranet cidr='208.77.188.164/32'> 
      <service url="http://www.service-provider.com/service">
        <!-- The intranet is currently not authorized to use this service.  -->
        <subscription>none</subscription>
      </service>
      <service url="http://www.service-provider2.com/service">
       <!-- The intranet is currently not authorized to use this service.  -->
         <subscription>none</subscription>
      </service>
    </intranet>
  </body>
</message>

3.1.3. When caller is an RPC client

In order to check whether an RPC (Remote Procedure Call) client is authorized to call directly a given set of services, the user agent might send a message such as the following to the DRM service:

<message>
  <head>
    <user-agent>java@qworum.com</user-agent>
    <probability>1.0</probability>
  </head>
  <body>
    <!-- The user attribute contains the subscriber's Qworum account user name.  -->
    <client user='john.smith@mail.com'> 
      <service url="http://www.service-provider.com/service" />
      <service url="http://www.service-provider2.com/service" />
    </client>
  </body>
</message>

The user agent might then receive the following response message:

<message>
  <head>
    <probability>1.0</probability>
    <!-- The user agent's current IP address, as seen by the DRM service. -->
    <address>208.77.188.164</address>
  </head>
  <body>
    <client user='john.smith@mail.com'>
      <service url="http://www.service-provider.com/service">
        <!-- 
        The RPC client is currently authorized to use this service; 
        the authorization expires after 2015.11.22 local time. 
        -->
        <subscription>2015.11.22</subscription> 
      </service>
      <service url="http://www.service-provider2.com/service">
        <!-- The RPC client is not currently authorized to use this service.  -->
        <subscription>none</subscription>
      </service>
    </client>
  </body>
</message>

3.2. Traffic regulation

In order to prevent the DRM service from receiving more requests than it can handle, Qworum makes use of several traffic regulation mechanisms.

3.2.1. Server-initiated

The DRM service throttles the traffic it receives by assigning a ping probability (a number between 0.0 and 1.0) to each user agent. Before sending a request to the DRM service, the user agent MUST generate a random number which is uniformly distributed between 0.0 and 1.0; it MUST NOT send the request if the generated number is greater than the ping probability.

The ping probability of user agents is 1.0 by default. The user agent MUST send its current ping probability in each request to the DRM service, and the DRM service MUST return the new value for this number.

For example, the user agent might send the following request message:

<message>
  <head>
    <user-agent>firefox@qworum.com</user-agent>
    <probability>1.0</probability> <!-- No throttling. -->
  </head>
  <body>
    <website domain='www.service-consumer.com'>
      <service url="http://www.service-provider.com/service" />
    </website>
  </body>
</message>

and the DRM service might return the following response message:

<message>
  <head>
    <!-- The DRM service has decided to throttle its traffic. -->
    <probability>0.85</probability> 
  </head>
  <body>
    <website domain='www.service-consumer.com'>
      <service url="http://www.service-provider.com/service">
        <subscription>2015.11.22</subscription>
      </service>
    </website>
  </body>
</message>

3.2.2. Client-initiated

The user agent MAY unilaterally decide to throttle the traffic it sends to the DRM service, based on service availability and service latency (i.e. the delay between sending a request and receiving a response).

For example, if the DRM service did not return a response to a request, then the user agent might presume that the service is overwhelmed by its current traffic, and it MAY choose to stop communicating with the service for a certain period of time (reasonably, a couple of days).

The user agent MAY also measure the service latency and decide to decrease its ping probability if the latency is deemed unacceptably long. The DRM service helps user agents measure latency by allowing them to include an OPTIONAL timestamp in requests, and returning the timestamp unchanged. The format of the timestamp text is entirely left to the user agent. For example, the DRM service might receive the following request message:

<message>
  <head>
    <user-agent>firefox@qworum.com</user-agent>
    <time>1231528489.86867</time>
    <probability>1.0</probability>
  </head>
  <body>
    <website domain='www.service-consumer.com'>
      <service url="http://www.service-provider.com/service" />
    </website>
  </body>
</message>

and it might return the following response message:

<message>
  <head>
    <time>1231528489.86867</time> <!-- Returned unchanged.  -->
    <probability>1.0</probability>
  </head>
  <body>
    <website domain='www.service-consumer.com'>
      <service url="http://www.service-provider.com/service">
        <subscription>2015.11.22</subscription>
      </service>
    </website>
  </body>
</message>

4. Implementations

User agents which implement the present version of the DRM specification MUST NOT implement any other system wherein the right to call an internet Qworum service can be purchased.

5. Appendices

5.1. References

[XML] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, Fran├žois Yergeau, Extensible Markup Language (XML), W3C Recommendation
[Keywords] Bradner, B., Key words for use in RFCs to Indicate Requirement Levels, RFC 2119
[CIDR] V. Fuller, T. Li, Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan, RFC 4632

5.2. Revision history

2012.01.10 Fixed typo in section 3.1.2.
2011.10.25 Changed the DRM service host to user-agent.qworum.com.
2011.09.12 Added support for RPC clients.
2011.07.22 Section 3.1.2 updated.
2010.11.06 DRM now applies to goto instructions as well as calls.
2010.04.05 First draft.

5.3. Copyright and disclaimer

© Copyright 2010 Doğa Armangil. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and these paragraphs are included on all such copies and derivative works. This document may not be modified in any way, such as by removing the copyright notice or references to Doğa Armangil or other organizations.

Any party may implement software that gives user agents the ability to send requests to the DRM service, without royalty or license fee to Doğa Armangil.

THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN IS PROVIDED "AS IS", AND DOĞA ARMANGIL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. FURTHER, DOĞA ARMANGIL WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THIS DOCUMENT.