A taxonomy/model for user context: defining user attributes to understand personalisation Paola Roccuzzo — Experience Design Director (Content Services), Foolproof London 2024
WIAD LONDON - MARCH 2024
A taxonomy/model for user context Defining user attributes to understand personalisation
Paola Roccuzzo, experience design director for content services @Foolproof_UX
WIAD LONDON - MARCH 2024
draft classification
A taxonomy/model for user context Defining user attributes to understand personalisation
Paola Roccuzzo, experience design director for content services @Foolproof_UX
01
Some background
2019: GOV.UK future strategy - personalisation
Our brief was to understand how a government account could remove friction for users interacting with GOV.UK. Things we had to grapple with: ●
define the different outcomes of a personalised experience
●
find successful examples to point to
●
land a shared understanding of the term ‘personalisation’
The personalisation spectrum: 2019
❌
In hindsight, despite using the concept in our prototypes, we didn’t fully understand digital identity. This is where I’m restarting from today.
02
The (draft) classification
Some caveats before diving in
● This is a work in progress, highly objectionable–objections welcome, this is a call for arms ● Some bits are esoteric–but technology is evolving fast ● It’s a partial view because 30 minutes is a short time–come find me for the rest if we don’t make it on time ● User context source: W3C Verifiable Credentials recommendations ● Personalisation outcomes inspo: Jeff Eaton
Facets for user context: user attribute type
User attribute type
Signal Credentials
Facets for user context: source
Source
Device System Holder
Facets for user context: source
Source
Device System Holder
Definition The entity making the claim (so far, only human)
Facets for user context: privacy spectrum
Privacy spectrum
Non correlatable Correlatable via collusion Highly correlatable
Data minimisation
more privacy
less privacy
Facets for user context: privacy spectrum
Privacy spectrum
Example “Is older than 18”
Non correlatable Correlatable via collusion Highly correlatable
Example Name, date of birth, postcode Example Government ID, shipping address
Facets for user context: level of identification
Level of identification
Example Returning user for analytics
Returning device Authorised credentials Verified identity
A system account with username, password and 2FA
A system account connected to a valid proof of identity (ex. online banking account)
Enter the trust model
● A trust model implies a set of rules and standards to verify identity (and claims) which organisations agree to follow ● Not common (yet): few systems require identity verification ● When you use a digital identity system (like GOV.UK One Login) you’re entering a trust ecosystem ● In the future the use of digital identity might extend to systems that right now don’t require it
Facets for user context: trust model entities
Trust model entities
Holder Subject Issuer Verifier
The entity that submits verifiable credentials The entity related to verifiable credential (can be ≠ holder, a parent or a carer) The entity that issues a verifiable credential for a holder The entity that verifies a verifiable credential for an issuer
Facets for user context: trust model concepts Trust model concepts Attribute that can be verified and exchanged in a trust ecosystem Verifiable credential
Verifiable presentation
Proof
Data derived from one or more verifiable credentials
The cryptographic encoding that allows to see whether a credential or a presentation has been tampered with
The personalisation spectrum: 2024 (WIP)
03
In practice
Identity verification system
Recommendations
We’re now in a trust ecosystem
Dynamic assembly based on verifiable credential + proof
Dynamic assembly based on verifiable credential - no proof
Verifiable credentials with proof
Verifiable credentials with proof
Verifiable credentials needs proof
Issuer
Holder (and subject)
Verifier
Automated decision based on verifiable presentation