Difference between revisions of "Revocation"
From MgmtWiki
(→Full Title or Meme) |
(→Problems) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 8: | Line 8: | ||
==Problems== | ==Problems== | ||
| + | *As a general rule any certificate that is issued to any [[Subject]] cannot be guaranteed of [[Revocation]] because it is not possible to know where that certificate has been used. | ||
*Once a [[Bearer Token]] has been issued to a [[Relying Party]] by a [[Identifier or Attribute Provider]] there is no practical way to issue a [[Revocation]] that will guarantee success. | *Once a [[Bearer Token]] has been issued to a [[Relying Party]] by a [[Identifier or Attribute Provider]] there is no practical way to issue a [[Revocation]] that will guarantee success. | ||
==Solutions== | ==Solutions== | ||
| + | * The two canonical ways to [[Revocation|revoke]] any grant (or certificate) is to require that the validity be checked online ([[OCSP]]) or to distribute a list of revoke certificates([[CRL]]). | ||
| + | * Many mitigations to the [[Revocation]] problem exists, for example giving certificates a very short life time. | ||
* Issue a [[Refresh Token]] that can be used by the [[Relying Party]] to acquire a fresh access token with a short life time on demand. The IAP would then handle any [[Revocation]] for the user which would have no effect during that short life time. | * Issue a [[Refresh Token]] that can be used by the [[Relying Party]] to acquire a fresh access token with a short life time on demand. The IAP would then handle any [[Revocation]] for the user which would have no effect during that short life time. | ||
* Require the [[Authorization]] endpoint to verify liveness of the token before it authorizes actual access to the [[Resource]]. | * Require the [[Authorization]] endpoint to verify liveness of the token before it authorizes actual access to the [[Resource]]. | ||
Latest revision as of 09:07, 3 October 2018
Full Title or Meme
The problem of revoking a grant previously issued by an Identifier or Attribute Provider (IAP) on behalf of a Subject which is a requirement of several privacy regulations.
Context
The collection of User Private Information by a Data Controller now necessitates the ability Authenticate the User under a wide range of challenges, like:
- Simplest of all the User needs to Authenticate from time to time and on a variety of devices under less than ideal conditions where passwords are mistyped and Alternate Authentication factors are lost or fail.
Problems
- As a general rule any certificate that is issued to any Subject cannot be guaranteed of Revocation because it is not possible to know where that certificate has been used.
- Once a Bearer Token has been issued to a Relying Party by a Identifier or Attribute Provider there is no practical way to issue a Revocation that will guarantee success.
Solutions
- The two canonical ways to revoke any grant (or certificate) is to require that the validity be checked online (OCSP) or to distribute a list of revoke certificates(CRL).
- Many mitigations to the Revocation problem exists, for example giving certificates a very short life time.
- Issue a Refresh Token that can be used by the Relying Party to acquire a fresh access token with a short life time on demand. The IAP would then handle any Revocation for the user which would have no effect during that short life time.
- Require the Authorization endpoint to verify liveness of the token before it authorizes actual access to the Resource.
