HTTP Authentication Extensions for Interactive Clients
draft-ietf-httpauth-extension-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-01-23
|
09 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2017-01-09
|
09 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2016-12-22
|
09 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2016-11-22
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2016-11-16
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2016-11-16
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2016-11-16
|
09 | (System) | RFC Editor state changed to EDIT |
2016-11-16
|
09 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2016-11-16
|
09 | (System) | Announcement was received by RFC Editor |
2016-11-16
|
09 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2016-11-15
|
09 | (System) | IANA Action state changed to Waiting on Authors |
2016-11-15
|
09 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup |
2016-11-15
|
09 | Cindy Morgan | IESG has approved the document |
2016-11-15
|
09 | Cindy Morgan | Closed "Approve" ballot |
2016-11-15
|
09 | Cindy Morgan | Ballot approval text was generated |
2016-09-17
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2016-09-17
|
09 | Yutaka Oiwa | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2016-09-17
|
09 | Yutaka Oiwa | New version available: draft-ietf-httpauth-extension-09.txt |
2016-09-17
|
09 | Yutaka Oiwa | New version approved |
2016-09-17
|
09 | Yutaka Oiwa | Request for posting confirmation emailed to previous authors: "Hiromitsu Takagi" , "Yutaka Oiwa" , "Kaoru Maeda" , "Yuichi Ioku" , "Tatsuya Hayashi" , "Hajime Watanabe" |
2016-09-17
|
09 | (System) | Uploaded new revision |
2016-09-08
|
08 | Tero Kivinen | Closed request for Telechat review by SECDIR with state 'No Response' |
2016-09-01
|
08 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Waiting for Writeup |
2016-09-01
|
08 | Alexey Melnikov | [Ballot comment] I agree with Stephen that this document must include the registration template as per Section 4.2.1 of BCP 90 (RFC 3864). … [Ballot comment] I agree with Stephen that this document must include the registration template as per Section 4.2.1 of BCP 90 (RFC 3864). In Section 2.2: bare-token = 1*(%x30-39 / %x41-5A / %x61-7A / "-" / "_") Did you intent to allow leading "-" (and possibly "_") above? As you are using "-." for private extensions, I think the ABNF is not right. I think you meant: lead-token-char = (%x30-39 / %x41-5A / %x61-7A / "_") bare-token = lead-token-char *(%x30-39 / %x41-5A / %x61-7A / "-" / "_") In Section 3, last paragraph: Support of this header is OPTIONAL; clients MAY also implement this extension only for some selected authentication schemes. New authentication schemes can make support of the optional authentication mandatory by its specification, though. I don't think this paragraph is needed, as this is granted, because support for any extension like specified in this document is optional. So I suggest deleting it. Section 3.1: I am still not convinced that Optional-WWW-Authenticate is needed, but the section provides a reasonable overview of the current situation. In Section 4: Support of this header is OPTIONAL, and clients MAY choose any subset of these parameters to be supported. The set of supported parameters MAY also be authentication scheme-dependent. However, some authentication schemes can require mandatory/recommended support for some or all of the features provided in this header. As above, I don't think this paragraph is needed. 4.4. No-auth parameter This parameter SHOULD NOT be used along with the location-when-unauthenticated parameter. Why is this only a SHOULD NOT (or to rephrase it: what are possible conditions for violating this)? If both were supplied, clients MAY choose which one is to be honored. I would rather you pick one behaviour in order to improve interoperability. In 4.5: When the user requests termination of an authentication period, and if the client currently displays a page supplied by a response with this parameter, the client will be redirected to the specified location by a new GET request (as if it received a 303 response). Is this value advisory? Should the client go to this page automatically or would the server redirect it? If the latter, why does this need to be told to the client? The log-out operation (e.g. erasing memories of user name, authentication credential and all related one-time credentials such as nonce or keys) SHOULD occur before processing a redirection. 4.6. Logout-timeout parameter The parameter "logout-timeout", when contained in a successfully- authenticated response, means that any authentication credentials and state related to the current protection space are to be discarded if a time specified in this header (in seconds) has passed since from the time this header was received. The value MUST be an integer. As a special case, the value 0 means that the client is requested to immediately log-out from the current authentication space and revert to an unauthenticated status. It sounds like this is not just a request, but the client will be logged out. If this is correct, then you should reword this, for example: As a special case, the value 0 means that the server is logging the client out immediately from the current authentication space and that the client is now returns to unauthenticated state. |
2016-09-01
|
08 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2016-09-01
|
08 | Stephen Farrell | [Ballot comment] I think experiments to improve web authentication are a good thing (tm:-) so am happy to see this experiment proceed. - Figure 1: … [Ballot comment] I think experiments to improve web authentication are a good thing (tm:-) so am happy to see this experiment proceed. - Figure 1: Maybe clarify that "credentials" here is not the same as in RFC 7235? - Figure 3: this is a mixture of an example ("Basic") and ABNF ("1#challenge") which is odd. I'd say just make it an example and fix the figure caption accordingly. - section 7: I thought that registrations of new HTTP headers needed some more information, e.g. in which messages they can be sent and with which status codes? BCP90 does seem to call for that - why aren't those details here? |
2016-09-01
|
08 | Stephen Farrell | [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell |
2016-09-01
|
08 | Joel Jaeggli | [Ballot comment] Rick Casarez provided the opsdir review |
2016-09-01
|
08 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2016-09-01
|
08 | Benoît Claise | [Ballot comment] As mentioned by Rick Casarez in his OPS DIR review: Section 3, paragraph 3: Some sentence cleanup is required so that this remains … [Ballot comment] As mentioned by Rick Casarez in his OPS DIR review: Section 3, paragraph 3: Some sentence cleanup is required so that this remains clear. I believe I understand what is being said as far as implementation goes but some cleanup would make this paragraph more concise. |
2016-09-01
|
08 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2016-09-01
|
08 | Mirja Kühlewind | [Ballot comment] 1) The following disclarer is a little odd: "The terms "encouraged" and "advised" are used for suggestions that do not constitute "SHOULD"-level … [Ballot comment] 1) The following disclarer is a little odd: "The terms "encouraged" and "advised" are used for suggestions that do not constitute "SHOULD"-level requirements. People MAY freely choose not to include the suggested items. However, complying with those suggestions would be a best practice; it will improve the security, interoperability, and/or operational performance." Both terms are only used once. I would recommend to remove the text above and simply use MAY later in the doc (or not use MAY and leave the later text as it is just without the disclaimer). 2) I agree that the section on username should point to the secturity section to give a clear warning. However, I also don't really understand why username is needed. If there is a good use case for it, maybe it's worth to explain this as another example. |
2016-09-01
|
08 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2016-09-01
|
08 | Jari Arkko | [Ballot comment] Comments from the Gen-ART reviewer Matt Miller should be taken into account, see below. I considered making a Discuss about the reference to … [Ballot comment] Comments from the Gen-ART reviewer Matt Miller should be taken into account, see below. I considered making a Discuss about the reference to Authentication-Info RFC but I trust that you guys will make the correct modifications. Thanks! ---- * There is at least a couple of mentions of the "Authentication-Info" header, but no reference to RFC 7615 in which it is defined. I think an informational reference is warranted here. * Just reading sections 4.5. "Location-when-logout parameter" and 4.6. "Logout-timeout parameter", it is unclear how these are meant to interact to inform a client the user's authentication session. Frankly, I think the text in section 4.5 is too vague about how a client can detect termination of a user's authenticated session, and could use more of a hint on how "logout-timeout" is involved to accomplish it. At the least, I think both sections 4.5. and 4.6. need pointers to section 5. to help readers get a sense of how to apply them. * In section 4.7. "Username parameter", I think there should be an explicit pointer to the Security Considerations to warn about potential issues this parameter presents. I also recommend separating that portion of the Security Considerations about "username" into its own subsection to make such a callout better. * Since this document is acknowledging that cookies are used for authentication, and Nits/editorial comments: * In section 2.1. "Terms for describing authentication protocol flow", the word "distinguishable" should instead be "distinguished" in the phrase "it can't be distinguishable from a non-authenticated response." * In section 3. "Optional Authentication", the word "be" is missing in "Optional-WWW-Authenticate header MUST NOT sent on 401 responses". * In section 3.1. "Note on Optional-WWW-Authenticate and use of WWW-Authenticate header with non-401 status", the word "is" should be replaced with "are" in the phrase "clients which is unaware of this extension will ignore the header". * Also in section 3.1., the word "authentications" should be "authentication" in the phrase "secondary fallback method of authentications". * Also in section 3.1., the word "ignores" should be "ignore" in the phrase "just ignores the WWW-Authenticate headers". * Also in section 3.1., all instances of the word "implementer" should be replaced with "implementers" in the phrase "the authors propose implementer of the standard HTTP/1.1 specification (especially implementer of this extension)". * In section 4. "Authentication-Control header", the word "an" should be "a" in the phrase "and MUST be sent in an plain". * In section 4.1. "Non-ASCII extended header parameters", the interoperability note as a number of grammatical challenges. I believe the following addresses the grammar issues while retaining its meaning: """ Interoperability note: [RFC7235], Section 2.2, defines the "realm" authentication parameter which cannot be replaced by the "realm*" extend parameter. It means that the use of non-ASCII values for an authentication realm is not the defined behavior in HTTP. Unfortunately, some people currently use a non-ASCII realm parameter in reality, but even its encoding scheme is not well-defined. Given this background, this document does not specify how to handle a non-ASCII "realm" parameter in the extended header fields. If needed, the authors propose to use a non-extended "realm" parameter form, with a wish for maximum interoperability. """ * In section 4.2. "Auth-style parameter", the word "preferences" should be replaced with "preference" in the phrase "server's preferences for user interface behavior". * In section .4.4. "No-auth parameter", the word "authentications" should be replaced with "authentication" in the phrase "content is desired before authentications". * In section 4.6. "Logout-timeout parameter", the word "from" should be removed in the phrase "has passed since from the time this header was received". * In section 5.3. "When to use Cookies", the first sentence has some grammatical challenges, which I believe the following text addresses: """ In current Web sites using form-based authentication, Cookies [RFC6265] are used for managing both authorization and application sessions. """ * In section 5.4. "Parallel deployment with Form/Cookie authentications", the META tag example should be "" instead of ">META http-equiv="refresh" ...<". * In section 7. "IANA Considerations", the word "documents" should be "document" in the phrase "a publicly-accessible documents". |
2016-09-01
|
08 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2016-09-01
|
08 | Matthew Miller | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Matthew Miller. |
2016-08-31
|
08 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2016-08-31
|
08 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2016-08-31
|
08 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2016-08-31
|
08 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2016-08-31
|
08 | Alexey Melnikov | [Ballot comment] In Section 2.2: bare-token = 1*(%x30-39 / %x41-5A / %x61-7A / "-" / "_") Did you intent to … [Ballot comment] In Section 2.2: bare-token = 1*(%x30-39 / %x41-5A / %x61-7A / "-" / "_") Did you intent to allow leading "-" (and possibly "_") above? As you are using "-." for private extensions, I think the ABNF is not right. I think you meant: lead-token-char = (%x30-39 / %x41-5A / %x61-7A / "_") bare-token = lead-token-char *(%x30-39 / %x41-5A / %x61-7A / "-" / "_") In Section 3, last paragraph: Support of this header is OPTIONAL; clients MAY also implement this extension only for some selected authentication schemes. New authentication schemes can make support of the optional authentication mandatory by its specification, though. I don't think this paragraph is needed, as this is granted, because support for any extension like specified in this document is optional. So I suggest deleting it. Section 3.1: I am still not convinced that Optional-WWW-Authenticate is needed, but the section provides a reasonable overview of the current situation. In Section 4: Support of this header is OPTIONAL, and clients MAY choose any subset of these parameters to be supported. The set of supported parameters MAY also be authentication scheme-dependent. However, some authentication schemes can require mandatory/recommended support for some or all of the features provided in this header. As above, I don't think this paragraph is needed. 4.4. No-auth parameter This parameter SHOULD NOT be used along with the location-when-unauthenticated parameter. Why is this only a SHOULD NOT (or to rephrase it: what are possible conditions for violating this)? If both were supplied, clients MAY choose which one is to be honored. I would rather you pick one behaviour in order to improve interoperability. In 4.5: When the user requests termination of an authentication period, and if the client currently displays a page supplied by a response with this parameter, the client will be redirected to the specified location by a new GET request (as if it received a 303 response). Is this value advisory? Should the client go to this page automatically or would the server redirect it? If the latter, why does this need to be told to the client? The log-out operation (e.g. erasing memories of user name, authentication credential and all related one-time credentials such as nonce or keys) SHOULD occur before processing a redirection. 4.6. Logout-timeout parameter The parameter "logout-timeout", when contained in a successfully- authenticated response, means that any authentication credentials and state related to the current protection space are to be discarded if a time specified in this header (in seconds) has passed since from the time this header was received. The value MUST be an integer. As a special case, the value 0 means that the client is requested to immediately log-out from the current authentication space and revert to an unauthenticated status. It sounds like this is not just a request, but the client will be logged out. If this is correct, then you should reword this, for example: As a special case, the value 0 means that the server is logging the client out immediately from the current authentication space and that the client is now returns to unauthenticated state. |
2016-08-31
|
08 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2016-08-30
|
08 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2016-08-30
|
08 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2016-08-29
|
08 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2016-08-27
|
08 | Kathleen Moriarty | Ballot has been issued |
2016-08-27
|
08 | Kathleen Moriarty | [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty |
2016-08-27
|
08 | Kathleen Moriarty | Created "Approve" ballot |
2016-08-27
|
08 | Kathleen Moriarty | Ballot writeup was changed |
2016-08-27
|
08 | Kathleen Moriarty | Changed consensus to Yes from Unknown |
2016-08-26
|
08 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2016-08-25
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Matthew Miller |
2016-08-25
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Matthew Miller |
2016-08-23
|
08 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2016-08-23
|
08 | Sabrina Tanamal | (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-httpauth-extension-07.txt. If any part of this review is inaccurate, please let us know. IANA … (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-httpauth-extension-07.txt. If any part of this review is inaccurate, please let us know. IANA has a question about one of the actions requested in the IANA Considerations section of [ RFC-to-be ]. IANA understands that, upon approval of [ RFC-to-be ], there are two actions which IANA must complete. First, in the Permanent Message Header Field Names subregistry of the Message Headers registry located at: https://www.iana.org/assignments/message-headers/message-headers.xhtml#perm-headers two new header field names are to be registered as follows: Header Field Name: Optional-WWW-Authenticate Template: Protocol: http Status: Reference: [ RFC-to-be ] Header Field Name: Authentication-Control Template: Protocol: http Status: Reference: [ RFC-to-be ] IANA Question --> what should be the value for "Status" for these two new header field names? As [ RFC-to-be ] requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Second, a new registry is to be created called the HTTP Authentication Control Parameters registry. IANA QUESTION -> Where should this new registry be located? Is it a néw registry on the List of all IANA maintained protocol parameter registries or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained? The new registry is to be managed via Specification Required as defined in RFC5226. There are initial entries in this new registry as follows: +-------------------------------+------------------------------+ | Token | Specification | +-------------------------------+------------------------------+ | auth-style | Section 4.2 of [ RFC-to-be ] | | location-when-unauthenticated | Section 4.3 of [ RFC-to-be ] | | no-auth | Section 4.4 of [ RFC-to-be ] | | location-when-logout | Section 4.5 of [ RFC-to-be ] | | logout-timeout | Section 4.6 of [ RFC-to-be ] | | username | Section 4.7 of [ RFC-to-be ] | +-------------------------------+------------------------------+ IANA understands that these are the only actions required to be completed upon approval of [ RFC-to-be ]. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thank you, Sabrina Tanamal IANA Specialist ICANN |
2016-08-16
|
08 | Yutaka Oiwa | New version available: draft-ietf-httpauth-extension-08.txt |
2016-08-16
|
07 | Gunter Van de Velde | Request for Telechat review by OPSDIR Completed: Has Nits. Reviewer: Rick Casarez. |
2016-08-12
|
07 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2016-08-12
|
07 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: "Yoav Nir" , ynir.ietf@gmail.com, httpauth-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, http-auth@ietf.org, … The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: "Yoav Nir" , ynir.ietf@gmail.com, httpauth-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, http-auth@ietf.org, draft-ietf-httpauth-extension@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (HTTP Authentication Extensions for Interactive Clients) to Experimental RFC The IESG has received a request from the Hypertext Transfer Protocol Authentication WG (httpauth) to consider the following document: - 'HTTP Authentication Extensions for Interactive Clients' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-08-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies extensions for the HTTP authentication framework for interactive clients. Currently, fundamental features of HTTP-level authentication are insufficient for complex requirements of various Web-based applications. This forces these applications to implement their own authentication frameworks by means like HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user-agent. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility with existing Web and non-Web uses of HTTP authentications. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-httpauth-extension/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-httpauth-extension/ballot/ No IPR declarations have been submitted directly on this I-D. |
2016-08-12
|
07 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2016-08-12
|
07 | Kathleen Moriarty | Last call was requested |
2016-08-12
|
07 | Kathleen Moriarty | Ballot approval text was generated |
2016-08-12
|
07 | Kathleen Moriarty | Ballot writeup was generated |
2016-08-12
|
07 | Kathleen Moriarty | IESG state changed to Last Call Requested from AD Evaluation |
2016-08-12
|
07 | Kathleen Moriarty | Last call announcement was generated |
2016-08-12
|
07 | Kathleen Moriarty | Last call announcement was generated |
2016-08-12
|
07 | Kathleen Moriarty | Telechat date has been changed to 2016-09-01 from 2016-08-18 |
2016-08-11
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Matthew Miller |
2016-08-11
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Matthew Miller |
2016-08-04
|
07 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Eric Osterweil |
2016-08-04
|
07 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Eric Osterweil |
2016-08-01
|
07 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Rick Casarez |
2016-08-01
|
07 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Rick Casarez |
2016-07-31
|
07 | Kathleen Moriarty | IESG state changed to AD Evaluation from Publication Requested |
2016-07-31
|
07 | Kathleen Moriarty | Placed on agenda for telechat - 2016-08-18 |
2016-07-17
|
07 | Yoav Nir | Authors are Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Tatsuya Hayashi and Yuichi Ioku. Kathleen Moriarty is the responsible Area Director. Yoav Nir is the document … Authors are Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Tatsuya Hayashi and Yuichi Ioku. Kathleen Moriarty is the responsible Area Director. Yoav Nir is the document shepherd. Summary This document specifies extensions for the HTTP authentication framework for interactive clients. Currently, fundamental features of HTTP-level authentication are insufficient for complex requirements of various Web-based applications. This forces these applications to implement their own authentication frameworks by means like HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user-agent. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility with existing Web and non-Web uses of HTTP authentications. Review and Consensus This document is one in a three-part set of documents describing the Mutual-Auth authentication method for HTTP. This part extends the HTTP authentication framework from RFC 7235 to include optional authentication as well as de-authorization (log out) and finer control of redirection depending on authentication status. With version -07 it is the consensus of the HTTP-Auth working group that this document is fit to be published as an experimental RFC. The document received a moderate amount of review from the working group. In addition we solicited and received a review from Cory Benfield. There are implementations of this protocol written by the authors. They take the form of a modified web server and a fork of the Firefox browser that include this functionality. Intellectual Property All authors have confirmed that they are not aware of any undisclosed IPR associated with this document. There have been no IPR disclosures. Other Issues None |
2016-07-17
|
07 | Yoav Nir | Responsible AD changed to Kathleen Moriarty |
2016-07-17
|
07 | Yoav Nir | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2016-07-17
|
07 | Yoav Nir | IESG state changed to Publication Requested |
2016-07-17
|
07 | Yoav Nir | IESG process started in state Publication Requested |
2016-07-16
|
07 | Yoav Nir | Changed document writeup |
2016-07-16
|
07 | Yoav Nir | Notification list changed to "Yoav Nir" <ynir.ietf@gmail.com> |
2016-07-16
|
07 | Yoav Nir | Document shepherd changed to Yoav Nir |
2016-07-16
|
07 | Yoav Nir | Intended Status changed to Experimental from None |
2016-07-16
|
07 | Yoav Nir | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2016-07-07
|
07 | Yutaka Oiwa | New version available: draft-ietf-httpauth-extension-07.txt |
2016-05-25
|
06 | Yutaka Oiwa | New version available: draft-ietf-httpauth-extension-06.txt |
2016-04-04
|
05 | Yoav Nir | Added to session: IETF-95: httpauth Wed-1620 |
2016-01-06
|
05 | Yutaka Oiwa | New version available: draft-ietf-httpauth-extension-05.txt |
2015-07-06
|
04 | Yutaka Oiwa | New version available: draft-ietf-httpauth-extension-04.txt |
2015-02-19
|
03 | Yutaka Oiwa | New version available: draft-ietf-httpauth-extension-03.txt |
2014-08-18
|
02 | Yutaka Oiwa | New version available: draft-ietf-httpauth-extension-02.txt |
2013-10-21
|
01 | Yutaka Oiwa | New version available: draft-ietf-httpauth-extension-01.txt |
2013-07-01
|
00 | Yutaka Oiwa | New version available: draft-ietf-httpauth-extension-00.txt |