Labs/Weave/Identity/Account Manager/Spec/Latest: Difference between revisions

Line 65: Line 65:
The user-agent determines the account session status by following this set of steps:
The user-agent determines the account session status by following this set of steps:


# 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 an "<tt>X-Account-Management-Status</tt>" 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 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 <tt>X-Account-Management-Status</tt> 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.
# If the resource currently being loaded corresponds to the <tt>sessionstatus</tt> 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.
# Otherwise, the browser MUST inspect the Control Document for the realm to see if a <tt>sessionstatus</tt> method definition is present.  If one is present, the user-agent should execute that method 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 continue to present the last-reported status as current until notified otherwise.


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 <tt>sessionstatus</tt> 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 <tt>sessionstatus</tt> method on a page view, if the page contained the account status in the header or content.


=== Interpretation of the Account Session Status ===
=== Interpretation of the Account Session Status ===
Line 80: Line 80:
These status values should be interpreted by a user-agent as follows:
These status values should be interpreted by a user-agent as follows:


active: The server is maintaining a session with the user-agent in the positive belief that it is interacting with the user associated with the account.  No further credentials will be required to interact with the account.  (NB that some applications, i.e. financial transactions, may require additional verification steps during a session.  See Security Considerations, below).
<tt>active</tt>: The server is maintaining a session with the user-agent in the positive belief that it is interacting with the user associated with the account.  No further credentials will be required to interact with the account.  (NB that some applications, i.e. financial transactions, may require additional verification steps during a session.  See Security Considerations, below).


passive: The server is maintaining a session with the user-agent according to some token other than a positive exchange of credentials, e.g. a long-duration cookie.  The server may require the user to present additional credentials before taking action with the account.
<tt>passive</tt>: The server is maintaining a session with the user-agent according to some token other than a positive exchange of credentials, e.g. a long-duration cookie.  The server may require the user to present additional credentials before taking action with the account.


none: The server is not maintaining a session with the user.  It is up to the user-agent to render additional user interface elements if the user-agent believes that it has credentials that would allow a session to be established.
<tt>none</tt>: The server is not maintaining a session with the user.  It is up to the user-agent to render additional user interface elements if the user-agent believes that it has credentials that would allow a session to be established.


Legal keys in the attribute list are:
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.
<tt>name</tt>: 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.


Example:
Example:
946

edits