UI/UX Docs for Consent-informed Attribute Release (CAR)
- CAR aims to:
- Promote transparency and inquiry about how a user's personal data is being shared between his/herhome institution and affiliated sites.
- Promote privacy by allowing users to participate in decisions about when their personal information is shared.
- Promote innovation by enabling data sharing in contexts where it might otherwise not be possible, such as:
- Student-facing applications that can receive FERPA-protected data only with revokable consent by the user.
- International audiences that may represent countries with privacy laws stricter than the United States'.
- CAR is distributed:
- Integrates with Shibboleth.
- Can be used with other authentication mechanisms, e.g. OAuth, OIDC.
- Can be integrated with other systems requesting data.
- Offers a means for users to make attribute release choices that apply even when the user is not part of the interaction between a website and the institution.
- CAR contains 4 UI components:
- Intercept Interface: An interface to provide users with information and choices about attribute release as it's about to happen.
- User Self-Service: Web application to allow users to review and update choices about attribute release.
- Policy Admin Tool (docs coming soon!): A place for institutions to manage institutional rules and settings around attribute release.
- Configuration/Deployment UI for “super admins” (docs coming soon!): A Web application to allow highly empowered admins to configure security sensitive aspects of the system, e.g. installation of PKI certificates.
- CAR holds:
- Institutional rules on attribute release based on the user’s identity, the attribute in question, specific values of the attribute, and requesting site’s identity.
- User choices on attribute release based on the the attribute in question, specific values of the attribute, and the requesting site’s identity.
- CAR renders decisions about attribute release but does not enforce them. Integrated systems (such as Shibboleth Identity Providers) are responsible for the final decision about when to release attributes.
Concepts and Vocabulary
Architect/engineer vocabulary is sometimes necessary to convey nuances that are not always important for the user to think about. Here's a map of generic terminology:
|To Engineers/Architects:||To Users:||To Mean:|
|Attribute||Information||Data about a user held in “label” and “value” pairs. For example, email = email@example.com. Here “email” is the label and “firstname.lastname@example.org” is the value. All attributes have at least the label.|
|Relying Party, RP, Service Provider, SP||Site||The requester of user attributes/information|
|Resource Holder, RH||-||A holder of user attributes/information that is using CAR for policy decisions about attribute release about specific users to specific requesters.|
|Locale||-||A regional or other context for how content should be presented to the user - language, currency, date formatting, etc.|
|ARPSI||-||Attribute Release Policy Service for Institution: the back end component of CAR that deals with rules about attribute release.|
|COPSU||-||Consent Policy Service for Users: the back end component of CAR that deals with user choices about attribute release.|
|CARMA||-||CAR MAnager: The component of CAR that communicates between the user interfaces and COPSU/ARPSI|
We Avoid Saying:
|Notice||This is a legal term with sensitive implications.|
|Share (information)||User testing has found this term to frequently evoke concerns that data will be published (similar to the concept of sharing on Facebook). Our best working term at the moment is "release".|
Style and Branding
CAR components are co-branded between the host institution and TIER. Controlled customization (colors, logos) is available.
Working style guide (blues are Duke-specific)