Difference between revisions of "Revocation"
From MgmtWiki
(Created page with "==Full Title or Meme== The problem of revoking a grant previously issued on behalf of a Subject. ==Context== The collection of User Private Information by a Data C...") |
(→Problems) |
||
| (14 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
| − | The problem of revoking a grant previously issued on behalf of a [[Subject]]. | + | 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== | ==Context== | ||
The collection of [[User Private Information]] by a [[Data Controller]] now necessitates the ability [[Authentication|Authenticate]] the [[User]] under a wide range of challenges, like: | The collection of [[User Private Information]] by a [[Data Controller]] now necessitates the ability [[Authentication|Authenticate]] the [[User]] under a wide range of challenges, like: | ||
# Simplest of all the [[User]] needs to [[Authentication|Authenticate]] from time to time and on a variety of devices under less than ideal conditions where passwords are mistyped and [[Multi-factor Authentication|Alternate Authentication factors]] are lost or fail. | # Simplest of all the [[User]] needs to [[Authentication|Authenticate]] from time to time and on a variety of devices under less than ideal conditions where passwords are mistyped and [[Multi-factor Authentication|Alternate Authentication factors]] are lost or fail. | ||
| − | |||
| − | |||
| − | |||
==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. | |
| − | * | + | * Certificate revocation: Mechanics and meaning Barbara Fox and Brian LaMacchia<ref>Research Gate https://www.researchgate.net/scientific-contributions/Barbara-Fox-70755466</ref> |
| + | <blockquote>[[Revocation]] of public key certificates is controversial in every aspect: methodology, mechanics, and even meaning. This isn't so surprising, though, when considered in the context of current public key infrastructure (PKI) implementations. PKIs are still immature; consumers, including application developers and end-users, are just beginning to understand the implications of large-scale, heterogeneous PKIs, let alone PKI subtleties such as revocation. In this paper, which is the product of a panel discussion at Financial Cryptography '98, we illustrate some of the semantic meanings possible with current certificate revocation technology and their impact on the process of determining trust relationships among public keys in the PKI. Further, we postulate that real-world financial applications provide analogous and appropriate models for certificate revocation.</blockquote> | ||
==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. | ||
| + | * Require the [[Authorization]] endpoint to verify liveness of the token before it authorizes actual access to the [[Resource]]. | ||
==References== | ==References== | ||
Latest revision as of 15:58, 15 November 2024
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.
- Certificate revocation: Mechanics and meaning Barbara Fox and Brian LaMacchia[1]
Revocation of public key certificates is controversial in every aspect: methodology, mechanics, and even meaning. This isn't so surprising, though, when considered in the context of current public key infrastructure (PKI) implementations. PKIs are still immature; consumers, including application developers and end-users, are just beginning to understand the implications of large-scale, heterogeneous PKIs, let alone PKI subtleties such as revocation. In this paper, which is the product of a panel discussion at Financial Cryptography '98, we illustrate some of the semantic meanings possible with current certificate revocation technology and their impact on the process of determining trust relationships among public keys in the PKI. Further, we postulate that real-world financial applications provide analogous and appropriate models for certificate revocation.
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.
