idnits 2.17.1 draft-miller-microid-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 546. 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 11, 2007) is 5975 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2368 (ref. 'MAILTO') (Obsoleted by RFC 6068) -- Obsolete informational reference (is this intentional?): RFC 4622 (ref. 'XMPP') (Obsoleted by RFC 5122) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Miller 3 Internet-Draft P. Saint-Andre 4 Intended status: Informational 5 Expires: June 13, 2008 F. Stutzman 6 ClaimID 7 December 11, 2007 9 MicroID 10 draft-miller-microid-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on June 13, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This specification defines MicroID, a lightweight identity technology 44 that enables the creation of a portable identity token based on any 45 two Uniform Resource Identifiers. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.3. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 3 53 1.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 3 54 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Generation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 5. Meaning . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.2. Generating Applications . . . . . . . . . . . . . . . . . 7 60 5.3. Using Technologies . . . . . . . . . . . . . . . . . . . . 8 61 6. Internationalization Considerations . . . . . . . . . . . . . 9 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 66 Appendix A. Legacy Support . . . . . . . . . . . . . . . . . . . 11 67 Appendix B. Copying Conditions . . . . . . . . . . . . . . . . . 11 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 69 Intellectual Property and Copyright Statements . . . . . . . . . . 13 71 1. Introduction 73 1.1. Overview 75 MicroID is a lightweight identity technology that enables the 76 creation of a portable identity token from any two Uniform Resource 77 Identifiers [URI]. 79 Such identity tokens are desirable because they: 81 o Enable individuals to assert ownership over information published 82 and reputation earned on the Internet in a granular manner. 83 o Enable service providers to "stamp" information and reputation 84 based on a validated URI associated with an individual who uses 85 the service. 87 1.2. Terminology 89 The following keywords as used in this document are to be interpreted 90 as described in [TERMS]: "MUST", "SHALL", "REQUIRED"; "MUST NOT", 91 "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT 92 RECOMMENDED"; "MAY", "OPTIONAL". 94 1.3. Discussion Venue 96 The preferred discussion forum for this specification is the MicroID 97 mailing list; subscription information is located at 98 and the mailing 99 list archives are located at 100 . 102 1.4. Acknowledgements 104 Thanks to James Cridland, Yaniv Golan, David Koblas, Paco Nathan, 105 Will Norris, Evan Prodromou, Chris Roos, Terrell Russell, Eran 106 Sandler, and Brian Suda for their feedback. 108 2. Format 110 The syntax for a MicroID is defined as follows, using the Augmented 111 Backus-Naur Form specified in [ABNF]. 113 microid = inputs ":" algo ":" hash 114 inputs = scheme "+" scheme 115 scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) 116 ; a URI scheme name (e.g., mailto) 117 algo = ALPHA *( ALPHA / DIGIT ) 118 ; the short name of a hashing 119 ; algorithm (e.g., sha256), 120 hash = *( ALPHA / DIGIT ) 121 ; a hash of the URIs for both entities 123 Note: If the URI scheme name includes the "+" character (which is 124 allowed by [URI] but not in common use), that character MUST be 125 escaped to %2B. 127 Note: The algorithm names should be as registered with the IANA in 128 the Hash Function Textual Names registry located at 129 , but may 130 exclude the "-" character (e.g., "sha1" rather than "sha-1"). 132 Note: See the Legacy Support (Appendix A) section of this document 133 for information regarding the original MicroID format. 135 3. Generation 137 The method for generating the hash is: 139 hash = algo( 140 algo(EntityURI) 141 + 142 algo(EntityURI) 143 ) 145 The "algo" MAY be any recognized hashing algorithm, such as those 146 defined in [SHA]. Support for the sha1 and sha256 algorithms is 147 REQUIRED for interoperability. The output MUST be in hexadecimal 148 (not base64) format. The same algorithm MUST be used for all hashing 149 functions when generating a given MicroID. 151 The "EntityURI" MAY conform to any URI scheme, such as [HTTP], 152 [MAILTO], [SIP], or [XMPP]. 154 As an example, consider the following inputs, from which a MicroID is 155 generated using the sha1 algorithm: 157 o The first entity is an individual identified by an XMPP URI of 158 "xmpp:stpeter@jabber.org". 160 o The second entity is a service provider identified by an HTTP URI 161 of "https://www.xmpp.net/". 163 The hash is generated as follows (note: the line break in the third 164 example is included only for the sake of readability): 166 sha1( 167 sha1(xmpp:stpeter@jabber.org) 168 + 169 sha1(https://www.xmpp.net/) 170 ) 172 sha1( 173 afa6353518f818af2f036da336c3097dedc00dee 174 + 175 3115de01ebfa34a34314060b5f30038b0fa359f8 176 ) 178 sha1( 179 afa6353518f818af2f036da336c3097dedc00dee 180 3115de01ebfa34a34314060b5f30038b0fa359f8 181 ) 183 6196ea6709be2a4cbdf2bc0cfaeac491f2fb8921 185 Thus in accordance with the format previously described the issued 186 MicroID is: 188 xmpp+https:sha1:6196ea6709be2a4cbdf2bc0cfaeac491f2fb8921 190 4. Processing 192 A processing application MAY use only the hash portion of the MicroID 193 for comparison purposes. An implementation SHOULD be liberal in 194 accepting MicroIDs that conform to the legacy format; for details, 195 see the Legacy Support (Appendix A) section of this document. 197 5. Meaning 199 5.1. Overview 201 By itself, a MicroID has no inherent meaning, since it is simply a 202 string created from two URIs. Any entity can generate a MicroID even 203 if it has not verified the identity of the resources associated with 204 one or both URIs. Furthermore, a MicroID is easily copied by an 205 entity that did not generate it. Finally, a MicroID is not digitally 206 signed by the entity that generated it and therefore cannot be 207 cryptographically associated with the generating entity. 209 Therefore it may be wondered: what is the meaning of a MicroID? The 210 answer is: any meaning imputed to a MicroID results from the context 211 in which it is used. That context includes the nature of the 212 generating application and the nature of the using technology. 214 Some possible generating applications and using technologies are 215 described in the following sections. We use the following terms to 216 describe the parties involved in the generation and processing of a 217 MicroID: 219 o Consumer -- Any party that reads a MicroID issued by an Issuer (in 220 other identity systems, a consumer is sometimes called a relying 221 party). 222 o Entity -- Either party identified by a URI or IRI that is used to 223 construct a MicroID. 224 o Individual -- An entity that generates information or earns 225 reputation. 226 o Issuer -- The party that generates a MicroID. The issuer can be a 227 third party and need not be an entity. 228 o Service Provider -- An entity that is responsible for hosting 229 information or reputation; a service provider may or may not be an 230 issuer. 232 A MicroID should be generated by an issuer, not by an individual. 233 The issuer may be the service provider that hosts the information 234 about, content created by, or reputation earned by an individual, or 235 it may be a third party trusted by both the individual and the 236 service provider. 238 An issuer should not generate a MicroID until it has verified that 239 the individual or service provider has control over a given entity 240 URI. Methods for such verification are out of scope for this 241 specification and may vary according to local service policies and 242 the URI scheme in question. 244 The first entity URI should be that of the individual and the second 245 EntityURI should be that of the service provider. Any given entity 246 URI may have meaning above and beyond that encapsulated in the 247 relevant URI scheme; for example, the HTTP URI for an individual 248 could be hosted by an OpenID service (see ). 249 However, MicroID places no restrictions on the semantics of a given 250 entity URI. 252 5.2. Generating Applications 254 5.2.1. Service Provider 256 It is envisioned that one common deployment scenario will be that of 257 a service provider "stamping" information or reputation that is 258 hosted by the service provider on behalf of individuals. In this 259 architecture, the service provider is both the issuer and one of the 260 entities, where the other entity is an individual. 262 +--------+ 263 | Entity | 264 +--------+ 265 | 266 | registration 267 | 268 +-------------------+ 269 | Service Provider | 270 | (Entity + Issuer) | 271 +-------------------+ 272 | 273 | issuance 274 | 275 MicroID 277 Whether a given consumer imputes meaning to the MicroID in this 278 scenario depends on the consumer's relationship to the service 279 provider, whether the consumer has some trust in the information 280 presented by the service provider, etc. 282 5.2.2. Third Party as Issuer 284 Another scenario is that in which the MicroID is issued by a trusted 285 third party (e.g., a part with which both a service provider and 286 individual have registered). In this architecture, the service 287 provider is merely one of the entities. 289 +--------+ +------------------+ 290 | Entity | | Service Provider | 291 +--------+ +------------------+ 292 | | 293 | | 294 +-----------------+ 295 | 296 | registration 297 | 298 +--------+ 299 | Issuer | 300 +--------+ 301 | 302 | issuance 303 | 304 MicroID 306 Whether a given consumer imputes meaning to the MicroID in this 307 scenario depends on the consumer's relationship to the third part, 308 whether the consumer has some trust in the information presented by 309 the third party, whether the consumer is one of the entities, etc. 311 5.3. Using Technologies 313 This specification does not limit the technologies that might make 314 use of MicroIDs, and future versions of this specification might 315 describe a wide range of such uses. Here we describe two such uses. 317 Note: The scope of information (e.g., markup) covered by a MicroID 318 depends on the nature of the using technology and must be defined 319 separately by each using technology. 321 5.3.1. HTML Class Attribute 323 One possible use is to include a MicroID in the HyperText Markup 324 Language [HTML] class attribute. The recommended format is to 325 prepend the MicroID itself with the string "microid-", as shown in 326 the following example: 328

330 mycontent

332 In this usage, the scope of the MicroID is all information contained 333 within the element that possesses the class attribute, whether that 334 information is represented as attributes, character data, or child 335 elements. However, any given child element may itself possess a 336 class attribute specifying a MicroID that overrides the content claim 337 asserted by the parent element. In all cases, the relevant claim is 338 always that of the nearest containing element in the hierarchy. 340 A MicroID can be used on its own to mark content as created by a 341 certain individual (e.g., a comment made on a web forum): 343
345

This is a great idea!

346
348 A MicroID can be also used in concert with other lightweight identity 349 technologies such as the rel='me' value defined by XHTML Friends 350 Network (XFN) as specified at : 352
354

This is a great idea!

355

-- 357 stpeter

358
360 5.3.2. HTML Meta Data 362 Another possible use is in meta data about an [HTML] file (e.g., to 363 signify that a given web page is created by, owned by, or about a 364 given Individual). This is done by including a tag whose 365 'name' attribute is "microid" and whose 'content' attribute specifies 366 the MicroID, as shown in the following example: 368 372 In this usage, the scope of the MicroID is the page itself. However, 373 the whole-page claim represented in the META tag can be overridden by 374 claims represented in class attributes possessed by elements within 375 the HTML body. 377 A file MAY contain multiple META tags with a name of "microid" (e.g., 378 to claim ownership by multiple authors or to represent multiple 379 identities associated with the same individual). 381 6. Internationalization Considerations 383 A MicroID SHOULD be constructed using two Uniform Resource 384 Identifiers [URI] but one or both inputs MAY instead be an 385 Internationalized Resource Identifier [IRI]. 387 7. Security Considerations 389 MicroID is a technology for identifying the ownership or authorship 390 of information on the Internet. It is not a mechanism for 391 authentication, authorization, security, or encryption. Use of 392 MicroID technology results only in weak verification of identities 393 (if any). MicroID may be susceptible to [DNS] poisoning attacks 394 unless [DNSSEC] is used, since most URIs depend on DNS. 396 8. References 398 8.1. Normative References 400 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 401 Specifications: ABNF", RFC 4234, October 2005. 403 [SHA] National Institute of Standards and Technology, "Secure 404 Hash Standard", FIPS PUB 180-2, August 2002, . 408 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", BCP 14, RFC 2119, March 1997. 411 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 412 Resource Identifier (URI): Generic Syntax", STD 66, 413 RFC 3986, January 2005. 415 8.2. Informative References 417 [DNS] Mockapetris, P., "Domain names - implementation and 418 specification", STD 13, RFC 1035, November 1987. 420 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 421 Rose, "DNS Security Introduction and Requirements", 422 RFC 4033, March 2005. 424 [HTML] Jacobs, I., Raggett, D., and A. Hors, "HTML 4.01 425 Specification", World Wide Web Consortium 426 Recommendation REC-html401-19991224, December 1999, 427 . 429 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 430 L., Leach, P., and T. Berners-Lee, "Hypertext Transfer 431 Protocol -- HTTP/1.1", RFC 2616, June 1999. 433 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource 434 Identifiers (IRIs)", RFC 3987, January 2005. 436 [MAILTO] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL 437 scheme", RFC 2368, July 1998. 439 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 440 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, 441 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 443 [XMPP] Saint-Andre, P., "Internationalized Resource Identifiers 444 (IRIs) and Uniform Resource Identifiers (URIs) for the 445 Extensible Messaging and Presence Protocol (XMPP)", 446 RFC 4622, August 2006. 448 Appendix A. Legacy Support 450 MicroID originally assumed the use of sha1 as the hashing algorithm 451 and did not specify the schemes of the EntityURI inputs, resulting in 452 the following format: 454 microid = hash 455 hash = *( ALPHA / DIGIT ) 456 ; a hash of the URIs for both entities 458 For example, using the same inputs as shown in the body of this 459 specification, the MicroID in legacy format would be: 461 6196ea6709be2a4cbdf2bc0cfaeac491f2fb8921 463 An implementation MUST generate MicroIDs in the format specified in 464 the Format (Section 2) section of this document, but SHOULD process 465 MicroIDs generated using the legacy format for the sake of backward 466 compatibility. 468 Appendix B. Copying Conditions 470 The Contributors grant third parties the irrevocable right to copy, 471 use and distribute the Contribution, with or without modification, in 472 any medium, without royalty, provided that, unless separate 473 permission is granted, redistributed modified works: 475 1. do not contain misleading author, version, name of work, or 476 endorsement information, and 477 2. do not claim endorsement of the modified work by the 478 Contributors, or any organizations the Contributors belong to, 479 the Internet Engineering Task Force (IETF), Internet Research 480 Task Force (IRTF), Internet Engineering Steering Group (IESG), 481 Internet Architecture Board (IAB), Internet Assigned Numbers 482 Authority (IANA), Internet Society (ISOC), Request For Comments 483 (RFC) Editor, or any combination or variation of such terms 484 (including without limitation the IETF "4 diamonds" logo), or any 485 terms that are confusingly similar thereto, and 486 3. remove any claims of status as an Internet Standard, including 487 without limitation removing the RFC boilerplate. 489 The IETF suggests that any citation or excerpt of unmodified text 490 reference the RFC or other document from which the text is derived. 492 Authors' Addresses 494 Jeremie Miller 496 Email: jeremie@jabber.org 498 Peter Saint-Andre 500 Email: stpeter@jabber.org 501 URI: https://stpeter.im/ 503 Fred Stutzman 504 ClaimID 506 Email: fred@metalab.unc.edu 508 Full Copyright Statement 510 Copyright (C) The IETF Trust (2007). 512 This document is subject to the rights, licenses and restrictions 513 contained in BCP 78, and except as set forth therein, the authors 514 retain all their rights. 516 This document and the information contained herein are provided on an 517 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 518 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 519 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 520 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 521 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 522 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 524 Intellectual Property 526 The IETF takes no position regarding the validity or scope of any 527 Intellectual Property Rights or other rights that might be claimed to 528 pertain to the implementation or use of the technology described in 529 this document or the extent to which any license under such rights 530 might or might not be available; nor does it represent that it has 531 made any independent effort to identify any such rights. Information 532 on the procedures with respect to rights in RFC documents can be 533 found in BCP 78 and BCP 79. 535 Copies of IPR disclosures made to the IETF Secretariat and any 536 assurances of licenses to be made available, or the result of an 537 attempt made to obtain a general license or permission for the use of 538 such proprietary rights by implementers or users of this 539 specification can be obtained from the IETF on-line IPR repository at 540 http://www.ietf.org/ipr. 542 The IETF invites any interested party to bring to its attention any 543 copyrights, patents or patent applications, or other proprietary 544 rights that may cover technology that may be required to implement 545 this standard. Please address the information to the IETF at 546 ietf-ipr@ietf.org. 548 Acknowledgment 550 Funding for the RFC Editor function is provided by the IETF 551 Administrative Support Activity (IASA).