Scope

Full Title or Meme

A request for Claims is expressed as a set of Scopes.

Context

• Scopes were introduced in OAuth 2.0 as a means to request a collection of claims. They have since been called to fill a large number of other functions.
• The primary reason to be concerned with Scopes here is as a means to inform the user which User Information is requested by the Relying Party.

Claims typically go through a series of steps, for example:

1. A User will go to a Web Site hosting a Resource that the user wants to access.
2. The Web Site will send a collection of Scopes to a User asking for Claims to authorize access.
3. The User Agent should know, a priori, where to send the Claims for verification. In the case of OpenID Connect the request is automatically redirected to the OpenID Provider (OP) associated with the choice made by the user at the Relying Party Web Site, called the client by the OpenID specifications.
4. The user will need to stipulate a User Consent showing which Scopes they which to release to the Web Site.
5. The source of the User Consent may offer to retaining the user's choice for a limited time and apply it again if request for the same scope in made by the same Web Site.
6. The verified claims will be collected and forwarded to the Web Site.
7. The Web Site will evaluate the verified claims and determine whether to authorize access to the resource.
8. Optionally the Web Site will request additional claims to meet the needs to authorize access.

• In computer networking a variety of statements can be made by a user to acquire authorized access to a resource.

Problems

• There seems to be little agreement around the industry on what a scope really is since if was first used in OAuth 2.0.
• also SAML 2.0 scopes

Solution

This section starts by describing the scopes available from OpenID Connect as a good example, and is open to extension from there.

The name of the scope is followed by two scores for the risk to the user: (1) user security applies for both loss of access loss of control, (2) user privacy applies to the impact if the data is made public. These scores are not based on data, but are merely examples to show the concept.

Name	Sec Value	Priv Risk	Notes
openid	5	0	requests access to the user_id (sub) Claim which is assumed to be pair-wise unique for the privacy score.
profile	2	4	requests that access to the End-User’s profile Claims excluding the address and email Claims.
email	4	4	requests that access to the email and verified Claims
Email validated	2	0	more significant for AuthN - needed if noticed desired
address	3	4	requests access to address Claim
addr validated	3	0	for example by AAMVA
phone	5	5	requests that access to the phone_number Claim (assumed SMS capable)
phone validated	2	0	more significant for AuthN - needed if noticed desired
user device location	4	4	request for location of device used for this interaction (note that IP addresses leak a fairly good approximation of this)

The above canonical scopes will be extended over time as new types of request for user claims are understood.