Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Permissions
6 views
Skip to first unread message
Forbes Lindesay
May 15, 2013, 12:52:23 PM5/15/13
to
There are two types of permissions I want to consider. Permissions given by **users** to the **applications** they use and permissions given by **administrators** of organisations to the **users** within that application.
## **users** -> **applications**
It seems to me that the issue of where users store their data and what services they subscribe to is fundamentally separate from what Browser ID should cover. Gravatar already does a fine job of providing a public profile from an e-mail address so this doesn't need to be rolled in to what Browser ID does.
When it comes to parts of my identity that I don't consider completely public knowledge (e.g. my relationship status), it's a slightly different matter. I don't want everyone who has my e-mail to be able to see that. I don't even want every website that I've logged in to with Browser ID to be able to see that.
What I want is a way for a website to explicitly ask for permission to see that information. I also want a way to revoke that permission for a given website at some future date.
I think the issue of permissions is fundamentally linked to the issue of identity, and should be addressed as part of the same process (if possible).
### As a Consumer of Permissions
I want to be able to say when I log the user in, please give me permissions x, y and z. Where x, y and z are just simple, user readable, strings. The token I get back should be one that I can both validate as a Browser ID token for my domain and that someone else can validate as a permission token providing permissions x, y and z to my domain.
### As an IDP
Ideally I wouldn't want to have to deal with this initially, but in the long run I'm going to want to make it easy for users to revoke these permissions.
### As a Producer of Permissions
As someone like Facebook, I want to be given a token that I can verify gives the requester permission to view, say, the relationship status of user f...@example.com.
## **administrators** -> **users**
As an IDP I may want to restrict which users can obtain certain permissions. For example I might create an "Administrate Awesome Co. Website" as a permission that my website's content management system would recognize. I'd want my users to be able to delegate that permission to tools that help you update websites (IDEs and the like) in much the same way as with the typical transfer of permissions from **users** -> **applications**.
Essentially I think this is a case that could be covered in pretty much exactly the same way as **users** -> **applications** as it would be simply up to the IDP to do the extra work.
## Motivation
The reason this can't be provided by a third party very easily is that it would require users to log in twice. I suppose that would only be the first time on any given device (and then once each month or so), but it would be a little confusing for users?
One alternative way that this might work:
- Assume the user logs in to `www.consumer.com` using Browser ID as `f...@example.com`
- `www.consumer.com` wants the `CONSUME` permission, which it requests from `www.producer.com`. It does this by providing its Browser ID token to `www.producer.com`.
- `www.producer.com` verifies the token, but for `www.consumer.com`. It then asks Browser ID to perform an "upgrade" operation on that token. Providing the user is still logged in to Browser ID as `f...@example.com`, there are no new terms and conditions to accept, and the website requesting upgrade already knows who the user is (so they're not revealing anything new about their identity), this upgrade could be done without user interaction.
- `www.producer.com` then displays a permission dialog asking the user to give permission.
## Summary
In essence then I'm asking for one of the following two options:
1. An "UPGRADE" operation which takes a Browser ID authentication token for one domain and converts it to be for another domain without user interaction (providing the user is still authenticated).
2. A built in way to manage permissions being given by the user or IDP to applications.
## **users** -> **applications**
It seems to me that the issue of where users store their data and what services they subscribe to is fundamentally separate from what Browser ID should cover. Gravatar already does a fine job of providing a public profile from an e-mail address so this doesn't need to be rolled in to what Browser ID does.
When it comes to parts of my identity that I don't consider completely public knowledge (e.g. my relationship status), it's a slightly different matter. I don't want everyone who has my e-mail to be able to see that. I don't even want every website that I've logged in to with Browser ID to be able to see that.
What I want is a way for a website to explicitly ask for permission to see that information. I also want a way to revoke that permission for a given website at some future date.
I think the issue of permissions is fundamentally linked to the issue of identity, and should be addressed as part of the same process (if possible).
### As a Consumer of Permissions
I want to be able to say when I log the user in, please give me permissions x, y and z. Where x, y and z are just simple, user readable, strings. The token I get back should be one that I can both validate as a Browser ID token for my domain and that someone else can validate as a permission token providing permissions x, y and z to my domain.
### As an IDP
Ideally I wouldn't want to have to deal with this initially, but in the long run I'm going to want to make it easy for users to revoke these permissions.
### As a Producer of Permissions
As someone like Facebook, I want to be given a token that I can verify gives the requester permission to view, say, the relationship status of user f...@example.com.
## **administrators** -> **users**
As an IDP I may want to restrict which users can obtain certain permissions. For example I might create an "Administrate Awesome Co. Website" as a permission that my website's content management system would recognize. I'd want my users to be able to delegate that permission to tools that help you update websites (IDEs and the like) in much the same way as with the typical transfer of permissions from **users** -> **applications**.
Essentially I think this is a case that could be covered in pretty much exactly the same way as **users** -> **applications** as it would be simply up to the IDP to do the extra work.
## Motivation
The reason this can't be provided by a third party very easily is that it would require users to log in twice. I suppose that would only be the first time on any given device (and then once each month or so), but it would be a little confusing for users?
One alternative way that this might work:
- Assume the user logs in to `www.consumer.com` using Browser ID as `f...@example.com`
- `www.consumer.com` wants the `CONSUME` permission, which it requests from `www.producer.com`. It does this by providing its Browser ID token to `www.producer.com`.
- `www.producer.com` verifies the token, but for `www.consumer.com`. It then asks Browser ID to perform an "upgrade" operation on that token. Providing the user is still logged in to Browser ID as `f...@example.com`, there are no new terms and conditions to accept, and the website requesting upgrade already knows who the user is (so they're not revealing anything new about their identity), this upgrade could be done without user interaction.
- `www.producer.com` then displays a permission dialog asking the user to give permission.
## Summary
In essence then I'm asking for one of the following two options:
1. An "UPGRADE" operation which takes a Browser ID authentication token for one domain and converts it to be for another domain without user interaction (providing the user is still authenticated).
2. A built in way to manage permissions being given by the user or IDP to applications.
0 new messages