Internet Engineering Task Force P. Hallam-Baker Internet-Draft Comodo Group Inc. Intended status: Standards Track June 22, 2011 Expires: December 24, 2011 Open Web Confirmation Protocol (OWCP) draft-hallambaker-owcp-00 Abstract Open Web Confirmation Protocol (OWCP) 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 December 24, 2011. Copyright Notice Copyright (c) 2011 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 Expires December 24, 2011 [Page 1] Internet-Draft Open Web Confirmation Protocol June 2011 Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Second Factor Authentication . . . . . . . . . . . . . . . 5 1.2. Confirmation vs. Authentication . . . . . . . . . . . . . 6 1.3. Use Scenarios . . . . . . . . . . . . . . . . . . . . . . 6 1.3.1. Use in Financial Services . . . . . . . . . . . . . . 6 1.3.2. Machine Binding . . . . . . . . . . . . . . . . . . . 7 1.3.3. Tethered Use . . . . . . . . . . . . . . . . . . . . . 7 1.3.4. Co-Browser . . . . . . . . . . . . . . . . . . . . . . 8 2. Description . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Parties . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.1. Accounts . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.1.1. Dispatcher Discovery . . . . . . . . . . . . . . . 9 2.1.1.2. Third Party Domain Names . . . . . . . . . . . . . 9 2.1.1.3. Open and Closed Services . . . . . . . . . . . . . 10 2.1.2. User Experience . . . . . . . . . . . . . . . . . . . 10 2.1.2.1. Dispatcher Subscription . . . . . . . . . . . . . 10 2.1.2.2. Registration . . . . . . . . . . . . . . . . . . . 10 2.1.2.3. Requestor Subscription . . . . . . . . . . . . . . 11 2.1.2.4. Confirmation . . . . . . . . . . . . . . . . . . . 11 2.1.3. Examples of Use [Non Normative] . . . . . . . . . . . 11 2.1.3.1. Access Control . . . . . . . . . . . . . . . . . . 11 2.1.3.2. Payment . . . . . . . . . . . . . . . . . . . . . 13 2.1.3.3. Ticket and Transaction Acknowledgement . . . . . . 15 3. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 15 3.1. Common Format . . . . . . . . . . . . . . . . . . . . . . 16 3.1.1. Request . . . . . . . . . . . . . . . . . . . . . . . 16 3.1.2. Response . . . . . . . . . . . . . . . . . . . . . . . 16 3.2. Requestor to Dispatcher . . . . . . . . . . . . . . . . . 17 3.2.1. Operation RD-Confirm . . . . . . . . . . . . . . . . . 18 3.2.1.1. RD-Confirm Request . . . . . . . . . . . . . . . . 18 3.2.1.2. RD-Confirm Response . . . . . . . . . . . . . . . 19 3.2.2. Operation RD-Register . . . . . . . . . . . . . . . . 19 3.2.2.1. RD-Register Request . . . . . . . . . . . . . . . 19 3.2.2.2. RD-Register Response . . . . . . . . . . . . . . . 19 3.2.3. Operation RD-Deregister . . . . . . . . . . . . . . . 20 3.2.3.1. RD-Deregister Request . . . . . . . . . . . . . . 20 3.2.3.2. RD-Deregister Response . . . . . . . . . . . . . . 20 3.2.4. Operation RD-Status . . . . . . . . . . . . . . . . . 20 3.2.4.1. RD-Status Request . . . . . . . . . . . . . . . . 20 3.2.4.2. RD-Status Response . . . . . . . . . . . . . . . . 20 3.2.5. Operation RD-Final . . . . . . . . . . . . . . . . . . 20 3.2.5.1. RD-Final Request . . . . . . . . . . . . . . . . . 20 3.2.5.2. RD-Final Response . . . . . . . . . . . . . . . . 20 3.3. Dispatcher to Requestor . . . . . . . . . . . . . . . . . 21 3.3.1. Operation DR-Complete . . . . . . . . . . . . . . . . 21 3.3.1.1. DR-Complete Request . . . . . . . . . . . . . . . 21 Hallam-Baker Expires December 24, 2011 [Page 2] Internet-Draft Open Web Confirmation Protocol June 2011 3.3.1.2. DR-Complete Response . . . . . . . . . . . . . . . 21 3.4. Client to Dispatcher . . . . . . . . . . . . . . . . . . . 21 3.4.1. Operation CD-Register . . . . . . . . . . . . . . . . 22 3.4.1.1. CD-Register Request . . . . . . . . . . . . . . . 22 3.4.1.2. CD-Register Response . . . . . . . . . . . . . . . 22 3.4.2. Operation CD-Deregister . . . . . . . . . . . . . . . 22 3.4.2.1. CD-Deregister Request . . . . . . . . . . . . . . 22 3.4.2.2. CD-Deregister Response . . . . . . . . . . . . . . 23 3.4.3. Operation CD-List . . . . . . . . . . . . . . . . . . 23 3.4.3.1. CD-List Request . . . . . . . . . . . . . . . . . 23 3.4.3.2. RD-List Response . . . . . . . . . . . . . . . . . 23 3.4.4. Operation CD-Reply . . . . . . . . . . . . . . . . . . 23 3.4.4.1. CD-Reply Request . . . . . . . . . . . . . . . . . 23 3.4.4.2. CD-Reply Response . . . . . . . . . . . . . . . . 24 4. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 24 4.1. ESRV Discovery . . . . . . . . . . . . . . . . . . . . . . 24 4.1.1. ESRV Properties . . . . . . . . . . . . . . . . . . . 24 4.2. Manual Discovery . . . . . . . . . . . . . . . . . . . . . 24 5. Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1. HTTP/JSON Binding . . . . . . . . . . . . . . . . . . . . 25 5.1.1. Transport . . . . . . . . . . . . . . . . . . . . . . 25 5.1.2. HTTP Encapsulation . . . . . . . . . . . . . . . . . . 25 5.1.3. Binary Multipart Container . . . . . . . . . . . . . . 25 5.1.3.1. Data Segment Format . . . . . . . . . . . . . . . 25 5.1.3.2. Data Section Format . . . . . . . . . . . . . . . 26 5.1.4. JSON Object Syntax . . . . . . . . . . . . . . . . . . 27 6. Request Schema . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 27 6.2. Request . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.3.
. . . . . . . . . . . . . . . . . . . . . . . . . 28 6.3.1. and . . . . . . . . . . . . . . . . . . . 29 6.3.2. . . . . . . . . . . . . . . . . . . . . 29 6.3.3. . . . . . . . . . . . . . . . . . . . . . . 30 6.3.4. . . . . . . . . . . . . . . . . . . . . . 30 6.4. . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.4.1.

