draft-ietf-regext-rdap-openid-07.txt   draft-ietf-regext-rdap-openid-08.txt 
REGEXT Working Group S. Hollenbeck REGEXT Working Group S. Hollenbeck
Internet-Draft Verisign Labs Internet-Draft Verisign Labs
Intended status: Standards Track 28 June 2021 Intended status: Standards Track 8 November 2021
Expires: 30 December 2021 Expires: 12 May 2022
Federated Authentication for the Registration Data Access Protocol Federated Authentication for the Registration Data Access Protocol
(RDAP) using OpenID Connect (RDAP) using OpenID Connect
draft-ietf-regext-rdap-openid-07 draft-ietf-regext-rdap-openid-08
Abstract Abstract
The Registration Data Access Protocol (RDAP) provides "RESTful" web The Registration Data Access Protocol (RDAP) provides "RESTful" web
services to retrieve registration metadata from domain name and services to retrieve registration metadata from domain name and
regional internet registries. RDAP allows a server to make access regional internet registries. RDAP allows a server to make access
control decisions based on client identity, and as such it includes control decisions based on client identity, and as such it includes
support for client identification features provided by the Hypertext support for client identification features provided by the Hypertext
Transfer Protocol (HTTP). Identification methods that require Transfer Protocol (HTTP). Identification methods that require
clients to obtain and manage credentials from every RDAP server clients to obtain and manage credentials from every RDAP server
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 30 December 2021. This Internet-Draft will expire on 12 May 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Federated Authentication for RDAP . . . . . . . . . . . . . . 4 3. Federated Authentication for RDAP . . . . . . . . . . . . . . 4
3.1. RDAP and OpenID Connect . . . . . . . . . . . . . . . . . 5 3.1. RDAP and OpenID Connect . . . . . . . . . . . . . . . . . 5
3.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5
skipping to change at page 2, line 36 skipping to change at page 2, line 36
3.1.3.2. Authentication Request . . . . . . . . . . . . . 6 3.1.3.2. Authentication Request . . . . . . . . . . . . . 6
3.1.3.3. End-User Authorization . . . . . . . . . . . . . 7 3.1.3.3. End-User Authorization . . . . . . . . . . . . . 7
3.1.3.4. Authorization Response and Validation . . . . . . 7 3.1.3.4. Authorization Response and Validation . . . . . . 7
3.1.3.5. Token Processing . . . . . . . . . . . . . . . . 7 3.1.3.5. Token Processing . . . . . . . . . . . . . . . . 7
3.1.3.6. Delivery of User Information . . . . . . . . . . 8 3.1.3.6. Delivery of User Information . . . . . . . . . . 8
3.1.4. Specialized Claims for RDAP . . . . . . . . . . . . . 8 3.1.4. Specialized Claims for RDAP . . . . . . . . . . . . . 8
3.1.4.1. Stated Purpose . . . . . . . . . . . . . . . . . 8 3.1.4.1. Stated Purpose . . . . . . . . . . . . . . . . . 8
3.1.4.2. Do Not Track . . . . . . . . . . . . . . . . . . 9 3.1.4.2. Do Not Track . . . . . . . . . . . . . . . . . . 9
4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10
4.1. Client Authentication Request and Response . . . . . . . 10 4.1. Client Authentication Request and Response . . . . . . . 10
4.2. Token Request and Response . . . . . . . . . . . . . . . 10 4.2. Token Request and Response . . . . . . . . . . . . . . . 11
4.3. Token Refresh and Revocation . . . . . . . . . . . . . . 12 4.3. Token Refresh and Revocation . . . . . . . . . . . . . . 12
4.4. Token Exchange . . . . . . . . . . . . . . . . . . . . . 14 4.4. Token Exchange . . . . . . . . . . . . . . . . . . . . . 14
4.5. Parameter Processing . . . . . . . . . . . . . . . . . . 15 4.5. Parameter Processing . . . . . . . . . . . . . . . . . . 14
4.6. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 15 4.6. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 15
5. Clients with Limited User Interfaces . . . . . . . . . . . . 16 5. Clients with Limited User Interfaces . . . . . . . . . . . . 15
5.1. OAuth 2.0 Device Authorization Grant . . . . . . . . . . 16 5.1. OAuth 2.0 Device Authorization Grant . . . . . . . . . . 16
5.2. Manual Token Management . . . . . . . . . . . . . . . . . 16 5.2. Manual Token Management . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 17 6.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 17
6.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 17 6.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 17
6.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 18 6.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 18
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 20
7.1. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 20
7.2. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 21 7.2. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8.1. Authentication and Access Control . . . . . . . . . . . . 22 8.1. Authentication and Access Control . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
skipping to change at page 10, line 7 skipping to change at page 10, line 7
the claim is "true", and accepting the claim complies with local the claim is "true", and accepting the claim complies with local
regulations regarding logging and tracking. regulations regarding logging and tracking.
The "dnt" value is represented as a JSON boolean literal. An The "dnt" value is represented as a JSON boolean literal. An
example: example:
{"dnt" : true} {"dnt" : true}
No special query tracking processing is required if this claim is not No special query tracking processing is required if this claim is not
present or if the value of the claim is "false". Use of this claim present or if the value of the claim is "false". Use of this claim
MUST be limited to End-Users who are granted "do not track" MUST be limited to End-Users who are granted "do not track"
priviliges in accordance with service policies and regulations. privileges in accordance with service policies and regulations.
Specification of these policies and regulations is beyond the scope Specification of these policies and regulations is beyond the scope
of this document. of this document.
4. Protocol Parameters 4. Protocol Parameters
This specification adds the following protocol parameters to RDAP: This specification adds the following protocol parameters to RDAP:
1. A query parameter to request authentication for a specific end- 1. A query parameter to request authentication for a specific end-
user identity. user identity.
2. A path segment to request an ID Token and an Access Token for a 2. A path segment to request an ID Token and an Access Token for a
specific end-user identity. specific end-user identity.
3. A query parameter to deliver an ID Token and an Access Token for 3. A query parameter to deliver an ID Token and an Access Token for
use with an RDAP query. use with an RDAP query.
4.1. Client Authentication Request and Response 4.1. Client Authentication Request and Response
Client authentication is requested by adding a query component to an Client authentication is requested using one of two methods: either
RDAP request URI using the syntax described in Section 3.4 of RFC by adding a query component to an RDAP request URI using the syntax
3986 [RFC3986]. The query used to request client authentication is described in Section 3.4 of RFC 3986 [RFC3986], or by including an
represented as a "key=value" pair using a key value of "id" and a HTTP authorization header for the Basic authentication scheme as
value component that contains the client identifier issued by an OP. described in RFC 7617 [RFC7617]. Clients can use either method.
An example: Servers MUST support both methods.
The query used to request client authentication is represented as an
OPTIONAL "key=value" pair using a key value of "id" and a value
component that contains the client identifier issued by an OP. An
example for client identifier "user.idp.example":
https://example.com/rdap/domain/example.com?id=user.idp.example https://example.com/rdap/domain/example.com?id=user.idp.example
The authorization header for the Basic authentication scheme contains
a Base64-encoded representation of the client identifier issued by an
OP. No password is provided. An example for client identifier
"user.idp.example":
https://example.com/rdap/domain/example.com Authorization: Basic
dXNlci5pZHAuZXhhbXBsZQ==
The response to an authenticated query MUST use the response The response to an authenticated query MUST use the response
structures specified in RFC 7483 [RFC7483]. Information that the structures specified in RFC 7483 [RFC7483]. Information that the
end-user is not authorized to receive MUST be omitted from the end-user is not authorized to receive MUST be omitted from the
response. response.
4.2. Token Request and Response 4.2. Token Request and Response
Clients MAY send a request to an RDAP server to authenticate an end- Clients MAY send a request to an RDAP server to authenticate an end-
user and return an ID Token and an Access Token from an OP that can user and return tokens (an ID Token, an Access Token, and a Refresh
be then be passed to the RP/RDAP server to authenticate and process Token) from an OP that can be then be passed to the RP/RDAP server to
subsequent queries. Identity provider authentication is requested authenticate and process subsequent queries. An access token can be
using a "tokens" path segment and a query parameter with key value of refreshed as described in Section 12 of the OpenID Connect Core
"id" and a value component that contains the client identifier issued protocol [OIDCC] and Section 6 of RFC 6749 [RFC6749]. Clients can
by an OP. An example: take advantage of this functionality if it is supported by the OP and
accepted by the RDAP server. Identity provider authentication is
requested using a "tokens" path segment and a query parameter with a
key value of "id" and a value component that contains the client
identifier issued by an OP. An example:
https://example.com/rdap/tokens?id=user.idp.example https://example.com/rdap/tokens?id=user.idp.example
In addition to any core RDAP response elements, the response to this In addition to any core RDAP response elements, the response to this
query MUST contain four name-value pairs, in any order, representing query MUST contain five name-value pairs, in any order, representing
the returned ID Token and Access Token. The ID Token is represented the returned ID Token, Access Token, and Refresh Token. The ID Token
using a key value of "id_token". The Access Token is represented is represented using a key value of "id_token". The Access Token is
using a key value of "access_token". The access token type is represented using a key value of "access_token". The access token
represented using a key value of "token_type" and a value of "bearer" type is represented using a key value of "token_type" and a value of
as described in Sections 4.2.2 and 7.1 of RFC 6749 [RFC6749]. The "bearer" as described in Sections 4.2.2 and 7.1 of RFC 6749
lifetime of the access token is represented using a key value of [RFC6749]. The lifetime of the access token is represented using a
"expires_in" and a numerical value that describes the lifetime in key value of "expires_in" and a numerical value that describes the
seconds of the access token as described in Section 4.2.2 of RFC 6749 lifetime in seconds of the access token as described in Section 4.2.2
[RFC6749]. The token values returned in the RDAP server response of RFC 6749 [RFC6749]. The Refresh Token is represented using a key
MUST be Base64url encoded as described in RFCs 7515 [RFC7515] and value of "refresh_token". The token values returned in the RDAP
7519 [RFC7519]. server response MUST be Base64url-encoded as described in RFCs 7515
[RFC7515] and 7519 [RFC7519].
An example (the encoded tokens have been abbreviated for clarity): An example (the encoded tokens have been abbreviated for clarity):
{ {
"access_token" : "eyJ0...NiJ9", "access_token" : "eyJ0...NiJ9",
"id_token" : "eyJ0...EjXk", "id_token" : "eyJ0...EjXk",
"token_type" : "bearer", "token_type" : "bearer",
"expires_in" : "3600" "expires_in" : "3600",
"refresh_token" : "eyJ0...c8da"
} }
Figure 1 Figure 1
An RDAP server that processes this type of query MUST determine if An RDAP server that processes this type of query MUST determine if
the identifier is associated with an OP that is recognized and the identifier is associated with an OP that is recognized and
supported by the server. Servers MUST reject queries that include an supported by the server. Servers MUST reject queries that include an
identifier associated with an unsupported OP with an HTTP 501 (Not identifier associated with an unsupported OP with an HTTP 501 (Not
Implemented) response. An RDAP server that receives a query Implemented) response. An RDAP server that receives a query
containing an identifier associated with a recognized OP MUST perform containing an identifier associated with a recognized OP MUST perform
skipping to change at page 12, line 4 skipping to change at page 12, line 21
The tokens can then be passed to the server for use with an RDAP The tokens can then be passed to the server for use with an RDAP
query by passing the encoded ID Token as a query parameter with a key query by passing the encoded ID Token as a query parameter with a key
value of "id_token" and the encoded Access Token in an HTTP Bearer value of "id_token" and the encoded Access Token in an HTTP Bearer
authorization header [RFC6750]. An example (the encoded tokens have authorization header [RFC6750]. An example (the encoded tokens have
been abbreviated and the URI split across multiple lines for been abbreviated and the URI split across multiple lines for
clarity): clarity):
https://example.com/rdap/domain/example.com?id_token=eyJ0...EjXk https://example.com/rdap/domain/example.com?id_token=eyJ0...EjXk
Authorization: Bearer eyJ0...NiJ9 Authorization: Bearer eyJ0...NiJ9
The response to an authenticated query MUST use the response The response to an authenticated query MUST use the response
structures specified in RFC 7483 [RFC7483]. Information that the structures specified in RFC 7483 [RFC7483]. Information that the
end-user is not authorized to receive MUST be omitted from the end-user is not authorized to receive MUST be omitted from the
response. response.
4.3. Token Refresh and Revocation 4.3. Token Refresh and Revocation
An access token can be refreshed as described in Section 12 of the The refresh token returned in the token response can be used to
OpenID Connect Core protocol [OIDCC] and Section 6 of OAuth 2.0 refresh an access token. An access token is refreshed using a
[RFC6749]. Clients can take advantage of this functionality if it is "tokens" path segment and a query parameter. The query parameter
supported by the OP and accepted by the RDAP server.
A refresh token is requested using a "tokens" path segment and two
query parameters. The first query parameter includes a key value of
"id" and a value component that contains the client identifier issued
by an OP. The second query parameter includes a key value of
"refresh" and a value component of "true". A value component of
"false" MUST be processed to return a result that is consistent with
not including a "refresh" parameter at all as described in
Section 4.2. An example using "refresh=true":
https://example.com/rdap/tokens?id=user.idp.example&refresh=true
The response to this query MUST contain all of the response elements
described in Section 4.2. In addition, the response MUST contain a
name-value pair that represents a refresh token. The name-value pair
includes a key value of "refresh_token" and a Base64url-encoded value includes a key value of "refresh_token" and a Base64url-encoded value
that represents the refresh token. that represents the refresh token. An example:
Example refresh token request response (the encoded tokens have been
abbreviated for clarity):
{
"access_token" : "eyJ0...NiJ9",
"id_token" : "eyJ0...EjXk",
"token_type" : "bearer",
"expires_in" : "3600",
"refresh_token" : "eyJ0...c8da"
}
Figure 2
Once acquired, a refresh token can be used to refresh an access
token. An access token is refreshed using a "tokens" path segment
and two query parameters. The first query parameter includes a key
value of "id" and a value component that contains the client
identifier issued by an OP. The second query parameter includes a
key value of "refresh_token" and a Base64url-encoded value that
represents the refresh token. An example:
https://example.com/rdap/ https://example.com/rdap/tokens?refresh_token=eyJ0...c8da
tokens?id=user.idp.example&refresh_token=eyJ0...f3jE
In addition to any core RDAP response elements, the response to this In addition to any core RDAP response elements, the response to this
query MUST contain four name-value pairs, in any order, representing query MUST contain four name-value pairs, in any order, representing
a returned Refresh Token and Access Token. The Refresh Token is a returned Refresh Token and Access Token. The Refresh Token is
represented using a key value of "refresh_token". The Access Token represented using a key value of "refresh_token". The Access Token
is represented using a key value of "access_token". The access token is represented using a key value of "access_token". The access token
type is represented using a key value of "token_type" and a value of type is represented using a key value of "token_type" and a value of
"bearer" as described in Sections 4.2.2 and 7.1 of RFC 6749 "bearer" as described in Sections 4.2.2 and 7.1 of RFC 6749
[RFC6749]. The lifetime of the access token is represented using a [RFC6749]. The lifetime of the access token is represented using a
key value of "expires_in" and a numerical value that describes the key value of "expires_in" and a numerical value that describes the
lifetime in seconds of the access token as described in Section 4.2.2 lifetime in seconds of the access token as described in Section 4.2.2
of RFC 6749 [RFC6749]. The token values returned in the RDAP server of RFC 6749 [RFC6749]. The token values returned in the RDAP server
response MUST be Base64url encoded as described in RFCs 7515 response MUST be Base64url-encoded as described in RFCs 7515
[RFC7515] and 7519 [RFC7519]. [RFC7515] and 7519 [RFC7519].
Example access token refresh response (the encoded tokens have been Example access token refresh response (the encoded tokens have been
abbreviated for clarity): abbreviated for clarity):
{ {
"access_token" : "0dac...13b0", "access_token" : "0dac...13b0",
"refresh_token" : "f735...d30c", "refresh_token" : "f735...d30c",
"token_type" : "bearer", "token_type" : "bearer",
"expires_in" : "3600" "expires_in" : "3600"
} }
Figure 3 Figure 2
Access and refresh tokens can be revoked as described in RFC 7009 Access and refresh tokens can be revoked as described in RFC 7009
[RFC7009] by sending a request to an RDAP server that contains a [RFC7009] by sending a request to an RDAP server that contains a
"tokens/revoke" path segment and two query parameters. The first "tokens/revoke" path segment and a query parameter. The query
query parameter includes a key value of "id" and a value component parameter includes a key value of "token" and a Base64url-encoded
that contains the client identifier issued by an OP. The second value that represents either the current refresh token or the
query parameter includes a key value of "token" and a Base64url-
encoded value that represents either the current refresh token or the
associated access token. An example: associated access token. An example:
https://example.com/rdap/tokens/ https://example.com/rdap/tokens/revoke?token=f735...d30c
revoke?id=user.idp.example&token=f735...d30c
Note that this command will revoke both access and refresh tokens at Note that this command will revoke both access and refresh tokens at
the same time. In addition to any core RDAP response elements, the the same time. In addition to any core RDAP response elements, the
response to this query MUST contain a description of the result of response to this query MUST contain a description of the result of
processing the revocation request within the RDAP "notices" data processing the revocation request within the RDAP "notices" data
structure. structure.
Example token revocation success: Example token revocation success:
"notices" : "notices" :
[ [
{ {
"title" : "Token Revocation Result", "title" : "Token Revocation Result",
"description" : "Token revocation succeeded.", "description" : "Token revocation succeeded.",
} }
], ],
"lang" : "en-US" "lang" : "en-US"
Figure 4 Figure 3
Example token revocation failure: Example token revocation failure:
"notices" : "notices" :
[ [
{ {
"title" : "Token Revocation Result", "title" : "Token Revocation Result",
"description" : "Token revocation failed.", "description" : "Token revocation failed.",
} }
], ],
"errorCode" : 400, "errorCode" : 400,
"lang" : "en-US" "lang" : "en-US"
Figure 5 Figure 4
4.4. Token Exchange 4.4. Token Exchange
ID tokens include an audience parameter that contains the OAuth 2.0 ID tokens include an audience parameter that contains the OAuth 2.0
client_id of the RP as an audience value. In some operational client_id of the RP as an audience value. In some operational
scenarios (such as a client that is providing a proxy service), an RP scenarios (such as a client that is providing a proxy service), an RP
can receive tokens with an audience value that does not include the can receive tokens with an audience value that does not include the
RP's client_id. These tokens might not be trusted by the RP, and the RP's client_id. These tokens might not be trusted by the RP, and the
RP might refuse to accept the tokens. This situation can be remedied RP might refuse to accept the tokens. This situation can be remedied
by having the RP exchange these tokens with the OP for a set of by having the RP exchange these tokens with the OP for a set of
skipping to change at page 16, line 13 skipping to change at page 15, line 40
Registry is described in Section 6.1. Registry is described in Section 6.1.
Example rdapConformance structure with extension specified: Example rdapConformance structure with extension specified:
"rdapConformance" : "rdapConformance" :
[ [
"rdap_level_0", "rdap_level_0",
"rdap_openidc_level_0" "rdap_openidc_level_0"
] ]
Figure 6 Figure 5
5. Clients with Limited User Interfaces 5. Clients with Limited User Interfaces
The flow described in Section 3.1.3 requires a client to interact The flow described in Section 3.1.3 requires a client to interact
with a server using a web browser. This will not work well in with a server using a web browser. This will not work well in
situations where the client is automated or an end-user is using a situations where the client is automated or an end-user is using a
command line user interface such as curl (http://curl.haxx.se/) or command line user interface such as curl (http://curl.haxx.se/) or
wget (https://www.gnu.org/software/wget/). There are multiple ways wget (https://www.gnu.org/software/wget/). There are multiple ways
to address this limitation using a web browser on a second device. to address this limitation using a web browser on a second device.
Two are described here. Two are described here.
skipping to change at page 16, line 43 skipping to change at page 16, line 23
constrained device. constrained device.
5.2. Manual Token Management 5.2. Manual Token Management
A second method of requesting user authorization from a constrained A second method of requesting user authorization from a constrained
device is possible by producing and managing tokens manually as device is possible by producing and managing tokens manually as
follows: follows:
1. Authenticate with the OP as described in Section 4.2 using a 1. Authenticate with the OP as described in Section 4.2 using a
browser or browser-like client. browser or browser-like client.
2. Store the returned ID Token and Access Token locally. 2. Store the returned ID Token, Access Token, and Refresh Token
locally.
3. Send a request to the content provider/RP along with the ID Token 3. Send a request to the content provider/RP along with the ID Token
and Access Token received from the OP. and Access Token received from the OP.
The Access Token MAY be passed to the RP in an HTTP "Authorization" The Access Token MAY be passed to the RP in an HTTP "Authorization"
header [RFC7235] or as a query parameter. The Access Token MUST be header [RFC7235] or as a query parameter. The Access Token MUST be
specified using the "Bearer" authentication scheme [RFC6750] if it is specified using the "Bearer" authentication scheme [RFC6750] if it is
passed in an "Authorization" header. The ID Token MUST be passed to passed in an "Authorization" header. The ID Token MUST be passed to
the RP as a query parameter. the RP as a query parameter.
Here are two examples using the curl and wget utilities. Start by Here are two examples using the curl and wget utilities. Start by
skipping to change at page 22, line 31 skipping to change at page 22, line 20
policy. For example, a client who provides an email address (and policy. For example, a client who provides an email address (and
nothing more) might be entitled to receive a subset of the nothing more) might be entitled to receive a subset of the
information that would be available to a client who provides an email information that would be available to a client who provides an email
address, a full name, and a stated purpose. Development of these address, a full name, and a stated purpose. Development of these
access control policies is beyond the scope of this document. access control policies is beyond the scope of this document.
9. Acknowledgements 9. Acknowledgements
The author would like to acknowledge the following individuals for The author would like to acknowledge the following individuals for
their contributions to the development of this document: Tom their contributions to the development of this document: Tom
Harrison, Russ Housley, Mario Loffredo, Rhys Smith, Jaromir Talir, Harrison, Russ Housley, Rhys Smith, Jaromir Talir, and Alessandro
and Alessandro Vesely. In addition, the Verisign Registry Services Vesely. In addition, the Verisign Registry Services Lab development
Lab development team of Joseph Harvey, Andrew Kaizer, Sai Mogali, team of Joseph Harvey, Andrew Kaizer, Sai Mogali, Anurag Saxena,
Anurag Saxena, Swapneel Sheth, Nitin Singh, and Zhao Zhao provided Swapneel Sheth, Nitin Singh, and Zhao Zhao provided critical "proof
critical "proof of concept" implementation experience that helped of concept" implementation experience that helped demonstrate the
demonstrate the validity of the concepts described in this document. validity of the concepts described in this document.
Mario Loffredo provided significant feedback based on implementation
experience that led to welcome improvements in several sections of
this document. His contributions are greatly appreciated.
10. References 10. References
10.1. Normative References 10.1. Normative References
[OIDC] OpenID Foundation, "OpenID Connect", [OIDC] OpenID Foundation, "OpenID Connect",
<http://openid.net/connect/>. <http://openid.net/connect/>.
[OIDCC] OpenID Foundation, "OpenID Connect Core incorporating [OIDCC] OpenID Foundation, "OpenID Connect Core incorporating
errata set 1", November 2014, errata set 1", November 2014,
skipping to change at page 24, line 28 skipping to change at page 24, line 23
<https://www.rfc-editor.org/info/rfc7483>. <https://www.rfc-editor.org/info/rfc7483>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>. 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015,
<https://www.rfc-editor.org/info/rfc7617>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, [RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,
"OAuth 2.0 Device Authorization Grant", RFC 8628, "OAuth 2.0 Device Authorization Grant", RFC 8628,
DOI 10.17487/RFC8628, August 2019, DOI 10.17487/RFC8628, August 2019,
<https://www.rfc-editor.org/info/rfc8628>. <https://www.rfc-editor.org/info/rfc8628>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
skipping to change at page 25, line 24 skipping to change at page 25, line 24
03: Updated OAuth 2.0 Device Authorization Grant description and 03: Updated OAuth 2.0 Device Authorization Grant description and
reference due to publication of RFC 8628. reference due to publication of RFC 8628.
04: Updated OAuth 2.0 token exchange description and reference due 04: Updated OAuth 2.0 token exchange description and reference due
to publication of RFC 8693. Corrected the RDAP conformance to publication of RFC 8693. Corrected the RDAP conformance
identifier to be registered with IANA. identifier to be registered with IANA.
05: Keepalive refresh. 05: Keepalive refresh.
06: Keepalive refresh. 06: Keepalive refresh.
07: Added "login_hint" description to Section 3.1.3.2. Added some 07: Added "login_hint" description to Section 3.1.3.2. Added some
text to Section 3.1.4.2 to note that "do not track" requires text to Section 3.1.4.2 to note that "do not track" requires
compliance with local regulations. compliance with local regulations.
08: Rework of token management processing in Sections 4 and 5.
Author's Address Author's Address
Scott Hollenbeck Scott Hollenbeck
Verisign Labs Verisign Labs
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
United States of America United States of America
Email: shollenbeck@verisign.com Email: shollenbeck@verisign.com
 End of changes. 31 change blocks. 
100 lines changed or deleted 91 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/