idnits 2.17.1 draft-ietf-oauth-amr-values-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 28, 2017) is 2614 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group M. Jones 3 Internet-Draft Microsoft 4 Intended status: Standards Track P. Hunt 5 Expires: September 1, 2017 Oracle 6 A. Nadalin 7 Microsoft 8 February 28, 2017 10 Authentication Method Reference Values 11 draft-ietf-oauth-amr-values-06 13 Abstract 15 The "amr" (Authentication Methods References) claim is defined and 16 registered in the IANA "JSON Web Token Claims" registry but no 17 standard Authentication Method Reference values are currently 18 defined. This specification establishes a registry for 19 Authentication Method Reference values and defines an initial set of 20 Authentication Method Reference values. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 1, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Notation and Conventions . . . . . . . . . . 3 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Authentication Method Reference Values . . . . . . . . . . . 3 60 3. Relationship to "acr" (Authentication Context Class 61 Reference) . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 6.1. Authentication Method Reference Values Registry . . . . . 6 66 6.1.1. Registration Template . . . . . . . . . . . . . . . . 7 67 6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 8 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 7.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 72 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 13 73 Appendix C. Document History . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 The "amr" (Authentication Methods References) claim is defined and 79 registered in the IANA "JSON Web Token Claims" registry 80 [IANA.JWT.Claims] but no standard Authentication Method Reference 81 values are currently defined. This specification establishes a 82 registry for Authentication Method Reference values and defines an 83 initial set of Authentication Method Reference values. 85 For context, the "amr" (Authentication Methods References) claim is 86 defined by Section 2 of the OpenID Connect Core 1.0 specification 87 [OpenID.Core] as follows: 89 amr 90 OPTIONAL. Authentication Methods References. JSON array of 91 strings that are identifiers for authentication methods used in 92 the authentication. For instance, values might indicate that both 93 password and OTP authentication methods were used. The definition 94 of particular values to be used in the "amr" Claim is beyond the 95 scope of this specification. Parties using this claim will need 96 to agree upon the meanings of the values used, which may be 97 context-specific. The "amr" value is an array of case sensitive 98 strings. 100 The "amr" values defined by this specification is not intended to be 101 an exhaustive set covering all use cases. Additional values can and 102 will be added to the registry by other specifications. Rather, the 103 values defined herein are an intentionally small set that are already 104 actually being used in practice. 106 For context, while the claim values registered pertain to 107 authentication, note that OAuth 2.0 [RFC6749] is designed for 108 resource authorization and cannot be used for authentication without 109 employing appropriate extensions, such as those defined by OpenID 110 Connect Core 1.0 [OpenID.Core]. The existence of the "amr" claim and 111 values for it should not be taken as encouragement to try to use 112 OAuth 2.0 for authentication without employing extensions enabling 113 secure authentication to be performed. 115 When used with OpenID Connect, if the identity provider supplies an 116 "amr" claim in the ID Token resulting from a successful 117 authentication, the relying party can inspect the values returned and 118 thereby learn details about how the authentication was performed. 119 For instance, the relying party might learn that only a password was 120 used or it might learn that iris recognition was used in combination 121 with a hardware-secured key. Whether "amr" values are provided and 122 which values are understood by what parties are both beyond the scope 123 of this specification. The OpenID Connect MODRNA Authentication 124 Profile 1.0 [OpenID.MODRNA] is one example of an application context 125 that uses "amr" values defined by this specification. 127 1.1. Requirements Notation and Conventions 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in RFC 132 2119 [RFC2119]. 134 1.2. Terminology 136 This specification uses the terms defined by JSON Web Token (JWT) 137 [JWT] and OpenID Connect Core 1.0 [OpenID.Core]. 139 2. Authentication Method Reference Values 141 The following is a list of Authentication Method Reference values 142 defined by this specification: 144 face 145 Biometric authentication [RFC4949] using facial recognition 147 fpt 148 Biometric authentication [RFC4949] using a fingerprint 150 geo 151 Use of geolocation information for authentication, such as that 152 provided by [W3C.REC-geolocation-API-20161108] 154 hwk 155 Proof-of-possession (PoP) of a hardware-secured key. See 156 Appendix C of [RFC4211] for a discussion on PoP. 158 iris 159 Biometric authentication [RFC4949] using an iris scan 161 kba 162 Knowledge-based authentication [NIST.800-63-2] [ISO29115] 164 mca 165 Multiple-channel authentication [MCA]. The authentication 166 involves communication over more than one distinct communication 167 channel. For instance, a multiple-channel authentication might 168 involve both entering information into a workstation's browser and 169 providing information on a telephone call to a pre-registered 170 number. 172 mfa 173 Multiple-factor authentication [NIST.800-63-2] [ISO29115]. When 174 this is present, specific authentication methods used may also be 175 included. 177 otp 178 One-time password [RFC4949]. One-time password specifications 179 that this authentication method applies to include [RFC4226] and 180 [RFC6238]. 182 pin 183 Personal Identification Number (PIN) [RFC4949] or pattern (not 184 restricted to containing only numbers) that a user enters to 185 unlock a key on the device. This mechanism should have a way to 186 deter an attacker from obtaining the PIN by trying repeated 187 guesses. 189 pwd 190 Password-based authentication [RFC4949] 192 rba 193 Risk-based authentication [JECM] 195 retina 196 Biometric authentication [RFC4949] using a retina scan 198 sc 199 Smart card [RFC4949] 201 sms 202 Confirmation using SMS [SMS] text message to the user at a 203 registered number 205 swk 206 Proof-of-possession (PoP) of a software-secured key. See 207 Appendix C of [RFC4211] for a discussion on PoP. 209 tel 210 Confirmation by telephone call to the user at a registered number. 211 This authentication technique is sometimes also referred to as 212 "call back" [RFC4949]. 214 user 215 User presence test. Evidence that the end-user is present and 216 interacting with the device. This is sometimes also referred to 217 as "test of user presence" [W3C.WD-webauthn-20170216]. 219 vbm 220 Biometric authentication [RFC4949] using a voiceprint 222 wia 223 Windows integrated authentication [MSDN] 225 3. Relationship to "acr" (Authentication Context Class Reference) 227 The "acr" (Authentication Context Class Reference) claim and 228 "acr_values" request parameter are related to the "amr" 229 (Authentication Methods References) claim, but with important 230 differences. An Authentication Context Class specifies a set of 231 business rules that authentications are being requested to satisfy. 232 These rules can often be satisfied by using a number of different 233 specific authentication methods, either singly or in combination. 234 Interactions using "acr_values" request that the specified 235 Authentication Context Classes be used and that the result should 236 contain an "acr" claim saying which Authentication Context Class was 237 satisfied. The "acr" claim in the reply states that the business 238 rules for the class were satisfied -- not how they were satisfied. 240 In contrast, interactions using the "amr" claim make statements about 241 the particular authentication methods that were used. This tends to 242 be more brittle than using "acr", since the authentication methods 243 that may be appropriate for a given authentication will vary over 244 time, both because of the evolution of attacks on existing methods 245 and the deployment of new authentication methods. 247 4. Privacy Considerations 249 The list of "amr" claim values returned in an ID Token reveals 250 information about the way that the end-user authenticated to the 251 identity provider. In some cases, this information may have privacy 252 implications. 254 While this specification defines identifiers for particular kinds of 255 credentials, it does not define how these credentials are stored or 256 protected. For instance, ensuring the security and privacy of 257 biometric credentials that are referenced by some of the defined 258 Authentication Method Reference values is beyond the scope of this 259 specification. 261 5. Security Considerations 263 The security considerations in OpenID Connect Core 1.0 [OpenID.Core] 264 and OAuth 2.0 [RFC6749] and the OAuth 2.0 Threat Model [RFC6819] 265 apply to applications using this specification. 267 As described in Section 3, taking a dependence upon particular 268 authentication methods may result in brittle systems, since the 269 authentication methods that may be appropriate for a given 270 authentication will vary over time. 272 6. IANA Considerations 274 6.1. Authentication Method Reference Values Registry 276 This specification establishes the IANA "Authentication Method 277 Reference Values" registry for "amr" claim array element values. The 278 registry records the Authentication Method Reference value and a 279 reference to the specification that defines it. This specification 280 registers the Authentication Method Reference values defined in 281 Section 2. 283 Values are registered on an Expert Review [RFC5226] basis after a 284 three-week review period on the jwt-reg-review@ietf.org mailing list, 285 on the advice of one or more Designated Experts. To increase 286 potential interoperability, the experts are requested to encourage 287 registrants to provide the location of a publicly-accessible 288 specification defining the values being registered, so that their 289 intended usage can be more easily understood. 291 Registration requests sent to the mailing list for review should use 292 an appropriate subject (e.g., "Request to register Authentication 293 Method Reference value: otp"). 295 Within the review period, the Designated Experts will either approve 296 or deny the registration request, communicating this decision to the 297 review list and IANA. Denials should include an explanation and, if 298 applicable, suggestions as to how to make the request successful. 299 Registration requests that are undetermined for a period longer than 300 21 days can be brought to the IESG's attention (using the 301 iesg@ietf.org mailing list) for resolution. 303 IANA must only accept registry updates from the Designated Experts 304 and should direct all requests for registration to the review mailing 305 list. 307 It is suggested that the same Designated Experts evaluate these 308 registration requests as those who evaluate registration requests for 309 the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims]. 311 Criteria that should be applied by the Designated Experts includes 312 determining whether the proposed registration duplicates existing 313 functionality, whether it is likely to be of general applicability or 314 whether it is useful only for a single application, whether the value 315 is actually being used, and whether the registration description is 316 clear. 318 6.1.1. Registration Template 320 Authentication Method Reference Name: 321 The name requested (e.g., "otp"). Because a core goal of this 322 specification is for the resulting representations to be compact, 323 it is RECOMMENDED that the name be short -- that is, not to exceed 324 8 characters without a compelling reason to do so. To facilitate 325 interoperability, the name must use only printable ASCII 326 characters excluding double quote ('"') and backslash ('\') (the 327 Unicode characters with code points U+0021, U+0023 through U+005B, 328 and U+005D through U+007E). This name is case sensitive. Names 329 may not match other registered names in a case-insensitive manner 330 unless the Designated Experts state that there is a compelling 331 reason to allow an exception. 333 Authentication Method Reference Description: 334 Brief description of the Authentication Method Reference (e.g., 335 "One-time password"). 337 Change Controller: 338 For Standards Track RFCs, state "IESG". For others, give the name 339 of the responsible party. Other details (e.g., postal address, 340 email address, home page URI) may also be included. 342 Specification Document(s): 343 Reference to the document or documents that specify the parameter, 344 preferably including URIs that can be used to retrieve copies of 345 the documents. An indication of the relevant sections may also be 346 included but is not required. 348 6.1.2. Initial Registry Contents 350 o Authentication Method Reference Name: "face" 351 o Authentication Method Reference Description: Facial recognition 352 o Change Controller: IESG 353 o Specification Document(s): Section 2 of [[ this specification ]] 355 o Authentication Method Reference Name: "fpt" 356 o Authentication Method Reference Description: Fingerprint biometric 357 o Change Controller: IESG 358 o Specification Document(s): Section 2 of [[ this specification ]] 360 o Authentication Method Reference Name: "geo" 361 o Authentication Method Reference Description: Geolocation 362 o Change Controller: IESG 363 o Specification Document(s): Section 2 of [[ this specification ]] 365 o Authentication Method Reference Name: "hwk" 366 o Authentication Method Reference Description: Proof-of-possession 367 of a hardware-secured key 368 o Change Controller: IESG 369 o Specification Document(s): Section 2 of [[ this specification ]] 371 o Authentication Method Reference Name: "iris" 372 o Authentication Method Reference Description: Iris scan biometric 373 o Change Controller: IESG 374 o Specification Document(s): Section 2 of [[ this specification ]] 376 o Authentication Method Reference Name: "kba" 377 o Authentication Method Reference Description: Knowledge-based 378 authentication 379 o Change Controller: IESG 380 o Specification Document(s): Section 2 of [[ this specification ]] 382 o Authentication Method Reference Name: "mca" 383 o Authentication Method Reference Description: Multiple-channel 384 authentication 386 o Change Controller: IESG 387 o Specification Document(s): Section 2 of [[ this specification ]] 389 o Authentication Method Reference Name: "mfa" 390 o Authentication Method Reference Description: Multiple-factor 391 authentication 392 o Change Controller: IESG 393 o Specification Document(s): Section 2 of [[ this specification ]] 395 o Authentication Method Reference Name: "otp" 396 o Authentication Method Reference Description: One-time password 397 o Change Controller: IESG 398 o Specification Document(s): Section 2 of [[ this specification ]] 400 o Authentication Method Reference Name: "pin" 401 o Authentication Method Reference Description: Personal 402 Identification Number or pattern 403 o Change Controller: IESG 404 o Specification Document(s): Section 2 of [[ this specification ]] 406 o Authentication Method Reference Name: "pwd" 407 o Authentication Method Reference Description: Password-based 408 authentication 409 o Change Controller: IESG 410 o Specification Document(s): Section 2 of [[ this specification ]] 412 o Authentication Method Reference Name: "rba" 413 o Authentication Method Reference Description: Risk-based 414 authentication 415 o Change Controller: IESG 416 o Specification Document(s): Section 2 of [[ this specification ]] 418 o Authentication Method Reference Name: "retina" 419 o Authentication Method Reference Description: Retina scan biometric 420 o Change Controller: IESG 421 o Specification Document(s): Section 2 of [[ this specification ]] 423 o Authentication Method Reference Name: "sc" 424 o Authentication Method Reference Description: Smart card 425 o Change Controller: IESG 426 o Specification Document(s): Section 2 of [[ this specification ]] 428 o Authentication Method Reference Name: "sms" 429 o Authentication Method Reference Description: Confirmation using 430 SMS 431 o Change Controller: IESG 432 o Specification Document(s): Section 2 of [[ this specification ]] 433 o Authentication Method Reference Name: "swk" 434 o Authentication Method Reference Description: Proof-of-possession 435 of a software-secured key 436 o Change Controller: IESG 437 o Specification Document(s): Section 2 of [[ this specification ]] 439 o Authentication Method Reference Name: "tel" 440 o Authentication Method Reference Description: Confirmation by 441 telephone call 442 o Change Controller: IESG 443 o Specification Document(s): Section 2 of [[ this specification ]] 445 o Authentication Method Reference Name: "user" 446 o Authentication Method Reference Description: User presence test 447 o Change Controller: IESG 448 o Specification Document(s): Section 2 of [[ this specification ]] 450 o Authentication Method Reference Name: "vbm" 451 o Authentication Method Reference Description: Voice biometric 452 o Change Controller: IESG 453 o Specification Document(s): Section 2 of [[ this specification ]] 455 o Authentication Method Reference Name: "wia" 456 o Authentication Method Reference Description: Windows integrated 457 authentication 458 o Change Controller: IESG 459 o Specification Document(s): Section 2 of [[ this specification ]] 461 7. References 463 7.1. Normative References 465 [IANA.JWT.Claims] 466 IANA, "JSON Web Token Claims", 467 . 469 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 470 (JWT)", RFC 7519, May 2015, 471 . 473 [OpenID.Core] 474 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 475 C. Mortimore, "OpenID Connect Core 1.0", November 2014, 476 . 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, 480 DOI 10.17487/RFC2119, March 1997, 481 . 483 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 484 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 485 DOI 10.17487/RFC5226, May 2008, 486 . 488 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 489 RFC 6749, DOI 10.17487/RFC6749, October 2012, 490 . 492 7.2. Informative References 494 [ISO29115] 495 International Organization for Standardization, "ISO/IEC 496 29115:2013 -- Information technology - Security techniques 497 - Entity authentication assurance framework", ISO/ 498 IEC 29115:2013, April 2013, 499 . 502 [JECM] Williamson, G., "Enhanced Authentication In Online 503 Banking", Journal of Economic Crime Management 4.2: 18-19, 504 2006, 505 . 508 [MCA] ldapwiki.com, "Multiple-channel Authentication", August 509 2016, . 512 [MSDN] Microsoft, "Integrated Windows Authentication with 513 Negotiate", September 2011, 514 . 518 [NIST.800-63-2] 519 National Institute of Standards and Technology (NIST), 520 "Electronic Authentication Guideline", NIST Special 521 Publication 800-63-2, August 2013, 522 . 525 [OpenID.MODRNA] 526 Connotte, J. and J. Bradley, "OpenID Connect MODRNA 527 Authentication Profile 1.0", September 2016, 528 . 531 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 532 Certificate Request Message Format (CRMF)", RFC 4211, 533 DOI 10.17487/RFC4211, September 2005, 534 . 536 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 537 O. Ranen, "HOTP: An HMAC-Based One-Time Password 538 Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, 539 . 541 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 542 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 543 . 545 [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: 546 Time-Based One-Time Password Algorithm", RFC 6238, 547 DOI 10.17487/RFC6238, May 2011, 548 . 550 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 551 Threat Model and Security Considerations", RFC 6819, 552 DOI 10.17487/RFC6819, January 2013, 553 . 555 [SMS] 3rd Generation Partnership Project, "Technical realization 556 of the Short Message Service (SMS)", 3GPP Technical 557 Specification (TS) 03.40 V7.5.0 (2001-12), January 2002, 558 . 561 [W3C.REC-geolocation-API-20161108] 562 Popescu, A., "Geolocation API Specification 2nd Edition", 563 World Wide Web Consortium Recommendation REC-geolocation- 564 API-20161108, November 2016, . 567 [W3C.WD-webauthn-20170216] 568 Bharadwaj, V., Le Van Gong, H., Balfanz, D., Czeskis, A., 569 Birgisson, A., Hodges, J., Jones, M., Lindemann, R., and 570 J. Jones, "Web Authentication: An API for accessing Scoped 571 Credentials", World Wide Web Consortium Working Draft WD- 572 webauthn-20170216, February 2017, 573 . 575 Appendix A. Examples 577 In some cases, the "amr" claim value returned may contain a single 578 Authentication Method Reference value. For example, the following 579 "amr" claim value indicates that the authentication performed used an 580 iris scan biometric: 582 "amr": ["iris"] 584 In other cases, the "amr" claim value returned may contain multiple 585 Authentication Method Reference values. For example, the following 586 "amr" claim value indicates that the authentication performed used a 587 password and knowledge-based authentication: 589 "amr": ["pwd", "kba"] 591 Appendix B. Acknowledgements 593 Caleb Baker participated in specifying the original set of "amr" 594 values. Jari Arkko, John Bradley, Ben Campbell, Brian Campbell, 595 William Denniss, Linda Dunbar, Stephen Farrell, Paul Kyzivat, Elaine 596 Newton, James Manger, Catherine Meadows, Alexey Melnikov, Kathleen 597 Moriarty, Nat Sakimura, and Mike Schwartz provided reviews of the 598 specification. 600 Appendix C. Document History 602 [[ to be removed by the RFC editor before publication as an RFC ]] 604 -05 606 o Addressed IESG comments. Identifiers are now restricted to using 607 only printable JSON-friendly ASCII characters. Additional 608 references to documentation relevant to specific AMR values were 609 added. 611 -05 613 o Specified characters allowed in "amr" values, reusing the IANA 614 Considerations language on this topic from RFC 7638. 616 -04 618 o Added examples with single and multiple values. 619 o Clarified that the actual credentials referenced are not part of 620 this specification to avoid additional privacy concerns for 621 biometric data. 622 o Clarified that the OAuth 2.0 Threat Model [RFC6819] applies to 623 applications using this specification. 625 -03 627 o Addressed shepherd comments. 629 -02 631 o Addressed working group last call comments. 633 -01 635 o Distinguished between retina and iris biometrics. 636 o Expanded the introduction to provide additional context to 637 readers. 638 o Referenced the OpenID Connect MODRNA Authentication Profile 1.0 639 specification, which uses "amr" values defined by this 640 specification. 642 -00 644 o Created the initial working group draft from draft-jones-oauth- 645 amr-values-05 with no normative changes. 647 Authors' Addresses 649 Michael B. Jones 650 Microsoft 652 Email: mbj@microsoft.com 653 URI: http://self-issued.info/ 655 Phil Hunt 656 Oracle 658 Email: phil.hunt@yahoo.com 659 Anthony Nadalin 660 Microsoft 662 Email: tonynad@microsoft.com