Talk:Labs/Weave/Identity/Account Manager/Spec/2
From MozillaWiki
< Talk:Labs | Weave | Identity/Account Manager
How to handle secure cookies?
Hi, I am wondering how to deal with secure cookies. If someone tries to login to http://stendhalgame.org he is redirected to https://stendhalgame.org and of course the cookie is set to require SSL. So if the person returns at a later time to http://stendhalgame.org, he is obviously not logged in and should not be. How can the site tell the account manager about the requirement of https? --Hendrik Brummermann 16:34, 5 June 2010 (UTC)
Diffs from prior version
+Draft Version 2 Authors: Michael Hanson and Dan Mills, Mozilla Labs +WikiMedia tip: If you aren't seeing numbered section headings in the body of this document, you need to login and click the "My preferences" link, at left, and select "Auto-number headings" + +
= Introduction =
@@ -31,7 +35,9 @@ This proposal is NOT an attempt to deal
== Account Management Realms ==
-This proposal defines an "Account Management Realm" to be a set of HTTP(S)-addressed resources that are subject to a single account and session management control domain. In common practice, this means that they share a user session cookie.
+This proposal defines an "Account Management Realm" to be a set of HTTP(S)-addressed resources that are subject to a single account and session management control authority. In common practice, this means that they share a user session cookie.
+
+In many cases, a realm is the same as a site. For large web properties, however, a realm could include some number of content properties, which may or may not share a primary domain name.
It is an explicit goal of this protocol to support the description of user session status across an entire realm, even when not every URL or server in the realm participates in the protocol message exchange. This is intended to support large web properties, where a single host (e.g. "login.host.com") is responsible for issuing and clearing user session cookies.
@@ -49,10 +55,11 @@ The interpretation of the Control Docume
The user-agent must follow this set of checks to determine an Account Management Realm on retrieving a resource:
-# If the HTTP response has an "X-Account-Management" HTTP header, the realm is the value of this header.
-# If there is no X-Account-Management header, the browser SHOULD discover the XRD Host Metadata for the domain of the resource. (as of this writing, this involves making an HTTP request to /.well-known/host-meta, or perhaps a DNS-based system TBD). The user-agent may apply standard HTTP caching practices to this metadata file.
+# If the HTTP response has a "Link" HTTP header with a "rel" attribute of "acct-mgmt", the realm is the link-value of this header. Note that the interpretation of Link headers is defined by the Web Linking standard, which, means that the value will be delimited with angle brackets, as follows:
+ Link: <http://site.com/meta/accounts.xml>; rel="acct-mgmt"
+# If there is no Link header with a "rel" attribute, the browser SHOULD discover the Host Metadata for the domain of the resource. (as of this writing, this involves making an HTTP request to /.well-known/host-meta, or perhaps a DNS-based system TBD). The user-agent may apply standard HTTP caching practices to this metadata file.
-Note that #2 means that an Account Management Realm defined in the Host Metadata applies to all resources on the host that do not provide an X-Account-Management header or a value in their HTML content.
+Note that #2 means that an Account Management Realm defined in the Host Metadata applies to all resources on the host that do not provide an acct-mgmt Link header.
See also the discussion in Security Considerations, below.
@@ -66,12 +73,11 @@ The user-agent determines the account se
# If the HTTP response for the resource has an "X-Account-Management-Status" HTTP header, the session status is the value of this header.
# If the HTTP response for the resource has a status that will cause a redirection (e.g., 303), the redirect MUST be followed and steps 1 and 2 repeated for the redirected-to resource. In the event that the redirected-to resource has no X-Account-Management-Status header, or it has a different value, the last resource to be loaded with the header will be used to determine the session status.
-# If the resource currently being loaded corresponds to the sessionstatus method in the Control Document, the user-agent MUST abort and consider this attempt to determine the session status a failure.
-# Otherwise, the browser MUST inspect the Control Document for the realm to see if a sessionstatus method definition is present. If one is present, the user-agent should execute that method to determine the session status.
+# If a session status was previously provided, the user-agent MAY stop and report the last-reported status. The user agent MAY also alternatively invoke the sessionstatus method defined for the realm to determine the session status.
-The server is responsible for notifying the client of any changes to the current status of the session The user-agent MAY continue to present the last-reported status as current until notified otherwise.
+The server is responsible for notifying the client of any changes to the current status of the session.
-The user-agent MAY use the sessionstatus method to request the current status at any time. The user-agent SHOULD use it after a client restart. user-agents SHOULD NOT request the status using the sessionstatus method on a page view, if the page contained the account status in the header or content.
+The user-agent MAY use the sessionstatus method to request the current status at any time. The user-agent SHOULD use it after a client restart. User-agents SHOULD NOT request the status using the sessionstatus method on a page view, if the page contained the account status in the header. The server should be prepared to answer to the sessionstatus method at any time, but user agents are encouraged to use the last-reported value unless there is reason to believe that it is no longer correct, e.g. after a browser restart or processing a Set-Cookie header.
=== Interpretation of the Account Session Status ===
@@ -89,9 +95,17 @@ Legal keys in the attribute list are:
name: A human-readable label for the current session. The entire text of the string SHOULD be presented to the user as the current session identifier. In common practice, this will be the username, display name, or given name of the current user.
+id: The server's primary identifier for the current session. The identifier given here should match that submitted by the user-agent when a session was established.
+
Example:
- X-Account-Management-Status: active; name="Joe User"
+ X-Account-Management-Status: active; name="Joe User"; id="joe@domain.com"
+
+=== Interaction of Account Session Status with Caching Proxies ===
+
+Servers should set Cache-Control headers on responses that include an X-Account-Management-Status to ensure that the response will not be cached in a way that allows cross-user access or past the expected expiry window of the user's session.
+
+Servers are strongly encouraged to assume that clients will use the last-reported value of X-Account-Management-Status, and are therefore free to omit the header for responses that do not change the state of the client (i.e. do not include a Set-Cookie header). The use of the features described here is not intended to supersede any of the existing cache-control mechanisms described by HTTP.
= Contents of the Account Management Control Document =
@@ -105,7 +119,7 @@ The Control Document is a JSON document.
methods: An object mapping profile names to objects. Each profile object maps method names to Method Descriptions (see section 4.2 below). The profile names are drawn from the list of Supported Account Managment Profiles; each profile defines a list of supported methods.
-signature: maybe?
+applicable-domains: (optional) A list of fully-qualified host names. If this attribute is present, user-agents must only use the document to perform account management functions on pages whose hosts are present in the list.
== Method Descriptions ==
@@ -252,7 +266,9 @@ Defines a way for a user-agent to determ
=== accountstatus ===
-Defines an endpoint used by the user-agent to retrieve the status of the account bound to the current session. The user-agent SHOULD NOT invoke the accountstatus method until it has successfully executed a connect method.
+Defines an endpoint used by the user-agent to retrieve the status of the account bound to the current session. The user-agent SHOULD NOT invoke the accountstatus method until it has successfully executed a connect method. The intent of accountstatus is to provide a machine readable rendering of data that is stored or generated by the server. Expected use cases include:
+* Displaying account and contact information for the user
+* Reporting access histories (to allow the user-agent to check for unexpected access patterns)
;Required properties
:None
@@ -261,7 +277,9 @@ Defines an endpoint used by the user-age
:None
;Response interpretation
-A 2xx response may be interpreted by the user-agent by following the Data Identifiers in Content rules (section 7.1) described below. Any 4xx or 5xx response will be interpreted as an error.
+A 2xx response may be interpreted by the user-agent to produce a report of user data. The format of this data is not yet determined; HCard microformat data is one possibility but further discussion is needed. Any 4xx or 5xx response will be interpreted as an error.
+
+It is intended that the accountstatus page could, at the server's discretion, also be a human-readable page of HTML. The use of microformats is indicated as a way to provide machine-readable markup that is not perceptible to the human user.
Servers should return a 403 error if they expected a session for the accountstatus page and the user-agent failed to establish one.
@@ -283,35 +301,36 @@ Most common browser implementations of H
= Security Considerations =
-Rough notes on threats:
+== Additional Verification Steps Allowed ==
-Information Disclosure Threat: User asks to create an account on Alice, but attacker gets them to create an account with Bob.
+Nothing in this specification should be taken to forbid additional verification or authorization steps that might be performed in content.
-How: Inject an AccountManagement header, or META into a page at Alice, or compromise Alice's HostMeta. Or poison DNS on a non-SSL URL. When user requests account, Bob phishes Alice-domain data.
+== Threat Modeling ==
+
+Information Disclosure Threat: User asks to create an account on Alice, but attacker gets them to create an account with Bob, phishing Alice-domain data.
+
+How: Inject an AccountManagement header, or compromise Alice's HostMeta, or poison DNS on a non-SSL URL. When user requests account, Bob phishes Alice-domain data.
Countermeasures:
-# Don't allow cross-domain AM realm (problem: Large, multi-domain sites like Yahoo! want it)
+# Don't allow cross-domain AM realm (problem: Large, multi-domain sites want it)
# Require strict hierarchical AM realm (problem: nobody with a content.host.com runs logins on host.com)
# Sign AMCD - but for what signing authority? If you can inject an AM header, you can lie there.
-Sounds like the only safe approach is to require additional security if you want a cross-domain AM realm - forbid by default. But if we're putting something on both ends of the transaction, the attacker could do the same.
-
-One countermeasure would be to provide a way to disable content-based (or even header-based) AM discovery (like CSP). That way even if you compromised Alice's content you couldn't do anything. If we have DNS-based host-meta discovery you can't reach anything good unless you compromise DNS.
-
-Variant - same site: Alice and Bob are on the same domain, and we're counting on META or HTTP headers to indicate which realm we're in. e.g. http://host.com/~alice and http://host.com/~bob - Bob hacks Alice and sets her AM to http://host.com/~bob/account_mgmt. That one is pretty tough.
+Sounds like the only safe approach is to require additional security if you want a cross-domain AM realm - forbid by default. But if we're putting something on both ends of the transaction, the attacker could do the same. We can perform piece-wise countermeasures - e.g. disable header-based AM discovery.
-Credential Theft Threat: User asks to log into Alice, but actually sends their credentials to Bob.
+Variant attack - same site: Alice and Bob are on the same domain, and we're counting on HTTP headers to indicate which realm we're in. e.g. http://host.com/~alice and http://host.com/~bob - Bob hacks Alice and sets her AM to http://host.com/~bob/account_mgmt.
-How: Inject an AM header or META, or compromise HostMeta, or poison DNS for non-SSL.
+Credential Theft Threat: Similar to the registration attack - user asks to log into Alice, but actually sends their credentials to Bob, through direct man-in-the-middle on login request.
-Counterfeit registration - is this a threat?: Bob injects content onto a page that fools the browser into thinking it is undergoing a registration procedure (i.e. through FORM rel attribute injection, perhaps with hidden username and password fields). When the browser reaches the next page, it creates a username-password record for the site that has a value known to Bob.
+Site Masquerade Threat: Bob advertises account management details for Alice; the user sees his Alice account information in the browser chrome and feels more comfortable. Bob then phishes additional details in content.
-Does this accomplish anything useful? All Bob has done is scribble over the password stored already for Alice. Right now this looks like vandalism rather than a serious attack.
+This threat is intended to be addressed by the applicable-domain property of the AMCD. The strongest version would be to require an applicable-domain property for any cross-domain usage.
How to handle periodic credential challenges:
Some websites (e.g. commerce and financial applications) require additional credential challenges, even after a user correctly responds to a session-establishment challenge.
+
= Appendix A: Account Management Control Document Example =
{
@@ -372,3 +391,16 @@ Some websites (e.g. commerce and financi
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Link rel='http://services.mozilla.com/amcd/0.1' href='/path/to/your/amcd'/>
</XRD>
+
+= Version History =
+
+0.2: May 14, 2010
+* Introduced numeric coding in body content
+* Clarified definition of an Account Management realm
+* Changed X-Account-Management header to a Link header, see Web Linking spec
+* Clarified Session Status discovery flow
+* Added "id" attribute to Session Status value
+* Added Caching Proxies interaction note to Session Status section
+* Clarified and expanded accountstatus section
+* Added "applicable-domains" attribute to account management document top-level attributes
+* Clarified security considerations (more work needed)
Headers are not 8-bit clean
Portions of our headers, like usernames, need to be in (normalized) UTF-8, and Base-64 encoded.
Note that this also makes using JSON in headers a problem, because JSON allows unescaped unicode. The spec doesn't have any JSON headers ATM, but this idea was floating around.
