idnits 2.17.1 draft-ietf-oauth-amr-values-08.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 (March 13, 2017) is 2601 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 14, 2017 Oracle 6 A. Nadalin 7 Microsoft 8 March 13, 2017 10 Authentication Method Reference Values 11 draft-ietf-oauth-amr-values-08 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 14, 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 . . . . . . . . . . 4 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Authentication Method Reference Values . . . . . . . . . . . 4 60 3. Relationship to "acr" (Authentication Context Class 61 Reference) . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 6.1. Authentication Method Reference Values Registry . . . . . 7 66 6.1.1. Registration Template . . . . . . . . . . . . . . . . 8 67 6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 9 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 70 7.2. Informative References . . . . . . . . . . . . . . . . . 12 71 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 72 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14 73 Appendix C. Document History . . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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 Each "amr" value typically provides an identifier for a family of 101 closely-related authentication methods. For example, the "otp" 102 identifier intentionally covers both time-based and HMAC-based OTPs. 103 Many relying parties will be content to know that an OTP has been 104 used in addition to a password; the distinction between which kind of 105 OTP was used is not useful to them. Thus, there's a single 106 identifier that can be satisfied in two or more nearly equivalent 107 ways. 109 Similarly, there's a whole range of nuances between different 110 fingerprint matching algorithms. They differ in false positive and 111 false negative rates over different population samples and also 112 differ based on the kind and model of fingerprint sensor used. Like 113 the OTP case, many relying parties will be content to know that a 114 fingerprint match mas made, without delving into and differentiating 115 based on every aspect of the implementation of fingerprint capture 116 and match. The "fpt" identifier accomplishes this. 118 Ultimately, the relying party is depending upon the identity provider 119 to do reasonable things. If it does not trust the identity provider 120 to do so, it has no business using it. The "amr" value lets the 121 identity provider signal to the relying party additional information 122 about what it did, for the cases in which that information is useful 123 to the relying party. 125 The "amr" values defined by this specification are not intended to be 126 an exhaustive set covering all use cases. Additional values can and 127 will be added to the registry by other specifications. Rather, the 128 values defined herein are an intentionally small set that are already 129 actually being used in practice. 131 The values defined by this specification only make distinctions that 132 are known to be useful to relying parties. Slicing things more 133 finely than would be used in practice would actually hurt interop, 134 rather than helping it, because it would force relying parties to 135 recognize that several or many different values actually mean the 136 same thing to them. 138 For context, while the claim values registered pertain to 139 authentication, note that OAuth 2.0 [RFC6749] is designed for 140 resource authorization and cannot be used for authentication without 141 employing appropriate extensions, such as those defined by OpenID 142 Connect Core 1.0 [OpenID.Core]. The existence of the "amr" claim and 143 values for it should not be taken as encouragement to try to use 144 OAuth 2.0 for authentication without employing extensions enabling 145 secure authentication to be performed. 147 When used with OpenID Connect, if the identity provider supplies an 148 "amr" claim in the ID Token resulting from a successful 149 authentication, the relying party can inspect the values returned and 150 thereby learn details about how the authentication was performed. 151 For instance, the relying party might learn that only a password was 152 used or it might learn that iris recognition was used in combination 153 with a hardware-secured key. Whether "amr" values are provided and 154 which values are understood by what parties are both beyond the scope 155 of this specification. The OpenID Connect MODRNA Authentication 156 Profile 1.0 [OpenID.MODRNA] is one example of an application context 157 that uses "amr" values defined by this specification. 159 1.1. Requirements Notation and Conventions 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in RFC 164 2119 [RFC2119]. 166 1.2. Terminology 168 This specification uses the terms defined by JSON Web Token (JWT) 169 [JWT] and OpenID Connect Core 1.0 [OpenID.Core]. 171 2. Authentication Method Reference Values 173 The following is a list of Authentication Method Reference values 174 defined by this specification: 176 face 177 Biometric authentication [RFC4949] using facial recognition 179 fpt 180 Biometric authentication [RFC4949] using a fingerprint 182 geo 183 Use of geolocation information for authentication, such as that 184 provided by [W3C.REC-geolocation-API-20161108] 186 hwk 187 Proof-of-possession (PoP) of a hardware-secured key. See 188 Appendix C of [RFC4211] for a discussion on PoP. 190 iris 191 Biometric authentication [RFC4949] using an iris scan 193 kba 194 Knowledge-based authentication [NIST.800-63-2] [ISO29115] 196 mca 197 Multiple-channel authentication [MCA]. The authentication 198 involves communication over more than one distinct communication 199 channel. For instance, a multiple-channel authentication might 200 involve both entering information into a workstation's browser and 201 providing information on a telephone call to a pre-registered 202 number. 204 mfa 205 Multiple-factor authentication [NIST.800-63-2] [ISO29115]. When 206 this is present, specific authentication methods used may also be 207 included. 209 otp 210 One-time password [RFC4949]. One-time password specifications 211 that this authentication method applies to include [RFC4226] and 212 [RFC6238]. 214 pin 215 Personal Identification Number (PIN) [RFC4949] or pattern (not 216 restricted to containing only numbers) that a user enters to 217 unlock a key on the device. This mechanism should have a way to 218 deter an attacker from obtaining the PIN by trying repeated 219 guesses. 221 pwd 222 Password-based authentication [RFC4949] 224 rba 225 Risk-based authentication [JECM] 227 retina 228 Biometric authentication [RFC4949] using a retina scan 230 sc 231 Smart card [RFC4949] 233 sms 234 Confirmation using SMS [SMS] text message to the user at a 235 registered number 237 swk 238 Proof-of-possession (PoP) of a software-secured key. See 239 Appendix C of [RFC4211] for a discussion on PoP. 241 tel 242 Confirmation by telephone call to the user at a registered number. 243 This authentication technique is sometimes also referred to as 244 "call back" [RFC4949]. 246 user 247 User presence test. Evidence that the end-user is present and 248 interacting with the device. This is sometimes also referred to 249 as "test of user presence" [W3C.WD-webauthn-20170216]. 251 vbm 252 Biometric authentication [RFC4949] using a voiceprint 254 wia 255 Windows integrated authentication [MSDN] 257 3. Relationship to "acr" (Authentication Context Class Reference) 259 The "acr" (Authentication Context Class Reference) claim and 260 "acr_values" request parameter are related to the "amr" 261 (Authentication Methods References) claim, but with important 262 differences. An Authentication Context Class specifies a set of 263 business rules that authentications are being requested to satisfy. 264 These rules can often be satisfied by using a number of different 265 specific authentication methods, either singly or in combination. 266 Interactions using "acr_values" request that the specified 267 Authentication Context Classes be used and that the result should 268 contain an "acr" claim saying which Authentication Context Class was 269 satisfied. The "acr" claim in the reply states that the business 270 rules for the class were satisfied -- not how they were satisfied. 272 In contrast, interactions using the "amr" claim make statements about 273 the particular authentication methods that were used. This tends to 274 be more brittle than using "acr", since the authentication methods 275 that may be appropriate for a given authentication will vary over 276 time, both because of the evolution of attacks on existing methods 277 and the deployment of new authentication methods. 279 4. Privacy Considerations 281 The list of "amr" claim values returned in an ID Token reveals 282 information about the way that the end-user authenticated to the 283 identity provider. In some cases, this information may have privacy 284 implications. 286 While this specification defines identifiers for particular kinds of 287 credentials, it does not define how these credentials are stored or 288 protected. For instance, ensuring the security and privacy of 289 biometric credentials that are referenced by some of the defined 290 Authentication Method Reference values is beyond the scope of this 291 specification. 293 5. Security Considerations 295 The security considerations in OpenID Connect Core 1.0 [OpenID.Core] 296 and OAuth 2.0 [RFC6749] and the OAuth 2.0 Threat Model [RFC6819] 297 apply to applications using this specification. 299 As described in Section 3, taking a dependence upon particular 300 authentication methods may result in brittle systems since the 301 authentication methods that may be appropriate for a given 302 authentication will vary over time. 304 6. IANA Considerations 306 6.1. Authentication Method Reference Values Registry 308 This specification establishes the IANA "Authentication Method 309 Reference Values" registry for "amr" claim array element values. The 310 registry records the Authentication Method Reference value and a 311 reference to the specification that defines it. This specification 312 registers the Authentication Method Reference values defined in 313 Section 2. 315 Values are registered on an Expert Review [RFC5226] basis after a 316 three-week review period on the jwt-reg-review@ietf.org mailing list, 317 on the advice of one or more Designated Experts. To increase 318 potential interoperability, the experts are requested to encourage 319 registrants to provide the location of a publicly-accessible 320 specification defining the values being registered, so that their 321 intended usage can be more easily understood. 323 Registration requests sent to the mailing list for review should use 324 an appropriate subject (e.g., "Request to register Authentication 325 Method Reference value: otp"). 327 Within the review period, the Designated Experts will either approve 328 or deny the registration request, communicating this decision to the 329 review list and IANA. Denials should include an explanation and, if 330 applicable, suggestions as to how to make the request successful. 331 Registration requests that are undetermined for a period longer than 332 21 days can be brought to the IESG's attention (using the 333 iesg@ietf.org mailing list) for resolution. 335 IANA must only accept registry updates from the Designated Experts 336 and should direct all requests for registration to the review mailing 337 list. 339 It is suggested that the same Designated Experts evaluate these 340 registration requests as those who evaluate registration requests for 341 the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims]. 343 Criteria that should be applied by the Designated Experts includes 344 determining whether the proposed registration duplicates existing 345 functionality, whether it is likely to be of general applicability or 346 whether it is useful only for a single application, whether the value 347 is actually being used, and whether the registration description is 348 clear. 350 6.1.1. Registration Template 352 Authentication Method Reference Name: 353 The name requested (e.g., "otp") for the authentication method or 354 family of closely-related authentication methods. Because a core 355 goal of this specification is for the resulting representations to 356 be compact, it is RECOMMENDED that the name be short -- that is, 357 not to exceed 8 characters without a compelling reason to do so. 358 To facilitate interoperability, the name must use only printable 359 ASCII characters excluding double quote ('"') and backslash ('\') 360 (the Unicode characters with code points U+0021, U+0023 through 361 U+005B, and U+005D through U+007E). This name is case sensitive. 362 Names may not match other registered names in a case-insensitive 363 manner unless the Designated Experts state that there is a 364 compelling reason to allow an exception. 366 Authentication Method Reference Description: 367 Brief description of the Authentication Method Reference (e.g., 368 "One-time password"). 370 Change Controller: 371 For Standards Track RFCs, state "IESG". For others, give the name 372 of the responsible party. Other details (e.g., postal address, 373 email address, home page URI) may also be included. 375 Specification Document(s): 376 Reference to the document or documents that specify the parameter, 377 preferably including URIs that can be used to retrieve copies of 378 the documents. An indication of the relevant sections may also be 379 included but is not required. 381 6.1.2. Initial Registry Contents 383 o Authentication Method Reference Name: "face" 384 o Authentication Method Reference Description: Facial recognition 385 o Change Controller: IESG 386 o Specification Document(s): Section 2 of [[ this specification ]] 388 o Authentication Method Reference Name: "fpt" 389 o Authentication Method Reference Description: Fingerprint biometric 390 o Change Controller: IESG 391 o Specification Document(s): Section 2 of [[ this specification ]] 393 o Authentication Method Reference Name: "geo" 394 o Authentication Method Reference Description: Geolocation 395 o Change Controller: IESG 396 o Specification Document(s): Section 2 of [[ this specification ]] 398 o Authentication Method Reference Name: "hwk" 399 o Authentication Method Reference Description: Proof-of-possession 400 of a hardware-secured key 401 o Change Controller: IESG 402 o Specification Document(s): Section 2 of [[ this specification ]] 404 o Authentication Method Reference Name: "iris" 405 o Authentication Method Reference Description: Iris scan biometric 406 o Change Controller: IESG 407 o Specification Document(s): Section 2 of [[ this specification ]] 409 o Authentication Method Reference Name: "kba" 410 o Authentication Method Reference Description: Knowledge-based 411 authentication 412 o Change Controller: IESG 413 o Specification Document(s): Section 2 of [[ this specification ]] 415 o Authentication Method Reference Name: "mca" 416 o Authentication Method Reference Description: Multiple-channel 417 authentication 418 o Change Controller: IESG 419 o Specification Document(s): Section 2 of [[ this specification ]] 421 o Authentication Method Reference Name: "mfa" 422 o Authentication Method Reference Description: Multiple-factor 423 authentication 424 o Change Controller: IESG 425 o Specification Document(s): Section 2 of [[ this specification ]] 427 o Authentication Method Reference Name: "otp" 428 o Authentication Method Reference Description: One-time password 429 o Change Controller: IESG 430 o Specification Document(s): Section 2 of [[ this specification ]] 432 o Authentication Method Reference Name: "pin" 433 o Authentication Method Reference Description: Personal 434 Identification Number or pattern 435 o Change Controller: IESG 436 o Specification Document(s): Section 2 of [[ this specification ]] 438 o Authentication Method Reference Name: "pwd" 439 o Authentication Method Reference Description: Password-based 440 authentication 441 o Change Controller: IESG 442 o Specification Document(s): Section 2 of [[ this specification ]] 444 o Authentication Method Reference Name: "rba" 445 o Authentication Method Reference Description: Risk-based 446 authentication 447 o Change Controller: IESG 448 o Specification Document(s): Section 2 of [[ this specification ]] 450 o Authentication Method Reference Name: "retina" 451 o Authentication Method Reference Description: Retina scan biometric 452 o Change Controller: IESG 453 o Specification Document(s): Section 2 of [[ this specification ]] 455 o Authentication Method Reference Name: "sc" 456 o Authentication Method Reference Description: Smart card 457 o Change Controller: IESG 458 o Specification Document(s): Section 2 of [[ this specification ]] 460 o Authentication Method Reference Name: "sms" 461 o Authentication Method Reference Description: Confirmation using 462 SMS 463 o Change Controller: IESG 464 o Specification Document(s): Section 2 of [[ this specification ]] 466 o Authentication Method Reference Name: "swk" 467 o Authentication Method Reference Description: Proof-of-possession 468 of a software-secured key 469 o Change Controller: IESG 470 o Specification Document(s): Section 2 of [[ this specification ]] 472 o Authentication Method Reference Name: "tel" 473 o Authentication Method Reference Description: Confirmation by 474 telephone call 475 o Change Controller: IESG 476 o Specification Document(s): Section 2 of [[ this specification ]] 477 o Authentication Method Reference Name: "user" 478 o Authentication Method Reference Description: User presence test 479 o Change Controller: IESG 480 o Specification Document(s): Section 2 of [[ this specification ]] 482 o Authentication Method Reference Name: "vbm" 483 o Authentication Method Reference Description: Voice biometric 484 o Change Controller: IESG 485 o Specification Document(s): Section 2 of [[ this specification ]] 487 o Authentication Method Reference Name: "wia" 488 o Authentication Method Reference Description: Windows integrated 489 authentication 490 o Change Controller: IESG 491 o Specification Document(s): Section 2 of [[ this specification ]] 493 7. References 495 7.1. Normative References 497 [IANA.JWT.Claims] 498 IANA, "JSON Web Token Claims", 499 . 501 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 502 (JWT)", RFC 7519, May 2015, 503 . 505 [OpenID.Core] 506 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 507 C. Mortimore, "OpenID Connect Core 1.0", November 2014, 508 . 510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 511 Requirement Levels", BCP 14, RFC 2119, 512 DOI 10.17487/RFC2119, March 1997, 513 . 515 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 516 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 517 DOI 10.17487/RFC5226, May 2008, 518 . 520 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 521 RFC 6749, DOI 10.17487/RFC6749, October 2012, 522 . 524 7.2. Informative References 526 [ISO29115] 527 International Organization for Standardization, "ISO/IEC 528 29115:2013 -- Information technology - Security techniques 529 - Entity authentication assurance framework", ISO/ 530 IEC 29115:2013, April 2013, 531 . 534 [JECM] Williamson, G., "Enhanced Authentication In Online 535 Banking", Journal of Economic Crime Management 4.2: 18-19, 536 2006, 537 . 540 [MCA] ldapwiki.com, "Multiple-channel Authentication", August 541 2016, . 544 [MSDN] Microsoft, "Integrated Windows Authentication with 545 Negotiate", September 2011, 546 . 550 [NIST.800-63-2] 551 National Institute of Standards and Technology (NIST), 552 "Electronic Authentication Guideline", NIST Special 553 Publication 800-63-2, August 2013, 554 . 557 [OpenID.MODRNA] 558 Connotte, J. and J. Bradley, "OpenID Connect MODRNA 559 Authentication Profile 1.0", March 2017, 560 . 563 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 564 Certificate Request Message Format (CRMF)", RFC 4211, 565 DOI 10.17487/RFC4211, September 2005, 566 . 568 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 569 O. Ranen, "HOTP: An HMAC-Based One-Time Password 570 Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, 571 . 573 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 574 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 575 . 577 [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: 578 Time-Based One-Time Password Algorithm", RFC 6238, 579 DOI 10.17487/RFC6238, May 2011, 580 . 582 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 583 Threat Model and Security Considerations", RFC 6819, 584 DOI 10.17487/RFC6819, January 2013, 585 . 587 [SMS] 3rd Generation Partnership Project, "Technical realization 588 of the Short Message Service (SMS)", 3GPP Technical 589 Specification (TS) 03.40 V7.5.0 (2001-12), January 2002, 590 . 593 [W3C.REC-geolocation-API-20161108] 594 Popescu, A., "Geolocation API Specification 2nd Edition", 595 World Wide Web Consortium Recommendation REC-geolocation- 596 API-20161108, November 2016, . 599 [W3C.WD-webauthn-20170216] 600 Bharadwaj, V., Le Van Gong, H., Balfanz, D., Czeskis, A., 601 Birgisson, A., Hodges, J., Jones, M., Lindemann, R., and 602 J. Jones, "Web Authentication: An API for accessing Scoped 603 Credentials", World Wide Web Consortium Working Draft WD- 604 webauthn-20170216, February 2017, 605 . 607 Appendix A. Examples 609 In some cases, the "amr" claim value returned may contain a single 610 Authentication Method Reference value. For example, the following 611 "amr" claim value indicates that the authentication performed used an 612 iris scan biometric: 614 "amr": ["iris"] 616 In other cases, the "amr" claim value returned may contain multiple 617 Authentication Method Reference values. For example, the following 618 "amr" claim value indicates that the authentication performed used a 619 password and knowledge-based authentication: 621 "amr": ["pwd", "kba"] 623 Appendix B. Acknowledgements 625 Caleb Baker participated in specifying the original set of "amr" 626 values. Jari Arkko, John Bradley, Ben Campbell, Brian Campbell, 627 William Denniss, Linda Dunbar, Stephen Farrell, Paul Kyzivat, Elaine 628 Newton, James Manger, Catherine Meadows, Alexey Melnikov, Kathleen 629 Moriarty, Nat Sakimura, and Mike Schwartz provided reviews of the 630 specification. 632 Appendix C. Document History 634 [[ to be removed by the RFC editor before publication as an RFC ]] 636 -08 638 o Added text in the IANA Registration Template saying that names can 639 be for families of closely-related authentication methods, as 640 suggested by Stephen Farrell. 642 -07 644 o Clarified that the values are intended to provide identifiers for 645 families of closely-related authentication methods. 646 o Updated the MODRNA Authentication Profile reference. 648 -06 650 o Addressed IESG comments. Identifiers are now restricted to using 651 only printable JSON-friendly ASCII characters. Additional 652 references to documentation relevant to specific AMR values were 653 added. 655 -05 657 o Specified characters allowed in "amr" values, reusing the IANA 658 Considerations language on this topic from RFC 7638. 660 -04 662 o Added examples with single and multiple values. 663 o Clarified that the actual credentials referenced are not part of 664 this specification to avoid additional privacy concerns for 665 biometric data. 666 o Clarified that the OAuth 2.0 Threat Model [RFC6819] applies to 667 applications using this specification. 669 -03 671 o Addressed shepherd comments. 673 -02 675 o Addressed working group last call comments. 677 -01 679 o Distinguished between retina and iris biometrics. 680 o Expanded the introduction to provide additional context to 681 readers. 682 o Referenced the OpenID Connect MODRNA Authentication Profile 1.0 683 specification, which uses "amr" values defined by this 684 specification. 686 -00 688 o Created the initial working group draft from draft-jones-oauth- 689 amr-values-05 with no normative changes. 691 Authors' Addresses 693 Michael B. Jones 694 Microsoft 696 Email: mbj@microsoft.com 697 URI: http://self-issued.info/ 699 Phil Hunt 700 Oracle 702 Email: phil.hunt@yahoo.com 704 Anthony Nadalin 705 Microsoft 707 Email: tonynad@microsoft.com