| Network Working Group | P. Hallam-Baker |
| Internet-Draft | Comodo Group Inc. |
| Expires: November 22, 2014 | May 21, 2014 |
SXS Confirmation Protocol (SXS-Confirm)
draft-hallambaker-sxs-confirm-01
JSON Confirmation Protocol (JCP) is a three party Web Service that supports a transactional second factor confirmation mechanism that provides a superset of the capabilities of traditional second factor authentication schemes.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 22, 2014.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Authentication of end users is one of the biggest challenges for Internet and Web security today. Despite an abundance of technology that offers authentication mechanisms that are more robust, more secure and easier to use, the default mechanism for user authentication is the use of usernames and passwords.
Unlike traditional schemes, JCP is designed for implementation on a device that has at least the capabilities of a modern 'smartphone'. In particular an JCP client device must support a display, a means of accepting text input from the user and a connection to the Internet.
While mobile devices offering this degree of functionality were rare in 2007, they have since become ubiquitous. It is thus now a practical proposition for a site requiring second factor authentication to support at least a part of its users using a technology that requires this level of capability. Indeed software applications that emulate traditional second factor authentication protocols on such devices have been available for some time.
Second factor authentication mechanisms offer greater security over the use of passwords alone by combining a first factor (typically a password) with a biometric or proof of possession of a physical token.
Traditional second factor authentication techniques have suffered from the need to distribute physical tokens and the difficulty of ensuring that a biometric authentication is presented to a trustworthy terminal.
The usability of traditional second factor authentication techniques has been poor or worse. Even the simplest scheme in which the user is required to read in a 'one time use' numeric code from the authentication token device and enter it into a password field. While such operations are relatively simple they require the user to engage in a sequence of operations that bears no necessary or natural relationship to the underlying task for which the authentication is required.
Nor does the act of engaging in a traditional second factor scheme offer proof of anything other than that the user was authenticated. Any correspondence between the act of authentication and the purpose for which the authentication was provided must be maintained separately.
A second factor confirmation service addresses the limitations of traditional second factor authentication schemes.
A confirmation service allows the user experience to be precisely matched to the action that the user is attempted. Instead of beinf asked to read a random number from one device and enter it into another, the user is asked if they really want to perform the action for which authentication is requested.
A confirmation service offers better accountability for end users than a traditional authentication service. An authentication service only provides an assertion that the user was present. A confirmation service provides an assertion that the user was present and that they confirmed a specific transaction.
For example, Alice has been granted access to a machine storing classified data. If an authentication service is used for access control, the authentication service log will only record the dates and times that Alice accessed the system. to find out if Alice accessed a particular file on a particular day it is necessary to consult and correlate both the authentication log of the system and the activity log for the application.
If instead a confirmation service is used the confirmation log contains an authenticated record of both the authentication events and the transactions for which the authentication was requested.
A confirmation service complements rather than replaces a traditional authentication scheme. Providing a highly secure and convenient means of authenticating requests that carry a high degree of risk mitigates the risk of using convenient but intrinsically low security techniques for other actions.
If an attacker is to profit from breaching a an account with a financial service such as a bank or a brokerage they must find a way to move money out of the account. Thus adding bill payment recipients, initiating wire transfers and trading in low volume 'penny stocks' represent high risk activities.
For example: Bank of Ethel might permit customers to use a simple username and password scheme to gain access to their account for the purpose of checking their balance or paying bills to existing reciepients but require use of the second factor confirmation device for a high risk transaction such as paying a bill.
A second factor confirmation service may be combined with a machine level authentication scheme to permit a transparent form of authentication for low risk transactions.
For example: Alice stores her low risk authentication credentials (e.g usernames and passwords) using a 'cloud' service. When she wishes to use those credentials an agent on her personal machine fetches credentials from the cloud service as necessary. When Alice wishes to access a site from a different machine she receives a confirmation request on her mobile device to grant access from that machine.
Use of such a mechanism is clearly more satisfactory when suitable cryptographic protocols such as SAML or Kerberos are employed to limit the disclosure and hence possible compromise of the credentials. The specification of such protocols is outside the scope of this document.
Although JCP is designed for use in a three party scenario, there are situations in which a two party mode may be preferred.
For example: Bob is a roadwarrior who requires access to confidential documents stored on his laptop device from anywhere in the world, including locations where Internet access is not possible. To permit access in such circumstances, Bob's JCP client supports use of a tethered mode in which the mobile device is plugged into his laptop via a USB port.
For example: Carol is a network manager of a large computing facility that uses JCP to authenticate and track all changes to critical resources. Since JCP is itself a network resource a bootstrap consideration arises: How can Carol confirm her network configuration requests using JCP when the network itself is down? Support for a tethered mode in which the JCP device communicates via USB or similar wired protocol allows this use case to be supported.
While availability of a tethered mode is clearly essential if JCP is to be used in certain applications, support for this feature outside the scope of this version of the specification.
While JCP is designed for deployment on a secondary device, deployment on the same device as the one for which confirmation is being requested is also possible and can provide security benefits.
Modern Web browsers are large and complex with many features such as support for mobile code that are incompatible with a high security environment. Separating the confirmation protocol from the Web Browsing protocol permits implementation in a minimal client designed to permit detailed security analysis. Such a client might be embedded in or support means of secure interaction with a trustworthy operating system component.
While this means of deployment does not provide a true second factor confirmation, it is likely to provide a sufficient degree of authentication for many transactions.
JCP is a Web Service that permits a Enquirer to request that a User confirm or reject a specified action. If the user responds, the response is signed with a digital signature under a key that is unique to the user account, the client and the device.
Each JCP protocol interaction takes place between a connection pair of the following parties:
+-------------+ +------------+ +-------------+
| Initiator | <-----> | Broker | <------ | Device |
+-------------+ +------------+ +-------------+
^
|
V
+-------------+
| User |
+-------------+
Users are identified by means of an account identifier. The display presentation of an account identifier is the form of an RFC2822 email address identifier without the enclosing angle braces, for example:
alice@example.com
The account identifier is used by the User when registering the use of the confirmation service with a Broker.
An JCP service MAY be Open or Closed. An Open service provider provides JCP service to the general public. A Closed service provider only provides service to a specific community.
For example: An Internet Service Provider or DNS Registrar might provide an open JCP service as a part of their standard service offering to customers. An employer might operate a closed JCP service to be used for company business.
SXS-Confirm is presented in JSON encoding [RFC4627] over a HTTP Session [RFC2616] using HTTP Session Continuation [I-D.hallambaker-httpsession] for message layer authentication. Implementations MUST support and SHOULD use TLS transport for confidentiality and server authentication [RFC4627].
The Session Connection Service (SXS) [I-D.hallambaker-wsconnect] is used to establish the connection between the User Device and the Broker and the Initiator and the Broker. In each case the Broker is the SXS service. The Initiator and User Device are SXS clients.
SXS supports mutual and server-only authentication modes. Authentication MAY be performed using a wide range of client authentication mechanisms including PIN based, Out Of Band, PKI and none.
For a Private broker, the choice of authentication mode and credential lifetime is left to individual site policy.
Alice is a new employee of Example Inc which has the domain example.com. To make use of the connfirmation service, Alice must first configure her device for use. This would typically be performed once for the lifetime of the device. Her system administrator issues her with an account alice@example.com and a one time use PIN Q80370-1RA606-F04B.
Alice installs an SXS-Confirm application on her device. To configure the device she supplies the data proivided by the system administrator:
AccountName: alice@example.com PIN: Q80370-1RA606-F04B
The application MAY allow Alice to enter additional passwords and/or capture biometric profile data to provide multi-factor authentication in cases in which this is required.
The device makes an SXS service establishment request:
POST /.well-known/sxs-connect/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Host: localhost:8080
Content-Length: 348
Expect: 100-continue
{
"OpenPINRequest": {
"Encryption": ["A128CBC",
"A256CBC",
"A128GCM",
"A256GCM"],
"Authentication": ["HS256",
"HS384",
"HS512",
"HS256T128"],
"Account": "alice",
"Service": ["sxs-confirm-user"],
"Domain": "example.com",
"HaveDisplay": false,
"Challenge": "
5S8iMguqQjToLsiYkWzFqg"}}
The service verifies the request and issues a challenge to verify holdership of the PIN:
HTTP/1.1 281 Pin code required
Content-Length: 511
Date: Wed, 21 May 2014 20:05:54 GMT
Server: Microsoft-HTTPAPI/2.0
{
"OpenPINResponse": {
"Status": 281,
"StatusDescription": "Pin code required",
"Challenge": "
14w9zlndGuTL--MpoFvqGw",
"ChallengeResponse": "
0ZQ0sBgH2by-tsDOO1Z0ZgGs2JwbALHK8P3Xe5wV1ds",
"Cryptographic": {
"Secret": "
TXF8EFu-MEsoyYYeernfkA",
"Encryption": "A128CBC",
"Authentication": "HS256",
"Ticket": "
llSYMf2-eLXtBUI0gimo4EWh7s73dDI-CGPRH8pA1kO3jphiQ-dRy0xbuwNm2lS3
rLApBeSy43gY0Lw-hG-GwyYFEiAaBbcBd5SbEuPzmFAFvIIAJR1FWnItHWmeLqT2
uXqaZ90dCZpUVFCMSrhzXA"}}}
Having received the challenge, the client presents proof of knowledge of the PIN:
POST /.well-known/sxs-connect/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Session: Value=WWL9QUlubhwTCc-p3IPoj5n8lDX5fTMF0Y5IVyJ27Mk;
Id=llSYMf2-eLXtBUI0gimo4EWh7s73dDI-CGPRH8pA1kO3jphiQ-dRy0xbuwNm
2lS3rLApBeSy43gY0Lw-hG-GwyYFEiAaBbcBd5SbEuPzmFAFvIIAJR1FWnItHWm
eLqT2uXqaZ90dCZpUVFCMSrhzXA
Host: localhost:8080
Content-Length: 133
Expect: 100-continue
{
"TicketRequest": {
"Service": ["sxs-confirm-user"],
"ChallengeResponse": "
NtLC4b3Yh-M4nYE-d8L7AR20xjjCQaUoqsCJszSyJ8E"}}
The service now completes the transaction by returning the connection credentials:
HTTP/1.1 OK Success
Content-Length: 855
Date: Wed, 21 May 2014 20:05:54 GMT
Server: Microsoft-HTTPAPI/2.0
{
"TicketResponse": {
"Status": 200,
"StatusDescription": "Success",
"Cryptographic": [{
"Protocol": "sxs-connect",
"Secret": "
arirqsCsTxd__rS4fP3z_w",
"Encryption": "A128CBC",
"Authentication": "HS256",
"Ticket": "
SBogEm9gzuX7i0NoRI4B6Fpjn_JN1XW6WudJNSesXLSs0MmQjqpTpG9aQ7r308DE
WMsscT9ty8f4_lKNyVVVcnuTMlHUTbeKMJKLjavR7YA"}],
"Service": [{
"Service": "sxs-confirm-user",
"Name": "localhost",
"Port": 8080,
"Priority": 100,
"Weight": 100,
"Transport": "HTTP",
"Cryptographic": {
"Secret": "
cjOJoN1vQJI4fHtWqyi-Eg",
"Encryption": "A128CBC",
"Authentication": "HS256T128",
"Ticket": "
9iWlfDxGtFPS8hwVlKLHt4IDFdDj6TiJMUU8WvRTnuKTwS9pKZJLuBdRg-2Ea8Ld
m_77w3dwvYyipqTm3BUHbA-hxeBLBcJgpuXD6KdA92I"}}]}}
Note that for the sake of brevity, only a single confirmation host is specified in these examples. A service MAY specify multiple hosts to provide for service connectivity in the case of a service outage affecting only one host.
Having connected her device to the SXS-Confirm service, Alice begins work. She attempts to gain access to a restricted Web Site in the corporate Intranet. This site requires that she confirm this request using her registered User Device and that the BIOMETRIC authentication factor be used as a second factor.
Alice enters her account into the site. Note that she does not supply a password to the site.
SXSConfirm Account: alice@example.com
The Web site initiates a request for confirmation of the access request. It begins by identifying the service from Alice's account as example.com. If the Initiator has already established a connection to this broker and it has not expired, that connection is reused. Otherwise the Initiator MUST establish a connection to the Broker. This has two steps, broker discovery and the session establishment itself.
To obtain the broker for the SXSConfirm service, the SRV Service Discovery mechanism [RFC2782] and Well Known Service conventions [RFC5785] are used:
Initiator clients MUST support the following service discovery mechanism:
The Initiator begins by retrieving the SRV record for example.com:
_sxsconfirm._tcp.example.com SRV 0 1 8080 sxsconfirm0.example.com _sxsconfirm._tcp.example.com SRV 0 1 8080 sxsconfirm1.example.com
The service randomly selects the host sxsconfirm1. The Web Service Endpoint for the SXSConfirm service is therefore:
https://sxsconfirm1:8080/.well-known/sxsconfirm/
Having determined the service endpoint, the Initiator attempts to establish a connection. Since this is a server to server interaction, TLS Certificate based Client Authentication is used in combination with the SXS BindRequest:
POST /.well-known/sxs-connect/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Host: localhost:8080
Content-Length: 227
Expect: 100-continue
{
"BindRequest": {
"Service": ["sxs-confirm-initiator"],
"Encryption": ["A128CBC",
"A256CBC",
"A128GCM",
"A256GCM"],
"Authentication": ["HS256",
"HS384",
"HS512",
"HS256T128"]}}
HTTP/1.1 OK Success
Content-Length: 580
Date: Wed, 21 May 2014 20:05:54 GMT
Server: Microsoft-HTTPAPI/2.0
{
"TicketResponse": {
"Status": 200,
"StatusDescription": "Success",
"Cryptographic": [],
"Service": [{
"Service": "sxs-confirm-initiator",
"Name": "localhost",
"Port": 8080,
"Priority": 100,
"Weight": 100,
"Transport": "HTTP",
"Cryptographic": {
"Secret": "
6FOiWaEb_54Q1PMuzsmrbA",
"Encryption": "A128CBC",
"Authentication": "HS256T128",
"Ticket": "
t2lm_h3wbKVF2hzkoHXaG1Q5wMv7P03RhQgBeEsBkV_8zXYcx7GzhCSxqHpgmhGo
6CIO5vV6w3n3sEYvArSCeHFoGw59IHCuFOvBoKe9EME"}}]}}
Having established a connection to the service, the Initiator can make its confirmation request:
POST /.well-known/sxs-confirm-initiator/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Session: Value=jWwsg7lWNquvAokfx4OQ414RWo_YbKITOhF3-TadxtQ;
Id=t2lm_h3wbKVF2hzkoHXaG1Q5wMv7P03RhQgBeEsBkV_8zXYcx7GzhCSxqHpg
mhGo6CIO5vV6w3n3sEYvArSCeHFoGw59IHCuFOvBoKe9EME
Host: localhost:8080
Content-Length: 904
Expect: 100-continue
{
"ConfirmationRequest": {
"Payload": "
ewogICJNZXNzYWdlSXRlbSI6IHsKICAgICJUcmFuc2FjdGlvbklEIjogIgo2VkJu
dHJwNnJmc182SlkwUW0zZ01RIiwKICAgICJJc3N1ZSI6ICIyMDE0LTA1LTIxVDE2
OjA1OjU1WiIsCiAgICAiQWNjb3VudCI6ICJhbGljZUBleGFtcGxlLmNvbSIsCiAg
ICAiVGV4dCI6ICJ7XG4gIFwiUmVxdWVzdFRleHRcIjoge1xuICAgIFwiVGl0bGVc
IjogXCJDb25maXJtIEFjY2VzcyB0byBSZXN0cmljdGVkIFNpdGVcIixcbiAgICBc
IlBcIjogW1wiVGhlIGFjY291bnQgYWxpY2VAZXhhbXBsZS5jb20gaGFzIHJlcXVl
c3RlZCBhY2Nlc3MgdG8gdGhlIGNsYXNzaWZpZWQgc2l0ZS5cIixcbiAgICAgIFwi
RG8geW91IHdpc2ggdG8gcGVybWl0IHRoaXM_XCJdLFxuICAgIFwiQnV0dG9uc1wi
OiBbe1xuICAgICAgICBcIk5hbWVcIjogXCJBY3Rpb25cIixcbiAgICAgICAgXCJW
YWx1ZVwiOiBcImFjY2VwdFwiLFxuICAgICAgICBcIlRleHRcIjogXCJBY2NlcHRc
In0sXG4gICAgICB7XG4gICAgICAgIFwiTmFtZVwiOiBcIkFjdGlvblwiLFxuICAg
ICAgICBcIlZhbHVlXCI6IFwicmVqZWN0XCIsXG4gICAgICAgIFwiVGV4dFwiOiBc
IlJlamVjdFwifV19fSIsCiAgICAiQ29udGVudFR5cGUiOiAiYXBwbGljYXRpb24v
anNvbiJ9fQ"}}
Broker Responds:
HTTP/1.1 OK Success
Content-Length: 133
Date: Wed, 21 May 2014 20:05:54 GMT
Server: Microsoft-HTTPAPI/2.0
{
"ConfirmationResponse": {
"Status": 200,
"StatusDescription": "Success",
"TransactionID": "
XCu4oCDocPcQKBVCdL1X2w"}}
Before she can respond to an individual message, Alice must first download her pending requests from the broker:
POST /.well-known/sxs-confirm-user/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Session: Value=hj4sW_-lf9F13F7NdG-OCv2eDQKUTjGTQAp5YoGWVSg;
Id=9iWlfDxGtFPS8hwVlKLHt4IDFdDj6TiJMUU8WvRTnuKTwS9pKZJLuBdRg-2E
a8Ldm_77w3dwvYyipqTm3BUHbA-hxeBLBcJgpuXD6KdA92I
Host: localhost:8080
Content-Length: 25
Expect: 100-continue
{
"ConfirmRequest": {}}
Broker Responds:
HTTP/1.1 OK Success
Content-Length: 80
Date: Wed, 21 May 2014 20:05:54 GMT
Server: Microsoft-HTTPAPI/2.0
{
"ConfirmResponse": {
"Status": 200,
"StatusDescription": "Success"}}
Alice can now confirm the request from the Web Server:
[To Be Specified]
Broker Responds:
[To Be Specified]
The Broker can now provide the Initiator with its response:
POST /.well-known/sxs-confirm-initiator/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Session: Value=fztYuA1t_mvfRjruWX6J7f0RpI2dEgHCh2xHdXM-_XY;
Id=t2lm_h3wbKVF2hzkoHXaG1Q5wMv7P03RhQgBeEsBkV_8zXYcx7GzhCSxqHpg
mhGo6CIO5vV6w3n3sEYvArSCeHFoGw59IHCuFOvBoKe9EME
Host: localhost:8080
Content-Length: 71
Expect: 100-continue
{
"StatusRequest": {
"TransactionID": "
XCu4oCDocPcQKBVCdL1X2w"}}
Broker Responds:
HTTP/1.1 OK Success
Content-Length: 79
Date: Wed, 21 May 2014 20:05:54 GMT
Server: Microsoft-HTTPAPI/2.0
{
"StatusResponse": {
"Status": 200,
"StatusDescription": "Success"}}
Note that since the user might take seconds, minutes, hours or even days to respond to a request, more than one mechanism for returning the User response to the Initiator is required. These mechanisms are:
The UYFM transport permits low latency status reports to be made with minimal server resource use.
Uses SXS with the Protocol type SXS-CONFIRM for device binding
A request
Post a request for confirmation to a user.
Query the status of a pending Confirmation transaction
Note that the status values only report the success or failure of the transaction itself. User responses are only returned as signed content.
Asynchronous status update on pending transaction.
Request a confirmation from a specified user.
Reports the success or failure of the message
The WrappedData object permits optional authetication data to be added to SXS-Confirm requests and responses.
While JSON markup is sufficient to send the simplest request messages, the limitations of using a data encoding format for what is essentially a document markup are apparent.
Simple Request Markup Language (SRML) is a markup language for use in confirmation requests. The capabilities of the basic JSON encoding are provided by the following tags:
While SRML is loosely based on the HTML forms markup, there are important differences. The HTML markup model supports multiple document types of which forms are only one and a single document may contain multiple forms with multiple different action values. In an SRML document is a single form and the form action to be performed is impicit in the presentation of the document to the user.
The MIME Content Type and schema identifier for SRML are
Content-Type: text/xml xmlns: http://hallambaker.com/Schemas/srml.xsd
The schema is
<?xml version="1.0" encoding="utf-8"?>
<xs:schema id="XMLSchema1"
targetNamespace="http://hallambaker.com/Schemas/srml.xsd"
xmlns="http://hallambaker.com/Schemas/srml.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="srml" type="SRMLType"/>
<xs:complexType name="SRMLType">
<xs:sequence>
<xs:element name="title" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<xs:element name="p" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="button" minOccurs="2" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="button" type="InputType"/>
<xs:complexType name="InputType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="name" type="xs:ID"/>
<xs:attribute name="value" type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
The capabilities of SRML are intentionally limited to the bare minimum. It should be possible to make use of SRML to display options to the user on a smartwatch or other device with a highly constrained display.
The function of the confirmation service is to provide confirmation of an action that was initiated elsewhere. It is therefore inappropriate for this or any future version of SRML to offer extensive data entry or validation capabilities. SRML applications MUST NOT support any form of scripting or active code extensions to SRML content.
It might prove advantageous in the future to extend the input types to include simple form elements such as checkboxes, numeric fields, text choices and possibly free form text.
Consider spam control, how do users prevent unwanted requests? (EV accreditatio, filtering at Broker)
People deploying JCP as a means of controlling access to networking infrastructure must consider the bootstrap issue. In particular since JCP requires Internet access the network administrator must ensure that it is possible to manage the network resources necessary to support an SXS service when that service is down.
| [I-D.hallambaker-wsconnect] | Hallam-Baker, P., "JSON Service Connect (JCX) Protocol", Internet-Draft draft-hallambaker-wsconnect-05, January 2014. |
| [RFC2782] | Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. |
| [RFC5785] | Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010. |
| [RFC4627] | Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. |
| [RFC2616] | Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
| [I-D.hallambaker-httpsession] | Hallam-Baker, P., "HTTP Session Management", Internet-Draft draft-hallambaker-httpsession-02, January 2014. |