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

Abstract

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.

Status of This Memo

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 Notice

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.

1. Background

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.

1.1. Second Factor Authentication

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.

1.2. Confirmation vs. Authentication

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.

1.3. Use Scenarios

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.

1.4. Use in Financial Services

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.

1.5. Machine Binding

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.

1.6. Tethered Use

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.

1.7. Co-Browser

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.

2. Architecture

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.

2.1. Parties

Each JCP protocol interaction takes place between a connection pair of the following parties:

Initiator
A party that initiates a confirmation request.
User
The User is the person being asked to grant or refuse confirmation. A User MAY have multiple accounts with multiple Broker Services.
User Device
A device that the user has bound to their broker account.
Broker
A clearing house that stores and forwards requests from Initiators to Users Device and responses from Users to Initiators. The Broker is only trusted to perform routing filtering and recording of requests and responses. The Broker is not trusted with respect to the responses returned.

+-------------+         +------------+         +-------------+
|  Initiator  | <-----> |   Broker   | <------ |   Device    |
+-------------+         +------------+         +-------------+
                                                      ^
                                                      |
                                                      V
                                               +-------------+
                                               |     User    |
                                               +-------------+

2.2. Accounts

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.

2.3. Open and Closed Services

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.

3. Protocol

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.

3.1. User Device Service Connection

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.

3.2. Initiator Service Connection

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.

3.2.1. Broker Discovery

To obtain the broker for the SXSConfirm service, the SRV Service Discovery mechanism [RFC2782] and Well Known Service conventions [RFC5785] are used:

SRV Prefix:
Well Known Service Identifier:

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/

3.2.2. Establish Service Connection to Broker

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"}}]}}

3.3. Query

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"}}

3.4. User Response

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]

3.5. Query Response

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:

Continuing HTTP Session.
A broker MAY allow an Initiator to keep the initial HTTP session alive for a sufficiently long interval for the user to respond.
Polling
A broker MUST support the AskStatus transaction that permits the Initiator to query the status of a pending transaction. This mechanism permits a Broker to set a minimum interval within which a status update request will be responded to and refuse queries that are too frequent.
Asynchronous
An Initiator MAY specify a URI being the Web Service Endpoint of a Web Service to which the Broker may return the user response using the AsyncStatus transaction.

The UYFM transport permits low latency status reports to be made with minimal server resource use.

4. Binding

Uses SXS with the Protocol type SXS-CONFIRM for device binding

5. ConfirmationBroker

5.1. ConfirmationBroker Transactions

5.2. ConfirmationBroker Messages

5.3. ConfirmationBroker Structures

5.3.1. Structure: MessageItem

A request

TransactionID :
Binary [1..1] Unique Message Identifier assigned by either the Initiator or broker. Note that unlike an email message identifier, the transaction identifier SHOULD change.
Issue :
DateTime [1..1] Time at which the transaction identifier was issued
Entry :
DateTime [0..1] Time at which the request was initiated if different from the Issue time.
Account :
String [1..1] The account to which the request was directed. A given user MAY have multiple accounts and multiple users MAY have authority to respond to a given account.
Text :
String [1..1] Text describing the request to the user.
ContentType :
String [0..1] Format of the request text.
Factor :
String [0..Many] Keyword indicating that a particular multi-factor authentication technique is required.

5.3.2. Structure: RequestText

Title :
String [0..1] Title of the request message
P :
String [0..Many] Paragraph of request message text
Buttons :
Input [0..Many] Button Entry

5.3.3. Structure: Input

Name :
String [0..1] Specifies a JSON tag name to be specified if the button is pressed to make the response.
Value :
String [0..1] Specifies a string of text to be returned as the value of the 'Name' tag.
Text :
String [0..1] Text to be displayed to the user

6. ConfirmationBroker

6.1. ConfirmationBroker Transactions

6.1.1. Confirmation

Post a request for confirmation to a user.

6.1.2. AskStatus

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.

6.1.3. Cancel

6.1.4. AsyncStatus

Asynchronous status update on pending transaction.

