idnits 2.17.1 draft-hallambaker-owcp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 332: '...spatcher Service MAY impose a use poli...' RFC 2119 keyword, line 340: '... permits, a User MAY register multiple...' RFC 2119 keyword, line 342: '... each Device MUST have a separate ...' RFC 2119 keyword, line 345: '...rmation. A User MAY have multiple acc...' RFC 2119 keyword, line 398: '... An OWCP service MAY be Open or Closed...' (32 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 22, 2011) is 4682 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Accept' is mentioned on line 506, but not defined == Missing Reference: 'Reject' is mentioned on line 506, but not defined == Missing Reference: 'Required' is mentioned on line 1456, but not defined == Missing Reference: 'Attachment' is mentioned on line 917, but not defined == Missing Reference: 'Optional' is mentioned on line 1195, but not defined == Missing Reference: 'Digest' is mentioned on line 697, but not defined == Missing Reference: 'Complete' is mentioned on line 730, but not defined == Missing Reference: 'Acknolwedge' is mentioned on line 732, but not defined == Missing Reference: 'XXX' is mentioned on line 771, but not defined == Missing Reference: 'Scope' is mentioned on line 805, but not defined == Missing Reference: 'String' is mentioned on line 994, but not defined == Missing Reference: 'TBS' is mentioned on line 1135, but not defined == Missing Reference: 'RFC5395' is mentioned on line 1524, but not defined ** Obsolete undefined reference: RFC 5395 (Obsoleted by RFC 6195) == Unused Reference: 'RFC1035' is defined on line 1519, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Standards Track June 22, 2011 5 Expires: December 24, 2011 7 Open Web Confirmation Protocol (OWCP) 8 draft-hallambaker-owcp-00 10 Abstract 12 Open Web Confirmation Protocol (OWCP) is a three party Web Service 13 that supports a transactional second factor confirmation mechanism 14 that provides a superset of the capabilities of traditional second 15 factor authentication schemes. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 24, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 1.1. Second Factor Authentication . . . . . . . . . . . . . . . 5 53 1.2. Confirmation vs. Authentication . . . . . . . . . . . . . 6 54 1.3. Use Scenarios . . . . . . . . . . . . . . . . . . . . . . 6 55 1.3.1. Use in Financial Services . . . . . . . . . . . . . . 6 56 1.3.2. Machine Binding . . . . . . . . . . . . . . . . . . . 7 57 1.3.3. Tethered Use . . . . . . . . . . . . . . . . . . . . . 7 58 1.3.4. Co-Browser . . . . . . . . . . . . . . . . . . . . . . 8 59 2. Description . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 2.1. Parties . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 2.1.1. Accounts . . . . . . . . . . . . . . . . . . . . . . . 9 62 2.1.1.1. Dispatcher Discovery . . . . . . . . . . . . . . . 9 63 2.1.1.2. Third Party Domain Names . . . . . . . . . . . . . 9 64 2.1.1.3. Open and Closed Services . . . . . . . . . . . . . 10 65 2.1.2. User Experience . . . . . . . . . . . . . . . . . . . 10 66 2.1.2.1. Dispatcher Subscription . . . . . . . . . . . . . 10 67 2.1.2.2. Registration . . . . . . . . . . . . . . . . . . . 10 68 2.1.2.3. Requestor Subscription . . . . . . . . . . . . . . 11 69 2.1.2.4. Confirmation . . . . . . . . . . . . . . . . . . . 11 70 2.1.3. Examples of Use [Non Normative] . . . . . . . . . . . 11 71 2.1.3.1. Access Control . . . . . . . . . . . . . . . . . . 11 72 2.1.3.2. Payment . . . . . . . . . . . . . . . . . . . . . 13 73 2.1.3.3. Ticket and Transaction Acknowledgement . . . . . . 15 74 3. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 15 75 3.1. Common Format . . . . . . . . . . . . . . . . . . . . . . 16 76 3.1.1. Request . . . . . . . . . . . . . . . . . . . . . . . 16 77 3.1.2. Response . . . . . . . . . . . . . . . . . . . . . . . 16 78 3.2. Requestor to Dispatcher . . . . . . . . . . . . . . . . . 17 79 3.2.1. Operation RD-Confirm . . . . . . . . . . . . . . . . . 18 80 3.2.1.1. RD-Confirm Request . . . . . . . . . . . . . . . . 18 81 3.2.1.2. RD-Confirm Response . . . . . . . . . . . . . . . 19 82 3.2.2. Operation RD-Register . . . . . . . . . . . . . . . . 19 83 3.2.2.1. RD-Register Request . . . . . . . . . . . . . . . 19 84 3.2.2.2. RD-Register Response . . . . . . . . . . . . . . . 19 85 3.2.3. Operation RD-Deregister . . . . . . . . . . . . . . . 20 86 3.2.3.1. RD-Deregister Request . . . . . . . . . . . . . . 20 87 3.2.3.2. RD-Deregister Response . . . . . . . . . . . . . . 20 88 3.2.4. Operation RD-Status . . . . . . . . . . . . . . . . . 20 89 3.2.4.1. RD-Status Request . . . . . . . . . . . . . . . . 20 90 3.2.4.2. RD-Status Response . . . . . . . . . . . . . . . . 20 91 3.2.5. Operation RD-Final . . . . . . . . . . . . . . . . . . 20 92 3.2.5.1. RD-Final Request . . . . . . . . . . . . . . . . . 20 93 3.2.5.2. RD-Final Response . . . . . . . . . . . . . . . . 20 94 3.3. Dispatcher to Requestor . . . . . . . . . . . . . . . . . 21 95 3.3.1. Operation DR-Complete . . . . . . . . . . . . . . . . 21 96 3.3.1.1. DR-Complete Request . . . . . . . . . . . . . . . 21 97 3.3.1.2. DR-Complete Response . . . . . . . . . . . . . . . 21 98 3.4. Client to Dispatcher . . . . . . . . . . . . . . . . . . . 21 99 3.4.1. Operation CD-Register . . . . . . . . . . . . . . . . 22 100 3.4.1.1. CD-Register Request . . . . . . . . . . . . . . . 22 101 3.4.1.2. CD-Register Response . . . . . . . . . . . . . . . 22 102 3.4.2. Operation CD-Deregister . . . . . . . . . . . . . . . 22 103 3.4.2.1. CD-Deregister Request . . . . . . . . . . . . . . 22 104 3.4.2.2. CD-Deregister Response . . . . . . . . . . . . . . 23 105 3.4.3. Operation CD-List . . . . . . . . . . . . . . . . . . 23 106 3.4.3.1. CD-List Request . . . . . . . . . . . . . . . . . 23 107 3.4.3.2. RD-List Response . . . . . . . . . . . . . . . . . 23 108 3.4.4. Operation CD-Reply . . . . . . . . . . . . . . . . . . 23 109 3.4.4.1. CD-Reply Request . . . . . . . . . . . . . . . . . 23 110 3.4.4.2. CD-Reply Response . . . . . . . . . . . . . . . . 24 111 4. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 24 112 4.1. ESRV Discovery . . . . . . . . . . . . . . . . . . . . . . 24 113 4.1.1. ESRV Properties . . . . . . . . . . . . . . . . . . . 24 114 4.2. Manual Discovery . . . . . . . . . . . . . . . . . . . . . 24 115 5. Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 116 5.1. HTTP/JSON Binding . . . . . . . . . . . . . . . . . . . . 25 117 5.1.1. Transport . . . . . . . . . . . . . . . . . . . . . . 25 118 5.1.2. HTTP Encapsulation . . . . . . . . . . . . . . . . . . 25 119 5.1.3. Binary Multipart Container . . . . . . . . . . . . . . 25 120 5.1.3.1. Data Segment Format . . . . . . . . . . . . . . . 25 121 5.1.3.2. Data Section Format . . . . . . . . . . . . . . . 26 122 5.1.4. JSON Object Syntax . . . . . . . . . . . . . . . . . . 27 123 6. Request Schema . . . . . . . . . . . . . . . . . . . . . . . . 27 124 6.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 27 125 6.2. Request . . . . . . . . . . . . . . . . . . . . . . . . . 27 126 6.3.
. . . . . . . . . . . . . . . . . . . . . . . . . 28 127 6.3.1. and . . . . . . . . . . . . . . . . . . . 29 128 6.3.2. . . . . . . . . . . . . . . . . . . . . 29 129 6.3.3. . . . . . . . . . . . . . . . . . . . . . . 30 130 6.3.4. . . . . . . . . . . . . . . . . . . . . . 30 131 6.4. . . . . . . . . . . . . . . . . . . . . . . . . . . 30 132 6.4.1.

