I’ve got a new post up on the Forrester blogs about “consensual impersonation”, which is what happens when you give your password to someone else so they can do something from your account. As Paul Madsen points out, it’s “another manifestation of the password anti-pattern”, and it’s a use case whose legitimacy — at least some of the time — we haven’t really thought about. Head over there to see if I manage to avoid mentioning UMA. (Hint…)
Tangled musings on identity, privacy, trust, and suchlike
Eve,
I am working on application which needs to provide delegated access to user’s data. There are many dimensions to delegated access— Access scope (OAuth scope), time limit on the access, geographical location from where the delegating access can be used, automatic revocation on access abuse, 2-step verification setup for the delegacy etc.
Suffice to say it is not easy to do access delegation the “right way” :(
Saqib
Saqib– All excellent points. In the UMA ecosystem, at least some of these dimensions would/could be managed by the authorization server, depending on what features it offers to enable the resource owner to set policy and revoke access. Some types of authorization context are independent of the requesting party and their client, such as time of day; others are dependent on knowing claims about them. This is discussed a bit in the spec. As well, if the resource server itself detects abuse, it always has the right to refuse access even if the token comes back valid with suitable entitlements. Outsourcing even this is something we’ve discussed from time to time. Let me know if you’re interested to join in…