Responsive Design Pattern

Design Pattern Metadata

Title

Responsive Design Pattern shows how a web site can be adapted to the capabilities of the user agent.

Status

Design Pattern Lifecycle Status

Contributed	Working Draft	Committee Review	Compilation	Approval	Publication
This Design Pattern is available for review by the User Experice Committee (UXC) with the goal of refining and completing the Design Pattern, , see Identity Design Patterns for the current list of design patterns and their status.

Design Pattern Review Status

Contributed, not yet reviewed.

Expect changes before this pattern is final.

A required picture has not yet been supplied.

Design Pattern Category

Privacy, Trust/Assurance, Interoperability

Contributor

Tom Jones

Design Pattern Content

Problem Description (meme)

Users have a wide variety of connected devices available to them a different times during the day. A responsive web design can successfully be used on any devices regardless of screen size and local caching capability.

When to use this Pattern (Context)

• Any time a user is expected to use the web site on multiple devices with different capabilities.
  • Devices with different screen sizes.
  • Devices with different capability to store user credentials and preferences.

Relationships with other Design Patterns

This design pattern assumes the use of a device connected to internet service providers as described in the Common to any Internet Identity Ecosystem design pattern. TK - user preferences / personalization

Relationships with Use Cases

TK

Actors

1. User: In this case a human being that wants to access services on a web site and still retain privacy by requesting that the site not link the user's attributes to any other site or instance.
2. User Agent: in this case any piece of code that displays a user experience and obtains responses from the user in order to satisfy the privacy concerns of the user and the need for identity and attribute claims by the relying party.
3. Relying Party (RP): A service provider that needs a collection of claims to provide that service. The claims may relate to financial responsibility or other user attributes that are required by regulation to met legal responsibilities. The user experience for RP web sites should improve if they can automate some requests for user's attributes. It is beyond the scope of this Design Pattern to determine whether the RP actually has any justification in requesting any user attribute at all.
4. Identity or Attribute Provider (IAP): contains identities and attributes of users that will be provided on demand in claims that the user can forward to a RP.
5. Identity Ecosystem: a set of services that implement other trust services as required by the rules of that ecosystem. Note that all of the other actors are almost certainly required to function with multiple identity ecosystems; some, but not all, of these ecosystems are expected to be compliant with IDESG trust frameworks.

Solution

Description of the Solution

1. The user establishes an

Error Conditions

Any error condition that requires user action should create the following user experience elements

1. As much detail about the cause of the error that would help the user understand while not significantly impacting the user flow or security.
2. A way for the user to mitigate the error. The response "Please contact your administrator" does not qualify as a mitigation step.

The following are specific errors that the user might see.

1. User does not have credentials that can generate claims acceptable to the relying party.
   1. Mitigation: The ID ecosystem redirects the user to one or more sources of appropriate credentials that do meet the criteria for authorization at the RP.
   2. Mitigation: The relying party redirects the user to one or more Identity Providers or trust frameworks that are acceptable. If a new framework is chosen, that may involve user acceptance or change the PET to meet those particular authorization requirements.
   3. Mitigation: The user is allowed to back-out of the current path to one where they can succeed.

Usability Considerations

>>THE UXC PLANS TO EXPAND THIS SECTION <<

It is expected that when a user first navigates to a web site that the interaction will be treated as anonymous and no user data would be collected until the user selected some action which explicitly was acknowledged to require user information, such as clicking a logon or framework logo. The user cannot be expected to have made any trust decision just because they have landed on a web location. As an example the user should not expect that whitehouse.com was trustworthy. Note that it is only after the web site renders that the user can see if the URL is trusted (e.g. if it has a trusted EV-certificate.)

All IDESG logoed web sites are expected to participate in setting a trustworthy context. This design pattern will be combined with other design patterns, including IDESG general patterns to help design and build web sites that meet IDESG UX goals. For example each web site needs to allow users to stop, cancel or back out of decisions when they change their mind.

One important part of any Design Pattern is the intelligibility of the design to the user. Here it is very important that the user understand the meaning of the Trustmark sufficiently well to make an informed consent decision.

All providers will be assessable and localized in English, Spanish and any other language expected to be encountered by a significant number of users.

Read the report of the IDESG experience committee on use case usability at UXC Use Case Mapping

Value Proposition

The most difficult acceptance barrier for most new design choices is the web site of the relying party. If any part of the implementation hinders use of the web site, the feature will not be implemented. The Trustmark evolution depends on increasing the value of the web site at every stage of the evolution. For early adoption by web sites that means that users or partners will prefer dealing with a web site that shows the Trustmark and delivers on the promise that is contained in the terms of use for that Trustmark. That implies that some organization has taken the responsibility to validate the web site before and during operation.

References and Citations

Responsive Web Design on Wikipedia [[1]]

NSTIC Guiding Principles Considerations

Privacy Considerations

There are three sources of leaks to user private information that are considered by this pattern:

1. The user agent provides more information to the RP than the user intended.
2. The user interacts with the RP over an extended period allowing the RP to determine the user ID from their behavior.
3. The RP has privacy policies that are obscure or not followed. A multipage privacy policy is ipso facto obscure. Often leaks of user private data are allowed by insufficient security at the RP or other parties that have access to the data.

Other privacy considerations, such as an expressed user intent, have been separated out to other design patterns. For an example see the User Intent Pattern.

Security Considerations

In general security is not considered in this Design Pattern as security will be provided by the same type of credentials, token and claims as used in any secure implementation. One additional wrinkle that is inserted by a PET provider is that the PET provider must have a sufficient level of trust by the user and the relying party to perform the desired function.

Interoperability Considerations

User satisfaction depends critically on

Framework Specific Considerations

Aerospace and Defense

• For this affinity group the user basis is limited to people or services who are well know to the enterprise that issues them with credentials. Those credentials will likely include access authorizations based on the trustworthiness of the user. It is a closed community.
• The specific example is employees, contractors and vendors which are under contract to one of the recognized employers in the A&D industry complying with DoD regulations for protection of secret information.
• Currently most employers assume that their employment contract allows then to provide employee attributes to any site that the employee voluntarily visits. The assumption is likely to need to be make more explicit in the years to come.

Health Care

• Two specific examples within the Health Care communities have ID ecosystem interest:
  • Users of the healthcare system that are open to any person seeking healthcare. It is an open system.
  • Providers of health care that is closed to persons with credentials appropriate to the care provided. It is a closed system.

The specific interest of the User eXperience Committee is the open enrollment of any person looking for health care. This involves every range of user involvement and must be able to accommodate all comers, but may need to send the user to some other location for verification of some attribute as a part of authorizing health care. A user must have the capability to anonymously browse health care provider web sites to determine their qualifications and cost before providing private information. On the other hand the user should expect that health care information will not be released to them until they provide strong proof of identity.