. . . . . . . . . . . . . . . . . . . . . . . . . 31 133 6.4.2. . . . . . . . . . . . . . . . . . . . . . . 31 134 6.5. . . . . . . . . . . . . . . . . . . . . . . . . . 32 135 6.5.1. . . . . . . . . . . . . . . . . . . . . 33 136 6.6.
and
. . . . . . . . . . . . . . . . . . . . . . . . . . . 33 137 6.7. Text . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 138 6.7.1. . . . . . . . . . . . . . . . . . . . . . . . 34 139 6.7.2. , and . . . . . . . . . . . . . . . . . . . 34 140 6.8. End . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 141 7. Internationalization Considerations . . . . . . . . . . . . . 35 142 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 143 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 144 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 145 10.1. Normative References . . . . . . . . . . . . . . . . . . . 36 146 10.2. Non Normative References . . . . . . . . . . . . . . . . . 36 147 Appendix A. Collected Schema . . . . . . . . . . . . . . . . . . 36 148 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 150 1. Background 152 Authentication of end users is one of the biggest challenges for 153 Internet and Web security today. Despite an abundance of technology 154 that offers authentication mechanisms that are more robust, more 155 secure and easier to use, the default mechanism for user 156 authentication is the use of usernames and passwords. 158 Unlike traditional schemes, OWCP is designed for implementation on a 159 device that has at least the capabilities of a modern 'smartphone'. 160 In particular an OWCP client device must support a display, a means 161 of accepting text input from the user and a connection to the 162 Internet. 164 While mobile devices offering this degree of functionality were rare 165 in 2007, they have since become ubiquitous. It is thus now a 166 practical proposition for a site requiring second factor 167 authentication to support at least a part of its users using a 168 technology that requires this level of capability. Indeed software 169 applications that emulate traditional second factor authentication 170 protocols on such devices have been available for some time. 172 1.1. Second Factor Authentication 174 Second factor authentication mechanisms offer greater security over 175 the use of passwords alone by combining a first factor (typically a 176 password) with a biometric or proof of possession of a physical 177 token. 179 Traditional second factor authentication techniques have suffered 180 from the need to distribute physical tokens and the difficulty of 181 ensuring that a biometric authentication is presented to a 182 trustworthy terminal. 184 The usability of traditional second factor authentication techniques 185 has been poor or worse. Even the simplest scheme in which the user 186 is required to read in a 'one time use' numeric code from the 187 authentication token device and enter it into a password field. 188 While such operations are relatively simple they require the user to 189 engage in a sequence of operations that bears no necessary or natural 190 relationship to the underlying task for which the authentication is 191 required. 193 Nor does the act of engaging in a traditional second factor scheme 194 offer proof of anything other than that the user was authenticated. 195 Any correspondence between the act of authentication and the purpose 196 for which the authentication was provided must be maintained 197 separately. 199 1.2. Confirmation vs. Authentication 201 A second factor confirmation service addresses the limitations of 202 traditional second factor authentication schemes. 204 A confirmation service allows the user experience to be precisely 205 matched to the action that the user is attempted. Instead of beinf 206 asked to read a random number from one device and enter it into 207 another, the user is asked if they really want to perform the action 208 for which authentication is requested. 210 A confirmation service offers better accountability for end users 211 than a traditional authentication service. An authentication service 212 only provides an assertion that the user was present. A confirmation 213 service provides an assertion that the user was present and that they 214 confirmed a specific transaction. 216 For example, Alice has been granted access to a machine storing 217 classified data. If an authentication service is used for access 218 control, the authentication service log will only record the dates 219 and times that Alice accessed the system. to find out if Alice 220 accessed a particular file on a particular day it is necessary to 221 consult and correlate both the authentication log of the system and 222 the activity log for the application. 224 If instead a confirmation service is used the confirmation log 225 contains an authenticated record of both the authentication events 226 and the transactions for which the authentication was requested. 228 1.3. Use Scenarios 230 A confirmation service complements rather than replaces a traditional 231 authentication scheme. Providing a highly secure and convenient 232 means of authenticating requests that carry a high degree of risk 233 mitigates the risk of using convenient but intrinsically low security 234 techniques for other actions. 236 1.3.1. Use in Financial Services 238 If an attacker is to profit from breaching a an account with a 239 financial service such as a bank or a brokerage they must find a way 240 to move money out of the account. Thus adding bill payment 241 recipients, initiating wire transfers and trading in low volume 242 'penny stocks' represent high risk activities. 244 For example: Bank of Ethel might permit customers to use a simple 245 username and password scheme to gain access to their account for the 246 purpose of checking their balance or paying bills to existing 247 reciepients but require use of the second factor confirmation device 248 for a high risk transaction such as paying a bill. 250 1.3.2. Machine Binding 252 A second factor confirmation service may be combined with a machine 253 level authentication scheme to permit a transparent form of 254 authentication for low risk transactions. 256 For example: Alice stores her low risk authentication credentials 257 (e.g usernames and passwords) using a 'cloud' service. When she 258 wishes to use those credentials an agent on her personal machine 259 fetches credentials from the cloud service as necessary. When Alice 260 wishes to access a site from a different machine she receives a 261 confirmation request on her mobile device to grant access from that 262 machine. 264 Use of such a mechanism is clearly more satisfactory when suitable 265 cryptographic protocols such as SAML or Kerberos are employed to 266 limit the disclosure and hence possible compromise of the 267 credentials. The specification of such protocols is outside the 268 scope of this document. 270 1.3.3. Tethered Use 272 Although OWCP is designed for use in a three party scenario, there 273 are situations in which a two party mode may be preferred. 275 For example: Bob is a roadwarrior who requires access to confidential 276 documents stored on his laptop device from anywhere in the world, 277 including locations where Internet access is not possible. To permit 278 access in such circumstances, Bob's OWCP client supports use of a 279 tethered mode in which the mobile device is plugged into his laptop 280 via a USB port. 282 For example: Carol is a network manager of a large computing facility 283 that uses OWCP to authenticate and track all changes to critical 284 resources. Since OWCP is itself a network resource a bootstrap 285 consideration arises: How can Carol confirm her network configuration 286 requests using OWCP when the network itself is down? Support for a 287 tethered mode in which the OWCP device communicates via USB or 288 similar wired protocol allows this use case to be supported. 290 While availability of a tethered mode is clearly essential if OWCP is 291 to be used in certain applications, support for this feature outside 292 the scope of this version of the specification. 294 1.3.4. Co-Browser 296 While OWCP is designed for deployment on a secondary device, 297 deployment on the same device as the one for which confirmation is 298 being requested is also possible and can provide security benefits. 300 Modern Web browsers are large and complex with many features such as 301 support for mobile code that are incompatible with a high security 302 environment. Separating the confirmation protocol from the Web 303 Browsing protocol permits implementation in a minimal client designed 304 to permit detailed security analysis. Such a client might be 305 embedded in or support means of secure interaction with a trustworthy 306 operating system component. 308 While this means of deployment does not provide a true second factor 309 confirmation, it is likely to provide a sufficient degree of 310 authentication for many transactions. 312 2. Description 314 OWCP is a Web Service that permits a Requestor to request that a User 315 confirm or reject a specified action. If the user responds, the 316 response is signed with a digital signature under a key that is 317 unique to the user account, the client and the device. 319 2.1. Parties 321 Each OWCP protocol interaction takes place between a connection pair 322 of the following parties: 324 A party that initiates a confirmation request. 326 A clearing house that stores and forwards requests from requestors 327 and responses from Clients. The dispatcher is only trusted to 328 perform routing filtering and recording of requests and responses. 329 The dispatcher is not trusted with respect to the responses 330 returned. 332 A Dispatcher Service MAY impose a use policy on Requestors, 333 Clients and Users. 335 Issue and maintenance of Client Device credentials is a trusted 336 function that is logically independent of the store and forward 337 operation of the Dispatcher. 339 The Client interacts with the User and the Dispatcher. If 340 Dispatcher policy permits, a User MAY register multiple Devices to 341 serve as confirmation devices for the same account. In this case 342 each Device MUST have a separate signature key. 344 The User is the person being asked to grant or refuse 345 confirmation. A User MAY have multiple accounts with multiple 346 Dispatcher Services. 348 +-------------+ +------------+ +-------------+ 349 | Requestor | <-----> | Dispatcher | <------ | Client | 350 +-------------+ +------------+ +-------------+ 351 ^ ^ 352 | | 353 V V 354 +------------+ +-------------+ 355 | PKI | | User | 356 +------------+ +-------------+ 358 2.1.1. Accounts 360 Users and Requestors are identified by means of an account 361 identifier. The display presentation of an account identifier is the 362 form of an RFC2822 email address identifier without the enclosing 363 angle braces, for example: 365 alice@example.com 367 The account identifier is used by the User when registering the use 368 of the confirmation service with a dispatcher. 370 2.1.1.1. Dispatcher Discovery 372 The domain component of the account identifier is the DNS name of the 373 corresponding Dispatcher Web Service. 375 DNS Service discovery is used by Requestors and Clients to discover 376 the Dispatcher service corresponding to a specified account. 378 2.1.1.2. Third Party Domain Names 380 OWCP requires that the provider of a Dispatcher service have control 381 over the DNS names used in the corresponding account identifiers. 383 It is thus not possible for any party other than the holder of the 384 domain name example.com to provide OWCP service for 385 alice@example.com. If Alice, the holder of the alice@example.com 386 email address wishes to use an OWCP confirmation service, her choices 387 are limited to persuading the holder of example.com to provide an 388 OWCP dispatcher service and allow her to use her email identifier or 389 registering with another confirmation service provider and accepting 390 a different identifier. 392 Requiring a strong binding between the Dispatcher service and the 393 account identifier permits the use of the account identifier to be 394 used as a proxy for authorization. 396 2.1.1.3. Open and Closed Services 398 An OWCP service MAY be Open or Closed. An Open service provider 399 provides OWCP service to the general public. A Closed service 400 provider only provides service to a specific community. 402 For example: An Internet Service Provider or DNS Registrar might 403 provide an open OWCP service as a part of their standard service 404 offering to customers. An employer might operate a closed OWCP 405 service to be used for company business. 407 2.1.2. User Experience 409 Since the purpose of OWCP is to support user interaction, the user 410 experience is an important part of the OWCP specification. 412 While the realization of the User Experience is outside the scope of 413 the specification, the specification will inevitably constrain the 414 User Experiences that an implementer can provide. 416 2.1.2.1. Dispatcher Subscription 418 Dispatcher Subscription is the procedure whereby a User creates an 419 account with a new account identifier. 421 OWCP Dispatcher Subscription is equivalent to establishing an account 422 for email or for computer access. 424 2.1.2.2. Registration 426 To make use of a Client, A User must register it for use with at 427 least one OWCP account. 429 If the User is attempting to register a Client for use with an 430 existing account, the registration request SHOULD be authenticated to 431 ensure that the it comes from the authorized account holder. A One 432 Time Use authentication code or a confirmation from a device that has 433 already been registered MAY be used for this purpose. 435 A Client MAY support a mode in which the Dispatcher Subscription 436 procedure is combined with registration. In this case the Dispatcher 437 service policy MAY permit registration without additional 438 authentication if the account has never existed before. 440 2.1.2.3. Requestor Subscription 442 To make use of OWCP with a requestor, a User simply provides their 443 OWCP account identifier. 445 In the case that the OWCP account identifier is also the email 446 address supplied when the User established an account with the 447 Requestor, the Requestor MAY perform the subscription process 448 automatically. 450 2.1.2.4. Confirmation 452 In the typical case, use of the Confirmation service is triggered by 453 a User request to the Requestor or an event that requires the User's 454 attention. 456 For example: Alice attempts to access the personnel file causing the 457 access control system to generate a confirmation request that is 458 received on Alice's mobile device. Alice accepts the confirmation 459 and access is granted. 461 For example: Bob is working as a network manager and the datacenter 462 cooling system has started leaking. He attempts to engage an 463 emergency plumming service which in turn requires authorization from 464 Carol, the Finance Director. 466 2.1.3. Examples of Use [Non Normative] 468 For clarity, only the XML Message component of the requests are 469 shown. The HTTP Headers and CMS packaging is omitted. 471 2.1.3.1. Access Control 473 Alice (alice@example.com) is an employee of Example Corp. She is 474 attempting to log into the corporporate network from the laptop 475 (#234) issued by her employer. 477 When Alice attempts to connect to the VPN, the VPN generates the 478 following request and sends it to the Dispatcher service that 479 services example.com: 481 482 483
486 access@example.com 487 alice@example.com 488 PIN 489 Do you wish to connect to the corporate network from 490 Laptop #234 issued to Alice? 491
492 494 If Alice's mobile device supports a notification service this MAY be 495 used to alert Alice to the fact that a new confirmation request is 496 pending. Alternatively, Alice picks up her mobile device and starts 497 the confirmation client manualy. In either case, Alice is shown the 498 following dialog: 500 From: access@example.com 501 To: alice@example.com 503 Do you wish to connect to the corporate 504 network from Laptop #234 issued to Alice? 506 [Accept] [Reject] 508 Since the request specifies PIN verification, Alice is asked to 509 provide her PIN before a response can be generated. Note that the 510 PIN MUST be supplied regardless of whether the action is accepted or 511 rejected. 513 Alice accepts the request and the client generates a receipt message 514 that contains the original request message and Alice's response. The 515 receipt message is then digitally signed using a signature key that 516 is unique to the account, device and the client. 518 [TBS response] 520 The reciept is sent to the dispatcher which forwards at least the 521 result of the request to the Requestor. 523 In this case the Requestor is trusted to receive digitally signed 524 responses for the specific action requested and the original request 525 and signature is forwarded to the Requestor. 527 2.1.3.2. Payment 529 A confirmation service MAY be used to support payment transactions. 530 In this use case there is often a need to present the User with both 531 a high level summary of the action being requested and a more 532 detailed description. 534 The following message asks Alice if she wishes to transfer a sum of 535 money to a person she met in an Internet chat room. 537 538 539
542 access@example.com 543 alice@example.com 544 PIN 545 Do you wish to transfer to the account of Barrister Mugu 547 #666-201919 at Bank of Nigeria? 548 549
550 551

