OAuth 2.0 Device Posture Signals
draft-wdenniss-oauth-device-posture-01
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | William Denniss , Karl McGuinness , John Bradley | ||
| Last updated | 2018-05-17 (Latest revision 2017-11-13) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Enterprise and security focused OAuth providers typically want additional signals to confirm user presence when users return to previously authorized apps. Rather than requiring a full reauthentication, or require enrollment in a mobile device management solution, some authorization servers may be willing to accept device posture signals from the app, like the fact that device has a lock screen, as confirmation of user presence. This document details how OAuth native app clients can communicate device posture signals to OAuth providers.
Authors
William Denniss
Karl McGuinness
John Bradley
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)