Internet DRAFT - draft-hunt-oauth-scim-client-reg
draft-hunt-oauth-scim-client-reg
OAuth Working Group P. Hunt, Ed.
Internet-Draft Oracle Corporation
Intended status: Standards Track M. Ansari
Expires: January 06, 2014 Cisco
T. Nadalin
Microsoft
July 05, 2013
OAuth 2.0 SCIM Client Registration Profile
draft-hunt-oauth-scim-client-reg-00
Abstract
This specification defines a SCIM endpoint used to register and
provision OAuth 2.0 clients to access a OAuth 2.0 protected service
API in a just-in-time fashion. This draft profiles how a OAuth 2.0
client may use SCIM and OAuth 2.0 to manage its registration.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 06, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Hunt, et al. Expires January 06, 2014 [Page 1]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Typical Registration Flow . . . . . . . . . . . . . . . . 6
2. SCIM OAuth Client Resource Schema . . . . . . . . . . . . . . 8
2.1. Singular Attributes . . . . . . . . . . . . . . . . . . . 9
2.2. Multi-valued Attributes . . . . . . . . . . . . . . . . . 12
2.3. Client Representation . . . . . . . . . . . . . . . . . . 13
2.4. Relationship Between Grant Types and Response Types . . . 13
2.5. Human Readable Client Metadata . . . . . . . . . . . . . 14
2.6. Registration Server Processing Rules . . . . . . . . . . 15
3. SCIM Interaction Profile . . . . . . . . . . . . . . . . . . 16
3.1. Adding A Registration . . . . . . . . . . . . . . . . . . 16
3.1.1. Anonymous Registration . . . . . . . . . . . . . . . 16
3.1.2. Pre-Authorized Registration . . . . . . . . . . . . . 17
3.2. Reading A Registration . . . . . . . . . . . . . . . . . 18
3.3. Modifying A Registration . . . . . . . . . . . . . . . . 20
3.4. Deleting A Registration . . . . . . . . . . . . . . . . . 20
3.5. Expired Registration . . . . . . . . . . . . . . . . . . 20
4. Software Assertion Token . . . . . . . . . . . . . . . . . . 21
4.1. Software Assertion Requirements . . . . . . . . . . . . . 21
5. Server Schema Configurations . . . . . . . . . . . . . . . . 22
5.1. Resource Type . . . . . . . . . . . . . . . . . . . . . . 22
5.2. Schema Representation . . . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
6.1. OAuth Token Endpoint Authentication Methods Registry . . 26
6.1.1. Registration Template . . . . . . . . . . . . . . . . 27
6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Normative References . . . . . . . . . . . . . . . . . . . . 30
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 31
Appendix B. Document History . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
Hunt, et al. Expires January 06, 2014 [Page 2]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
The OAuth 2.0 Authorization Framework [RFC6749] is a framework by
which client applications are authorized by authorization servers to
access software API servers using access tokens issued by a token
server. As a framework, OAuth 2.0 enables many different flows by
which a client application may obtain an access token including
delegated authorization from a user. Most of these flows require
that each client have a client identifier and some means of
authentication.
In order for an OAuth 2.0 client to work with an OAuth authorization
server, it must have previously obtained a client identifier
(client_id) and a client credential (such as a password, secret, or
authentication token). The OAuth 2.0 authorization framework does
not define how the relationship between the client and the
authorization server is initialized, or how a given client is
assigned a unique client identifier. Further, because many clients
(such as mobile applications) are copied for wide distribution,
special security considerations are defined for those clients known
as "public" clients. Public clients represent a high risk when
hundreds to millions of clients share the same authentication
credential and client_id. This draft provides a means by which
public clients can be issued unique client identifiers to become
confidential clients.
This draft profiles using SCIM [I-D.ietf-scim-api] as a just-in-time
identity management system enabling every client to register itself
with a designated SCIM endpoint to obtain a unique OAuth 2.0
[RFC6749] client_id and authentication credential. In addition to
accepting a registration request, the profile specifies how the
endpoint can be used to dynamically assign a client identifier, and
optionally a client credential. This specification defines OAuth 2.0
client schema and objects accessible through SCIM. The OAuth 2.0
client schema includes metadata about the client software being
registered as well as OAuth 2.0 protocol metadata required for the
successful operation of a client in an OAuth 2.0 protected
environment.
Finally, this specification also defines how a publisher of software
services APIs deployed in multiple environments may issue a software
assertion that may be used by the registration endpoint to recognize
and accept client software. Additionally, the specification also
defines a mechanism for pre-approval of client software within an
administrative domain.
1.1. Notational Conventions
Hunt, et al. Expires January 06, 2014 [Page 3]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in [RFC2119].
Unless otherwise noted, all the protocol parameter names and values
are case sensitive.
1.2. Terminology
This specification uses the terms "Access Token", "Refresh Token",
"Authorization Code", "Authorization Grant", "Authorization Server",
"Authorization Endpoint", "Client", "Client Identifier", "Client
Secret", "Protected Resource", "Resource Owner", "Resource Server",
and "Token Endpoint" defined by OAuth 2.0 [RFC6749].
In RFC6749, a client identifier was typically given to a developer
for inclusion in the software. As a result, client identifier often
had two different meanings when comparing public and confidential
clients. A confidential client tended to be deployed in limited
locations on server platforms and thus a client identifier was
associated with a client instance. Public clients on the other hand
are deployed in many locations. In these cases, the client
identifier has closer association to the software being used rather
than the instance.
In this specification, "client identifier" is re-scoped more narrowly
to imply an instance of client software (or a cluster). A new term,
"software identifier" refers to a packaging of a software that is
deployed in one or more location. Thus for every software
identifier, there may be one or more client identifiers.
This specification defines the following additional terms:
Client Registration Endpoint A SCIM endpoint through which a client
can be registered. The means by which the URL for this endpoint
are obtained (discovery) are out of scope for this specification.
Client Configuration Endpoint An OAuth 2.0 protected SCIM Resource
endpoint through which registration information for a registered
client can be managed. This URL for this endpoint is returned by
the authorization server in the client registration response or
may be discovered by performing a SCIM GET query.
Hunt, et al. Expires January 06, 2014 [Page 4]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
Deployment Organization An administrative security domain under
which, a software API is deployed and protected by an OAuth 2.0
framework. In simple cloud deployments, the software API
publisher and the deployment organization may be the same. In
other scenarios, a Software Publisher may be working with many
different deployment organizations.
Software API Deployment A deployment instance of a software API that
is protected by OAuth 2.0 in a particular deployment organization
domain. For any particular software API, there may be one or
more deployments. A software API deployment typically has an
associated OAuth 2.0 authorization server endpoint as well as a
client registration endpoint. The means by which endpoints are
obtained (discovery) are out of scope for this specification.
Software API Publisher The organization that defines a particular
web accessible API that may deployed in one or more deployment
environments. A publisher may be any commercial, public,
private, or open source organization that is responsible for
publishing and distributing software that may be protected via
OAuth 2.0. A software API publisher may issue software
assertions which client developers use to distribute with their
software to facilitate registration.
Client Developer The person or organization that builds a client
software package and prepares it for distribution. A client
developer may obtain a software assertion from a software
publisher for the purposes of facilitating client registration.
Software Assertion A signed OAuth 2.0 Bearer Token [OAuth.JWT]
issued by an software API publisher that asserts information
about the client software (see Section 4) that may be used by
registration system to qualify clients for eligibility to
register. Typically a client developer registers with a software
API publisher to obtain a software assertion that will be
distributed with all copies of a client application and may be
used during the registration process to identify the client to
the client registration endpoint.
Initial Access Token An OAuth 2.0 access token is typically issued
by a software API deployment's security domain and used by the
client at the registration endpoint in order to register a
client. In an authenticated registration, the token is usually
issued by the same security domain as the Service API the client
is registering for. The content, structure, generation, and
validation of this token are out of scope for this specification.
The SCIM registration endpoint security policy can use this token
to verify that the presenter is allowed to dynamically register a
Hunt, et al. Expires January 06, 2014 [Page 5]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
client. This token may be shared between multiple instances of a
client to allow each client to register separately, thereby
letting the authorization server use this token to tie multiple
instances of registered clients (each with their own distinct
client identifier) back to the party to whom the initial access
token was issued.
Registration Access Token A registration access token is an optional
token a registration server may issue for the purpose of
supporting server initiated rotation of client credentials. If
client credentials are revoked or expired, the registered client
may use a provided registration access token to refresh its
registration and obtain new client credentials. When doing this,
the client does not need to obtain an access token.
1.3. Typical Registration Flow
+------------+ +--------------+
| Client App +-(A)---------------------------------->| Software API |
| Developer | [Register] | Publisher |
| |<--------------------------------------+ |
+-----+------+ +--------------+
|
v
+------------+
+ Builds App |
|Distribution| [Package & Distribute]
+-----+------+ +--------------+
(B) +---(C)-----------------------------------+ Pre-reg Auth |
| | +--------------+
v V
+------------+ +--------------+
| +-(D)-----------------------------------> |
| | [POST/Register-Add] | |
| |<--------------------------------------+ |
| | +-----------+ | OAuth2 |
| +-(E)------------->| OAuth2 AS | | SCIM JIT |
| Client App | [Token Request] | Token | | Registration |
| Deployment |<-----------------+ Endpoint | | Endpoint |
| Instance | +-----------+ | |
| +-(F)---------------------------------->| |
| | [PATCH/Update][PUT/Replace][GET/Read] | |
| |<--------------------------------------+ |
| | | |
| | | |
| +-(G)---------------------------------->| |
| | [DELETE/Unregister] | |
| |<--------------------------------------+ |
Hunt, et al. Expires January 06, 2014 [Page 6]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
+------------+ +--------------+
Figure 1: Figure 1: Registration Lifecycle Flow
The abstract OAuth 2.0 SCIM JIT Client Registration flow illustrated
in Figure 1 describes the interaction between a software API
publisher, a client developer, a deployed client software instance
and the software API deployment registration services in this
specification. This figure does not demonstrate error conditions.
This flow includes the following steps:
(A) Optionally, a client developer registers the clent application
with a software API publisher. The software publisher, upon
approval, generates a signed software assertion that is returned
to the developer. While the software assertion is defined by
this specification, the process of issuance is out-of-scope and
is likely a web workflow the developer follows with the
publisher.
(B) The client developer packages the client software with the signed
software assertion and distributes the client application. The
method for doing this is out-of-scope of this specification.
(C) Upon receiving a client application software distribution, a
deploying organization may assign an initial access token, that
can be used to authenticate a particular distribution of client
software for use within the deploying organization's
administrative domain. The mechanism for obtaining an initial
access token and distributing it with a set of client software
instances is out of scope of this application. One example might
be a token supplied during the installation process of a client
software, or it may inserted within a locally re-packaged
distribution of the client application.
(D) A client application performs an HTTP POST of a "Client" of a
JSON structured resource to the registration endpoint. If the
client received an iInitial access token in (C), it includes it
in the HTTP Authorization field, otherwise, the registration is
treated as an "anonymous" POST. An optional software assertion,
received in (A), is included in the SCIM Client resource JSON
being posted.
Upon successful registration, the SCIM Server returns a copy of
the successful registration, including an assigned "client_id"
and client credential (e.g. "client_secret"). In order for the
client to access and update its registration in the future, an
HTTP "Location" (client configuration endpoint) is returned
specifying the location of the created SCIM resource.
Hunt, et al. Expires January 06, 2014 [Page 7]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
(E) As with any OAuth 2.0 protected resource, before a client may
access and update its registration, the OAuth 2.0 client MUST
obtain an access token. If the client received a "registration
access token" in step (D), the client MAY use it. Alternatively,
the client obtains an access token using the normal OAuth 2.0 a
client credential flow section 4.3 [RFC6749] to obtain an access
token with scope "urn:oauth:scim:api:scope:registration".
(F) The Client or Developer optionally calls the client configuration
endpoint with a SCIM GET, PUT or PATCH request using the access
token obtained in (E). Upon reading and or updating client
registration data, a SCIM registration endpoint may choose to
rotate the client credential.
(G) The Client or Developer optionally calls the client configuration
endpoint with a Delete request using the access token issued in
(E).
Clients that need to register for more than one service API should
typically make a separate registration request for each API being
registered.
2. SCIM OAuth Client Resource Schema
This specification defines a new SCIM resource type known as a
"Client" identified using the URI
"urn:scim:schemas:oauth:Client:1.0". [[Note include in IANA
considerations]]
For each attribute defined, a qualifier (OPTIONAL, RECOMMENDED,
REQUIRED) is included that indicates the usage requirement for the
client. If the word "READ-ONLY" is used, it shall mean the attribute
SHOULD be server generated. String attributes and mult-valued
attributes are based on the attribute types defined in Section 3.1
and 3.2 [I-D.ietf-scim-core-schema]. Unless otherwise stated, ALL
client schema attributes are String based values. For example, URIs,
email addresses, identifiers, are all defined as SCIM String
Attributes.
Extensions and profiles of this specification MAY expand this list.
Authorization servers MUST accept all fields in this schema. The
authorization server MUST ignore any additional parameters sent by
the client that it does not understand. Clients MAY ignore
additional parameters returned by the Server that the client does not
understand.
Hunt, et al. Expires January 06, 2014 [Page 8]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
2.1. Singular Attributes
The following is a list of attributes that MUST have only a SINGLE
value.
client_id OPTIONAL. An identifier whose value SHOULD be unique for
EACH instance registered to a registration server. The value
SHOULD be assigned by the registration endpoint on successful
completion of the registration. While many clients may share a
single software_id, each client instance SHOULD have a unique
client_id. If a client registration expires or is revoked, the
client MAY provide its previous registration value for continuity
purposes (see Section 3.5).
software_assertion
OPTIONAL. A value containing a signed sofware assertion (see
Section 4) from a software API publisher. Values in the
assertion MAY be used as DEFAULT values for other client
registration metadata.
software_id
RECOMMENDED. A unique identifier that identifies the software
such as a UUID. The identifier SHOULD NOT change when software
version changes or when a new installation instance is detected.
"software_id" is intended to help a registration endpoint
recognize a client's assertion that it is a prticular piece of
software. Because of this, software identifier is usually
associated with a particular client name. While "client_id"is
linked to a client software deployment instance, the
"software_id" is an identifier shared between all copies of the
client software. Registration servers MAY use the supplied
software identifier to determine whether a particular client
software is approved or supported for use in the deployment
domain.
software_version
RECOMMENDED. A version identifier such as a UUID or a number.
Servers MAY use equality match to determine if a particular
client is a particular version. "software_version" SHOULD change
on any update to the client software. Registration servers MAY
use the software version and identity to determine whether a
particular client version is authorized for use in the deployment
domain.
client_name
RECOMMENDED. A human-readable name of the client to be presented
to the user. If omitted, the authorization server MAY display
the raw "client_id" value to the user instead. It is RECOMMENDED
Hunt, et al. Expires January 06, 2014 [Page 9]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
that clients always send this field. The value of this field MAY
be internationalized as described in Human Readable Client
Metadata (Section 2.5).
client_secret READ-ONLY. A value that is the OAuth 2.0
"client_secret". This value SHOULD be assigned by the server.
Any time the value is returned to the registered client, the
server MAY rotate the value. Clients MUST check for any change
in value returned and update their copy. The value is typically
only used when the attribute "token_endpoint_auth_method" is set
to "client_post" or "client_basic".
client_uri
RECOMMENDED. A URL of the homepage of the client software. If
present, the server SHOULD display this URL to the end user in a
clickable fashion. It is RECOMMENDED that clients always send
this field. The value of this field MUST point to a valid Web
page. The value of this field MAY be internationalized as
described in Human Readable Client Metadata (Section 2.5).
jwks_uri
OPTIONAL. A URL for the client's JSON Web Key Set [JWK] document
representing the client's public keys. The value of this field
MUST point to a valid JWK Set. These keys MAY also be used for
higher level protocols that require signing or encryption.
logo_uri
OPTIONAL. A URL that references a logo image for the client. If
present, the server SHOULD display this image to the end user
during approval. The value of this field MUST point to a valid
image file. The value of this field MAY be internationalized as
described in Human Readable Client Metadata (Section 2.5).
policy_uri
OPTIONAL. A URL that points to a human-readable policy document
for the client. The authorization server SHOULD display this URL
to the End-User if it is given. The Policy usually describes how
an End-User's data will be used by the client. The value of this
field MUST point to a valid Web page. The value of this field
MAY be internationalized as described in Human Readable Client
Metadata (Section 2.5).
registration_token
READ-ONLY. An OAuth 2.0 Bearer Token [OAuth.JWT] known as the
"registration access token". The token MAY be used by the client
as a long-term access token used to update and manage the
client's registration. The token is intended to allow the client
to refresh its registration and obtain new client credentials in
Hunt, et al. Expires January 06, 2014 [Page 10]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
the event of expiry or revocation of the client credentials by
the service API deployment domain. When client credentials are
rotated, the registration access token SHOULD also be rotated.
scope
OPTIONAL. A space separated list of scope values (as described
in Section 3.3 [RFC6749]) that the client can use when requesting
access tokens. The semantics of values in this list is service
specific. If omitted, an authorization server MAY register a
client with a default set of scopes.
targetEndpoint
RECOMMENDED. A URI of the service API the client is registering
for. The server MAY provide this value in its response. Clients
requesting access to more than one target endpoint should
register once for each target.
token_endpoint_auth_method
OPTIONAL. Value containing the requested authentication method
for the Token Endpoint. The server MAY override the requested
value. Clients MUST check for a change in value in the
registration response. Values defined by this specification are:
* "none": The client is a public client as defined in OAuth 2.0
and does not have a client secret.
* "client_secret_post": The client uses the HTTP POST parameters
defined in OAuth 2.0 section 2.3.1.
* "client_secret_basic": the client uses HTTP Basic defined in
OAuth 2.0 section 2.3.1
Additional values can be defined via the IANA OAuth Token
Endpoint Authentication Methods registry Section 6.1. Absolute
URIs can also be used as values for this parameter. If
unspecified or omitted, the default is "client_secret_basic",
denoting HTTP Basic Authentication Scheme as specified in
Section 2.3.1 of OAuth 2.0.
tos_uri
OPTIONAL. A URL that points to a human-readable "Terms of
Service" document for the client. The authorization server
SHOULD display this URL to the End-User if it is given. The
Terms of Service usually describe a contractual relationship
between the End-User and the client that the End-User accepts
when authorizing the client. The value of this field MUST point
to a valid Web page. The value of this field MAY be
internationalized as described in Human Readable Client Metadata
(Section 2.5).
Hunt, et al. Expires January 06, 2014 [Page 11]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
2.2. Multi-valued Attributes
The following is a list of SCIM multi-valued attributes that MAY be
part of a "Client" resource.
contacts
OPTIONAL. One or more email addresses for people responsible for
this client. The authorization server MAY make these addresses
available to end users for support requests for the client. An
authorization server MAY use these email addresses as identifiers
for an administrative page for this client.
redirect_uris
RECOMMENDED. One or more redirect URI values for use in
redirect-based flows such as the Authorization Code and Implicit
grant types. authorization servers SHOULD require registration
of valid redirect URIs for all clients that use these grant types
to protect against token and credential theft attacks.
grant_types
OPTIONAL. One or more OAuth 2.0 grant types that the client may
use. These grant types are defined as follows:
* "authorization_code": The Authorization Code Grant described
in OAuth 2.0 Section 4.1
* "implicit": The Implicit Grant described in OAuth 2.0
Section 4.2
* "password": The Resource Owner Password Credentials Grant
described in OAuth 2.0 Section 4.3
* "client_credentials": The "Client credentials Grant" described
in OAuth 2.0 Section 4.4
* "refresh_token": The Refresh Token Grant described in OAuth
2.0 Section 6.
* "urn:ietf:params:oauth:grant-type:jwt-bearer": The JWT Bearer
grant type defined in OAuth JWT Bearer Token Profiles
[OAuth.JWT].
* "urn:ietf:params:oauth:grant-type:saml2-bearer": The SAML 2
Bearer grant type defined in OAuth SAML 2 Bearer Token
Profiles [OAuth.SAML2].
Authorization servers MAY allow for other values as defined in
grant type extensions to OAuth 2.0. The extension process is
described in OAuth 2.0 Section 2.5, and the value of this
parameter MUST be the same as the value of the "grant_type"
parameter passed to the Token Endpoint defined in the extension.
response_types
Hunt, et al. Expires January 06, 2014 [Page 12]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
OPTIONAL. One or more OAuth 2.0 response types that the client
may use. These response types are defined as follows:
* "code": The Authorization Code response described in OAuth 2.0
Section 4.1.
* "token": The Implicit response described in OAuth 2.0
Section 4.2.
Authorization servers MAY allow for other values as defined in
response type extensions to OAuth 2.0. The extension process is
described in OAuth 2.0 Section 2.5, and the value of this
parameter MUST be the same as the value of the "response_type"
parameter passed to the Authorization Endpoint defined in the
extension.
2.3. Client Representation
The following is a non-normative example of a fully populated SCIM
OAuth 2.0 client registration in JSON format.
{
"schemas":["urn:scim:schemas:core:1.0",
"urn:scim:schemas:oauth:2.0:Client"],
"id":"2060107e82-fbe3-42bd-b199-15df7081a8ae",
"resourceType":"Client",
"software_id":"5ed2dd14-3ef7-4655-a41d-b5bd4c5266cc",
"software_version":"5.1.2.3.4",
"client_name":"Example Social Client",
"logo_uri":"https://client.example.org/logo.png",
"jwks_uri":"https://client.example.org/my_public_keys.jwks",
"token_endpoint_auth_method":"client_secret_post",
"scope":"read write dolphin",
"client_id":"2060107e82-fbe3-42bd-b199-15df7081a8ae",
"client_secret":"Z7tk2XqLKo1CfE14374teR4V554e8JUS",
"redirect_urls":[""https://client.example.org/callback",
"https://client.example.org/callback2"],
"targetEndpoint":"https://social.example.com/base"
}
Figure 2: Example Client Resource
2.4. Relationship Between Grant Types and Response Types
The "grant_types" and "response_types" values described above are
partially orthogonal, as they refer to arguments passed to different
endpoints in the OAuth protocol. However, they are related in that
the "grant_types" available to a client influence the
"response_types" that the client is allowed to use, and vice versa.
Hunt, et al. Expires January 06, 2014 [Page 13]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
For instance, a "grant_types" value that includes
"authorization_code" implies a "response_types" value that includes
code, as both values are defined as part of the OAuth 2.0
Authorization Code Grant. As such, a server supporting these fields
SHOULD take steps to ensure that a client cannot register itself into
an inconsistent state.
The correlation between the two fields is listed in the table below.
+-------------------------------------------------+-----------------+
| grant_types value includes: | response_types |
| | value includes: |
+-------------------------------------------------+-----------------+
| authorization_code | code |
| | |
| implicit | token |
| | |
| password | (none) |
| | |
| client_credentials | (none) |
| | |
| refresh_token | (none) |
| | |
| urn:ietf:params:oauth:grant-type:jwt-bearer | (none) |
| | |
| urn:ietf:params:oauth:grant-type:saml2-bearer | (none) |
+-------------------------------------------------+-----------------+
Extensions and profiles of this document that introduce new values to
either the "grant_types" or "response_types" parameter MUST document
all correspondences between these two parameter types.
2.5. Human Readable Client Metadata
[[This needs to be updated to be compatible with SCIM. There is a
also a problem with how to limit the amount of localization data
exchange for an instance registration. Note that mobile clients tend
to only need one preferred language while web clients represent many
clients and may have more than 20 languages to support.]]
Human-readable Client Metadata values and client Metadata values that
reference human-readable values MAY be represented in multiple
languages and scripts. For example, the values of fields such as
"client_name", "tos_uri", "policy_uri", "logo_uri", and "client_uri"
might have multiple locale-specific values in some client
registrations.
Hunt, et al. Expires January 06, 2014 [Page 14]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
To specify the languages and scripts, BCP47 [RFC5646] language tags
are added to client Metadata member names, delimited by a #
character. Since JSON member names are case sensitive, it is
RECOMMENDED that language tag values used in Claim Names be spelled
using the character case with which they are registered in the IANA
Language Subtag Registry [IANA.Language]. In particular, normally
language names are spelled with lowercase characters, region names
are spelled with uppercase characters, and languages are spelled with
mixed case characters. However, since BCP47 language tag values are
case insensitive, implementations SHOULD interpret the language tag
values supplied in a case insensitive manner. Per the
recommendations in BCP47, language tag values used in Metadata member
names should only be as specific as necessary. For instance, using
"fr" might be sufficient in many contexts, rather than "fr-CA" or
"fr-FR".
For example, a client could represent its name in English as
""client_name#en": "My Client"" and its name in Japanese as
""client_name#ja-Jpan-JP":
"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D"" within the same
registration request. The authorization server MAY display any or
all of these names to the Resource Owner during the authorization
step, choosing which name to display based on system configuration,
user preferences or other factors.
If any human-readable field is sent without a language tag, parties
using it MUST NOT make any assumptions about the language, character
set, or script of the string value, and the string value MUST be used
as-is wherever it is presented in a user interface. To facilitate
interoperability, it is RECOMMENDED that clients and servers use a
human-readable field without any language tags in addition to any
language-specific fields, and it is RECOMMENDED that any human-
readable fields sent without language tags contain values suitable
for display on a wide variety of systems.
Implementer's Note: Many JSON libraries make it possible to reference
members of a JSON object as members of an Object construct in the
native programming environment of the library. However, while the
"#" character is a valid character inside of a JSON object's member
names, it is not a valid character for use in an object member name
in many programming environments. Therefore, implementations will
need to use alternative access forms for these claims. For instance,
in JavaScript, if one parses the JSON as follows, "var j =
JSON.parse(json);", then the member "client_name#en-us" can be
accessed using the JavaScript syntax "j["client_name#en-us"]".
2.6. Registration Server Processing Rules
Hunt, et al. Expires January 06, 2014 [Page 15]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
A registration server MAY override any value that a client requests
during the registration process (including any omitted values) and
replace the requested value with a server generated value or default
at the server's discretion.
If a software assertion is provided the registration server SHOULD
validate the assertion as per Section 4.
3. SCIM Interaction Profile
All calls to the registration endpoint follow the HTTP verbs defined
in [I-D.ietf-scim-api].
All resources accessible through the SCIM client registration
endpoint are OAuth 2.0 protected. Clients that require access to
their own registration resource, MAY use the registration access
token ("registration_token") returned after registration, OR obtain
an access token from the token server endpoint using the client
credentials flow Section 4.4 [RFC6749], and scope
"urn:oauth:scim:api:scope:registration".
The initial access token used in the initial registration SHOULD NOT
be used for this purpose of managing or updating client resources.
Access to the client registration base for the purpose of adding a
new registration MAY permit anonymous access as desribed in the next
section.
Clients SHOULD NOT be able to access the registration resources of
other clients.
Clients with expired client credentials SHOULD follow the procedures
in Section 3.5.
3.1. Adding A Registration
Adding a registration follows the normal SCIM method for creating a
resource (an HTTP POST) as described in Section 3.1
[I-D.ietf-scim-api].
3.1.1. Anonymous Registration
The SCIM registration endpoint MAY support anonymous registration for
those clients that have not been issued an initial access token. For
those clients that have been issued a software assertion, the clients
SHOULD include this assertion in the software_assertion field of the
client resource being created. The Server SHOULD validate the
assertion and validate the issuer, subject, audience, and expiry
fields as described in Section 4.1.
Hunt, et al. Expires January 06, 2014 [Page 16]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
For a non-normative example, see Figure 2. In the anonymous case,
the "HTTP Authorization" header is omitted.
3.1.2. Pre-Authorized Registration
A pre-authorized registration is where the client or the installer of
the client has been issued an initial access token which may be used
to call the SCIM registration endpoint. Clients should use the token
by inserting the appropriate value in the HTTP Authorization header.
Additionally, as with anonymous registrations, clients MAY include a
software assertion. For example, a non-normative registration (line
breaks inserted for readability):
POST /Users HTTP/1.1
Host: example.com
Accept: application/json
Content-Type: application/json
Authorization: Bearer h480djs93hd8
Content-Length: ...
{
"schemas":["urn:scim:schemas:core:1.0",
"urn:scim:schemas:oauth:2.0:Client"],
"software_id":"5ed2dd14-3ef7-4655-a41d-b5bd4c5266cc",
"software_assertion":"eyJhbGciOiJSUzI1NiJ9.",
"software_version":"5.1.2.3.4",
"client_name":"Example Social Client",
"logo_uri":"https://client.example.org/logo.png",
"jwks_uri":"https://client.example.org/my_public_keys.jwks",
"token_endpoint_auth_method":"client_secret_post",
"scope":"read write dolphin",
"redirect_urls":[""https://client.example.org/callback",
"https://client.example.org/callback2"],
"targetEndpoint":"https://social.example.com/base"
}
Figure 2: Figure 3: Client Registration Request
On successful processing, the SCIM endpoint would respond with:
HTTP/1.1 201 Created
Content-Type: application/json
Location:
https://example.com/v2/Clients/2060107e82-42bd-b199-15df7081a8ae
ETag: W/"e180ee84f0671b1"
{
"schemas":["urn:scim:schemas:core:1.0",
Hunt, et al. Expires January 06, 2014 [Page 17]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
"urn:scim:schemas:oauth:2.0:Client"],
"resourceType":"Client",
"id":"2060107e82-42bd-b199-15df7081a8ae",
"software_id":"5ed2dd14-3ef7-4655-a41d-b5bd4c5266cc",
"software_assertion":"eyJhbGciOiJSUzI1NiJ9.",
"software_version":"5.1.2.3.4",
"client_name":"Example Social Client",
"logo_uri":"https://client.example.org/logo.png",
"jwks_uri":"https://client.example.org/my_public_keys.jwks",
"token_endpoint_auth_method":"client_secret_post",
"scope":"read write dolphin",
"client_id":"2060107e82-fbe3-42bd-b199-15df7081a8ae",
"client_secret":"Z7tk2XqLKo1CfE14374teR4V554e8JUS",
"redirect_urls":[""https://client.example.org/callback",
"https://client.example.org/callback2"],
"targetEndpoint":"https://social.example.com/base"
}
Figure 4: Client Registration Response
Clients SHOULD read the response and review and retain the following
items:
o The client SHOULD remember the "HTTP Location" returned. This
location is used for future registration updates and client
credential rotation.
o The client MUST read the assigned "client_id" value and retain for
use in all authorization server interactions with the associated
target endpoint.
o If returned, the client SHOULD retain the "registration_token" as
a credential that can be used to access and update the client's
registration.
o The client MUST read the "token_endpoint_auth_method" to obtain
the authentication method the server has chosen for the client.
o Based on the returned token endpoint authentication method
returned, the client MUST read the registration for the
appropriate client credential such as "token_secret".
3.2. Reading A Registration
When a server receives a GET request from an HTTP client whose access
token is assigned to the OAuth 2.0 client that is the subject of the
registration, the server MAY elect to rotate the client credential
(e.g. client_secret) or other relevant attributes. If the access
request is not from the registered client (such as an administrator),
the server SHOULD NOT change any registration values. [[should the
server mask anything?]]
Hunt, et al. Expires January 06, 2014 [Page 18]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
Reading a client resource is done using the SCIM HTTP GET verb as
defined in Section 3.2 [I-D.ietf-scim-api]
A client resource may be retrieved using the "location" returned from
the original client registration. The registration MAY be retrieved
directly using this URL. If the location is not available, the
current values of the registration can be obtained by querying this
URL, or by searching the "/Clients" with a query parameter for
client_id that corresponds to the client's "client_id".
GET /Clients/?
filter=client_id%20eq%2060107e82-fbe3-42bd-b199-15df7081a8ae
Host: example.com
Accept: application/json
Authorization: Bearer deadbeef
Figure 3: Figure 5: Retrieving a Registration
If found, the server will respond with a HTTP 200 message containing
a single client resource, with one or more attributes:
HTTP/1.1 200 OK
Content-Type: application/json
{
"totalResults":1,
"schemas":["urn:scim:schemas:core:1.0",
"urn:scim:schemas:oauth:Client:1.0"],
"Resources":[
{
"id":"2060107e82-fbe3-42bd-b199-15df7081a8ae",
"resourceType":"Client",
"software_id":"5ed2dd14-3ef7-4655-a41d-b5bd4c5266cc",
"software_version":"5.1.2.3.4",
"client_name":"Example Social Client",
...
"token_endpoint_auth_method":"client_secret_post",
"client_id":"2060107e82-fbe3-42bd-b199-15df7081a8ae",
"client_secret":"Z7tk2XqLKo1CfE14374teR4V554e8JUS"
}
]
}
Figure 6: Retrieving Registration Response
If no resource is found, the server will respond with a HTTP 200
message containing zero result resources.
Hunt, et al. Expires January 06, 2014 [Page 19]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
When a client returns its own record, clients should check for
updates to the following items:
o The client MUST read the assigned "client_id" value and retain for
use in all authorization server interactions with the associated
target endpoint.
o If returned, the client SHOULD update the "registration_token" as
a credential that can be used to access and update the client's
registration.
o The client MUST read the "token_endpoint_auth_method" to obtain
the authentication method the server has chosen for the client.
o Based on the returned token endpoint authentication method
returned, the client MUST read the registration for any changes to
client credential such as "token_secret".
3.3. Modifying A Registration
Modification of a client resource can be done using the SCIM PUT or
PATCH verbs as defined in Section 3.3 [I-D.ietf-scim-api].
When a server receives a PUT or PATCH request from an HTTP client
whose access token is assigned to the OAuth 2.0 client that is the
subject of the registration, the server MAY elect to rotate the
client credential (e.g. client_secret) or other relevant attributes.
3.4. Deleting A Registration
De-registration of a client resource can be done using the SCIM
DELETE verbs as defined in Section 3.4 [I-D.ietf-scim-api]. When a
delete is completed, all associated client credentials and access
tokens MUST be revoked or invalidated.
3.5. Expired Registration
An expired registration occurs when the client's credential has
expired, or has been revoked by the registration service. On expiry,
access tokens issued to the client MUST be revoked or invalidated.
If, on registration, the client was returned a registration access
token ("registration_token"), the client MAY obtain new credentials
by simply retrieving its client profile using the registration token
and the SCIM GET verb at the location returned after the initial
registration (see Figure 3).
Clients that do not have a valid registration access token MAY re-
register as a new client instance. In such case, the client MAY
include it's existing "client_id"in its client meta data as
"client_id"for tracking purposes only. In such cases, the old
Hunt, et al. Expires January 06, 2014 [Page 20]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
client_id SHOULD NOT be re-activated and the server SHOULD issue a
new client_id value.
4. Software Assertion Token
A software assertion is an 'authorization' bearer JSON Web Token as
defined in Section 2.1 [OAuth.JWT]. While the software assertion is
a JWT authorization token, it SHOULD not be used with the
authorization server token endpoint. It is used by the client
registration endpoint for the purpose of registration. A software
assertion is a statement of claims about the client software being
registered and SHOULD NOT be used as an authentication of the
software.
Software assertions may be generated by a software API publisher for
the purpose of allowing a developer to incorporate a signed assertion
that can be used to register client software at more than one
Software API deployment.
4.1. Software Assertion Requirements
In order to create and validate a software assertion, the following
requirements apply in addition to those stated in Section 3
[OAuth.JWT].
1. The JWT MAY contain any claim specified in Section 2.
2. The JWT MUST contain an "iss" (issuer) claim that contains a
unique identifier for the entity that issued the JWT. This value
SHOULD correspond to the software API publisher.
3. The JWT MUST contain a "sub" (subject) claim that contains a
unique value corresponding to the "software_id". This number is
MAY be assigned by the software API publisher.
4. The JWT MUST contain an "aud" (audience) claim containing a value
that is ONE of the following:
* A value that identifies one or more software API deployments,
where the client software MAY be registered.
* A value "urn:oauth:scim:reg:generic" which indicates the
assertion MAY be used with any software API deployment
environment.
5. The JWT MUST contain an "exp" (expiration) claim that limits the
time window during which the JWT can be used to register clients.
When registering clients, the registration server MUST verify
that the expiration time has not passed, subject to allowable
clock skew between systems, and reject expired JWTs. The
authorization server SHOULD NOT use this value to revoke an
existing client registration.
Hunt, et al. Expires January 06, 2014 [Page 21]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
5. Server Schema Configurations
[[This section to be revised pending clarification of schema
extensions methodology in draft-ietf-core-schema]]
5.1. Resource Type
The following is a normative JSON representation of a SCIM
"ResourceType" representing a client resorce in a SCIM server
returned by querying "GET [scimendpoint}/ResourceTypes". "..."
indicates other ResourceTypes removed for clarity.
[
...
{
"name": "Client",
"endpoint": "/Clients",
"schema": "urn:scim:schemas:oauth:2.0"
},
...
]
Figure 7: Client Resource Type
5.2. Schema Representation
The following is a normative exammple of the SCIM "Schema" for a
client in JSON format returned when querying "GET {scimendpoint}/
Schemas".
{ "id":"urn:scim:schemas:oauth:2.0:Client",
"name":"Client",
"description":"OAuth 2 Client",
"schema":["urn:scim:core:1.0",
"urn:scim:schemas:oauth:2.0"],
"endpoint":"/Clients",
"attributes":[
{
"name":"id",
"type":"string",
"multiValued":false,
"description":"Unique identifier for the SCIM resource....",
"readOnly":true,
"required":true,
"caseExact":false
},
{
"name":"client_id",
Hunt, et al. Expires January 06, 2014 [Page 22]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
"type":"string",
"multiValued":false,
"description":
"OAuth 2.0 client_id assigned to the registered client.",
"readOnly":false,
"required":false,
"caseExact":true
},
{
"name":"software_assertion",
"type":"string",
"multiValued":false,
"description":
"A signed JWT assertion about the client.",
"readOnly":false,
"required":false,
"caseExact":true
},
{
"name":"software_id",
"type":"string",
"multiValued":false,
"description":"Unique identifier for client software.",
"readOnly":false,
"required":false,
"caseExact":true
},
{
"name":"software_version",
"type":"string",
"multiValued":false,
"description":"A version identifier for the software.",
"readOnly":false,
"required":false,
"caseExact":true
},
{
"name":"client_name",
"type":"string",
"multiValued":false,
"description":"A human readable name of the client.",
"readOnly":false,
"required":false,
"caseExact":true
},
{
"name":"client_secret",
"type":"string",
Hunt, et al. Expires January 06, 2014 [Page 23]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
"multiValued":false,
"description":
"A client secret assigned by the registration endpoint.",
"readOnly":true,
"required":false,
"caseExact":true
},
{
"name":"client_uri",
"type":"string",
"multiValued":false,
"description":
"URL of homepage for client(displayable to an end-user).",
"readOnly":false,
"required":false,
"caseExact":true
},
{
"name":"jwks_uri",
"type":"string",
"multiValued":false,
"description":"A URL for the client's JSON Web Key Set.",
"readOnly":false,
"required":false,
"caseExact":true
},
{
"name":"logo_uri",
"type":"string",
"multiValued":false,
"description":"A URL that references a logo image for client.",
"readOnly":false,
"required":false,
"caseExact":true
},
{
"name":"policy_uri",
"type":"string",
"multiValued":false,
"description":
"A URL of a human-readable policy document for the client.",
"readOnly":false,
"required":false,
"caseExact":true
},
{
"name":"registration_token",
"type":"string",
Hunt, et al. Expires January 06, 2014 [Page 24]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
"multiValued":false,
"description":
"A token issued to client for updating its registration.",
"readOnly":true,
"required":false,
"caseExact":true
},
{
"name":"scope",
"type":"string",
"multiValued":false,
"description":"Registered OAuth 2 scopes the client uses.",
"readOnly":false,
"required":false,
"caseExact":true
},
{
"name":"targetEndpoint",
"type":"string",
"multiValued":false,
"description":
"The OAuth2 resource endpoint the client intends to access.",
"readOnly":false,
"required":false,
"caseExact":true
},
{
"name":"token_endpoint_auth_method",
"type":"string",
"multiValued":false,
"description":"OAuth 2 Token Endpoint authorization method.",
"readOnly":false,
"required":false,
"caseExact":true
},
{
"name":"tos_uri",
"type":"string",
"multiValued":false,
"description":
"A URL pointing to a human readable terms of service.",
"readOnly":false,
"required":false,
"caseExact":true
},
{
"name":"contacts",
"type":"string",
Hunt, et al. Expires January 06, 2014 [Page 25]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
"multiValued":true,
"description":
"One or more email addresses of contacts for client.",
"readOnly":false,
"required":false,
"caseExact":true
},
{
"name":"redirect_uris",
"type":"string",
"multiValued":true,
"description":"One or more OAuth 2 redirect URI values.",
"readOnly":false,
"required":false,
"caseExact":true
},
{
"name":"grant_types",
"type":"string",
"multiValued":true,
"description":
"One or more OAuth 2 grant types the client may use.",
"readOnly":false,
"required":false,
"caseExact":true
},
{
"name":"response_types",
"type":"string",
"multiValued":true,
"description":"One or more OAuth 2 response types.",
"readOnly":false,
"required":false,
"caseExact":true
},
]
}
Figure 8: Client Schema Representation
6. IANA Considerations
6.1. OAuth Token Endpoint Authentication Methods Registry
This specification establishes the OAuth Token Endpoint
Authentication Methods registry.
Hunt, et al. Expires January 06, 2014 [Page 26]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
Additional values for use as "token_endpoint_auth_method" metadata
values are registered with a Specification Required ([RFC5226]) after
a two-week review period on the oauth-ext-review@ietf.org mailing
list, on the advice of one or more Designated Experts. However, to
allow for the allocation of values prior to publication, the
Designated Expert(s) may approve registration once they are satisfied
that such a specification will be published.
Registration requests must be sent to the oauth-ext-review@ietf.org
mailing list for review and comment, with an appropriate subject
(e.g., "Request to register token_endpoint_auth_method value:
example").
Within the review period, the Designated Expert(s) will either
approve or deny the registration request, communicating this decision
to the review list and IANA. Denials should include an explanation
and, if applicable, suggestions as to how to make the request
successful.
IANA must only accept registry updates from the Designated Expert(s)
and should direct all requests for registration to the review mailing
list.
6.1.1. Registration Template
Token Endpoint Authorization Method name:
The name requested (e.g., "example"). This name is case
sensitive. Names that match other registered names in a case
insensitive manner SHOULD NOT be accepted.
Change controller:
For Standards Track RFCs, state "IETF". For others, give the name
of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also be included.
Specification document(s):
Reference to the document(s) that specify the token endpoint
authorization method, preferably including a URI that can be used
to retrieve a copy of the document(s). An indication of the
relevant sections may also be included but is not required.
6.1.2. Initial Registry Contents
The OAuth Token Endpoint Authentication Methods registry's initial
contents are:
o Token Endpoint Authorization Method name: "none"
o Change controller: IETF
Hunt, et al. Expires January 06, 2014 [Page 27]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
o Specification document(s): [[ this document ]]
o Token Endpoint Authorization Method name: "client_secret_post"
o Change controller: IETF
o Specification document(s): [[ this document ]]
o Token Endpoint Authorization Method name: "client_secret_basic"
o Change controller: IETF
o Specification document(s): [[ this document ]]
7. Security Considerations
Since requests to the client registration endpoint result in the
transmission of clear-text credentials (in the HTTP request and
response), the server MUST require the use of a transport-layer
security mechanism when sending requests to the registration
endpoint. The server MUST support TLS 1.2 RFC 5246 [RFC5246] and/or
TLS 1.0 [RFC2246] and MAY support additional transport-layer
mechanisms meeting its security requirements. When using TLS, the
client MUST perform a TLS/SSL server certificate check, per RFC 6125
[RFC6125].
Since the SCIM client configuration endpoint is an OAuth 2.0
protected resource, it SHOULD have some rate limiting on failures to
prevent initial access tokens from being disclosed though repeated
access attempts.
For clients that use redirect-based grant types such as Authorization
Code and Implicit, authorization servers SHOULD require clients to
register their "redirect_uris". Requiring clients to do so can help
mitigate attacks where rogue actors inject and impersonate a validly
registered client and intercept its authorization code or tokens
through an invalid redirect URI.
The authorization server MUST treat all client metadata, including
software assertions, as self-asserted. A rogue client might use the
name and logo for the legitimate client, which it is trying to
impersonate. An authorization server needs to take steps to mitigate
this phishing risk, since the logo could confuse users into thinking
they're logging in to the legitimate client. For instance, an
authorization server could warn if the domain/site of the logo
doesn't match the domain/site of redirect URIs. An authorization
server can also present warning messages to end users about untrusted
clients in all cases, especially if such clients have been
dynamically registered and have not been trusted by any users at the
authorization server before.
Hunt, et al. Expires January 06, 2014 [Page 28]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
Authorization servers MAY assume that registered client software
sharing the same software assertion, software_id, and other metadata
SHOULD have similar operational behaviour metrics. Similarly,
Authorization server administrators MAY use software_id and
software_version to facilitate normal change control and approval
management of client software including:
o Approval of specific clients software for use with specific
protected resources.
o Lifecycle management and support of specific software versions as
indicated by software_version.
o Revocation of groups of client credentials and associated access
tokens when support issues or security risks identified with a
particular client software as identified by software_id and
software_version.
In a situation where the authorization server is supporting open
client registration, it must be extremely careful with any URL
provided by the client that will be displayed to the user (e.g.
"logo_uri", "tos_uri", "client_uri", and "policy_uri"). For
instance, a rogue client could specify a registration request with a
reference to a drive-by download in the "policy_uri". The
authorization server SHOULD check to see if the "logo_uri",
"tos_uri", "client_uri", and "policy_uri" have the same host and
scheme as the those defined in the array of "redirect_uris" and that
all of these resolve to valid Web pages.
Access tokens issued to clients to facilitate update or retrieval of
client registrations SHOULD be short lived.
Clients SHOULD rotate their client credentials before they expire by
obtaining an access token from the authorization server using the
registration scope. If a client has not successfully rotated its
credential prior to expiry, the client MUST register as a new client.
If a client is deprovisioned from a server (due to expiry or de-
registration), any outstanding Registration Access Token for that
client MUST be invalidated at the same time. Otherwise, this can
lead to an inconsistent state wherein a client could make requests to
the client configuration endpoint where the authentication would
succeed but the action would fail because the client is no longer
valid.
Clients that are unable to retain a client credential for the life of
the client instance MAY NOT register and should continue to be
treated as Public clients as defined by OAuth 2.0.
Hunt, et al. Expires January 06, 2014 [Page 29]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
8. Normative References
[I-D.ietf-scim-api]
Drake, T., Mortimore, C., Ansari, M., Grizzle, K., and E.
Wahlstroem, "System for Cross-Domain Identity
Management:Protocol", draft-ietf-scim-api-00 (work in
progress), August 2012.
[I-D.ietf-scim-core-schema]
Mortimore, C., Harding, P., Madsen, P., and T. Drake,
"System for Cross-Domain Identity Management: Core
Schema", draft-ietf-scim-core-schema-00 (work in
progress), August 2012.
[IANA.Language]
Internet Assigned Numbers Authority (IANA), "Language
Subtag Registry", 2005.
[JWK] Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web-
key (work in progress), May 2013.
[OAuth.JWT]
Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Bearer Token Profiles for OAuth 2.0", draft-ietf-
oauth-jwt-bearer (work in progress), March 2013.
[OAuth.SAML2]
Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0
Bearer Assertion Profiles for OAuth 2.0", draft-ietf-
oauth-saml2-bearer (work in progress), March 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Hunt, et al. Expires January 06, 2014 [Page 30]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
6749, October 2012.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, October 2012.
Appendix A. Acknowledgments
This draft was based upon in large part upon the work in draft-ietf-
oauth-dyn-reg-12. The author would like to thank Justin Richter and
the members of the OAuth Working Group.
In turn, the authors thank the OAuth Working Group, the User-Managed
Access Working Group, and the OpenID Connect Working Group
participants for their input to this document. In particular, the
following individuals have been instrumental in their review and
contribution to various versions of this document: Amanda Anganes,
Tim Bray, Domenico Catalano, Donald Coffin, George Fletcher, Thomas
Hardjono, Torsten Lodderstedt, Eve Maler, Josh Mandel, Nov Matake,
Nat Sakimura, Christian Scholz, and Hannes Tschofenig.
Appendix B. Document History
[[ to be removed by the RFC editor before publication as an RFC ]]
-00
o First draft based on work from draft-ietf-oauth-dyn-reg-12.
Authors' Addresses
Phil Hunt (editor)
Oracle Corporation
Email: phil.hunt@yahoo.com
Hunt, et al. Expires January 06, 2014 [Page 31]
Internet-Draft OAuth-SCIM-Client-Reg July 2013
Morteza Ansari
Cisco
Email: moransar@cisco.com
Tony Nadalin
Microsoft
Email: tonynad@microsoft.com
Hunt, et al. Expires January 06, 2014 [Page 32]
