Difference between revisions of "Scope"

From MgmtWiki
Jump to: navigation, search
(→‎Solution)
(→‎Context)
 
(36 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
==Full Title or Meme==
 
==Full Title or Meme==
−
A request for [[Claim]]s is a [[Scope]].
+
A request for [[Claim]]s is expressed as a set of [[Scope]]s.
  
 
==Context==
 
==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 [[Scope]]s 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:
 
Claims typically go through a series of steps, for example:
 
# A [[User]] will go to a [[Web Site]] hosting a [[Resource]] that the user wants to access.
 
# A [[User]] will go to a [[Web Site]] hosting a [[Resource]] that the user wants to access.
 
# The [[Web Site]] will send a collection of [[Scope]]s to a [[User]] asking for [[Claim]]s to authorize access.
 
# The [[Web Site]] will send a collection of [[Scope]]s to a [[User]] asking for [[Claim]]s to authorize access.
−
# The [[User Agent]] should know, a priori, where to send the [[Claim]]s for verification.
+
# The [[User Agent]] should know, a priori, where to send the [[Claim]]s 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.
 +
# The user will need to stipulate a [[User Consent]] showing which [[Scope]]s they which to release to the [[Web Site]].
 +
# 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]].
 
# The verified claims will be collected and forwarded to the [[Web Site]].
 
# The verified claims will be collected and forwarded to the [[Web Site]].
 
# The [[Web Site]] will evaluate the verified claims and determine whether to authorize access to the resource.
 
# The [[Web Site]] will evaluate the verified claims and determine whether to authorize access to the resource.
 
# Optionally the [[Web Site]] will request additional claims to meet the needs to authorize access.
 
# 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==
  
−
* In computer networking a variety of statements can be made by a user to acquire authorized access to a resource.
+
*There seems to be little agreement around the industry on what a scope really is <ref>Vittorio Bertocci, ''On The Nature of OAuth2’s Scopes.'' (2018-09-04) Auth0 https://auth0.com/blog/on-the-nature-of-oauth2-scopes/</ref> since if was first used in [[OAuth 2.0]].
−
* The distinction as to [[Authentication]], who a user is, versus [[Authorization]], or what that user is permitted to do, is no longer helpful.
+
*also [[SAML 2.0]] scopes
−
* NIST has recognized that there are multiple metrics for the quality of statements about a user in their third update to SP 800-63
 
−
* [[Claim]]s can be highly detailed, do to data fields, or a collection of fields, like the [[User]] address, this can be overwhelming if presented for [[User Consent]]. Some protocols, like [[OpenID Connect]] provide for aggregated collections of claims that OpenID calls '''[[Scope]]'''.<ref>Nat Sakimura ''Scopes and Claims in OpenID Connect'' https://nat.sakimura.org/2012/01/26/scopes-and-claims-in-openid-connect/</ref>
 
  
 
==Solution==
 
==Solution==
−
Here will we describe the scopes available from [[OpenID Connect]] as a good example.
+
This section starts by describing the [https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims 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.
 
{|border="1" padding="2" width="799px"
 
{|border="1" padding="2" width="799px"
−
| Name || Type || Cat||  Notes  
+
| 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.
 
|-
 
|-
−
|openid ||Attribute ||driver's license || Informs the Authorization Server that the Client is making an OpenID Connect request. If the openid scope value is not present, the request MUST NOT be treated as an OpenID Connect request. The openid value also requests that the ID Token associated with the authentication session be returned. If the response_type includes token, the ID Token is returned in the Authorization Response along with the Access Token. If the response_type includes code, the ID Token is returned as part of the Token Endpoint response. This scope value requests access to the user_id Claim at the UserInfo Endpoint.
+
|profile  ||2 ||4 || requests that access to the End-User’s profile Claims excluding the address and email Claims.
  
 
|-
 
|-
−
|profile  || || || This requests that access to the End-User’s profile Claims excluding the address and email Claims at the UserInfo Endpoint be granted by the issued Access Token.
+
|email|| 4|| 4|| requests that access to the email and verified Claims
−
 
 
 
|-
 
|-
−
|email|| || UAF U2F|| This requests that access to the email and verified Claims at the UserInfo Endpoint be granted by the issued Access Token.
+
|Email validated || 2||0 ||more significant for AuthN - needed if noticed desired
−
 
 
 
|-
 
|-
−
|address|| || UMA||This requests that access to address Claim at the UserInfo Endpoint be granted by the issued Access Token.
+
|address|| 3|| 4||requests access to address Claim
 
|-
 
|-
−
|phone|| AuthZ|| ||This requests that access to the phone_number Claim at the UserInfo Endpoint be granted by the issued Access Token
+
|addr validated||3||0|| for example by AAMVA
−
 
 
 
|-
 
|-
−
|phone validated||AuthN+AuthZ ||OpenID Connect || more significant for AuthN
+
|phone|| 5|| 5||requests that access to the phone_number Claim (assumed SMS capable)
 
|-
 
|-
−
|SAML||AuthN ||SAML2||
+
|phone validated||2 ||0 || more significant for AuthN - needed if noticed desired
 
|-
 
|-
−
|Univ. of MD|| || ||IDEF registered
+
|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.
  
 
==References==
 
==References==
 
[[Category:Glossary]]
 
[[Category:Glossary]]
 +
[[Category:Security]]
 +
[[Category:Privacy]]
 
[[Category:Authentication]]
 
[[Category:Authentication]]
 +
[[Category:Authorization]]

Latest revision as of 13:01, 24 October 2018

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 [1] 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.

References

  1. ↑ Vittorio Bertocci, On The Nature of OAuth2’s Scopes. (2018-09-04) Auth0 https://auth0.com/blog/on-the-nature-of-oauth2-scopes/
Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=Scope&oldid=3951"