Subject: [websec] Last Call: <draft-ietf-websec-origin-04.txt> (The Web Origin Concept) to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 23 Aug 2011 14:19:53 -0700

The IESG has received a request from the Web Security WG (websec) to
consider the following document:
- 'The Web Origin Concept'
  <draft-ietf-websec-origin-04.txt> as a Proposed Standard

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
[email-masked] mailing lists by 2011-09-06. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document defines the concept of an "origin", which is often used
   as the scope of authority or privilege by user agents.  Typically,
   user agents isolate content retrieved from different origins to
   prevent malicious web site operators from interfering with the
   operation of benign web sites.  In addition to outlining the
   principles that underlie the concept of origin, this document defines
   how to determine the origin of a URI, how to serialize an origin into
   a string, and an HTTP header, named "Origin", that indicates which
   origins are associated with an HTTP request.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-websec-origin/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-websec-origin/

No IPR declarations have been submitted directly on this I-D.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 25 Aug 2011 18:32:24 +0200

Below a few late comments..

6. Serializing Origins

- It really really seems that the two algorithms need to be swapped (the 
first one converts to ASCII, but the second does not).

- Also, I'd prefer a declarative definition.

7. The HTTP Origin header

- header *field*

- the syntax doesn't allow multiple header fields, and the prose says 
clients MUST NOT generate them; what is the recipient supposed to do 
when it get's multiple instances anyway? Is the default approach 
(ignoring them all) good enough? Do we need to warn recipients so that 
they check?

11. References

- the WEBSOCKETS reference should be updated (if a new draft is produced)

Best regards, Julian