Internet Engineering Task Force (IETF) Phillip Hallam-Baker Internet-Draft Comodo Group Inc. Intended Status: Standards Track May 19, 2014 Expires: November 20, 2014 SXS Confirmation Protocol (SXS-Confirm) draft-hallambaker-sxs-confirm-00 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 November 20, 2014 [Page 1] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 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 . . . . . . . . . . . . . . 12 3.2.1. Broker Discovery . . . . . . . . . . . . . . . . . . 13 3.2.2. Establish Service Connection to Broker . . . . . . . 13 3.3. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4. User Response . . . . . . . . . . . . . . . . . . . . . . 15 3.5. Query Response . . . . . . . . . . . . . . . . . . . . . 16 3.5.1. Structure: MessageItem . . . . . . . . . . . . . . . 18 3.5.2. Structure: RequestText . . . . . . . . . . . . . . . 18 3.5.3. Structure: Input . . . . . . . . . . . . . . . . . . 18 3.5.4. Message: InitiatorRequest . . . . . . . . . . . . . 19 3.5.5. Message: InitiatorResponse . . . . . . . . . . . . . 19 4. Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. ConfirmationBroker . . . . . . . . . . . . . . . . . . . . . . 19 6. ConfirmationBroker . . . . . . . . . . . . . . . . . . . . . . 19 6.1. Confirmation . . . . . . . . . . . . . . . . . . . . . . 19 6.1.1. Message: ConfirmationRequest . . . . . . . . . . . . 19 6.1.2. Message: ConfirmationResponse . . . . . . . . . . . 20 6.2. AskStatus . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2.1. Message: StatusRequest . . . . . . . . . . . . . . . 20 6.2.2. Message: StatusResponse . . . . . . . . . . . . . . 20 6.2.3. Message: PresentStatus . . . . . . . . . . . . . . . 20 6.3. Cancel . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.3.1. Message: CancelRequest . . . . . . . . . . . . . . . 20 6.4. AsyncStatus . . . . . . . . . . . . . . . . . . . . . . . 20 6.4.1. Structure: WrappedData . . . . . . . . . . . . . . . 20 6.4.2. Message: UserRequest . . . . . . . . . . . . . . . . 21 6.4.3. Message: UserResponse . . . . . . . . . . . . . . . 21 7. ConfirmationBroker . . . . . . . . . . . . . . . . . . . . . . 21 7.1. GetMessages . . . . . . . . . . . . . . . . . . . . . . . 21 7.1.1. Message: GetMessagesRequest . . . . . . . . . . . . 21 7.1.2. Message: GetMessagesResponse . . . . . . . . . . . . 22 7.2. Confirm . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.2.1. Message: ConfirmRequest . . . . . . . . . . . . . . 22 7.2.2. Message: ConfirmResponse . . . . . . . . . . . . . . 22 8. Simple Request Markup Language (SRMLv1) . . . . . . . . . . . 22 Hallam-Baker November 20, 2014 [Page 2] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 2014 8.1. XML Schema and Content Type Identifier . . . . . . . . . 23 8.2. Design considerations and future options . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10. Acnowledgementsts . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 Hallam-Baker November 20, 2014 [Page 3] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 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 November 20, 2014 [Page 4] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 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 November 20, 2014 [Page 5] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 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 November 20, 2014 [Page 6] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 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 November 20, 2014 [Page 7] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 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 November 20, 2014 [Page 8] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 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. Hallam-Baker November 20, 2014 [Page 9] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 2014 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": " zCXJp-BZME7D1kJQzDqaSQ"}} The service verifies the request and issues a challenge to verify holdership of the PIN: Hallam-Baker November 20, 2014 [Page 10] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 2014 HTTP/1.1 281 Pin code required Content-Length: 511 Date: Mon, 19 May 2014 17:17:44 GMT Server: Microsoft-HTTPAPI/2.0 { "OpenPINResponse": { "Status": 281, "StatusDescription": "Pin code required", "Challenge": " jnPlBZNiC0ggSjum3ZiHpA", "ChallengeResponse": " QbbxWJXofbsWJLQVxWw2gF0dWC8gB9x69p5pjEnAF8E", "Cryptographic": { "Secret": " OQLktniFyjyAP3fkJ2lPvw", "Encryption": "A128CBC", "Authentication": "HS256", "Ticket": " JY3wIo9nHwAYeDXLIxdPpV2sqLkJWRRrJxqlBmNXtczaxD0_CSr-chPW0FQ2vhoS QXkj9L5LVtPD7B1N6dVyXYCbK7zZIKTrtMblmxe8Jv9L4wBPwVJAFZCgV5H6qc9p erMPef_iWaLz5zO256W-og"}}} 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=260qBHxRZGt1W1dNTk_vyIOm5GyC-uI3AT0BT-6oFp4; Id=JY3wIo9nHwAYeDXLIxdPpV2sqLkJWRRrJxqlBmNXtczaxD0_CSr-chPW0FQ2 vhoSQXkj9L5LVtPD7B1N6dVyXYCbK7zZIKTrtMblmxe8Jv9L4wBPwVJAFZCgV5H 6qc9perMPef_iWaLz5zO256W-og Host: localhost:8080 Content-Length: 133 Expect: 100-continue { "TicketRequest": { "Service": ["sxs-confirm-user"], "ChallengeResponse": " tKe6pYYnnB65nPtkC7mSlXwNZ_xr0gB3GqL0DoFoO4M"}} The service now completes the transaction by returning the connection credentials: Hallam-Baker November 20, 2014 [Page 11] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 2014 HTTP/1.1 OK Success Content-Length: 855 Date: Mon, 19 May 2014 17:17:44 GMT Server: Microsoft-HTTPAPI/2.0 { "TicketResponse": { "Status": 200, "StatusDescription": "Success", "Cryptographic": [{ "Protocol": "sxs-connect", "Secret": " UfL98xc2dCFY9riBYG8tfw", "Encryption": "A128CBC", "Authentication": "HS256", "Ticket": " xIUcz0Xo58CSkp3sGxmfcWxHRZhsXEje3K8X7vEe0mBy81KGddFygWKSepNiFNeC _szkx3b_fiwzLv2s9cbOvc7-7CTiic99-slhpryQ508"}], "Service": [{ "Service": "sxs-confirm-user", "Name": "localhost", "Port": 8080, "Priority": 100, "Weight": 100, "Transport": "HTTP", "Cryptographic": { "Secret": " Qv_4-9ua_QJ3aHx5DJzbzQ", "Encryption": "A128CBC", "Authentication": "HS256T128", "Ticket": " 2gvt6XFinSoEOqBEJrKl7pBWy-NSNLFbEg8S8APpOu0tHWo6CIy6vOnquJn6u9bO Kw3iC8fuWVUIuZZZM6qv_qjDzlEUhRJvtRlkLdJn9dQ"}}]}} 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 November 20, 2014 [Page 12] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 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. * [2] If no SRV record is found a client MAY attempt to discover the service at https:///.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 November 20, 2014 [Page 13] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 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"]}} HTTP/1.1 OK Success Content-Length: 580 Date: Mon, 19 May 2014 17:17:45 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": " ZpHUkYxmSChwt1gNG46P0Q", "Encryption": "A128CBC", "Authentication": "HS256T128", "Ticket": " iOnMpat7APcFDGQSijDm6REK4PcFNuHM9O_nhqe_tThHb74DrdG8xYuo4EqCc70C 2gYAivVmZoO7G5J4_azh9oFOGl6eq_GgHmYs90-LGL4"}}]}} 3.3. Query Having established a connection to the service, the Initiator can make its confirmation request: Hallam-Baker November 20, 2014 [Page 14] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 2014 POST /.well-known/sxs-confirm-initiator/ HTTP/1.1 Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Session: Value=BF8p6-29_Cu9YcT9E62GLY_wwuAU2hO-EecHVaTV2R0; Id=iOnMpat7APcFDGQSijDm6REK4PcFNuHM9O_nhqe_tThHb74DrdG8xYuo4EqC c70C2gYAivVmZoO7G5J4_azh9oFOGl6eq_GgHmYs90-LGL4 Host: localhost:8080 Content-Length: 904 Expect: 100-continue { "ConfirmationRequest": { "Payload": " ewogICJNZXNzYWdlSXRlbSI6IHsKICAgICJUcmFuc2FjdGlvbklEIjogIgp3ZTg4 Q3pjY0JYUUwxWUJJSWoxcmZRIiwKICAgICJJc3N1ZSI6ICIyMDE0LTA1LTE5VDEz OjE3OjQ1WiIsCiAgICAiQWNjb3VudCI6ICJhbGljZUBleGFtcGxlLmNvbSIsCiAg ICAiVGV4dCI6ICJ7XG4gIFwiUmVxdWVzdFRleHRcIjoge1xuICAgIFwiVGl0bGVc IjogXCJDb25maXJtIEFjY2VzcyB0byBSZXN0cmljdGVkIFNpdGVcIixcbiAgICBc IlBcIjogW1wiVGhlIGFjY291bnQgYWxpY2VAZXhhbXBsZS5jb20gaGFzIHJlcXVl c3RlZCBhY2Nlc3MgdG8gdGhlIGNsYXNzaWZpZWQgc2l0ZS5cIixcbiAgICAgIFwi RG8geW91IHdpc2ggdG8gcGVybWl0IHRoaXM_XCJdLFxuICAgIFwiQnV0dG9uc1wi OiBbe1xuICAgICAgICBcIk5hbWVcIjogXCJBY3Rpb25cIixcbiAgICAgICAgXCJW YWx1ZVwiOiBcImFjY2VwdFwiLFxuICAgICAgICBcIlRleHRcIjogXCJBY2NlcHRc In0sXG4gICAgICB7XG4gICAgICAgIFwiTmFtZVwiOiBcIkFjdGlvblwiLFxuICAg ICAgICBcIlZhbHVlXCI6IFwicmVqZWN0XCIsXG4gICAgICAgIFwiVGV4dFwiOiBc IlJlamVjdFwifV19fSIsCiAgICAiQ29udGVudFR5cGUiOiAiYXBwbGljYXRpb24v anNvbiJ9fQ"}} Broker Responds: HTTP/1.1 OK Success Content-Length: 133 Date: Mon, 19 May 2014 17:17:51 GMT Server: Microsoft-HTTPAPI/2.0 { "ConfirmationResponse": { "Status": 200, "StatusDescription": "Success", "TransactionID": " Z4k3NPOD3GOpZKqSqc-mjg"}} 3.4. User Response Before she can respond to an individual message, Alice must first download her pending requests from the broker: Hallam-Baker November 20, 2014 [Page 15] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 2014 POST /.well-known/sxs-confirm-user/ HTTP/1.1 Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Session: Value=JeUQWda26LjI4vYhqNB4ltLas2yzgS1wS8m3ndKPqPo; Id=2gvt6XFinSoEOqBEJrKl7pBWy-NSNLFbEg8S8APpOu0tHWo6CIy6vOnquJn6 u9bOKw3iC8fuWVUIuZZZM6qv_qjDzlEUhRJvtRlkLdJn9dQ Host: localhost:8080 Content-Length: 25 Expect: 100-continue { "ConfirmRequest": {}} Broker Responds: HTTP/1.1 OK Success Content-Length: 80 Date: Mon, 19 May 2014 17:17:51 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] Hallam-Baker November 20, 2014 [Page 16] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 2014 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=wgkPqQsT2UpVevtPWAHZG0fyI08J_IKLtolI-ddrEnk; Id=iOnMpat7APcFDGQSijDm6REK4PcFNuHM9O_nhqe_tThHb74DrdG8xYuo4EqC c70C2gYAivVmZoO7G5J4_azh9oFOGl6eq_GgHmYs90-LGL4 Host: localhost:8080 Content-Length: 71 Expect: 100-continue { "StatusRequest": { "TransactionID": " Z4k3NPOD3GOpZKqSqc-mjg"}} Broker Responds: HTTP/1.1 OK Success Content-Length: 79 Date: Mon, 19 May 2014 17:17:51 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. Hallam-Baker November 20, 2014 [Page 17] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 2014 The UYFM transport permits low latency status reports to be made with minimal server resource use. 3.5.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. 3.5.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 Hallam-Baker November 20, 2014 [Page 18] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 2014 3.5.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 3.5.4. Message: InitiatorRequest 3.5.5. Message: InitiatorResponse Status : Integer [1..1] Status return code value StatusDescription : String [0..1] Describes the status code (ignored by processors) 4. Binding Uses SXS with the Protocol type SXS-CONFIRM for device binding 5. ConfirmationBroker 6. ConfirmationBroker 6.1. Confirmation Post a request for confirmation to a user. 6.1.1. 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. Hallam-Baker November 20, 2014 [Page 19] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 2014 ReplyTo : URI [0..1] URI of a web service to which the service MAY post an asynchronous reply using the TransactionStatus transaction. 6.1.2. Message: ConfirmationResponse TransactionID : Binary [1..1] Unique Transaction Identifier for us in subsequent StatusRequest messages. 6.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.2.1. Message: StatusRequest TransactionID : Binary [1..1] Unique Transaction Identifier returned in ConfirmationResponse message 6.2.2. Message: StatusResponse UserResponse : String [1..1] Confirmation response from the user as specified by the confirmation challenge text. 6.2.3. Message: PresentStatus UserResponse : String [1..1] Confirmation response from the user as specified by the confirmation challenge text. 6.3. Cancel 6.3.1. Message: CancelRequest TransactionID : Binary [1..1] [TBS] Hallam-Baker November 20, 2014 [Page 20] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 2014 6.4. AsyncStatus Asynchronous status update on pending transaction. 6.4.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. 6.4.2. Message: UserRequest (Implementation only, remove) Superclass that all the requests inherit from 6.4.3. Message: UserResponse Every Query Response contains the following common elements: Status : Integer [1..1] Status return code value StatusDescription : String [0..1] Describes the status code (ignored by processors) 7. ConfirmationBroker 7.1. GetMessages 7.1.1. Message: GetMessagesRequest OnOrAfter : DateTime [0..1] Before : DateTime [0..1] MaxLength : Integer [0..1] Maximum request text length in bytes Hallam-Baker November 20, 2014 [Page 21] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 2014 7.1.2. Message: GetMessagesResponse 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. Confirm 7.2.1. 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.2. Message: ConfirmResponse Reports the success or failure of the message 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:

Heading Text

Heading Hallam-Baker November 20, 2014 [Page 22] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 2014

Running text

Paragraph 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. Hallam-Baker November 20, 2014 [Page 23] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 2014 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 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 Hallam-Baker November 20, 2014 [Page 24] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 2014 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. [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. Hallam-Baker November 20, 2014 [Page 25] Internet-Draft SXS Confirmation Protocol (SXS-Confirm) May 2014 Author's Address Phillip Hallam-Baker Comodo Group Inc. philliph@comodo.com Hallam-Baker November 20, 2014 [Page 26]