Identity/Architecture/IDAttachedServices
This is an exploration of how ID-attached services might work. None of this should be considered a spec or an indication of what the final solution will look like.
Profile server
For the purpose of this example, the profile server is a service which stores a user's name in a database, keyed on the user's identity (i.e. email address). That name is a simple string.
Reading
Relying parties will want to get a user's name when they log into their site for the first time.
Requirements:
- Users need to authenticate with BrowserID through the RP before that RP is allowed to query their name.
- Users need to consent to their name being given to the RP. Simply logging into an RP's site is not enough
To achieve this, the profile server needs to receive an assertion. However, compared to an RP getting an assertion to let users log into their site, there are two differences:
- Users will not visit the profile server directly so any assertion they get and present to the profile server will have the RP as the audience.
- The assertion is used to read information for a given identity, not to log into a service with that identity.
This means that the profile server will need to accept assertions with an audience of the RP because that's all the RP can provide. Therefore the audience check on the profile server side should be against the remote endpoint of the jschannel (as opposed to the address of the profile server).
There is however a problem if the RP shares an assertion with the profile server: the profile server can use that assertion to log into the RP.
TODO: should the IDP (e.g. BrowserID) interface with the profile server directly to prevent the profile server from knowing the RPs that a user visits?
Non-login assertion
One idea to solve this problem would be to create a new type of assertion: a non-login assertion.
If assertions had an extra "purpose" field, it would be easy to distinguish between a "get_info" purpose and a "login" purpose. The purpose would default to "login" and the verifier would reject non-login assertions unless it is told what purpose to check for.
The BrowserID dialog would know what type of assertion is being requested and could display a different consent message.
TODO: this get_info assertion would allow the RP to query any ID-attached service on behalf of the user. is that a problem? should it be restricted to the profile server?
TODO: are we reinventing OAuth?
Obtaining (and caching?) consent
We need to obtain consent from users before passing on their personal information to RPs.
TODO: do we ask users for permission every time we want to pass their name to an RP or do we somehow cache that consent? or do we assume that if their BCP trusts a service then consent is automatic?
Writing
The profile server will need to have a write interface so that the name entered by a user can be saved.
Requirements:
- The name entered by a user while logging into an RP needs to be cached so that it doesn't need to be entered again in a different browser.
Controlling write access to the profile server is tricky and we run into the same assertion audience as in the reading case.
In order to use the hypothetical "set_name" operation, an RP will need to present a "set_info" assertion with an audience of the profile server. This is normally not possible, but the BrowserID API will be extended to allow this limited grant of an assertion which violates the regular origin rules.
When the profile server receives the set_info assertion from the RP, it will write the name in its database against the email address contained in the assertion.
Pre-filling name field
In most cases, the IDP knows the names of its users and could therefore provide it without the need for a third party service. However, we want to give users the ability to choose what name they give to an RP.
This doesn't however prevent us from pre-filling the name field with what the IDP knows.
ID-attached bookmark storage service
Let's imagine another type of potential ID-attached service: a bookmark storage service.
To view a user's bookmarks, an RP must acquire an assertion from the IDP specific to that purpose. Then it uses that to access data for that user from the bookmark server.
To add a bookmark to the service on behalf of that user, it needs to get a different type of assertion from BrowserID. Then it can instruct the bookmark server to store bookmarks for that user.
Audit trail
Should we want an audit trail to catch abusive RPs, we could store the name of the RP against each bookmark, but this may have privacy implications since the profile server would then have a record of sites that a user has visited.