Internet Engineering Task Force (IETF) Phillip Hallam-Baker
Internet-Draft Comodo Group Inc.
Intended Status: Standards Track October 16, 2014
Expires: April 19, 2015
SXS Confirmation Protocol (SXS-Confirm)
draft-hallambaker-sxs-confirm-02
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."
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.
Hallam-Baker April 19, 2015 [Page 1]
Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014
Table of Contents
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Second Factor Authentication . . . . . . . . . . . . . . 4
1.2. Confirmation vs. Authentication . . . . . . . . . . . . . 4
1.3. Use Scenarios . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Use in Financial Services . . . . . . . . . . . . . . . . 5
1.5. Machine Binding . . . . . . . . . . . . . . . . . . . . . 6
1.6. Tethered Use . . . . . . . . . . . . . . . . . . . . . . 6
1.7. Co-Browser . . . . . . . . . . . . . . . . . . . . . . . 6
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Parties . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Accounts . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Open and Closed Services . . . . . . . . . . . . . . . . 8
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. User Device Service Connection . . . . . . . . . . . . . 9
3.2. Initiator Service Connection . . . . . . . . . . . . . . 11
3.2.1. Broker Discovery . . . . . . . . . . . . . . . . . . 12
3.2.2. Establish Service Connection to Broker . . . . . . . 12
4. Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. ConfirmationBroker . . . . . . . . . . . . . . . . . . . . . . 13
5.1. ConfirmationBroker Transactions . . . . . . . . . . . . . 13
5.2. ConfirmationBroker Messages . . . . . . . . . . . . . . . 13
5.3. ConfirmationBroker Structures . . . . . . . . . . . . . . 13
5.3.1. Structure: MessageItem . . . . . . . . . . . . . . . 13
5.3.2. Structure: RequestText . . . . . . . . . . . . . . . 14
5.3.3. Structure: Input . . . . . . . . . . . . . . . . . . 14
6. ConfirmationBroker . . . . . . . . . . . . . . . . . . . . . . 14
6.1. ConfirmationBroker Transactions . . . . . . . . . . . . . 14
6.1.1. Confirmation . . . . . . . . . . . . . . . . . . . . 14
6.1.2. AskStatus . . . . . . . . . . . . . . . . . . . . . 15
6.1.3. Cancel . . . . . . . . . . . . . . . . . . . . . . . 15
6.1.4. AsyncStatus . . . . . . . . . . . . . . . . . . . . 15
6.2. ConfirmationBroker Messages . . . . . . . . . . . . . . . 15
6.2.1. Message: InitiatorRequest . . . . . . . . . . . . . 15
6.2.2. Message: InitiatorResponse . . . . . . . . . . . . . 15
6.2.3. Message: ConfirmationRequest . . . . . . . . . . . . 15
6.2.4. Message: ConfirmationResponse . . . . . . . . . . . 16
6.2.5. Message: StatusRequest . . . . . . . . . . . . . . . 16
6.2.6. Message: StatusResponse . . . . . . . . . . . . . . 16
6.2.7. Message: PresentStatus . . . . . . . . . . . . . . . 16
6.2.8. Message: CancelRequest . . . . . . . . . . . . . . . 16
6.3. ConfirmationBroker Structures . . . . . . . . . . . . . . 16
7. ConfirmationBroker . . . . . . . . . . . . . . . . . . . . . . 17
7.1. ConfirmationBroker Transactions . . . . . . . . . . . . . 17
7.1.1. GetMessages . . . . . . . . . . . . . . . . . . . . 17
7.1.2. Confirm . . . . . . . . . . . . . . . . . . . . . . 17
7.2. ConfirmationBroker Messages . . . . . . . . . . . . . . . 17
7.2.1. Message: GetMessagesRequest . . . . . . . . . . . . 17
7.2.2. Message: GetMessagesResponse . . . . . . . . . . . . 17
7.2.3. Message: ConfirmRequest . . . . . . . . . . . . . . 18
Hallam-Baker April 19, 2015 [Page 2]
Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014
7.2.4. Message: ConfirmResponse . . . . . . . . . . . . . . 18
7.3. ConfirmationBroker Structures . . . . . . . . . . . . . . 18
7.3.1. Structure: WrappedData . . . . . . . . . . . . . . . 18
8. Simple Request Markup Language (SRMLv1) . . . . . . . . . . . 18
8.1. XML Schema and Content Type Identifier . . . . . . . . . 19
8.2. Design considerations and future options . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. Acnowledgementsts . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Hallam-Baker April 19, 2015 [Page 3]
Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014
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.
Hallam-Baker April 19, 2015 [Page 4]
Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014
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.
Hallam-Baker April 19, 2015 [Page 5]
Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014
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.
Hallam-Baker April 19, 2015 [Page 6]
Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014
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.
Hallam-Baker April 19, 2015 [Page 7]
Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014
+-------------+ +------------+ +-------------+
| 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.
Hallam-Baker April 19, 2015 [Page 8]
Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014
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": {
"Service": ["sxs-confirm-user"],
"Encryption": ["A128CBC",
"A256CBC",
"A128GCM",
"A256GCM"],
"Authentication": ["HS256",
"HS384",
"HS512",
"HS256T128"],
"Account": "alice",
"Domain": "example.com",
"HaveDisplay": false,
"Challenge": "
PDj21ZQmN8-mtk1m5jR-3A"}}
Hallam-Baker April 19, 2015 [Page 9]
Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014
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: Tue, 07 Oct 2014 21:34:57 GMT
Server: Microsoft-HTTPAPI/2.0
{
"OpenPINResponse": {
"Status": 281,
"StatusDescription": "Pin code required",
"Challenge": "
DAtbg-hOyP4vEfD2P3TKAg",
"ChallengeResponse": "
bp3gsrL379r7_DWtzaVlJMxaQSOdALCcgtBqfuu84MI",
"Cryptographic": {
"Secret": "
qTM1eURxmhzf-fzHL5qGwA",
"Encryption": "A128CBC",
"Authentication": "HS256",
"Ticket": "
D2T5A8ftUAfbd0SJ8MzFq7vF-UnzJn4OmfEibCjU5q0Ae2m_CQHJ4pwyRzrfpy4q
OtK8ZPk-wLQgmO_h7VDyA8Euyc-b0Alu8Fi80cUaiG3Z1btRnX_VVkrg2F_b4L9z
iQMF2ktmR7rlt_KrRW5Z2A"}}}
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=qXDOKEx9NVduoxzF_CSX0SWPEOXlb8oLp88kg3_eUbs;
Id=D2T5A8ftUAfbd0SJ8MzFq7vF-UnzJn4OmfEibCjU5q0Ae2m_CQHJ4pwyRzrf
py4qOtK8ZPk-wLQgmO_h7VDyA8Euyc-b0Alu8Fi80cUaiG3Z1btRnX_VVkrg2F_
b4L9ziQMF2ktmR7rlt_KrRW5Z2A
Host: localhost:8080
Content-Length: 133
Expect: 100-continue
{
"TicketRequest": {
"Service": ["sxs-confirm-user"],
"ChallengeResponse": "
8MR5xjrF-hk6U2PbG9UfW4hviIkylWtWdRlquXFFQXE"}}
The service now completes the transaction by returning the connection
credentials:
Hallam-Baker April 19, 2015 [Page 10]
Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014
HTTP/1.1 OK Success
Content-Length: 855
Date: Tue, 07 Oct 2014 21:34:57 GMT
Server: Microsoft-HTTPAPI/2.0
{
"TicketResponse": {
"Status": 200,
"StatusDescription": "Success",
"Cryptographic": [{
"Protocol": "sxs-connect",
"Secret": "
tsHfOB2boaYtaMWX6-joiw",
"Encryption": "A128CBC",
"Authentication": "HS256",
"Ticket": "
hRFVGigJ-0MdZS13VT5bF6fchTDAeVPbJPAYZA4oaI1-FcdeK_XemXya2G4Gph2w
RKjJhrmEGbvwrsliaroc_gAedCb8aATEWSC0kmAZmbo"}],
"Service": [{
"Service": "sxs-confirm-user",
"Name": "localhost",
"Port": 8080,
"Priority": 100,
"Weight": 100,
"Transport": "HTTP",
"Cryptographic": {
"Secret": "
L71fViIdYnptqtcvMkcw0Q",
"Encryption": "A128CBC",
"Authentication": "HS256T128",
"Ticket": "
Kwaqgil7P1OdYCczSEEXxE3LFkw60fLbMQGDZWIXdDKfcl0gjLP7E61UTvlRSYyO
6g7is2XaDHvgiC7DYDroX3jlt-xNtb0zveFPV0vXaTk"}}]}}
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.
Hallam-Baker April 19, 2015 [Page 11]
Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014
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:
* [1] Attempt to resolve an SRV record for
_sxsconfirm._tcp.<host>
* [2] If no SRV record is found a client MAY attempt to discover
the service at https://<host>/.well-known/sxsconfirm/
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:
Hallam-Baker April 19, 2015 [Page 12]
Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014
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"]}}
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.
Hallam-Baker April 19, 2015 [Page 13]
Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014
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
* Request: ConfirmationRequest
* Response: ConfirmationResponse
Post a request for confirmation to a user.
Hallam-Baker April 19, 2015 [Page 14]
Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014
6.1.2. AskStatus
* Request: StatusRequest
* Response: StatusResponse
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
* Request: CancelRequest
* Response: InitiatorResponse
6.1.4. AsyncStatus
* Request: PresentStatus
* Response: StatusResponse
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.
Hallam-Baker April 19, 2015 [Page 15]
Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014
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
Hallam-Baker April 19, 2015 [Page 16]
Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014
7. ConfirmationBroker
7.1. ConfirmationBroker Transactions
7.1.1. GetMessages
* Request: GetMessagesRequest
* Response: GetMessagesResponse
7.1.2. Confirm
* Request: ConfirmRequest
* Response: ConfirmResponse
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.
Hallam-Baker April 19, 2015 [Page 17]
Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014
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.
Hallam-Baker April 19, 2015 [Page 18]
Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014
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>
Hallam-Baker April 19, 2015 [Page 19]
Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014
<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. References
11.1. Normative References
[I-D.hallambaker-wsconnect] Hallam-Baker, P, "JSON Service Connect
(JCX) Protocol", Internet-Draft draft-hallambaker-
wsconnect-05, 21 January 2014.
[RFC2782] Gulbrandsen, A.,Vixie, P.,Esibov, L., "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
Hallam-Baker April 19, 2015 [Page 20]
Internet-Draft SXS Confirmation Protocol (SXS-Confirm) October 2014
[RFC5785] Nottingham, M.,Hammer-Lahav, E., "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.,Berners-Lee, T., "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, 21 January 2014.
Author's Address
Phillip Hallam-Baker
Comodo Group Inc.
philliph@comodo.com
Hallam-Baker April 19, 2015 [Page 21]