draft-ietf-ace-oauth-params-12.txt   draft-ietf-ace-oauth-params-13.txt 
ACE Working Group L. Seitz ACE Working Group L. Seitz
Internet-Draft Combitech Internet-Draft Combitech
Intended status: Standards Track February 1, 2020 Intended status: Standards Track April 29, 2020
Expires: August 4, 2020 Expires: October 31, 2020
Additional OAuth Parameters for Authorization in Constrained Additional OAuth Parameters for Authorization in Constrained
Environments (ACE) Environments (ACE)
draft-ietf-ace-oauth-params-12 draft-ietf-ace-oauth-params-13
Abstract Abstract
This specification defines new parameters and encodings for the OAuth This specification defines new parameters and encodings for the OAuth
2.0 token and introspection endpoints when used with the framework 2.0 token and introspection endpoints when used with the framework
for authentication and authorization for constrained environments for authentication and authorization for constrained environments
(ACE). These are used to express the proof-of-possession key the (ACE). These are used to express the proof-of-possession key the
client wishes to use, the proof-of-possession key that the client wishes to use, the proof-of-possession key that the
Authorization Server has selected, and the key the Resource Server Authorization Server has selected, and the key the Resource Server
uses to authenticate to the client. uses to authenticate to the client.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 August 4, 2020. This Internet-Draft will expire on October 31, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Parameters for the Token Endpoint . . . . . . . . . . . . . . 3 3. Parameters for the Token Endpoint . . . . . . . . . . . . . . 3
3.1. Client-to-AS Request . . . . . . . . . . . . . . . . . . 3 3.1. Client-to-AS Request . . . . . . . . . . . . . . . . . . 3
3.2. AS-to-Client Response . . . . . . . . . . . . . . . . . . 4 3.2. AS-to-Client Response . . . . . . . . . . . . . . . . . . 4
4. Parameters for the Introspection Endpoint . . . . . . . . . . 6 4. Parameters for the Introspection Endpoint . . . . . . . . . . 6
5. Confirmation Method Parameters . . . . . . . . . . . . . . . 7 5. Confirmation Method Parameters . . . . . . . . . . . . . . . 7
6. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . . . 8 6. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Requirements when using asymmetric keys . . . . . . . . . . . 8 7. Requirements when using asymmetric keys . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
skipping to change at page 2, line 43 skipping to change at page 2, line 43
The Authentication and Authorization for Constrained Environments The Authentication and Authorization for Constrained Environments
(ACE) specification [I-D.ietf-ace-oauth-authz] requires some new (ACE) specification [I-D.ietf-ace-oauth-authz] requires some new
parameters for interactions with the OAuth 2.0 [RFC6749] token and parameters for interactions with the OAuth 2.0 [RFC6749] token and
introspection endpoints, as well as some new claims to be used in introspection endpoints, as well as some new claims to be used in
access tokens. These parameters and claims can also be used in other access tokens. These parameters and claims can also be used in other
contexts and have therefore been put into a dedicated document, to contexts and have therefore been put into a dedicated document, to
facilitate their use in a manner independent of facilitate their use in a manner independent of
[I-D.ietf-ace-oauth-authz]. [I-D.ietf-ace-oauth-authz].
Note that although all examples are shown in CBOR [RFC7049], JSON Note that although all examples are shown in Concise Binary Object
[RFC8259] MAY be used as an alternative for HTTP-based Respresentation (CBOR) [RFC7049], JSON [RFC8259] MAY be used as an
communications, as specified in [I-D.ietf-ace-oauth-authz]. alternative for HTTP-based communications, as specified in
[I-D.ietf-ace-oauth-authz].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers are assumed to be familiar with the terminology from Readers are assumed to be familiar with the terminology from
[I-D.ietf-ace-oauth-authz], especially the terminology for entities [I-D.ietf-ace-oauth-authz], especially the terminology for entities
in the architecture such as client (C), resource server (RS) and in the architecture such as client (C), resource server (RS) and
authorization server (AS). authorization server (AS).
Terminology from [RFC8152] is used in the examples, especially Terminology from [RFC8152] is used in the examples, especially
COSE_Key defined in section 7 of [RFC8152]. COSE_Key defined in section 7 of [RFC8152].
Note that the term "endpoint" is used here following its OAuth 2.0 Note that the term "endpoint" is used here following its OAuth 2.0
[RFC6749] definition, which is to denote resources such as token and [RFC6749] definition, which is to denote resources such as token and
introspection at the AS and authz-info at the RS. The CoAP [RFC7252] introspection at the AS and authz-info at the RS. The Constrained
definition, which is "An entity participating in the CoAP protocol" Application Protocol (CoAP) [RFC7252] definition, which is "An entity
is not used in this specification. participating in the CoAP protocol" is not used in this
specification.
3. Parameters for the Token Endpoint 3. Parameters for the Token Endpoint
This section defines additional parameters for the interactions with This section defines additional parameters for the interactions with
the token endpoint in the ACE framework [I-D.ietf-ace-oauth-authz]. the token endpoint in the ACE framework [I-D.ietf-ace-oauth-authz].
3.1. Client-to-AS Request 3.1. Client-to-AS Request
This section defines the "req_cnf" parameter allowing clients to This section defines the "req_cnf" parameter allowing clients to
request a specific proof-of-possession key in an access token from a request a specific proof-of-possession key in an access token from a
skipping to change at page 10, line 39 skipping to change at page 10, line 39
[I-D.ietf-ace-cwt-proof-of-possession] [I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
possession-11 (work in progress), October 2019. possession-11 (work in progress), October 2019.
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-31 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33
(work in progress), January 2020. (work in progress), February 2020.
[I-D.ietf-oauth-mtls] [I-D.ietf-oauth-mtls]
Campbell, B., Bradley, J., Sakimura, N., and T. Campbell, B., Bradley, J., Sakimura, N., and T.
Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
and Certificate-Bound Access Tokens", draft-ietf-oauth- and Certificate-Bound Access Tokens", draft-ietf-oauth-
mtls-17 (work in progress), August 2019. mtls-17 (work in progress), August 2019.
[IANA.OAuthParameters] [IANA.OAuthParameters]
IANA, "OAuth Parameters", IANA, "OAuth Parameters",
<https://www.iana.org/assignments/oauth-parameters/oauth- <https://www.iana.org/assignments/oauth-parameters/oauth-
 End of changes. 7 change blocks. 
13 lines changed or deleted 15 lines changed or added

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