draft-ietf-ace-oauth-authz-36.txt   draft-ietf-ace-oauth-authz-37.txt 
ACE Working Group L. Seitz ACE Working Group L. Seitz
Internet-Draft Combitech Internet-Draft Combitech
Intended status: Standards Track G. Selander Intended status: Standards Track G. Selander
Expires: May 21, 2021 Ericsson Expires: August 8, 2021 Ericsson
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
November 17, 2020 February 4, 2021
Authentication and Authorization for Constrained Environments (ACE) Authentication and Authorization for Constrained Environments (ACE)
using the OAuth 2.0 Framework (ACE-OAuth) using the OAuth 2.0 Framework (ACE-OAuth)
draft-ietf-ace-oauth-authz-36 draft-ietf-ace-oauth-authz-37
Abstract Abstract
This specification defines a framework for authentication and This specification defines a framework for authentication and
authorization in Internet of Things (IoT) environments called ACE- authorization in Internet of Things (IoT) environments called ACE-
OAuth. The framework is based on a set of building blocks including OAuth. The framework is based on a set of building blocks including
OAuth 2.0 and the Constrained Application Protocol (CoAP), thus OAuth 2.0 and the Constrained Application Protocol (CoAP), thus
transforming a well-known and widely used authorization solution into transforming a well-known and widely used authorization solution into
a form suitable for IoT devices. Existing specifications are used a form suitable for IoT devices. Existing specifications are used
where possible, but extensions are added and profiles are defined to where possible, but extensions are added and profiles are defined to
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 21, 2021. This Internet-Draft will expire on August 8, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 36, line 49 skipping to change at page 36, line 49
token is valid, the RS MUST respond to the POST request with 2.01 token is valid, the RS MUST respond to the POST request with 2.01
(Created). Section Section 5.10.1.1 outlines how an RS MUST proceed (Created). Section Section 5.10.1.1 outlines how an RS MUST proceed
to verify the validity of an access token. to verify the validity of an access token.
The RS MUST be prepared to store at least one access token for future The RS MUST be prepared to store at least one access token for future
use. This is a difference to how access tokens are handled in OAuth use. This is a difference to how access tokens are handled in OAuth
2.0, where the access token is typically sent along with each 2.0, where the access token is typically sent along with each
request, and therefore not stored at the RS. request, and therefore not stored at the RS.
This specification RECOMMENDS that an RS stores only one token per This specification RECOMMENDS that an RS stores only one token per
proof-of-possession key, meaning that an additional token linked to proof-of-possession key. This means that an additional token linked
the same key will overwrite any existing token at the RS. The reason to the same key will supersede any existing token at the RS, by
is that this greatly simplifies (constrained) implementations, with replacing the corresponding authorization information. The reason is
that this greatly simplifies (constrained) implementations, with
respect to required storage and resolving a request to the applicable respect to required storage and resolving a request to the applicable
token. token.
If the payload sent to the authz-info endpoint does not parse to a If the payload sent to the authz-info endpoint does not parse to a
token, the RS MUST respond with a response code equivalent to the token, the RS MUST respond with a response code equivalent to the
CoAP code 4.00 (Bad Request). CoAP code 4.00 (Bad Request).
The RS MAY make an introspection request to validate the token before The RS MAY make an introspection request to validate the token before
responding to the POST request to the authz-info endpoint, e.g. if responding to the POST request to the authz-info endpoint, e.g. if
the token is an opaque reference. Some transport protocols may the token is an opaque reference. Some transport protocols may
skipping to change at page 62, line 29 skipping to change at page 62, line 29
<https://www.bluetooth.com/specifications/bluetooth-core- <https://www.bluetooth.com/specifications/bluetooth-core-
specification/>. specification/>.
[I-D.erdtman-ace-rpcc] [I-D.erdtman-ace-rpcc]
Seitz, L. and S. Erdtman, "Raw-Public-Key and Pre-Shared- Seitz, L. and S. Erdtman, "Raw-Public-Key and Pre-Shared-
Key as OAuth client credentials", draft-erdtman-ace- Key as OAuth client credentials", draft-erdtman-ace-
rpcc-02 (work in progress), October 2017. rpcc-02 (work in progress), October 2017.
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-32 (work and Secure Transport", draft-ietf-quic-transport-34 (work
in progress), October 2020. in progress), January 2021.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-39 (work in progress), 1.3", draft-ietf-tls-dtls13-40 (work in progress), January
November 2020. 2021.
[Margi10impact] [Margi10impact]
Margi, C., de Oliveira, B., de Sousa, G., Simplicio Jr, Margi, C., de Oliveira, B., de Sousa, G., Simplicio Jr,
M., Barreto, P., Carvalho, T., Naeslund, M., and R. Gold, M., Barreto, P., Carvalho, T., Naeslund, M., and R. Gold,
"Impact of Operating Systems on Wireless Sensor Networks "Impact of Operating Systems on Wireless Sensor Networks
(Security) Applications and Testbeds", Proceedings of (Security) Applications and Testbeds", Proceedings of
the 19th International Conference on Computer the 19th International Conference on Computer
Communications and Networks (ICCCN), August 2010. Communications and Networks (ICCCN), August 2010.
[MQTT5.0] Banks, A., Briggs, E., Borgendale, K., and R. Gupta, "MQTT [MQTT5.0] Banks, A., Briggs, E., Borgendale, K., and R. Gupta, "MQTT
 End of changes. 8 change blocks. 
12 lines changed or deleted 13 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/