Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Create accounts #41
created this issue from a note
in GOV.UK Design System Community Backlog
Jan 12, 2018
Starting to just prod a little at the format of "help a user to...", I wonder if it's more helpful to think about how services "recognise a user" and then work backward from there to whether or not that I have an account.
To unpack that a bit, I think there's 3 variations of recognising a user:
1. Recognising a user once
This is kind of mentioned in this pattern, under "when not to use", but I think we should probably also link off to a dedicated page for this – We've had stuff called "Save & Return" before and we definitely something about this properly documented.
2. Recognising a user you've seen before
This is what the current pattern is talking about. What's missing here is that the user might already have some way to identify them without creating an account. FutureGov have written about the idea of asking users knowledge based verification questions, which is also one way that Verify identity providers prove identity. In other words, this would be another page in itself which would be linked to from "when not to use this" which talks about using data already held about a user to identity them.
Connecting your service to Verify is another way of recognising a user, and is probably the best option if the only data your service holds about the user is their name, address and date of birth. Verify will validate that this is the current user's details by cross checking it with other information the user holds that your service won't see. In Verify land, we'd call this "matching".
3. Identifying a user you've not seen before, so you can recognise them later
This is sort "pure" creating an account – When you have no information about the user, but you need some for them to use the service. In these situations, it's important to consider what information you need from the user. We should make sure we document the fact that you shouldn't be asking for more information from a user than is neccesary.
Again, Verify can help with this because of it will (potentially) give you only the information you need (if that information is name, address and DoB) without you having to see the additional information which is needed to verify that data.
Sorry for the big brain dump, just thought it might useful to get some of this stuff down!
@sanjaypoyzer We (mostly Matti Keltanen) have been doing a bunch of thinking about how and when to identify users.
We published a bit of guidance on this - https://home-office-digital-patterns.herokuapp.com/patterns/identifying-users but it needs work.
Was just talking with @timpaul about how to structure guidance as it's kind of an adult pattern with lots of child patterns about how to approach different types of authentication. And how it links up with the service manual who are also writing guidance on this.
This was referenced
Oct 10, 2018
I'm proposing a pattern for encouraging users to choose more complex, more memorable passwords.
Patterns for user creation already exist, and multiple services ask users to create an account where Verify is too heavy-weight for integration
Cyberaware, a campaign by HMG supported by NCSC, recommends three simple words for users to generate strong but memorable passwords
So this is interesting because it came from recommendations to cleave closer to the pattern. We're planning to use a blacklist, and there's a separate thread of what the content design should be for that, but we're also working on also providing actionable information to the user so they've got a better idea of how to make a better password.
No data yet. I'm not really sure how we could check, other than comparing hashes?
 If there's an existing pattern I'd really appreciate if you could link to it
I think it would be good for the Design System to be recommending a passwordless authentication system, via a unique link in emails. The security benefits are well documented nowadays and the less we are asking users to remember passwords that they barely ever need to actually use, the better.