http://blog.gmane.org/gmane.ietf.http-auth hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.http-auth/788 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. Title : An Encoding Parameter for HTTP Basic Authentication Author(s) : Julian F. Reschke Filename : draft-ietf-httpauth-basicauth-enc-00.txt Pages : 10 Date : 2013-05-16 Abstract: The "Basic" authentication scheme defined in RFC 2617 does not properly define how to treat non-ASCII characters. This has lead to a situation where user agent implementations disagree, and servers make different assumptions based on the locales they are running in. There is little interoperability for the non-ASCII characters in the ISO-8859-1 character set, and even less interoperability for any characters beyond that. This document defines a backwards-compatible extension to "Basic", specifying the server's character encoding expectation, using a new authentication scheme parameter. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-enc There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-enc-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2013-05-16T19:18:11 http://comments.gmane.org/gmane.ietf.http-auth/779 <pre> Hi, So these two have a lot in common, but are in the end are a good bit different I think. Sufficiently different that they probably ought live separate lives as drafts probably, but maybe with bits in common. The common things:- - HTTP Authentication schemes - Both based on digital signatures for user authentication - Similar or could-be-the-same syntax in lots of places which does offer the possibility of some library/code re-use that might help both But there are very significant differences: #1 - HOBA aims to displace passwords and no more - draft-cavage wants to authenticate the user for payments as its main use-case #2 = HOBA doesn't try to authenticate other parts of the HTTP request (we'll probably in -01 allow TLS channel bindings but that's not the same) = draft-cavage does include other headers in the signature to authenticate those, possibly ultimately in a DKIM-like manner #3 * HOBA has a key-pair-per-web-origin, at least as a default, with no HOBA-defined linkage between the public key and any identifier with well-defined semantics (applications can do that) * draft-cavage I think wants just one or a few key pairs per user and probably with some well-defined semantics for identities associated with keys #4 - HOBA has a built-in use of .well-known/hoba for registration etc. - draft-cavage has very similar stuff in another spec but can't remember where that is:-) Other notes: - "Signature" as an HTTP authentication scheme seems way too broad - its hard to believe draft-cavage will be the only such ever (that's why I keep calling it draft-cavage above:-) - I hate the idea that the same scheme supports both digital signatures and HMAC for user authentication - I think that's a bad error - just define two HTTP auth schemes if you really see a need for HMAC, or use the updated Digest that this WG is chartered to develop - encouraging more password verifier databases is just a bad plan (with all due respect to the other proposals this wg will develop:-) - HOBA has this "demo of how to do hoba-js" aspect which isn't part of draft-cavage, us HOBA authors really like that:-) Overall, I think (not very confidently, very much open to chatting about it), were folks willing, it'd make sense to try define common syntax and signature mechanism processing for these but to progress them as separate HTTP authentication schemes that both happen to use the digital signature mechanism but for sufficiently different use-cases and security services that they're better kept apart. I'd be fine with this WG doing the work on draft-cavage if that made sense. To get an HTTP authentication scheme registered draft-cavage will have to pass IETF review in any case, as that's the rule the httpbis WG have set for new entries in that IANA registry. [1] So its not clear that taking the W3C REC route will save the dravt-cavage proponents much time, as their request for an IANA code point will end up back here anyway. (Doing stuff in one SDO is slow. Adding a 2nd SDO is a fine way to make treacle look speedy:-) But as I say, that's all fairly tentative so I wonder what others think. Cheers, S. [1] http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-22#section-2.3 </pre> Stephen Farrell 2013-05-14T19:13:57 http://comments.gmane.org/gmane.ietf.http-auth/762 <pre>The HTTP Signatures spec is a digital signature mechanism for the HTTP protocol. It adds origin authentication, message integrity, and replay resistance to HTTP requests. This is useful for any application that currently depends on Basic, Digest, OAuth, or OAuth2 authentication when performing RESTful HTTP calls. Basically, if a client needs to prove to a server that it sent an HTTP-based message, it can digitally sign that message. This spec defines exactly how that happens. This spec will be used by the Web Payments / PaySwarm / Web Keys work at W3C. We're going to combine the public/private key-based signature mechanism defined in HTTP Signatures with the public key infrastructure system as defined in Web Keys to provide an easy way for nodes on the Internet to verify their identity to other nodes on the Internet. The first draft of this spec was just published via the Internet Engineering Task Force (IETF) earlier today: http://tools.ietf.org/html/draft-cavage-http-signatures-00 You can also find a datetime-stamped version of the spec here: https://payswarm.com/specs/ED/http-signatures/2013-05-04/ The latest version of the spec can be found on the PaySwarm specs page: https://payswarm.com/specs/ </pre> Manu Sporny 2013-05-10T18:29:31 http://comments.gmane.org/gmane.ietf.http-auth/760 <pre>Thanks to everyone who volunteered to do a review of a potential working group document. I am pleased to announce that we were able to obtain an acceptable number of reviewers for each of the drafts. Therefore, the following documents will be accepted as HTTP-AUTH working group drafts: draft-williams-http-rest-auth draft-farrell-httpbis-hoba draft-melnikov-httpbis-scram-auth draft-oiwa-http-mutualauth and draft-oiwa-http-auth-extension The authors of each of these documents should submit a new version as draft-ietf-httpauth-whatever-00. Thanks again to everyone who volunteered to review one of these documents. Please be sure to send your reviews to the HTTP-AUTH mailing list. Of course, everyone on this list encourage to review the new working group documents regardless of whether or not you volunteered in advance to do a review. Thanks Matt &amp; Yoav _______________________________________________ http-auth mailing list http-auth&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/http-auth </pre> Matthew Lepinski 2013-05-07T03:59:55 http://comments.gmane.org/gmane.ietf.http-auth/758 <pre>First, my level-zero comments: - As most of you know by now, I think HTTP-layer authentication is a bit of a dead end. Consider Mozilla's BrowserID: an application-layer authentication mechanism (i.e., authentication messages are POSTed). But there is room for SCRAM here: in -to borrow a term from Kerberos- pre-authentication of the user to the user's IdP. This comment applies to all proposals for authentication mechanisms that fit into the existing HTTP authentication framework. Next: - This SCRAM is not *the* SCRAM of RFC5802. Perhaps it should have a different name to distinguish the two. In particular this SCRAM a) adds various attributes such as "realm" and "sid" parameters, and b) doesn't make use of the "-PLUS" suffix per-RFCs 5801 and 5802. Nor does this mechanism add the use of the SASL framework to HTTP -- it's just an adaptation of RFC5802, not 5801. A list of all the differences between this mechanism and RFC5802 would be nice. Is the authentication database for one usable with the other? See comments about the realm attribute below. - What's to be done with the "realm" attribute? Should it be added to the salt? Or merely be used to route a SCRAM exchange to an IdP, or to find the requisite authentication database? - What's the purpose of the "sid" attribute? What can be done with it? - Why shouldn't the client name the desired server in its messages? Then the exchange could be proxied to the named realm which could authenticate the server doing the proxying. That'd be nice. No, I think it'd have to be *required* if you want to have a realm for federation purposes. - "pre-stored dictionary attack" is not how I'd phrase it. More like "pre-computation attack""using "rainbow tables"-- "a dictionary of pre-computed hash results for a given one-way function and input passwords". - Please remove the reference to "Registration of TLS server end-point channel bindings"; RFC5929 should suffice. - A channel binding type should be required to be supported by clients and servers, and it should be tls-server-end-point. - The security considerations section should mention the lack of privacy protection for the client ID when not using TLS. - Section 7, third paragraph: no, no password-based authentication mechanism protects against off-line dictionary attacks on stolen password verifiers, not even ZKPPs. I recommend striking this sentence. - Section 7, fourth paragraph: how does salting help here? Oh, by ensuring that if the user uses the same password on multiple sites/servers/realms then the verifiers will be different. - Section 7, 5th paragraph: how would one negotiate hashes in a situation in which two SCRAM flavors are available, but both aren't available for all users (because, e.g., the not all users have re-enrolled). - Section 7, 6th paragraph, can you describe channel binding type negotiation? I thought there was none. I'll save nits for some other time. Nico -- </pre> Nico Williams 2013-05-04T00:34:39 http://comments.gmane.org/gmane.ietf.http-auth/755 <pre>Hi Folks. On Apris 10th, we issued a call for acceptance for several drafts. One has since been withdrawn. The remaining ones are (in no particular order): - draft-williams-http-rest-auth - draft-farrell-httpbis-hoba - draft-oiwa-http-mutualauth and draft-oiwa-http-auth-extension - draft-melnikov-httpbis-scram-auth We already have 2-3 people who have committed to reviewing each of these drafts. Of course we value quality over quantity, but we would like to have some more. So this is a call for volunteers to review these drafts. You don't have to be a cryptographer to do these reviews (but if you are, that would be great!). We will ask reviewers to look at security, at implementation pitfalls, and at barriers to implementation in browsers, programmatic clients, and servers. So if you have a good "feel" for security, we need you. And if you have experience in developing browsers or web applications, especially when such web applications require authentication and are high-value (think banks, online shopping), we really, really need you. Please send email to the list, or to me directly. Just to get things started, I will review rest-auth and SCRAM. Thanks in advance Matt &amp; Yoav </pre> Yoav Nir 2013-04-30T07:21:21 http://comments.gmane.org/gmane.ietf.http-auth/754 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. _______________________________________________ http-auth mailing list http-auth&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/http-auth </pre> johnsonhammond2< at >hushmail.com 2013-04-27T16:58:18 http://comments.gmane.org/gmane.ietf.http-auth/750 <pre>Hi there, below a few comments wrt to the base HTTP spec. Editorial: the "b64token" ABNF production is now "token68". Furthermore: "The "token68" notation was introduced for compatibility with existing authentication schemes and can only be used once per challenge/credentials. New schemes thus ought to use the "auth-param" syntax instead, because otherwise future extensions will be impossible." </pre> Julian Reschke 2013-04-23T10:43:59 http://comments.gmane.org/gmane.ietf.http-auth/742 <pre>My name is Manu Sporny. I'm the current Chair of the W3C RDFa WG, JSON for Linking Data (JSON-LD) CG, and Web Payments CG. I am also an editor of various W3C specs and member of the HTML WG and RDF WG. There is a relatively new spec at W3C called Web Keys[1] that now supports HTTP Signatures[2]. It is being worked on as a part of the Web Payments[3] work. Specifically, the PaySwarm[4] specifications use Web Keys and HTTP request signatures. We'd like to coordinate with the IETF on this work to make sure we have all parties interested in solving this problem involved in the work. We would also like more eyes doing security audits[5] on the protocol. For a high-level introduction to Web Keys, see the Mozilla Hacks article: https://hacks.mozilla.org/2013/04/web-payments-with-payswarm-identity-part-1-of-3/ For a high-level introduction to the Web Payments work, look here: http://blog.meritora.com/launch/ One of the first questions that came up in the IETF HTTP WG thread[5] on the matter is why none of the other HTTP authentication schemes were acceptable to the Web Payments group at W3C. Here is a quick run-down of the reasoning: HTTP Origin-Bound Authentication (HOBA) http://tools.ietf.org/id/draft-farrell-httpbis-hoba-02.txt We had considered signatures in the URL in the second approach to the problem in the Web Keys spec. We eventually rejected the solution because of limitations in the URL length in some browsers and because we wanted the semantics of the HTTP headers to be able to be a part of the digital signature. We also didn't want large signed messages being dumped to the webserver logs (the request line is typically included). So, while HOBA does solve the problem, it doesn't solve it in a way that is acceptable to us. HTTP Mutual Authentication http://tools.ietf.org/html/draft-oiwa-http-mutualauth-12 Overkill for our purposes and requires multiple bounces back and forth between the client and the server. Key exchange isn't required since that's taken care of by the Web Keys PKI framework. We don't intend the Web Keys HTTP signature protocol to be session-based, as a session-based value can be built on top of HTTP signatures pretty easily. HTTP Multilegged Auth http://tools.ietf.org/id/draft-montenegro-httpbis-multilegged-auth-01.txt Seems like overkill for our needs and is fairly specific to HTTP 2.0. We wanted something that could work for HTTP 1.0. Multi-legged authentication is something that we're not interested in solving using HTTP Signatures. Putting state into the protocol is something we'd like to avoid if possible. HTTP Salted Challenge Response http://tools.ietf.org/html/draft-melnikov-httpbis-scram-auth-00 Uses HMACs, doesn't use public key crypto, which is a requirement for Web Keys and the Web Payments work. HTTP REST Auth http://tools.ietf.org/id/draft-williams-http-rest-auth-03.txt This was the solution that seemed to be most interesting to the Web Keys and Web Payments work. However, it requires quite a bit of state to be remembered by the server (the Session URIs). Keeping the state of a "session" around isn't desirable. We didn't want there to be a concept of logging in and logging out of a website w/ the HTTP Signature stuff. We'd rather that sessions are built on top of HTTP Signatures via a HTTP header or cookie. Again, if we had to pick a back-up solution, HTTP REST Auth seems like it might work for us, but we'd rather not use if we don't have to. I'll stop here and wait for feedback from the groups that are involved. I am in contact with Stephen Farrell and a few other folks at IETF about where best to coordinate the work. </pre> Manu Sporny 2013-04-18T21:27:11 http://comments.gmane.org/gmane.ietf.http-auth/740 <pre>Hi there, reminder: HTTPbis is in WGLC, ending at the end of April: &lt;http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/1253.html&gt; This includes Part 7, which should be of interest for everybody over here :-). Best regards, Julian </pre> Julian Reschke 2013-04-16T12:09:13 http://comments.gmane.org/gmane.ietf.http-auth/731 <pre>Hi folks As per our charter, we are considering taking on draft-melnikov-httpbis-scran-auth to eventually publish as an experimental RFC. This is the call for acceptance. Please reply to this mail with a response such as: - yes, we should take this on, and I can be counted on to review it and contribute text in needed. - no, we should not take this on because… The document will be accepted only if there are sufficient reviewers volunteering. Just to make it interesting, we also require that each document author review at least one other document. Thanks Matt &amp; Yoav </pre> Yoav Nir 2013-04-10T11:23:46 http://comments.gmane.org/gmane.ietf.http-auth/729 <pre>Hi folks As per our charter, we are considering taking on draft-oiwa-http-mutualauth and draft-oiwa-http-auth-extension to eventually publish as experimental RFCs. This is the call for acceptance. Please reply to this mail with a response such as: - yes, we should take this on, and I can be counted on to review it and contribute text in needed. - no, we should not take this on because… The documents will be accepted only if there are sufficient reviewers volunteering. Just to make it interesting, we also require that each document author review at least one other document. Thanks Matt &amp; Yoav </pre> Yoav Nir 2013-04-10T11:23:43 http://comments.gmane.org/gmane.ietf.http-auth/728 <pre>Hi folks As per our charter, we are considering taking on draft-farrell-httpbis-hoba to eventually publish as an experimental RFC. This is the call for acceptance. Please reply to this mail with a response such as: - yes, we should take this on, and I can be counted on to review it and contribute text in needed. - no, we should not take this on because… The document will be accepted only if there are sufficient reviewers volunteering. Just to make it interesting, we also require that each document author review at least one other document. Thanks Matt &amp; Yoav </pre> Yoav Nir 2013-04-10T11:23:42 http://comments.gmane.org/gmane.ietf.http-auth/727 <pre>Hi folks As per our charter, we are considering taking on draft-montenegro-httpbis-multilegged-auth to eventually publish as an experimental RFC. This is the call for acceptance. Please reply to this mail with a response such as: - yes, we should take this on, and I can be counted on to review it and contribute text in needed. - no, we should not take this on because… The document will be accepted only if there are sufficient reviewers volunteering. Just to make it interesting, we also require that each document author review at least one other document. Thanks Matt &amp; Yoav </pre> Yoav Nir 2013-04-10T11:23:40 http://comments.gmane.org/gmane.ietf.http-auth/726 <pre>Hi folks As per our charter, we are considering taking on draft-williams-http-rest-auth to eventually publish as an experimental RFC. This is the call for acceptance. Please reply to this mail with a response such as: - yes, we should take this on, and I can be counted on to review it and contribute text in needed. - no, we should not take this on because… The document will be accepted only if there are sufficient reviewers volunteering. Just to make it interesting, we also require that each document author review at least one other document. Thanks Matt &amp; Yoav </pre> Yoav Nir 2013-04-10T11:23:45 http://comments.gmane.org/gmane.ietf.http-auth/723 <pre>Hello, Julian and I discussed this offline and we think that the mechanism defined in http://tools.ietf.org/html/draft-reschke-basicauth-enc-07 could be used to address the HTTP Digest encoding issue. The following is some text that we think we could add to the above draft to address this issue. --- In challenges, servers MAY use the "accept-charset" authentication parameter (case-insensitive) to express the character encoding they expect the user agent to use. If the user agent supports the encoding indicated by the server, it SHOULD add the "accept-charset" parameter, with the value it received from the server, to the Proxy-Authenticate or WWW-Authenticate header fields it sends back to the server. If the user agent does not support the encoding indicated by the server, it SHOULD add the "accept-charset" parameter to the Proxy-Authenticate or WWW-Authenticate header fields it sends back to the server, but the value in the parameter should be preceded by an exclamation point (!). A user agent that does not follow this specification will ignore the parameter and will not include it in any response to the server. When the server receives the new request with the Proxy-Authenticate or WWW-Authenticate header fields, it looks for the "accept-charset" parameter. If the "accept-charset" parameter is present, and its value matches the encoding the server sent to the client, the server will continue with its normal operation using the encoding it sent to the client. If, on the other hand, the "accept-charset" parameter value is preceded by an exclamation point (!), the server can immediately decline the request. If the new request with the Proxy-Authenticate or WWW-Authenticate header fields does not have the "accept-charset" parameter, the server will know that it is dealing with a client that does not support this specification and should continue to perform its current operation. The encoding indicated by the server impacts the way the server and the user agent concatenate the username-value, realm-value, and password when they calculate A1, as defined in section 3.2.2.2 of RFC2617. --- What we are missing is information on how this currently works in practice, as this might help us either validate the above proposal or guide us to find the proper solution to the real world issue. We would appreciate any feedback on the text above or any information on current practices. Regards, Rifaat _______________________________________________ http-auth mailing list http-auth&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/http-auth </pre> Shekh-Yusef, Rifaat (Rifaat 2013-03-18T13:39:19 http://comments.gmane.org/gmane.ietf.http-auth/710 <pre>Hi there, the above is in our charter, and I totally support that goal. Apart from extracting the text into a standalone document that references HTTPbis-Part7, the following things should be done: 1) Rephrase the security considerations (for instance, with respect to "Basic" over https). 2) *Explain* the I18N issue. 3) Update references where needed. 4) Resolve errata (the one I'm aware of -- &lt;http://www.rfc-editor.org/errata_search.php?rfc=2617&amp;eid=1959&gt; -- will be gone once we update the document to reference HTTPbis). The charter also asks for 5) *fixing* the I18N issue. That's non-trivial; see &lt;http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-07.html#faq&gt;. That draft has a *proposal* for fixing the issue, but it's unimplemented. I do not believe we can claim it solves the I18N issue unless we can show that it works in practice (two servers, to UAs). As such I would propose to: a) Just do 1)..4) b) Publish something like &lt;http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-07.html&gt; as Experimental c) Revisit the issue once we see implementations of b) Best regards, Julian </pre> Julian Reschke 2013-03-13T15:03:37 http://comments.gmane.org/gmane.ietf.http-auth/709 <pre>Hi there, no matter whether we tune/extend existing schemes, or try to deploy new schemes, we will have to consider limitations in existing user agents with respect to how WWW-Authenticate response header fields are parsed. See test cases at: &lt;http://greenbytes.de/tech/tc/httpauth/&gt; *All* of the major browsers get some of these tests wrong (*). In the case of Firefox, it's because it doesn't have a *parser* for WWW-Authenticate; it just does a sub-string lookup. So, please: - review test cases, - contribute new test cases, - try to get some of the UAs fixed (at least Chromium and FF are Open Source...). Best regards, Julian (*) Konqueror isn't a "major" browser, but it *does* get things right. </pre> Julian Reschke 2013-03-13T12:49:50 http://comments.gmane.org/gmane.ietf.http-auth/701 <pre>(see subject line) </pre> Julian Reschke 2013-03-12T13:34:04 http://comments.gmane.org/gmane.ietf.http-auth/698 <pre>All, regarding the charter[1] title, shouldn't that be "Hypertext Transfer Protocol Authentication"? Or am I missing historical context here? Jan [1] https://datatracker.ietf.org/doc/charter-ietf-httpauth/ </pre> Jan Algermissen 2013-03-08T04:21:11 http://comments.gmane.org/gmane.ietf.http-auth/697 <pre>The charter: https://datatracker.ietf.org/doc/charter-ietf-httpauth/ will be out for external review early next week. Barring any push back, the plan will be to have the WG officially up and running Tuesday morning of IETF week. Working on WG chairs now :) spt </pre> Sean Turner 2013-02-28T18:26:08 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.http-auth