-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create accounts #41
Comments
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 onceThis 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 beforeThis 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 laterThis 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. |
Digital Marketplace are looking at how we can encourage users to use more complex and memorable passwords. I think it's a pattern that would have value if we could fold it into this one. |
WhatI'm proposing a pattern for encouraging users to choose more complex, more memorable passwords. Why
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
I have Anything else
|
Thanks @jonodrew - we do have related guidance here, but it's mainly focussed on not stopping users from choosing the kind of passwords you describe, rather than actively encouraging them. Have you had any success on Digital Marketplace with encouraging users to create stronger 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[0], 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? [0] 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. |
Re: above comment, we now have a separate issue for Passwordless login. |
Should this page now reference consideration being given to using GOV.UK One Login? |
Use this issue to discuss this pattern in the GOV.UK Design System.
The text was updated successfully, but these errors were encountered: