Qworum Domain Rights Management (DRM) specification, version 1.0 Draft
1. Introduction
1.1. Purpose
Providers of internet Qworum services can monetize their services by requiring a subscription fee from service consumers. The present specification describes how user agents act as gatekeepers for pay services, ensuring that they are only accessible to paying consumers.
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. Service ownership
The following rules determine the ownership of services, call phases and RPC clients:
- The owner of a Qworum service is the owner of its first phase.
- A call phase hosted on an intranet website is owned by that intranet, as identified by its Intranet Assigned Domain Name.
- A call phase hosted on an internet website is owned by that website, as identified by its domain name (note that site.com and www.site.com represent different websites).
- An RPC client located on an intranet host is owned by that intranet, as identified by its Intranet Assigned Domain Name.
- An RPC client located on an internet host is owned by that host, as identified by a domain name that points to it.
An Intranet Assigned Domain Name is a domain name (example: mycompany.com) that is chosen to identify an intranet. There is no formal process for assigning a domain name to an intranet, and the same domain name can represent more than one intranet.
User agents MUST perform a call if both the caller (a call phase or the user agent itself, if it is an RPC client making a direct call) and the callee (a Qworum service) have the same owner.
The Domain Rights Management system comes into play when the rules above cannot determine the legitimacy of a call.
2.2. Restricting access to pay services
The right to call a Qworum service hosted on an internet website MAY require payment. In this case, the caller's owner MUST be subscribed to the service beforehand on http://www.qworum.com/.
Based on the subscription information that is available on the DRM service, user agents decide whether a call to an internet Qworum service is legitimate. If it isn't, then user agents raise an authorization fault instead of performing the call. If the caller's owner is undetermined (i.e. if the user agent is an unconfigured RPC client trying to make a direct call), then an authorization fault is raised as well.
The DRM system controls access to pay services on the internet
2.3. 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 domain name, service URL pair. 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:
- For each call statement contained in the message, it checks whether the cache information is enough to take an authorization decision for the call. The user agent then MUST query the DRM service in order to add the missing information to the cache, as needed.
- 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 statement. If the cache cannot satisfactorily answer the query, then the user agent MUST take an authorization decision that does not prevent legitimate calls. If the call is not authorized, then the user agent MUST raise an authorization fault instead of performing the call.
When an RPC client is to make a direct call to an internet Qworum service, it proceeds as follows:
- It checks whether the cache information is enough to take an authorization decision regarding the call. The user agent then MUST query the DRM service in order to add the missing information to the cache, as needed.
- It queries the DRM cache in order to take an authorization decision. If the cache cannot satisfactorily answer the query, then the user agent MUST take an authorization decision that does not prevent legitimate calls. If the call is not authorized, then the user agent MUST raise an authorization fault instead of performing the call.
3. Protocol
The user agent sends a POST request to the DRM service located at http://www.qworum.com/mediator/drm and receives a response with the status code 200. The content type of both the request body and the response body is application/xml.
3.1. Checking domain rights
In order to check the rights of a domain regarding a set of services, the user agent might send an XML [XML] 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, a software module, etc.
-->
<user-agent>firefox@qworum.com</user-agent>
<probability>1.0</probability>
</head>
<body> <!-- Contains one or more domain elements. -->
<domain name='www.service-consumer.com'> <!-- Contains zero, one or more service elements. -->
<service url="http://www.service-provider.com/service" />
<service url="http://www.service-provider.com/service2" />
<service url="http://www.service-provider2.com/service" />
</domain>
</body>
</message>
The user agent might then receive the following response message:
<message>
<head>
<probability>1.0</probability>
</head>
<body>
<domain name='www.service-consumer.com'>
<service url="http://www.service-provider.com/service">
<!--
The domain is currently authorized to use the service;
the authorization expires after 2009.11.22 local time.
-->
<subscription>2009.11.22</subscription>
</service>
<service url="http://www.service-provider.com/service2">
<!-- The domain is currently not authorized to use the service. -->
<subscription>none</subscription>
</service>
<service url="http://www.service-provider2.com/service">
<subscription>none</subscription>
</service>
<service url="http://www.service-provider.com/service3">
<subscription>2010.01.28</subscription>
</service>
</domain>
</body>
</message>
Note that the response message MAY contain information about services which are not mentioned in the request message.
3.2. Server-initiated traffic reduction
In order to allow the DRM service to throttle the traffic it receives, each user agent has a ping probability (a number between 0.0 and 1.0) associated with it. 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>
<domain name='www.service-consumer.com'>
<service url="http://www.service-provider.com/service" />
</domain>
</body>
</message>
and the DRM service might return the following response message:
<message>
<head>
<probability>0.85</probability> <!-- The DRM service has decided to throttle its traffic. -->
</head>
<body>
<domain name='www.service-consumer.com'>
<service url="http://www.service-provider.com/service">
<subscription>2009.11.22</subscription>
</service>
</domain>
</body>
</message>
3.3. Client-initiated traffic reduction
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>
<domain name='www.service-consumer.com'>
<service url="http://www.service-provider.com/service" />
</domain>
</body>
</message>
and it might return the following response message:
<message>
<head>
<time>1231528489.86867</time>
<probability>1.0</probability>
</head>
<body>
<domain name='www.service-consumer.com'>
<service url="http://www.service-provider.com/service">
<subscription>2009.11.22</subscription>
</service>
</domain>
</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 |
5.2. Revision history
2010.04.05: Initial release.
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.