. . . . . . . . . . . . . . . . . . . . . . . . . 31 6.4.2. . . . . . . . . . . . . . . . . . . . . . . 31 6.5. . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.5.1. . . . . . . . . . . . . . . . . . . . . 33 6.6.
and
. . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.7. Text . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.7.1. . . . . . . . . . . . . . . . . . . . . . . . 34 6.7.2. , and . . . . . . . . . . . . . . . . . . . 34 6.8. End . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7. Internationalization Considerations . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Hallam-Baker Expires December 24, 2011 [Page 3] Internet-Draft Open Web Confirmation Protocol June 2011 10.1. Normative References . . . . . . . . . . . . . . . . . . . 36 10.2. Non Normative References . . . . . . . . . . . . . . . . . 36 Appendix A. Collected Schema . . . . . . . . . . . . . . . . . . 36 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 Hallam-Baker Expires December 24, 2011 [Page 4] Internet-Draft Open Web Confirmation Protocol June 2011 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, OWCP is designed for implementation on a device that has at least the capabilities of a modern 'smartphone'. In particular an OWCP 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 Expires December 24, 2011 [Page 5] Internet-Draft Open Web Confirmation Protocol June 2011 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.3.1. 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 Hallam-Baker Expires December 24, 2011 [Page 6] Internet-Draft Open Web Confirmation Protocol June 2011 reciepients but require use of the second factor confirmation device for a high risk transaction such as paying a bill. 1.3.2. 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.3.3. Tethered Use Although OWCP 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 OWCP 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 OWCP to authenticate and track all changes to critical resources. Since OWCP is itself a network resource a bootstrap consideration arises: How can Carol confirm her network configuration requests using OWCP when the network itself is down? Support for a tethered mode in which the OWCP 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 OWCP is to be used in certain applications, support for this feature outside the scope of this version of the specification. Hallam-Baker Expires December 24, 2011 [Page 7] Internet-Draft Open Web Confirmation Protocol June 2011 1.3.4. Co-Browser While OWCP 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. Description OWCP is a Web Service that permits a Requestor 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 OWCP protocol interaction takes place between a connection pair of the following parties: A party that initiates a confirmation request. A clearing house that stores and forwards requests from requestors and responses from Clients. The dispatcher is only trusted to perform routing filtering and recording of requests and responses. The dispatcher is not trusted with respect to the responses returned. A Dispatcher Service MAY impose a use policy on Requestors, Clients and Users. Issue and maintenance of Client Device credentials is a trusted function that is logically independent of the store and forward operation of the Dispatcher. The Client interacts with the User and the Dispatcher. If Dispatcher policy permits, a User MAY register multiple Devices to Hallam-Baker Expires December 24, 2011 [Page 8] Internet-Draft Open Web Confirmation Protocol June 2011 serve as confirmation devices for the same account. In this case each Device MUST have a separate signature key. The User is the person being asked to grant or refuse confirmation. A User MAY have multiple accounts with multiple Dispatcher Services. +-------------+ +------------+ +-------------+ | Requestor | <-----> | Dispatcher | <------ | Client | +-------------+ +------------+ +-------------+ ^ ^ | | V V +------------+ +-------------+ | PKI | | User | +------------+ +-------------+ 2.1.1. Accounts Users and Requestors 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 dispatcher. 2.1.1.1. Dispatcher Discovery The domain component of the account identifier is the DNS name of the corresponding Dispatcher Web Service. DNS Service discovery is used by Requestors and Clients to discover the Dispatcher service corresponding to a specified account. 2.1.1.2. Third Party Domain Names OWCP requires that the provider of a Dispatcher service have control over the DNS names used in the corresponding account identifiers. It is thus not possible for any party other than the holder of the domain name example.com to provide OWCP service for alice@example.com. If Alice, the holder of the alice@example.com Hallam-Baker Expires December 24, 2011 [Page 9] Internet-Draft Open Web Confirmation Protocol June 2011 email address wishes to use an OWCP confirmation service, her choices are limited to persuading the holder of example.com to provide an OWCP dispatcher service and allow her to use her email identifier or registering with another confirmation service provider and accepting a different identifier. Requiring a strong binding between the Dispatcher service and the account identifier permits the use of the account identifier to be used as a proxy for authorization. 2.1.1.3. Open and Closed Services An OWCP service MAY be Open or Closed. An Open service provider provides OWCP 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 OWCP service as a part of their standard service offering to customers. An employer might operate a closed OWCP service to be used for company business. 2.1.2. User Experience Since the purpose of OWCP is to support user interaction, the user experience is an important part of the OWCP specification. While the realization of the User Experience is outside the scope of the specification, the specification will inevitably constrain the User Experiences that an implementer can provide. 2.1.2.1. Dispatcher Subscription Dispatcher Subscription is the procedure whereby a User creates an account with a new account identifier. OWCP Dispatcher Subscription is equivalent to establishing an account for email or for computer access. 2.1.2.2. Registration To make use of a Client, A User must register it for use with at least one OWCP account. If the User is attempting to register a Client for use with an existing account, the registration request SHOULD be authenticated to ensure that the it comes from the authorized account holder. A One Time Use authentication code or a confirmation from a device that has already been registered MAY be used for this purpose. Hallam-Baker Expires December 24, 2011 [Page 10] Internet-Draft Open Web Confirmation Protocol June 2011 A Client MAY support a mode in which the Dispatcher Subscription procedure is combined with registration. In this case the Dispatcher service policy MAY permit registration without additional authentication if the account has never existed before. 2.1.2.3. Requestor Subscription To make use of OWCP with a requestor, a User simply provides their OWCP account identifier. In the case that the OWCP account identifier is also the email address supplied when the User established an account with the Requestor, the Requestor MAY perform the subscription process automatically. 2.1.2.4. Confirmation In the typical case, use of the Confirmation service is triggered by a User request to the Requestor or an event that requires the User's attention. For example: Alice attempts to access the personnel file causing the access control system to generate a confirmation request that is received on Alice's mobile device. Alice accepts the confirmation and access is granted. For example: Bob is working as a network manager and the datacenter cooling system has started leaking. He attempts to engage an emergency plumming service which in turn requires authorization from Carol, the Finance Director. 2.1.3. Examples of Use [Non Normative] For clarity, only the XML Message component of the requests are shown. The HTTP Headers and CMS packaging is omitted. 2.1.3.1. Access Control Alice (alice@example.com) is an employee of Example Corp. She is attempting to log into the corporporate network from the laptop (#234) issued by her employer. When Alice attempts to connect to the VPN, the VPN generates the following request and sends it to the Dispatcher service that services example.com: Hallam-Baker Expires December 24, 2011 [Page 11] Internet-Draft Open Web Confirmation Protocol June 2011
access@example.com alice@example.com PIN Do you wish to connect to the corporate network from Laptop #234 issued to Alice?
If Alice's mobile device supports a notification service this MAY be used to alert Alice to the fact that a new confirmation request is pending. Alternatively, Alice picks up her mobile device and starts the confirmation client manualy. In either case, Alice is shown the following dialog: From: access@example.com To: alice@example.com Do you wish to connect to the corporate network from Laptop #234 issued to Alice? [Accept] [Reject] Since the request specifies PIN verification, Alice is asked to provide her PIN before a response can be generated. Note that the PIN MUST be supplied regardless of whether the action is accepted or rejected. Alice accepts the request and the client generates a receipt message that contains the original request message and Alice's response. The receipt message is then digitally signed using a signature key that is unique to the account, device and the client. [TBS response] The reciept is sent to the dispatcher which forwards at least the result of the request to the Requestor. In this case the Requestor is trusted to receive digitally signed Hallam-Baker Expires December 24, 2011 [Page 12] Internet-Draft Open Web Confirmation Protocol June 2011 responses for the specific action requested and the original request and signature is forwarded to the Requestor. 2.1.3.2. Payment A confirmation service MAY be used to support payment transactions. In this use case there is often a need to present the User with both a high level summary of the action being requested and a more detailed description. The following message asks Alice if she wishes to transfer a sum of money to a person she met in an Internet chat room. Hallam-Baker Expires December 24, 2011 [Page 13] Internet-Draft Open Web Confirmation Protocol June 2011
access@example.com alice@example.com PIN Do you wish to transfer to the account of Barrister Mugu #666-201919 at Bank of Nigeria?

Form of transfer: Wire

Item Amount
Expeditiary Fee
In this case Alice (wisely) declines the request. [TBS response] Hallam-Baker Expires December 24, 2011 [Page 14] Internet-Draft Open Web Confirmation Protocol June 2011 2.1.3.3. Ticket and Transaction Acknowledgement In the case that the confirmation service is used to authenticate a purchase for non-tangible goods, it is in some cases convenient to deliver the goods themselves through the confirmation service client. In this case the receipt is also the ticket. Alice purchases tickets for a concert tour. The ticket and the instructions to find her seat are returned to her through the confirmation service. The Requestor sends the following message to the dispatcher:
concerts@example.com alice@example.com Tickets for Spinal Tap Reonion Tour DC 24th June Seats A15+A16

This is your ticket.

Present the barcode to the barcode reader at the turnstile.

When Alice receives the message on her mobile device it displays a 2D barcode that can be read at the turnstile. Alice gains admission to the concert without the need to queue at the ticket booth. 3. Protocol Messages OWCP protocol messages are defined here in an abstract form to permit them to be expressed in different protocol bindings. OWCP 0.1 services MUST support the HTTP+CMS binding defined in section []. Hallam-Baker Expires December 24, 2011 [Page 15] Internet-Draft Open Web Confirmation Protocol June 2011 OWCP messages MUST be exchanged over an encrypted, authenticated transport such as TLS or IPSEC. OWCP 0.1 services MUST support use of TLS transport. Since the function of the Dispatcher is to store and forward messages, a sequence of OWCP messages will always be initiated by either a Requestor or a Client. 3.1. Common Format 3.1.1. Request All OWCP request messages specify an operation code. The following parameters are common to all requests. Transaction [Transaction Identifier][Required] The transaction identifier is unique for all requests except for RD-Status, RD- Final and DR-Complete in which case the transaction identifier of the original transaction for which status is being requested is used. Certificate Chain [Attachment][Optional] Certificate chain for the public key used in the Signature. Authentication [Authentication Code][Optional] Digital Signature or Message Authentication Code of the Request. 3.1.2. Response All responses return a response code. The following response codes are defined: 200 Success The operation succeeded and the result of the operation is returned. 303 Incomplete The operation requested by the Requestor has not completed and the result of the operation will be returned asynchronously. 400 Bad Request 401 Unauthorized The Requestor or Client is not permitted to perform the requested operation.. Hallam-Baker Expires December 24, 2011 [Page 16] Internet-Draft Open Web Confirmation Protocol June 2011 404 Not Found The requested User account or Transaction ID was not found. 408 Timeout The requested operation did not complete in the specified time or status was requested for a transaction that has expired. In addition an OWCP service MAY return any error or status code defined by the protocol binding and/or the transport layer. The following parameters are common to all responses: Transaction [Transaction Identifier][Required] The transaction identifier of the original request. Note that the transaction identifier is a required parameter for the protocol even though its value might be implicit from the context in many protocol bindings (e.g. HTTP). This is necessary to ensure that the authentication of the response also covers the request. Certificate Chain [Attachment][Optional] Certificate chain for the public key used in the Signature. Authentication [Authentication Code][Optional] Digital Signature or Message Authentication Code of the Request. Request-Link [Digest][Optional] Message Digest of the Request. This is only relevant when a response is digitally signed and allows the response to be cryptographically linked to the original request. 3.2. Requestor to Dispatcher Operations initiated by the Responder are logically a single request followed by a single response but may take longer to complete than it is desiable for the Responder to wait for a status code. Support for asynchronous completion is therefore necessary. If the Dispatcher is unable to complete an operation immediately it MUST return the Incomplete response code. A Responder MAY recover the result of an incomplete operation by polling using the STATUS operation or by accepting asynchronous completion by means of the Complete operation. In order to accept asynchronous completion of a request, a dispatcher specifies the Hallam-Baker Expires December 24, 2011 [Page 17] Internet-Draft Open Web Confirmation Protocol June 2011 Dispatchers MUST support completion of incomplete operations by use of the polling mechanism and MAY support asynchronous completion by means of the Complete operation. +------------+ +-------------+ | Requestor | ....... | Dispatcher | +------------+ +-------------+ Request ------> Resonse <------ [Complete] <------ [Acknolwedge] ------> The following parameters are common to all RD-Operation requests: Reply-To [DNS Name][Optional] DNS Name of a server that will accept completion of the request via the DR-Complete operation. Expiry [Date Time][Optional] A date and time beyond which the result of the request is no longer relevant. A Dispatcher MAY refuse to recognize the expiry term requested by Requestor and impose its own limit which MAY be shorter or longer. A Responder SHOULD NOT rely on an expiry time of less than ten minutes for any operation that requires User interaction. Machines should serve people, not the other way round. 3.2.1. Operation RD-Confirm The RD-Confirm operation is used to present a confirmation request to the User with the Dispatcher and Client(s) acting as intermediaries. 3.2.1.1. RD-Confirm Request The RD-Confirm request takes the following parameters: Registration [Registrarion Identifier][Optional] Registration identifier assigned by the Dispatcher to represent the Dispatcher- Responder relationship in a prior Registration operation. Hallam-Baker Expires December 24, 2011 [Page 18] Internet-Draft Open Web Confirmation Protocol June 2011 Expiry [Date Time][Optional] Date and Time at which the confirmation request will expire. Message [Attachment/XML][Optional] The Confirmation request message formatted according to the XML schema specified in section [XXX] 3.2.1.2. RD-Confirm Response Reply [Attachment/XML][Optional] The Confirmation response message formatted according to the XML schema specified in section [XXX] 3.2.2. Operation RD-Register The RD-Register operation allows a Requestor to pre-register with a Dispatcher. This allows the Responder to check that it is likely to be able to use the confirmation service before relying on it. The RD-Register operation is essentially a confirmation request without the actual confirmation. Use of the RD-Register operation is optional according to the OWCP protocol but MAY be required by the dispatcher policy. 3.2.2.1. RD-Register Request Operation Code: RD-Register Responder [Account Identifier][Optional] The account identifier the responder is attempting to register. This is only required in cases where the dispatcher needs to check the responder account against the certificate chain. User [Account Identifier][Optional] The account identifier a specific user that the responder is attempting to register. If no account is specified the Responder is attempting to register for all accounts. 3.2.2.2. RD-Register Response Registration [Registrarion Identifier][Required] Registration identifier assigned by the Dispatcher to represent the Dispatcher- Responder relationship. Scope [Scope][Optional] If the Scope is specified as 'User', the registration is accepted for that specific user alone. If the scope is specified as 'global' the registration is applies to all User accounts held by the dispatcher. Hallam-Baker Expires December 24, 2011 [Page 19] Internet-Draft Open Web Confirmation Protocol June 2011 Policy [Attachment/XML][Optional] Dispatcher policy statement. 3.2.3. Operation RD-Deregister The RD-Deregister operation cancels a previous registration request. 3.2.3.1. RD-Deregister Request Operation Code: RD-Deregister Registration [Registrarion Identifier][Required] Registration identifier assigned by the Dispatcher to represent the Dispatcher- Responder relationship in the original RD-Register operation. 3.2.3.2. RD-Deregister Response No additional data is returned if the operation succeeds 3.2.4. Operation RD-Status The operation RD-Status is used to request the result of an earlier request made by that Responder. 3.2.4.1. RD-Status Request No additional parameters are specified. 3.2.4.2. RD-Status Response If successful the RD-Status response returns the parameters defined for the original transaction request. 3.2.5. Operation RD-Final The operation RD-Final is used to request the result of an earlier request made by that Responder and cancel the request if it has not yet completed. 3.2.5.1. RD-Final Request No additional parameters are specified. 3.2.5.2. RD-Final Response If the original operation completed successfully, the RD-Final response returns the parameters defined for the original transaction request. Hallam-Baker Expires December 24, 2011 [Page 20] Internet-Draft Open Web Confirmation Protocol June 2011 If the Dispatcher accepts the request to attempt to cancel the operation the response code 408 Timeout is returned. But returning this response code in an RD-Final response does not guarantee that the operation will not be completed subsequently. 3.3. Dispatcher to Requestor The only circumstance in which a Dispatcher initiates a protocol exchange is when it is providing an asynchronous completion response for a previous request. 3.3.1. Operation DR-Complete The DR-Complete operation returns the result of a previously requested operation for which an Incomplete status was returned. 3.3.1.1. DR-Complete Request The request contains the result of the original response: Status [Response Code][Required] The response code of the request. If the operation was successful, the DR-Complete response returns the parameters defined for the original transaction request. 3.3.1.2. DR-Complete Response No additional parameters are specified. 3.4. Client to Dispatcher Protocol exchanges between the Dispatcher and the Client consist of a single request from the Client followed by a single response from the Dispatcher. +------------+ +-------------+ | Dispatcher | ....... | Client | +------------+ +-------------+ Request <------ Resonse ------> Hallam-Baker Expires December 24, 2011 [Page 21] Internet-Draft Open Web Confirmation Protocol June 2011 3.4.1. Operation CD-Register The CD-Register operation is used to register a Client to a Dispatcher. 3.4.1.1. CD-Register Request The CD-Register request specifies the following parameters: Account [Account Identifier][Required] Account identifier for the account being requested. Passphrase [String][Optional] Optional Passphrase value that MAY be used by the Dispatcher to authenticate the registration request. Key [Attachment][Required] Key to be used to authenticate messages from the client to the Dispatcher. Client [Client Identifier][Optional] Client identifier returned in a previous registration request. The client identifier is only specified by a client in the case of a rekeying operation. 3.4.1.2. CD-Register Response The CD-Register response specifies the following parameters: Client [Client Identifier][Optional] Identifier that the Client MUST use in future interactions with the dispatcher under this account. 3.4.2. Operation CD-Deregister The CD-Deregister operation is used to unregister a previously registered Client. Note that a Client may also be deregistered through other, out of band mechsanisms. For example through an account management interface for the account. 3.4.2.1. CD-Deregister Request The Deregister request specifies only the client identifier. Hallam-Baker Expires December 24, 2011 [Page 22] Internet-Draft Open Web Confirmation Protocol June 2011 Client [Client Identifier][Optional] Client identifier. 3.4.2.2. CD-Deregister Response The Deregister response only reports success or failure. [TBS Should it tell the user that they have other devices?] 3.4.3. Operation CD-List The CD-List operation is used to request that the Dispatcher return all pending confirmations. 3.4.3.1. CD-List Request The CD-List request takes the following parameters: Client [Client Identifier][Required] Registration identifier assigned by the Dispatcher to represent the Client-Responder relationship in a prior Registration operation. Since [Transaction Identifier][Optional] If specified directs the server to only return confirmation messages recieved since the specified transaction identifier. 3.4.3.2. RD-List Response If successful, the CD-List response takes the following parameters: Now [Transaction Identifier][Optional] Specifies an identifier that the client can specify in a request to indicate that the Requests [Attachment/Multipart][Required] A sequence of confirmation requests packaged as a multipart object. 3.4.4. Operation CD-Reply The CD-Reply Operation is used by the client to notify the Dispatcher that the user has responded to a confirmation request. 3.4.4.1. CD-Reply Request The CD-Reply Request specifies the transaction identifier of the confirmation for which a reply is being given and a response value. Hallam-Baker Expires December 24, 2011 [Page 23] Internet-Draft Open Web Confirmation Protocol June 2011 Transaction [Transaction Identifier][Required] The transaction identifier being responded to. Response [String][Required] The response value. 3.4.4.2. CD-Reply Response The CD-Reply operation only returns a status code value. No additional parameters are returned. [TBS May want to revist this. Wouldn't a client want to be able to confirm that an asyn completion has in fact been delivered?] 4. Service Discovery Requestors and Clients discover the client using DNS service discovery. 4.1. ESRV Discovery Requestors and Clients MUST support the ESRV discovery Mechanism and the SRV and URI extended discovery mechanisms. 4.1.1. ESRV Properties ESRV properties permit clients and servers to negotiate service protocol and properties such as the protocol version and/or protocol binding. 4.2. Manual Discovery ESRV service discovery depends on support for new DNS Resource Record types at the DNS Resolver used. Clients SHOULD and Requestors MAY support manual configuration of the Dispatcher service. Manual configuration does not provide the support for redundancy or fault tolerance provided in the ESRV discovery mechanism. 5. Bindings The abstract OWCP protocol is mapped to the wire-transport by means of a binding. Currently only one binding is defined. OWCP Responders and Dispatchers MUST support the HTTP/JSON binding and MAY support other bindings. Hallam-Baker Expires December 24, 2011 [Page 24] Internet-Draft Open Web Confirmation Protocol June 2011 OWCP Clients SHOULD support the HTTP/JSON binding and MAY support other bindings. 5.1. HTTP/JSON Binding The HTTP/JSON binding is designed to permit efficient implementation of an OWCP Requestor or Dispatcher without the need for XML support beyond the ability to generate Confirmation messages. 5.1.1. Transport 5.1.2. HTTP Encapsulation The service discovery process returns the Web Service Endpoint og the OWCP service as a URI. OWCP requests are mapped to HTTP Requests as follows: Method The request method is always POST. Request URI The request URI consists of the web service endpoint concatenated with a '/' character concatenated with the OWCP operation code. Content-Encoding The Content Encoding type MUST be either "8bit" or "Binary". Content The content of the request message is a Binary Multipart Container in which the first data segment MUST be the JSON parameter block. 5.1.3. Binary Multipart Container An OWCP message typically contains X.509 certificate chains, XML data objects and other data objects most suitably exchanged in binary form. The Binary Multipart representation is used to encapsulate the message parameter object and related attachments as binary objects. A Binary Multipart Container consists of a sequence of data segments. 5.1.3.1. Data Segment Format A Data Segment consists of a sequence of a segment type identifier followed by a sequence of sections as specified by the segment type identifier. Hallam-Baker Expires December 24, 2011 [Page 25] Internet-Draft Open Web Confirmation Protocol June 2011 Indicates that a parameter label item is present. Indicates that a MIME Content-Type item is present. Indicates that an Identifier is present. Indicates that a Data section is present. Indicates that an Object Digest Identifier of the Data section is present. Reserved for future use. If set the data segment is the final segment in the container. Otherwise at least one more data segment follows. 5.1.3.2. Data Section Format Data sections are presented in the same order as the segment type identifier bits starting with the low order bit. Each data section consists of a length specifier followed by the corresponding data. ASN.1 length encoding format is used to represent the length specifier. For length values less than 128 octets, the length is represented as a single octet and consists of the length value. For longer lengths, the high order bit of the first order octet is 1 and the remaining 7 bits specify the number of octets following used to specify the length. For example: A data segment that contains a MIME Content-Type section and a Data section will have the segment type specifier 5 (00000101 in binary). The first section will contain the Content-Type and the Second section the Data value. Contrary to the practice in ASN.1 DER encoding, the length specifier MAY contain leading zeros. Thus the octet sequence '0x13', the octext sequence '0x11 0x13' and the octet sequence '0x14 0x00 0x00 0x00 0x13' are all valid and each specifies that the length of the following data is 19 octets. Hallam-Baker Expires December 24, 2011 [Page 26] Internet-Draft Open Web Confirmation Protocol June 2011 5.1.4. JSON Object Syntax OWCP data objects are encoded using the JSON syntax [TBS]. The correspondance between OWCP data types and JSON object types is given below: [TBS] 6. Request Schema 6.1. Namespace The OWCP Request schema is defined in W3C XML Schema notation. The version specified in this document has the following namespace assigned: XML Namespace: http://schema.comodo.com/2011/owcp/0.1 6.2. Request The element The element contains the following sequence of elements:
The following XML Schema declares the element: Hallam-Baker Expires December 24, 2011 [Page 27] Internet-Draft Open Web Confirmation Protocol June 2011 6.3.
The
element The
element contains the following attributes and sequence of elements: issued [Required] identifier [Required] type [Required] Reference* [Optional] Identifier of previous confirmation messages that this confirmation message is cross-referenced to. The following XML Schema declares the
element: Hallam-Baker Expires December 24, 2011 [Page 28] Internet-Draft Open Web Confirmation Protocol June 2011 6.3.1. and The and elements The and elements are of type string. The following XML Schema declares the element: 6.3.2. The element The element is of type string and contains an OWCP verification mechansim identifier as registered by IANA. [TBS extensions by RFC] The following Verification methods are initially defined: PIN GPS Photo Voice If a client encounters an unknown Verification element, the request MUST be refused with the error return 'Unknown Verification Type'. [TBS: Should it be possible to specify Verification mechanisms as being required/optional or can this be handled in the negotiation profile?] The following XML Schema declares the element: Hallam-Baker Expires December 24, 2011 [Page 29] Internet-Draft Open Web Confirmation Protocol June 2011 6.3.3. The element The element is of type TextType and contains formatted text as described below. The following XML Schema declares the element: 6.3.4. The element The element is of type string. The following XML Schema declares the element: 6.4. The element The element:

The following XML Schema declares the element: Hallam-Baker Expires December 24, 2011 [Page 30] Internet-Draft Open Web Confirmation Protocol June 2011 6.4.1.

The

element The

element is of type TextType and contains formatted text as described below.: The following XML Schema declares the

element: 6.4.2. The <> element In order to minimize the complexity of the client while maximizing the range of barcode formats that can be supported, the barcode is represented as a bitstring corresponding to the values of pixels in a grid of the specified size. Note that this mechanism is NOT intended to provide a mechanism for display of arbitrary images. While the format described is capable of supporting the most comonly used 1D and 2D barcode formats, support for arbitrary formats is considered to be a non-requirement. The low order bit (0) of the first octect in the bitstream corresponds to the top left corner of the barcode image which is by definition the origin. A bit value of 1 corresponds to a black pixel and a bit value of 0 to a white pixel. The next bit, bit 1 corresponds to the pixel immediately to the right of the origin and so on. Octects are read from the bitstream as needed. Until the entire first row of pixels is presented. The low order bit of the next octet in the bitstream represents the pixel immediately below the origin and so on for the remainder of the row. A QR code Version 4 barcode is displayed in a 33x33 grid of pixels. Thus the bitstream representation of such a bitstream will require 5 octets per row for each of the 33 rows, a total of 155 octets. Hallam-Baker Expires December 24, 2011 [Page 31] Internet-Draft Open Web Confirmation Protocol June 2011 [TBS: decide whether this is acceptable and if it may lead to GIF abuse type issues with the barcode being used as a substitute for an icon.] The <> element: width height data The following XML Schema declares the element: 6.5.

The
element The
element: The following XML Schema declares the
element: Hallam-Baker Expires December 24, 2011 [Page 32] Internet-Draft Open Web Confirmation Protocol June 2011 6.5.1. The element The elements are of RowType and may contain the following element: elements: 6.6.
and
and
and
The following XML Schema declares the and
The element is of type TextType and MAY contain formatted text content. The following XML Schema declares the element: 6.7. Text The

and

elements are used to present free form text. Each of these elements are of the type TextType which is the only type of mixed content in the OWCP message markup. An element of type TextType MAY contain the following content and elements: Text data. elements used to represent quantities of money. elements used to highlight regions of the text with bold font. Hallam-Baker Expires December 24, 2011 [Page 33] Internet-Draft Open Web Confirmation Protocol June 2011 elements used to highlight regions of the text with italic font. elements used to highlight regions of the text with underlining. The following XML Schema declares the TextType: 6.7.1. The element is used to specify a sum of money in a specified currency within an element of type TextType. This permits the client to assit the user by providing an instant conversion into the currency of the user's choice. The following attributes are defined for the element: currency [Required] The ISO 4217 currency code for the amount specified. amount [Required] The amount specified in the currency indicated. The following XML Schema declares the element: 6.7.2. , and The , and elements are used to identify spans of text to be presented with Bold, Italic and Underline emphasis respectively. Each element is of type TextType and permit the same content to be Hallam-Baker Expires December 24, 2011 [Page 34] Internet-Draft Open Web Confirmation Protocol June 2011 used inside the element as is permitted in the enclosing element. The following XML Schema declares the , and elements: 6.8. End The following XML Schema completes the OWCP schema declarations: 7. Internationalization Considerations Might want to consider how a requestor can attempt to provide a request that is presented in a language that the requestor understands. Any such feature would have to be presented outside the XML Request message format since this needs to be kept as clean and compact and with as little room for ambiguity as possible. 8. Security Considerations Consider spam control, how do users prevent unwanted requests? (EV accreditatio, filtering at dispatcher) People deploying OWCP as a means of controlling access to networking infrastructure must consider the bootstrap issue. In particular since OWCP requires Internet access the network administrator must ensure that it is possible to manage the network resources necessary to support an OXCP service when that service is down. 9. IANA Considerations Mention the following: Registry of barcode encoding types (QR/DataMatrix/Bitfield) Register Schema URI Hallam-Baker Expires December 24, 2011 [Page 35] Internet-Draft Open Web Confirmation Protocol June 2011 Mime type for OWCP message? 10. References 10.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. 10.2. Non Normative References [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA Considerations", RFC 5395, November 2008. Appendix A. Collected Schema Hallam-Baker Expires December 24, 2011 [Page 36] Internet-Draft Open Web Confirmation Protocol June 2011 Hallam-Baker Expires December 24, 2011 [Page 37] Internet-Draft Open Web Confirmation Protocol June 2011 Author's Address Phillip Hallam-Baker Comodo Group Inc. Email: philliph@comodo.com Hallam-Baker Expires December 24, 2011 [Page 38]