I needed an eye test, so I booked online. I searched for a leading brand, a branch location and a time of mutual convenience. I clicked ‘book this appointment’.
I expected to be offered a standard downloadable appointment file for my choice of calendar. However, I was taken here…
So, being able and willing to go along with the process, and having made ‘sure I trust’ the supplier (How?) and having learnt ‘about the risks’, I dutifully clicked ‘Allow’, knowing that this third party in my online relationship with the optician could ‘View and Edit events in all my calendars’.
Everyone was happy! Even the blue robot gave me a familiar gesture of encouragement. My event was added to my calendar.
A week or so later, I travelled (by bike) to the conveniently located optician at the mutually agreed time: examination and advice ensued and spectacles were purchased.
A few weeks later, I checked and found that the authorisation was still recorded in my calendar account. As I had expected…
Of course, most readers of this ‘consideration’ will be aware of what is going on here. As google kindly notes above, it is up to me to ‘remove access’ for sites and apps which I ‘no longer trust or use’. From a normal user’s point of view, I only used this intermediary to book one appointment, so why does it still have access?
Since this is just an example, and I’m interested in the general case, I want to ask the following questions.
Questions on service design and authorisation
Complexity and generic risks ‘Can the average user manage the control of authorisations and assess their risks?’
User focused authorisation control ‘Is it reasonable to require users to track all of these permissions across all of the authorisation servers supporting their mesh of services and manually revoke them?’
Overreach for technical ease and commercialisation ‘Why is it appropriate to be given full read/write access? Why not ‘create an appointment’?’
Overreach ‘And why to *all* my calendars?’
Timescale of authorisation ‘Why is the access for longer than that necessary to create the appointment?’
Granularity of authorisation matching intention ‘IF there is a user need to move the appointment on behalf of the user, should circumstances change (and there was no evidence of this when they did change in my user journey), shouldn’t an additional authorisation be sought? Or at least a separate authorisation at the point of consent?’
Design for security and privacy ‘Why does the design of the API and of the authorisation scopes NOT match the use cases and meet the legitimate security and privacy concerns?’
User focused service ‘In short, why is there no notion of my intent when I gave consent, no model of time or purpose, to match the technology to the need?’
Good design ‘What happened to the principle of least privilege?’ https://en.wikipedia.org/wiki/Principle_of_least_privilege
In my view, the emerging use of OAuth to deliver inter-organisational user journeys is already fraught with pitfalls both of usability and of hidden attack vectors. A compromise of tokens, or breach of the organisation running the (generic) ‘blue robot’ could lead to loss of a lot of data. It is concerning enough that google itself scans my calendar, but enabling a myriad of infrastructure providers to do so is of even greater concern, whether they do so intentionally or as a result of breach.
Of course, there is much excellent work being done in strengthening the protections of tokens, and the types of token and the trust frameworks of closed eco-systems. This is clearly exemplified in the Open Banking world and I am not suggesting that such applications are included in the remit of my concerns here.
But the bulk of ‘ordinary’ use cases of OAuth do have these issues: system to system delegated authorisation with broad scopes of permitted access, lack of time bound controls, lack of effective user control, and design for technical ease rather than user-centric needs and privacy concerns.
So, I now have my spectacles.
I’m administering Vine Solutions and I need to join an online meeting with HMRC. I select the appointment, I’m sent an email…
I click my calendar provider, and I see…
OAuth isn’t enough
If I hadn’t already removed access, the intermediary’s blue robot would have used the previous permission to create a new event in my calendar.
As the screen above entreats us: we had better make sure ‘we TRUST XYZ.com’ – whoever that is – to be a key player in control of access to our distributed data sources. Perhaps especially so, if the current practice of designing and granting long lived, wide scoped authorisations is to continue.
Perhaps there is a better way?
I think there is.
Important note: This ‘consideration’ of mine is not seeking to single out one service provider. This is just an example based on a real-life user (me). Their web site tells me that my two appointments are part of the 100,000,000 events they have successfully created for over 50,000 businesses and 80,000 sites .
Rather, I’m making a more general point about the need to discuss and get these things right, to put the person at the centre, to respect their data and the risks, and to design services and authorisations which are more granular, more privacy preserving, more context aware.