| Internet Engineering Task Force | P. M. 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
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.
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 (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.
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.
Second factor authentication mechanisms offer greater security over the use of passwords alone by combining a first factor (typically a password) with a biometric or proof of possession of a physical token.
Traditional second factor authentication techniques have suffered from the need to distribute physical tokens and the difficulty of ensuring that a biometric authentication is presented to a trustworthy terminal.
The usability of traditional second factor authentication techniques has been poor or worse. Even the simplest scheme in which the user is required to read in a 'one time use' numeric code from the authentication token device and enter it into a password field. While such operations are relatively simple they require the user to engage in a sequence of operations that bears no necessary or natural relationship to the underlying task for which the authentication is required.
Nor does the act of engaging in a traditional second factor scheme offer proof of anything other than that the user was authenticated. Any correspondence between the act of authentication and the purpose for which the authentication was provided must be maintained separately.
A second factor confirmation service addresses the limitations of traditional second factor authentication schemes.
A confirmation service allows the user experience to be precisely matched to the action that the user is attempted. Instead of beinf asked to read a random number from one device and enter it into another, the user is asked if they really want to perform the action for which authentication is requested.
A confirmation service offers better accountability for end users than a traditional authentication service. An authentication service only provides an assertion that the user was present. A confirmation service provides an assertion that the user was present and that they confirmed a specific transaction.
For example, Alice has been granted access to a machine storing classified data. If an authentication service is used for access control, the authentication service log will only record the dates and times that Alice accessed the system. to find out if Alice accessed a particular file on a particular day it is necessary to consult and correlate both the authentication log of the system and the activity log for the application.
If instead a confirmation service is used the confirmation log contains an authenticated record of both the authentication events and the transactions for which the authentication was requested.
A confirmation service complements rather than replaces a traditional authentication scheme. Providing a highly secure and convenient means of authenticating requests that carry a high degree of risk mitigates the risk of using convenient but intrinsically low security techniques for other actions.
If an attacker is to profit from breaching a an account with a financial service such as a bank or a brokerage they must find a way to move money out of the account. Thus adding bill payment recipients, initiating wire transfers and trading in low volume 'penny stocks' represent high risk activities.
For example: Bank of Ethel might permit customers to use a simple username and password scheme to gain access to their account for the purpose of checking their balance or paying bills to existing reciepients but require use of the second factor confirmation device for a high risk transaction such as paying a bill.
A second factor confirmation service may be combined with a machine level authentication scheme to permit a transparent form of authentication for low risk transactions.
For example: Alice stores her low risk authentication credentials (e.g usernames and passwords) using a 'cloud' service. When she wishes to use those credentials an agent on her personal machine fetches credentials from the cloud service as necessary. When Alice wishes to access a site from a different machine she receives a confirmation request on her mobile device to grant access from that machine.
Use of such a mechanism is clearly more satisfactory when suitable cryptographic protocols such as SAML or Kerberos are employed to limit the disclosure and hence possible compromise of the credentials. The specification of such protocols is outside the scope of this document.
Although 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.
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.
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.
Each OWCP protocol interaction takes place between a connection pair of the following parties:
+-------------+ +------------+ +-------------+
| Requestor | <-----> | Dispatcher | <------ | Client |
+-------------+ +------------+ +-------------+
^ ^
| |
V V
+------------+ +-------------+
| PKI | | User |
+------------+ +-------------+
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
For clarity, only the XML Message component of the requests are shown. The HTTP Headers and CMS packaging is omitted.
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:
<?xml version="1.0" encoding="utf-8" ?>
<Request xmlns="http://schema.comodo.com/2011/owcp/0.1">
<Header issued="2011-06-08T09:30:10Z"
identifier="http://access.example.com/2737827178"
type="Access">
<From>access@example.com</From>
<To>alice@example.com</To>
<Verification>PIN</Verification>
<Summary>Do you wish to connect to the corporate network from
Laptop #234 issued to Alice?</Summary>
</Header>
</Request>
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 responses for the specific action requested and the original request and signature is forwarded to the Requestor.
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.
<?xml version="1.0" encoding="utf-8" ?>
<Request xmlns="http://schema.comodo.com/2011/owcp/0.1">
<Header issued="2011-06-08T09:30:10Z"
identifier="http://access.example.com/2737827178"
type="Payment">
<From>access@example.com</From>
<To>alice@example.com</To>
<Verification>PIN</Verification>
<Summary>Do you wish to transfer <Money currency="usd"
amount="9825.00"/> to the account of Barrister Mugu
#666-201919 at Bank of Nigeria?
</Summary>
</Header>
<Body>
<P>
Form of transfer: Wire
</P>
<Table>
<TH>
<TD>
Item
</TD>
<TD>
Amount
</TD>
</TH>
<TR>
<TD>
Expeditiary Fee
</TD>
<TD>
<Money currency="usd" amount="9825.00"/>
</TD>
</TR>
</Table>
</Body>
</Request>
In this case Alice (wisely) declines the request.
[TBS response]
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:
<?xml version="1.0" encoding="utf-8" ?>
<Request xmlns="http://schema.comodo.com/2011/owcp/0.1">
<Header issued="2011-06-08T09:30:10Z"
identifier="http://tickets.example.com/23iudi2u"
type="Acknowledgement">
<From>concerts@example.com</From>
<To>alice@example.com</To>
<Summary>
Tickets for Spinal Tap Reonion Tour DC 24th June Seats A15+A16
</Summary>
</Header>
<Body>
<P>
This is your ticket.
</P>
<P>
Present the barcode to the barcode reader at the turnstile.
</P>
<Barcode width="33" height="33" data="wusdjkw2owehofwoih=="/>
</Body>
</Request>
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.
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 [].
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.
All OWCP request messages specify an operation code.
The following parameters are common to all requests.
All responses return a response code. The following response codes are defined:
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:
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
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:
The RD-Confirm operation is used to present a confirmation request to the User with the Dispatcher and Client(s) acting as intermediaries.
The RD-Confirm request takes the following parameters:
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.
Operation Code: RD-Register
The RD-Deregister operation cancels a previous registration request.
Operation Code: RD-Deregister
No additional data is returned if the operation succeeds
The operation RD-Status is used to request the result of an earlier request made by that Responder.
No additional parameters are specified.
If successful the RD-Status response returns the parameters defined for the original transaction request.
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.
No additional parameters are specified.
If the original operation completed successfully, the RD-Final response returns the parameters defined for the original transaction request.
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.
The only circumstance in which a Dispatcher initiates a protocol exchange is when it is providing an asynchronous completion response for a previous request.
The DR-Complete operation returns the result of a previously requested operation for which an Incomplete status was returned.
The request contains the result of the original response:
If the operation was successful, the DR-Complete response returns the parameters defined for the original transaction request.
No additional parameters are specified.
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
------>
The CD-Register operation is used to register a Client to a Dispatcher.
The CD-Register request specifies the following parameters:
The CD-Register response specifies the following parameters:
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.
The Deregister request specifies only the client identifier.
The Deregister response only reports success or failure.
[TBS Should it tell the user that they have other devices?]
The CD-List operation is used to request that the Dispatcher return all pending confirmations.
The CD-List request takes the following parameters:
If successful, the CD-List response takes the following parameters:
The CD-Reply Operation is used by the client to notify the Dispatcher that the user has responded to a confirmation request.
The CD-Reply Request specifies the transaction identifier of the confirmation for which a reply is being given and a response value.
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?]
Requestors and Clients discover the client using DNS service discovery.
Requestors and Clients MUST support the ESRV discovery Mechanism and the SRV and URI extended discovery mechanisms.
ESRV properties permit clients and servers to negotiate service protocol and properties such as the protocol version and/or protocol binding.
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.
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.
OWCP Clients SHOULD support the HTTP/JSON binding and MAY support other bindings.
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.
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:
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.
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.
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.
OWCP data objects are encoded using the JSON syntax [TBS].
The correspondance between OWCP data types and JSON object types is given below:
[TBS]
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
<?xml version="1.0" encoding="utf-8"?>
<schema id="XMLSchema1"
targetNamespace="http://schema.comodo.com/2011/owcp/0.1"
elementFormDefault="qualified"
xmlns:owcp="http://schema.comodo.com/2011/owcp/0.1"
xmlns="http://www.w3.org/2001/XMLSchema">
The <Request> element
The <Request> element contains the following sequence of elements:
The following XML Schema declares the <Request> element:
<complexType name="RequestType">
<sequence>
<element ref="owcp:Header" minOccurs="1" maxOccurs="1"/>
<element ref="owcp:Body" minOccurs="0" maxOccurs="1"/>
</sequence>
</complexType>
<element name="Request" type="owcp:RequestType"/>
The <Header> element
The <Header> element contains the following attributes and sequence of elements:
The following XML Schema declares the <Header> element:
<complexType name="HeaderType">
<sequence>
<element ref="owcp:From" minOccurs="1" maxOccurs="1"/>
<element ref="owcp:To" minOccurs="1" maxOccurs="1"/>
<element ref="owcp:Verification" minOccurs="0"
maxOccurs="unbounded"/>
<element ref="owcp:Summary" minOccurs="1" maxOccurs="1"/>
<element ref="owcp:Reference" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
<attribute name="issued" type="dateTime"/>
<attribute name="identifier" type="anyURI"/>
<attribute name="type" type="string"/>
</complexType>
<element name="Header" type="owcp:HeaderType"/>
The <From> and <To> elements
The <From> and <To> elements are of type string.
The following XML Schema declares the <From> element:
<element name="From" type="string"/>
The <Verification> element
The <Verification> 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:
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 <Verification> element:
<element name="Verification" type="string"/>
The <Summary> element
The <Summary> element is of type TextType and contains formatted text as described below.
The following XML Schema declares the <Summary> element:
<element name="Summary" type="owcp:TextType"/>
The <Reference> element
The <Reference> element is of type string.
The following XML Schema declares the <Reference> element:
<element name="Reference" type="string"/>
The <Body> element
The <Body> element:
The following XML Schema declares the <Body> element:
<complexType name="BodyType">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="owcp:P" minOccurs="1" maxOccurs="1"/>
<element ref="owcp:Table" minOccurs="1" maxOccurs="1"/>
<element ref="owcp:Barcode" minOccurs="1" maxOccurs="1"/>
</choice>
</complexType>
<element name="Body" type="owcp:BodyType"/>
The <P> element
The <P> element is of type TextType and contains formatted text as described below.:
The following XML Schema declares the <P> element:
<element name="P" type="owcp:TextType"/>
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.
[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:
The following XML Schema declares the <Barcode> element:
<complexType name="BarcodeType" >
<attribute name="width" type="integer"/>
<attribute name="height" type="integer"/>
<attribute name="data" type="base64Binary"/>
</complexType>
<element name="Barcode" type="owcp:BarcodeType"/>
The <Table> element
The <Table> element:
The following XML Schema declares the <Table> element:
<complexType name="TableType">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="owcp:TH" minOccurs="1" maxOccurs="1"/>
<element ref="owcp:TR" minOccurs="1" maxOccurs="1"/>
</choice>
</complexType>
<element name="Table" type="owcp:TableType"/>
The <TH> and <TR> element
The <TH> and <TR> elements are of RowType and may contain the following element:
The following XML Schema declares the <TH> and <TR> elements:
<complexType name="RowType">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="owcp:TD" minOccurs="1" maxOccurs="1"/>
</choice>
</complexType>
<element name="TH" type="owcp:RowType"/>
<element name="TR" type="owcp:RowType"/>
The <TD> element is of type TextType and MAY contain formatted text content.
The following XML Schema declares the <TD> element:
<element name="TD" type="owcp:TextType"/>
The <Summary> <P> and <TD> 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:
The following XML Schema declares the TextType:
<complexType name="TextType" mixed="true">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="owcp:Money" maxOccurs="1"/>
<element ref="owcp:B" maxOccurs="1"/>
<element ref="owcp:I" maxOccurs="1"/>
<element ref="owcp:U" maxOccurs="1"/>
</choice>
</complexType>
The <Money> 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 <Money> element:
The following XML Schema declares the <Money> element:
<complexType name="MoneyType">
<attribute name="currency" type="string" use="required"/>
<attribute name="amount" type="decimal" use="required"/>
</complexType>
<element name="Money" type="owcp:MoneyType"/>
The <B>, <I> and <U> 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 used inside the element as is permitted in the enclosing element.
The following XML Schema declares the <B>, <I> and <U> elements:
<element name="B" type="owcp:TextType"/>
<element name="I" type="owcp:TextType"/>
<element name="U" type="owcp:TextType"/>
The following XML Schema completes the OWCP schema declarations:
</schema>
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.
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.
Mention the following:
Registry of barcode encoding types (QR/DataMatrix/Bitfield)
Register Schema URI
Mime type for OWCP message?
| [RFC1035] | Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. |
| [RFC5395] | Eastlake, D., "Domain Name System (DNS) IANA Considerations", RFC 5395, November 2008. |
<?xml version="1.0" encoding="utf-8"?>
<schema id="XMLSchema1"
targetNamespace="http://schema.comodo.com/2011/owcp/0.1"
elementFormDefault="qualified"
xmlns:owcp="http://schema.comodo.com/2011/owcp/0.1"
xmlns="http://www.w3.org/2001/XMLSchema">
<complexType name="RequestType">
<sequence>
<element ref="owcp:Header" minOccurs="1" maxOccurs="1"/>
<element ref="owcp:Body" minOccurs="0" maxOccurs="1"/>
</sequence>
</complexType>
<element name="Request" type="owcp:RequestType"/>
<complexType name="HeaderType">
<sequence>
<element ref="owcp:From" minOccurs="1" maxOccurs="1"/>
<element ref="owcp:To" minOccurs="1" maxOccurs="1"/>
<element ref="owcp:Verification" minOccurs="0"
maxOccurs="unbounded"/>
<element ref="owcp:Summary" minOccurs="1" maxOccurs="1"/>
<element ref="owcp:Reference" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
<attribute name="issued" type="dateTime"/>
<attribute name="identifier" type="anyURI"/>
<attribute name="type" type="string"/>
</complexType>
<element name="Header" type="owcp:HeaderType"/>
<element name="From" type="string"/>
<element name="To" type="string"/>
<element name="Verification" type="string"/>
<element name="Summary" type="owcp:TextType"/>
<element name="Reference" type="string"/>
<complexType name="BodyType">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="owcp:P" minOccurs="1" maxOccurs="1"/>
<element ref="owcp:Table" minOccurs="1" maxOccurs="1"/>
<element ref="owcp:Barcode" minOccurs="1" maxOccurs="1"/>
</choice>
</complexType>
<element name="Body" type="owcp:BodyType"/>
<element name="P" type="owcp:TextType"/>
<complexType name="BarcodeType" >
<attribute name="width" type="integer"/>
<attribute name="height" type="integer"/>
<attribute name="data" type="base64Binary"/>
</complexType>
<element name="Barcode" type="owcp:BarcodeType"/>
<complexType name="TableType">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="owcp:TH" minOccurs="1" maxOccurs="1"/>
<element ref="owcp:TR" minOccurs="1" maxOccurs="1"/>
</choice>
</complexType>
<element name="Table" type="owcp:TableType"/>
<complexType name="RowType">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="owcp:TD" minOccurs="1" maxOccurs="1"/>
</choice>
</complexType>
<element name="TH" type="owcp:RowType"/>
<element name="TR" type="owcp:RowType"/>
<element name="TD" type="owcp:TextType"/>
<complexType name="TextType" mixed="true">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="owcp:Money" maxOccurs="1"/>
<element ref="owcp:B" maxOccurs="1"/>
<element ref="owcp:I" maxOccurs="1"/>
<element ref="owcp:U" maxOccurs="1"/>
</choice>
</complexType>
<complexType name="MoneyType">
<attribute name="currency" type="string" use="required"/>
<attribute name="amount" type="decimal" use="required"/>
</complexType>
<element name="Money" type="owcp:MoneyType"/>
<element name="B" type="owcp:TextType"/>
<element name="I" type="owcp:TextType"/>
<element name="U" type="owcp:TextType"/>
</schema>