552 Form of transfer: Wire 553

554 555 559 562 563 564 567 570 571
556 557 Item 558 560 Amount 561
565 Expeditiary Fee 566 568 569
572 573 575 In this case Alice (wisely) declines the request. 577 [TBS response] 579 2.1.3.3. Ticket and Transaction Acknowledgement 581 In the case that the confirmation service is used to authenticate a 582 purchase for non-tangible goods, it is in some cases convenient to 583 deliver the goods themselves through the confirmation service client. 584 In this case the receipt is also the ticket. 586 Alice purchases tickets for a concert tour. The ticket and the 587 instructions to find her seat are returned to her through the 588 confirmation service. 590 The Requestor sends the following message to the dispatcher: 592 593 594
597 concerts@example.com 598 alice@example.com 599 600 Tickets for Spinal Tap Reonion Tour DC 24th June Seats A15+A16 601 602
603 604

605 This is your ticket. 606

607

608 Present the barcode to the barcode reader at the turnstile. 609

610 612 613 615 When Alice receives the message on her mobile device it displays a 2D 616 barcode that can be read at the turnstile. Alice gains admission to 617 the concert without the need to queue at the ticket booth. 619 3. Protocol Messages 621 OWCP protocol messages are defined here in an abstract form to permit 622 them to be expressed in different protocol bindings. OWCP 0.1 623 services MUST support the HTTP+CMS binding defined in section []. 625 OWCP messages MUST be exchanged over an encrypted, authenticated 626 transport such as TLS or IPSEC. OWCP 0.1 services MUST support use 627 of TLS transport. 629 Since the function of the Dispatcher is to store and forward 630 messages, a sequence of OWCP messages will always be initiated by 631 either a Requestor or a Client. 633 3.1. Common Format 635 3.1.1. Request 637 All OWCP request messages specify an operation code. 639 The following parameters are common to all requests. 641 Transaction [Transaction Identifier][Required] The transaction 642 identifier is unique for all requests except for RD-Status, RD- 643 Final and DR-Complete in which case the transaction identifier of 644 the original transaction for which status is being requested is 645 used. 647 Certificate Chain [Attachment][Optional] Certificate chain for the 648 public key used in the Signature. 650 Authentication [Authentication Code][Optional] Digital Signature or 651 Message Authentication Code of the Request. 653 3.1.2. Response 655 All responses return a response code. The following response codes 656 are defined: 658 200 Success The operation succeeded and the result of the operation 659 is returned. 661 303 Incomplete The operation requested by the Requestor has not 662 completed and the result of the operation will be returned 663 asynchronously. 665 400 Bad Request 667 401 Unauthorized The Requestor or Client is not permitted to perform 668 the requested operation.. 670 404 Not Found The requested User account or Transaction ID was not 671 found. 673 408 Timeout The requested operation did not complete in the 674 specified time or status was requested for a transaction that has 675 expired. 677 In addition an OWCP service MAY return any error or status code 678 defined by the protocol binding and/or the transport layer. 680 The following parameters are common to all responses: 682 Transaction [Transaction Identifier][Required] The transaction 683 identifier of the original request. 685 Note that the transaction identifier is a required parameter for 686 the protocol even though its value might be implicit from the 687 context in many protocol bindings (e.g. HTTP). This is necessary 688 to ensure that the authentication of the response also covers the 689 request. 691 Certificate Chain [Attachment][Optional] Certificate chain for the 692 public key used in the Signature. 694 Authentication [Authentication Code][Optional] Digital Signature or 695 Message Authentication Code of the Request. 697 Request-Link [Digest][Optional] Message Digest of the Request. This 698 is only relevant when a response is digitally signed and allows 699 the response to be cryptographically linked to the original 700 request. 702 3.2. Requestor to Dispatcher 704 Operations initiated by the Responder are logically a single request 705 followed by a single response but may take longer to complete than it 706 is desiable for the Responder to wait for a status code. Support for 707 asynchronous completion is therefore necessary. 709 If the Dispatcher is unable to complete an operation immediately it 710 MUST return the Incomplete response code. A Responder MAY recover 711 the result of an incomplete operation by polling using the STATUS 712 operation or by accepting asynchronous completion by means of the 713 Complete operation. 715 In order to accept asynchronous completion of a request, a dispatcher 716 specifies the 717 Dispatchers MUST support completion of incomplete operations by use 718 of the polling mechanism and MAY support asynchronous completion by 719 means of the Complete operation. 721 +------------+ +-------------+ 722 | Requestor | ....... | Dispatcher | 723 +------------+ +-------------+ 725 Request 726 ------> 727 Resonse 728 <------ 730 [Complete] 731 <------ 732 [Acknolwedge] 733 ------> 735 The following parameters are common to all RD-Operation requests: 737 Reply-To [DNS Name][Optional] DNS Name of a server that will accept 738 completion of the request via the DR-Complete operation. 740 Expiry [Date Time][Optional] A date and time beyond which the result 741 of the request is no longer relevant. A Dispatcher MAY refuse to 742 recognize the expiry term requested by Requestor and impose its 743 own limit which MAY be shorter or longer. 745 A Responder SHOULD NOT rely on an expiry time of less than ten 746 minutes for any operation that requires User interaction. 747 Machines should serve people, not the other way round. 749 3.2.1. Operation RD-Confirm 751 The RD-Confirm operation is used to present a confirmation request to 752 the User with the Dispatcher and Client(s) acting as intermediaries. 754 3.2.1.1. RD-Confirm Request 756 The RD-Confirm request takes the following parameters: 758 Registration [Registrarion Identifier][Optional] Registration 759 identifier assigned by the Dispatcher to represent the Dispatcher- 760 Responder relationship in a prior Registration operation. 762 Expiry [Date Time][Optional] Date and Time at which the confirmation 763 request will expire. 765 Message [Attachment/XML][Optional] The Confirmation request message 766 formatted according to the XML schema specified in section [XXX] 768 3.2.1.2. RD-Confirm Response 770 Reply [Attachment/XML][Optional] The Confirmation response message 771 formatted according to the XML schema specified in section [XXX] 773 3.2.2. Operation RD-Register 775 The RD-Register operation allows a Requestor to pre-register with a 776 Dispatcher. This allows the Responder to check that it is likely to 777 be able to use the confirmation service before relying on it. 779 The RD-Register operation is essentially a confirmation request 780 without the actual confirmation. 782 Use of the RD-Register operation is optional according to the OWCP 783 protocol but MAY be required by the dispatcher policy. 785 3.2.2.1. RD-Register Request 787 Operation Code: RD-Register 789 Responder [Account Identifier][Optional] The account identifier the 790 responder is attempting to register. This is only required in 791 cases where the dispatcher needs to check the responder account 792 against the certificate chain. 794 User [Account Identifier][Optional] The account identifier a 795 specific user that the responder is attempting to register. If no 796 account is specified the Responder is attempting to register for 797 all accounts. 799 3.2.2.2. RD-Register Response 801 Registration [Registrarion Identifier][Required] Registration 802 identifier assigned by the Dispatcher to represent the Dispatcher- 803 Responder relationship. 805 Scope [Scope][Optional] If the Scope is specified as 'User', the 806 registration is accepted for that specific user alone. If the 807 scope is specified as 'global' the registration is applies to all 808 User accounts held by the dispatcher. 810 Policy [Attachment/XML][Optional] Dispatcher policy statement. 812 3.2.3. Operation RD-Deregister 814 The RD-Deregister operation cancels a previous registration request. 816 3.2.3.1. RD-Deregister Request 818 Operation Code: RD-Deregister 820 Registration [Registrarion Identifier][Required] Registration 821 identifier assigned by the Dispatcher to represent the Dispatcher- 822 Responder relationship in the original RD-Register operation. 824 3.2.3.2. RD-Deregister Response 826 No additional data is returned if the operation succeeds 828 3.2.4. Operation RD-Status 830 The operation RD-Status is used to request the result of an earlier 831 request made by that Responder. 833 3.2.4.1. RD-Status Request 835 No additional parameters are specified. 837 3.2.4.2. RD-Status Response 839 If successful the RD-Status response returns the parameters defined 840 for the original transaction request. 842 3.2.5. Operation RD-Final 844 The operation RD-Final is used to request the result of an earlier 845 request made by that Responder and cancel the request if it has not 846 yet completed. 848 3.2.5.1. RD-Final Request 850 No additional parameters are specified. 852 3.2.5.2. RD-Final Response 854 If the original operation completed successfully, the RD-Final 855 response returns the parameters defined for the original transaction 856 request. 858 If the Dispatcher accepts the request to attempt to cancel the 859 operation the response code 408 Timeout is returned. But returning 860 this response code in an RD-Final response does not guarantee that 861 the operation will not be completed subsequently. 863 3.3. Dispatcher to Requestor 865 The only circumstance in which a Dispatcher initiates a protocol 866 exchange is when it is providing an asynchronous completion response 867 for a previous request. 869 3.3.1. Operation DR-Complete 871 The DR-Complete operation returns the result of a previously 872 requested operation for which an Incomplete status was returned. 874 3.3.1.1. DR-Complete Request 876 The request contains the result of the original response: 878 Status [Response Code][Required] The response code of the request. 880 If the operation was successful, the DR-Complete response returns the 881 parameters defined for the original transaction request. 883 3.3.1.2. DR-Complete Response 885 No additional parameters are specified. 887 3.4. Client to Dispatcher 889 Protocol exchanges between the Dispatcher and the Client consist of a 890 single request from the Client followed by a single response from the 891 Dispatcher. 893 +------------+ +-------------+ 894 | Dispatcher | ....... | Client | 895 +------------+ +-------------+ 897 Request 898 <------ 899 Resonse 900 ------> 902 3.4.1. Operation CD-Register 904 The CD-Register operation is used to register a Client to a 905 Dispatcher. 907 3.4.1.1. CD-Register Request 909 The CD-Register request specifies the following parameters: 911 Account [Account Identifier][Required] Account identifier for the 912 account being requested. 914 Passphrase [String][Optional] Optional Passphrase value that MAY be 915 used by the Dispatcher to authenticate the registration request. 917 Key [Attachment][Required] Key to be used to authenticate messages 918 from the client to the Dispatcher. 920 Client [Client Identifier][Optional] Client identifier returned in a 921 previous registration request. 923 The client identifier is only specified by a client in the case of 924 a rekeying operation. 926 3.4.1.2. CD-Register Response 928 The CD-Register response specifies the following parameters: 930 Client [Client Identifier][Optional] Identifier that the Client MUST 931 use in future interactions with the dispatcher under this account. 933 3.4.2. Operation CD-Deregister 935 The CD-Deregister operation is used to unregister a previously 936 registered Client. 938 Note that a Client may also be deregistered through other, out of 939 band mechsanisms. For example through an account management 940 interface for the account. 942 3.4.2.1. CD-Deregister Request 944 The Deregister request specifies only the client identifier. 946 Client [Client Identifier][Optional] Client identifier. 948 3.4.2.2. CD-Deregister Response 950 The Deregister response only reports success or failure. 952 [TBS Should it tell the user that they have other devices?] 954 3.4.3. Operation CD-List 956 The CD-List operation is used to request that the Dispatcher return 957 all pending confirmations. 959 3.4.3.1. CD-List Request 961 The CD-List request takes the following parameters: 963 Client [Client Identifier][Required] Registration identifier 964 assigned by the Dispatcher to represent the Client-Responder 965 relationship in a prior Registration operation. 967 Since [Transaction Identifier][Optional] If specified directs the 968 server to only return confirmation messages recieved since the 969 specified transaction identifier. 971 3.4.3.2. RD-List Response 973 If successful, the CD-List response takes the following parameters: 975 Now [Transaction Identifier][Optional] Specifies an identifier that 976 the client can specify in a request to indicate that the 978 Requests [Attachment/Multipart][Required] A sequence of confirmation 979 requests packaged as a multipart object. 981 3.4.4. Operation CD-Reply 983 The CD-Reply Operation is used by the client to notify the Dispatcher 984 that the user has responded to a confirmation request. 986 3.4.4.1. CD-Reply Request 988 The CD-Reply Request specifies the transaction identifier of the 989 confirmation for which a reply is being given and a response value. 991 Transaction [Transaction Identifier][Required] The transaction 992 identifier being responded to. 994 Response [String][Required] The response value. 996 3.4.4.2. CD-Reply Response 998 The CD-Reply operation only returns a status code value. No 999 additional parameters are returned. 1001 [TBS May want to revist this. Wouldn't a client want to be able to 1002 confirm that an asyn completion has in fact been delivered?] 1004 4. Service Discovery 1006 Requestors and Clients discover the client using DNS service 1007 discovery. 1009 4.1. ESRV Discovery 1011 Requestors and Clients MUST support the ESRV discovery Mechanism and 1012 the SRV and URI extended discovery mechanisms. 1014 4.1.1. ESRV Properties 1016 ESRV properties permit clients and servers to negotiate service 1017 protocol and properties such as the protocol version and/or protocol 1018 binding. 1020 4.2. Manual Discovery 1022 ESRV service discovery depends on support for new DNS Resource Record 1023 types at the DNS Resolver used. Clients SHOULD and Requestors MAY 1024 support manual configuration of the Dispatcher service. 1026 Manual configuration does not provide the support for redundancy or 1027 fault tolerance provided in the ESRV discovery mechanism. 1029 5. Bindings 1031 The abstract OWCP protocol is mapped to the wire-transport by means 1032 of a binding. Currently only one binding is defined. 1034 OWCP Responders and Dispatchers MUST support the HTTP/JSON binding 1035 and MAY support other bindings. 1037 OWCP Clients SHOULD support the HTTP/JSON binding and MAY support 1038 other bindings. 1040 5.1. HTTP/JSON Binding 1042 The HTTP/JSON binding is designed to permit efficient implementation 1043 of an OWCP Requestor or Dispatcher without the need for XML support 1044 beyond the ability to generate Confirmation messages. 1046 5.1.1. Transport 1048 5.1.2. HTTP Encapsulation 1050 The service discovery process returns the Web Service Endpoint og the 1051 OWCP service as a URI. 1053 OWCP requests are mapped to HTTP Requests as follows: 1055 Method The request method is always POST. 1057 Request URI The request URI consists of the web service endpoint 1058 concatenated with a '/' character concatenated with the OWCP 1059 operation code. 1061 Content-Encoding The Content Encoding type MUST be either "8bit" or 1062 "Binary". 1064 Content The content of the request message is a Binary Multipart 1065 Container in which the first data segment MUST be the JSON 1066 parameter block. 1068 5.1.3. Binary Multipart Container 1070 An OWCP message typically contains X.509 certificate chains, XML data 1071 objects and other data objects most suitably exchanged in binary 1072 form. The Binary Multipart representation is used to encapsulate the 1073 message parameter object and related attachments as binary objects. 1075 A Binary Multipart Container consists of a sequence of data segments. 1077 5.1.3.1. Data Segment Format 1079 A Data Segment consists of a sequence of a segment type identifier 1080 followed by a sequence of sections as specified by the segment type 1081 identifier. 1083 Indicates that a parameter label item is present. 1085 Indicates that a MIME Content-Type item is present. 1087 Indicates that an Identifier is present. 1089 Indicates that a Data section is present. 1091 Indicates that an Object Digest Identifier of the Data section is 1092 present. 1094 Reserved for future use. 1096 If set the data segment is the final segment in the container. 1097 Otherwise at least one more data segment follows. 1099 5.1.3.2. Data Section Format 1101 Data sections are presented in the same order as the segment type 1102 identifier bits starting with the low order bit. 1104 Each data section consists of a length specifier followed by the 1105 corresponding data. 1107 ASN.1 length encoding format is used to represent the length 1108 specifier. 1110 For length values less than 128 octets, the length is represented as 1111 a single octet and consists of the length value. 1113 For longer lengths, the high order bit of the first order octet is 1 1114 and the remaining 7 bits specify the number of octets following used 1115 to specify the length. 1117 For example: A data segment that contains a MIME Content-Type section 1118 and a Data section will have the segment type specifier 5 (00000101 1119 in binary). The first section will contain the Content-Type and the 1120 Second section the Data value. 1122 Contrary to the practice in ASN.1 DER encoding, the length specifier 1123 MAY contain leading zeros. Thus the octet sequence '0x13', the 1124 octext sequence '0x11 0x13' and the octet sequence '0x14 0x00 0x00 1125 0x00 0x13' are all valid and each specifies that the length of the 1126 following data is 19 octets. 1128 5.1.4. JSON Object Syntax 1130 OWCP data objects are encoded using the JSON syntax [TBS]. 1132 The correspondance between OWCP data types and JSON object types is 1133 given below: 1135 [TBS] 1137 6. Request Schema 1139 6.1. Namespace 1141 The OWCP Request schema is defined in W3C XML Schema notation. The 1142 version specified in this document has the following namespace 1143 assigned: 1145 XML Namespace: http://schema.comodo.com/2011/owcp/0.1 1147 1148 1154 6.2. Request 1156 The element 1158 The element contains the following sequence of elements: 1160
1162 1164 The following XML Schema declares the element: 1166 1167 1168 1169 1170 1171 1172 1174 6.3.
1176 The
element 1178 The
element contains the following attributes and sequence 1179 of elements: 1181 issued [Required] 1183 identifier [Required] 1185 type [Required] 1187 1189 1191 1193 1195 Reference* [Optional] Identifier of previous confirmation messages 1196 that this confirmation message is cross-referenced to. 1198 The following XML Schema declares the
element: 1200 1201 1202 1203 1204 1206 1207 1209 1210 1211 1212 1213 1214 1216 6.3.1. and 1218 The and elements 1220 The and elements are of type string. 1222 The following XML Schema declares the element: 1224 1226 6.3.2. 1228 The element 1230 The element is of type string and contains an OWCP 1231 verification mechansim identifier as registered by IANA. [TBS 1232 extensions by RFC] 1234 The following Verification methods are initially defined: 1236 PIN 1238 GPS 1240 Photo 1242 Voice 1244 If a client encounters an unknown Verification element, the request 1245 MUST be refused with the error return 'Unknown Verification Type'. 1247 [TBS: Should it be possible to specify Verification mechanisms as 1248 being required/optional or can this be handled in the negotiation 1249 profile?] 1251 The following XML Schema declares the element: 1253 1255 6.3.3. 1257 The element 1259 The element is of type TextType and contains formatted text 1260 as described below. 1262 The following XML Schema declares the element: 1264 1266 6.3.4. 1268 The element 1270 The element is of type string. 1272 The following XML Schema declares the element: 1274 1276 6.4. 1278 The element 1280 The element: 1282

1284 1286 1288 The following XML Schema declares the element: 1290 1291 1292 1293 1294 1295 1297 1298 1300 6.4.1.

1302 The

element 1304 The

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

element: 1309 1311 6.4.2. 1313 The <> element 1315 In order to minimize the complexity of the client while maximizing 1316 the range of barcode formats that can be supported, the barcode is 1317 represented as a bitstring corresponding to the values of pixels in a 1318 grid of the specified size. 1320 Note that this mechanism is NOT intended to provide a mechanism for 1321 display of arbitrary images. While the format described is capable 1322 of supporting the most comonly used 1D and 2D barcode formats, 1323 support for arbitrary formats is considered to be a non-requirement. 1325 The low order bit (0) of the first octect in the bitstream 1326 corresponds to the top left corner of the barcode image which is by 1327 definition the origin. A bit value of 1 corresponds to a black pixel 1328 and a bit value of 0 to a white pixel. 1330 The next bit, bit 1 corresponds to the pixel immediately to the right 1331 of the origin and so on. Octects are read from the bitstream as 1332 needed. Until the entire first row of pixels is presented. 1334 The low order bit of the next octet in the bitstream represents the 1335 pixel immediately below the origin and so on for the remainder of the 1336 row. 1338 A QR code Version 4 barcode is displayed in a 33x33 grid of pixels. 1339 Thus the bitstream representation of such a bitstream will require 5 1340 octets per row for each of the 33 rows, a total of 155 octets. 1342 [TBS: decide whether this is acceptable and if it may lead to GIF 1343 abuse type issues with the barcode being used as a substitute for an 1344 icon.] 1346 The <> element: 1348 width 1350 height 1352 data 1354 The following XML Schema declares the element: 1356 1357 1358 1359 1360 1361 1363 6.5.

1365 The
element 1367 The
element: 1369 1373 The following XML Schema declares the
1371
element: 1375 1376 1378 1379 1380 1381 1382 1384 6.5.1. 1386 The element 1388 The elements are of RowType and may contain the 1389 following element: 1391 elements: 1395 1396 1397 1398 1399 1400 1401 1403 6.6.
and
and
and
1393 The following XML Schema declares the and
1405 The element is of type TextType and MAY contain formatted text 1406 content. 1408 The following XML Schema declares the element: 1410 1412 6.7. Text 1414 The

and

elements are used to present free form 1415 text. Each of these elements are of the type TextType which is the 1416 only type of mixed content in the OWCP message markup. 1418 An element of type TextType MAY contain the following content and 1419 elements: 1421 Text data. 1423 elements used to represent quantities of money. 1425 elements used to highlight regions of the text with bold font. 1427 elements used to highlight regions of the text with italic 1428 font. 1430 elements used to highlight regions of the text with 1431 underlining. 1433 The following XML Schema declares the TextType: 1435 1436 1437 1438 1439 1440 1441 1442 1444 6.7.1. 1446 The element is used to specify a sum of money in a specified 1447 currency within an element of type TextType. This permits the client 1448 to assit the user by providing an instant conversion into the 1449 currency of the user's choice. 1451 The following attributes are defined for the element: 1453 currency [Required] The ISO 4217 currency code for the amount 1454 specified. 1456 amount [Required] The amount specified in the currency indicated. 1458 The following XML Schema declares the element: 1460 1461 1462 1463 1464 1466 6.7.2. , and 1468 The , and elements are used to identify spans of text to 1469 be presented with Bold, Italic and Underline emphasis respectively. 1470 Each element is of type TextType and permit the same content to be 1471 used inside the element as is permitted in the enclosing element. 1473 The following XML Schema declares the , and elements: 1475 1476 1477 1479 6.8. End 1481 The following XML Schema completes the OWCP schema declarations: 1483 1485 7. Internationalization Considerations 1487 Might want to consider how a requestor can attempt to provide a 1488 request that is presented in a language that the requestor 1489 understands. 1491 Any such feature would have to be presented outside the XML Request 1492 message format since this needs to be kept as clean and compact and 1493 with as little room for ambiguity as possible. 1495 8. Security Considerations 1497 Consider spam control, how do users prevent unwanted requests? (EV 1498 accreditatio, filtering at dispatcher) 1500 People deploying OWCP as a means of controlling access to networking 1501 infrastructure must consider the bootstrap issue. In particular 1502 since OWCP requires Internet access the network administrator must 1503 ensure that it is possible to manage the network resources necessary 1504 to support an OXCP service when that service is down. 1506 9. IANA Considerations 1508 Mention the following: 1510 Registry of barcode encoding types (QR/DataMatrix/Bitfield) 1512 Register Schema URI 1513 Mime type for OWCP message? 1515 10. References 1517 10.1. Normative References 1519 [RFC1035] Mockapetris, P., "Domain names - implementation and 1520 specification", STD 13, RFC 1035, November 1987. 1522 10.2. Non Normative References 1524 [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA 1525 Considerations", RFC 5395, November 2008. 1527 Appendix A. Collected Schema 1529 1530 1536 1537 1538 1539 1540 1541 1542 1544 1545 1546 1547 1548 1550 1551 1553 1554 1555 1556 1558 1559 1561 1562 1563 1564 1565 1567 1568 1569 1570 1571 1572 1573 1574 1576 1578 1579 1580 1581 1582 1583 1585 1586 1588 1589 1590 1591 1592 1594 1595 1596 1597 1598 1599 1600 1602 1604 1605 1606 1607 1608 1609 1610 1611 1613 1614 1615 1616 1617 1619 1620 1621 1623 1625 Author's Address 1627 Phillip Hallam-Baker 1628 Comodo Group Inc. 1630 Email: philliph@comodo.com