Difference between revisions of "Scope"
From MgmtWiki
(→Solution) |
(→Solution) |
||
| Line 31: | Line 31: | ||
|address|| 3|| 4||requests that access to address Claim | |address|| 3|| 4||requests that 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|| 5|| 5||requests that access to the phone_number Claim (assumed SMS capable) | ||
|- | |- | ||
Revision as of 21:12, 18 August 2018
Full Title or Meme
A request for Claims is expressed as a set of Scopes.
Context
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.
- The Web Site will send a collection of Scopes to a User asking for Claims to authorize access.
- The User Agent should know, a priori, where to send the Claims for verification.
- 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.
- 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.
Solution
Here will we describe the scopes available from OpenID Connect as a good example.
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,
| 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. |
| 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 that access to address Claim |
| 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 good approximation of this) |
The above canonical scope will be extended over time as new types of request for user claims are understood.