6.2. ConfirmationBroker Messages

6.2.1. Message: InitiatorRequest

6.2.2. Message: InitiatorResponse

Status :
Integer [1..1] Status return code value
StatusDescription :
String [0..1] Describes the status code (ignored by processors)

6.2.3. Message: ConfirmationRequest

Request a confirmation from a specified user.

Header :
Binary [0..1] If present specifies a Jose Web Signature Protected Header.
Payload :
Binary [1..1] A Base64 encoded binary field, the contents of which are a MessageItem structure.
Signature :
Binary [0..1] If present specifies a Jose Web Signature Value.
ReplyTo :
URI [0..1] URI of a web service to which the service MAY post an asynchronous reply using the TransactionStatus transaction.

6.2.4. Message: ConfirmationResponse

Status :
Integer [1..1] Status return code value
StatusDescription :
String [0..1] Describes the status code (ignored by processors)
TransactionID :
Binary [1..1] Unique Transaction Identifier for us in subsequent StatusRequest messages.

6.2.5. Message: StatusRequest

TransactionID :
Binary [1..1] Unique Transaction Identifier returned in ConfirmationResponse message

6.2.6. Message: StatusResponse

Status :
Integer [1..1] Status return code value
StatusDescription :
String [0..1] Describes the status code (ignored by processors)
UserResponse :
String [1..1] Confirmation response from the user as specified by the confirmation challenge text.

6.2.7. Message: PresentStatus

UserResponse :
String [1..1] Confirmation response from the user as specified by the confirmation challenge text.

6.2.8. Message: CancelRequest

TransactionID :
Binary [1..1] [TBS]

6.3. ConfirmationBroker Structures

7. ConfirmationBroker

7.1. ConfirmationBroker Transactions

7.1.1. GetMessages

7.1.2. Confirm

7.2. ConfirmationBroker Messages

7.2.1. Message: GetMessagesRequest

OnOrAfter :
DateTime [0..1]
Before :
DateTime [0..1]
MaxLength :
Integer [0..1] Maximum request text length in bytes

7.2.2. Message: GetMessagesResponse

Status :
Integer [1..1] Status return code value
StatusDescription :
String [0..1] Describes the status code (ignored by processors)
Pending :
Integer [1..1] Number of pending confirmation requests.
Answered :
Integer [0..1] Number of previously answered confirmation requests.
Expired :
Integer [0..1] Number of pending confirmation requests that expired before they were answered.
Messages :
WrappedData [1..Many] List of WrappedData objects in which the Payload field is a pending message. These MAY be returned in any order. Note that the list of messages MAY be incomplete as transactions MAY have been responded to earlier.

7.2.3. Message: ConfirmRequest

UserResponse :
WrappedData [0..1] A WrappedData object whose payload is the response from the user. This is a JSON object whose tags and values are determined by the request markup.
Abuse :
String [0..1] If present, the user has indicated that the request is being refused as abusive. For example, the message text is an unsolicited commercial message.

7.2.4. Message: ConfirmResponse

Reports the success or failure of the message

Status :
Integer [1..1] Status return code value
StatusDescription :
String [0..1] Describes the status code (ignored by processors)

7.3. ConfirmationBroker Structures

7.3.1. Structure: WrappedData

The WrappedData object permits optional authetication data to be added to SXS-Confirm requests and responses.

Header :
Binary [0..1] If present specifies a Jose Web Signature Protected Header.
Payload :
Binary [1..1] The signed data
Signature :
Binary [0..1] If present specifies a Jose Web Signature Value over the header and payload values.

8. Simple Request Markup Language (SRMLv1)

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:

<h1>Heading Text</h1>
Heading
<p>Running text</p>
Paragraph
<button value="value">User option</button>
Button specifying a value that the user can select.

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.

8.1. XML Schema and Content Type Identifier

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>

8.2. Design considerations and future options

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.

9. Security Considerations

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.

10. Acnowledgementsts

11. Normative References

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

Author's Address

Phillip Hallam-Baker Comodo Group Inc. EMail: philliph@comodo.com

Table of Contents