One document matched: draft-hunt-oauth-software-statement-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
"http://xml.resource.org/authoring/rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-hunt-oauth-software-statement-00"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc='yes' ?>
<?rfc tocdepth='3' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes' ?>
<?rfc compact='no' ?>
<?rfc subcompact='no' ?>
<?rfc strict='yes' ?>
<?rfc notedraftinprogress='yes' ?>
<front>
<title abbrev="OAuth-Software-Statement-00">OAuth 2.0 Software
Statement</title>
<author fullname="Phil Hunt" initials="P" role="editor" surname="Hunt">
<organization>Oracle Corporation</organization>
<address>
<email>phil.hunt@yahoo.com</email>
</address>
</author>
<author fullname="Tony Nadalin" initials="T." surname="Nadalin">
<organization>Microsoft</organization>
<address>
<email>tonynad@microsoft.com</email>
</address>
</author>
<date day="18" month="September" year="2013"/>
<area>Security</area>
<workgroup>OAuth</workgroup>
<abstract>
<t>This specification defines a JWT authorization assertion known as a
'software statment' for use in an OAuth protected environment. A
software statement is a JWT assertion used by an OAuth client to provide
both informational and OAuth protocol related assertions that aid
service providers to recognize OAuth client software and its expected
behaviour within an OAuth Framework protected resource environment.</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>The OAuth 2.0 Authorization Framework <xref target="RFC6749"/> is a
framework by which client applications use access tokens issued by
authorization servers to access to a service provider's software API
endpoints. 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.</t>
<t>This specification defines a JWT authorization assertion <xref
target="I-D.ietf-oauth-jwt-bearer"/> known as a 'software statment'. An
software statement is used by an OAuth client to provide both
informational and OAuth protocol <xref target="RFC6749"/> related
assertions that aid OAuth infrastructure to both recognize client
software and determine a client's expected requirements when accessing
an OAuth protected resource.</t>
<t>Applications using software statements, may typically go through 3
phases where:<list hangIndent="8" style="symbols">
<t hangText="Obtain Software Statement">A software statement is
generated and associated with a client application.</t>
<t hangText="Client Software Approval">A service provider approves
client software for use within its domain on the basic of
software_id, developer, or software statment signing
organization.</t>
<t hangText="Client Instance Association">And finally, where a
particular instance of a client possessing a software statement
associates with a particular serivce provider.</t>
</list></t>
<section anchor="Notation" title="Notational Conventions">
<t>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 <xref
target="RFC2119"/>.</t>
<t>Unless otherwise noted, all the protocol parameter names and values
are case sensitive.</t>
</section>
<section anchor="terminology" title="Terminology">
<t>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 <xref target="RFC6749">OAuth
2.0</xref>.</t>
<t>This specification uses the following additional terms:<list
hangIndent="4" style="hanging">
<t hangText="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.<vspace blankLines="1"/></t>
<t hangText="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.<vspace blankLines="1"/></t>
<t hangText="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. In some cases a software API publisher
and a client developer may be the same organization.<vspace
blankLines="1"/></t>
<t hangText="Client Developer">The person or organization that
builds a client software package and prepares it for distribution.
A client developer obtains a software assertion from a software
publisher, or self-generates one for the purposes of facilitating
client association.<vspace blankLines="1"/></t>
<t hangText="Software Statement">A signed JWT authorization token
<xref target="I-D.ietf-oauth-jwt-bearer"/> that asserts
information about the client software that may be used by
registration system to qualify clients for eligibility to
register. To obtain a statement, a client developer may generate a
client specific assertion, or a client developer may registers
with a software API publisher to obtain a software assertion. The
statement is distributed with all copies of a client application
and may be used during the client-to-service provider association
process.<vspace blankLines="1"/></t>
</list></t>
</section>
</section>
<section anchor="statement" title="Software Statement">
<t>As per the introduction, a software statement is an 'authorization'
bearer token (as defined in Section 2.1 of <xref
target="I-D.ietf-oauth-jwt-bearer"/>) that carries assertions about a
software that MAY be used in one or more deployment organizations and is
shared by all instances of a client application.</t>
<t>A software statement IS NOT an authentication assertion. A software
statement is a signed set of assertions fixing both OAuth related
protocol values as well as informational assertions as a signed
assertion from a trusted party. A deployment organization MAY use the
statement to set access policy and to recognize client software during
registration or association processes.</t>
<section anchor="lifecycle" title="Software Statement Lifecycle">
<t>Software statements are used in 3 stages in the lifecycle of an
OAuth enabled client application. A typical lifecycle flow is
illustrated in Figure 1 describing when a developer obtains a software
statement and how it is used within a deployment organization.</t>
<t><figure align="center" anchor="abstractFlow" height="46"
title="Client Statement Lifecycle">
<artwork height="46"> Client App
Developer
O (A) Obtain Software Statement ****************
\|/ <-------------------------------------- * Software API *
| * Publisher *
/ \ ****************
|
| |
| |
|D S | A
|i o | p
|s f | p
|t t | r (B)
A |r w | o
p |i a | v
p |b r | a
|u e | l
|t |
|i |
|o |
|n *************|********
v * v *
+------------+ * +---------------+ *
| Client App | (C) Present Software Statement * | OAuth 2.0 | *
| Instance | --------------------------------->| Authorization | *
+------------+ * | Server | *
* +---------------+ *
* OAuth 2.0 aware *
* Service Provider *
**********************
Legend:
O
\|/ - Developer
|
/ \
+----+
| | - Piece of software
| |
+----+
******
* * - Organization
* *
******</artwork>
</figure></t>
<t><list hangIndent="4" style="hanging">
<t hangText="(A)">A client developer registers a clent application
with a software API publisher. The software publisher, upon
approval, generates a signed software statement that is returned
to the developer. Alternatively, a developer may self-sign a
software statement. A self-signed statement, while weaker from a
trust perspective, allows the provider to recognize and approve
software (step B). A statement ensures that all registration
parameters for a client are the same for every instance of a
client deployed. The advantage of having the software API
publisher is that deploying organizations MAY choose to
pre-approve (step B) all software signed by a common trusted
organization.<vspace blankLines="1"/></t>
<t>This protocol and procedure for issuing a software statement to
the client app developer is out-of-scope of this document. This
document assumes that the client app developer has obtained such a
software statement already.<vspace blankLines="1"/></t>
<t hangText="(B)">When an administrator at a service provider
obtains a software statement, the administrator configures
policies to accept or reject a particular client software
statement for use within a deploying organization. An
administrator may also configure broader pre-approval policy that
accepts software by name, author, or signing organization, or
other category that can be derived from a software
statement.<vspace blankLines="1"/></t>
<t hangText="(C)">A client instance conveys the software statement
to the service provider, as described in <xref
target="I-D.draft-hunt-oauth-client-association"/>.<vspace
blankLines="1"/></t>
</list></t>
</section>
<section anchor="client-metadata" title="Statement Attributes">
<t>The following are attributes that may be included in a software
statement. For each attribute defined, a qualifier (OPTIONAL,
RECOMMENDED, REQUIRED) is included that indicates the usage
requirement for the client. Unless otherwise stated, all client schema
attributes are String based values. For example, URIs, email
addresses, identifiers, are all defined as Strings.</t>
<t>Authorization servers MUST reject statements if it does not
understand the values of any of the following singular or multi-valued
attributes. An authorization server MAY override any value (including
any omitted values) provided in a statement or separately during the
association process and replace the requested value with a default at
the server's discretion.</t>
<t>Extensions and profiles of this specification MAY expand this list,
and authorization servers MUST accept all fields in this list. The
authorization server MUST ignore any additional parameters sent by the
Client that it does not understand.</t>
<section title="Singular Attributes">
<t>The following is a list of attributes that MUST have only a
SINGLE value in a software statement.</t>
<t><list hangIndent="4" style="hanging">
<t hangText="software_id"><vspace blankLines="0"/>REQUIRED. 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. <spanx
style="verb">software_id</spanx> 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 the OAuth<spanx style="verb">client_id</spanx>is linked to
a client software deployment instance, the <spanx style="verb">software_id</spanx>
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.<vspace
blankLines="1"/></t>
<t hangText="software_version"><vspace
blankLines="0"/>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. <spanx style="verb">software_version</spanx>
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.<vspace blankLines="1"/></t>
<t hangText="client_name"><vspace blankLines="0"/>RECOMMENDED. A
human-readable name of the client to be presented to the user.
If omitted, the authorization server MAY display the raw <spanx
style="verb">software_id</spanx> value to the user instead. It
is RECOMMENDED that clients always send this field. The value of
this field MAY be internationalized as described in <xref
target="HumanReadableClientMetadata">Human Readable Client
Metadata</xref>.<vspace blankLines="1"/></t>
<t hangText="client_uri"><vspace blankLines="0"/>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
<xref target="HumanReadableClientMetadata">Human Readable Client
Metadata</xref>.<vspace blankLines="1"/></t>
<t hangText="jwks_uri"><vspace blankLines="0"/>OPTIONAL. A URL
for the client's <xref target="I-D.ietf-jose-json-web-key">JSON
Web Key Set</xref> 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.<vspace blankLines="1"/></t>
<t hangText="logo_uri"><vspace blankLines="0"/>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 <xref target="HumanReadableClientMetadata">Human
Readable Client Metadata</xref>.<vspace blankLines="1"/></t>
<t hangText="policy_uri"><vspace blankLines="0"/>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 <xref
target="HumanReadableClientMetadata">Human Readable Client
Metadata</xref>.<vspace blankLines="1"/></t>
<t hangText="scope"><vspace blankLines="0"/>OPTIONAL. A space
separated list of scope values (as described in <xref
target="RFC6749">Section 3.3</xref>) 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.<vspace
blankLines="1"/></t>
<t hangText="targetEndpoint"><vspace
blankLines="0"/>RECOMMENDED. A generic URI of the service API
the client is registering for (often set by the software API
publisher). Clients requesting access to more than one target
endpoint SHOULD use a separate statement for each target.<vspace
blankLines="1"/></t>
<t hangText="token_endpoint_auth_method"><vspace
blankLines="0"/>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: <list style="symbols">
<t><spanx style="verb">none</spanx>: The client is a public
client as defined in OAuth 2.0 and does not have a client
secret.</t>
<t><spanx style="verb">bearer</spanx>: The client is will
use a bearer assertion as defined in Section 4.2 of <xref
target="I-D.ietf-oauth-assertions"/>.</t>
</list> Additional values can be defined via the IANA OAuth
Token Endpoint Authentication Methods registry <xref
target="team-registry"/>. Absolute URIs can also be used as
values for this parameter. If unspecified or omitted, the
default is <spanx style="verb">bearer</spanx>.<vspace
blankLines="1"/></t>
<t hangText="tos_uri"><vspace blankLines="0"/>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
<xref target="HumanReadableClientMetadata">Human Readable Client
Metadata</xref>.<vspace blankLines="1"/></t>
</list></t>
</section>
<section title="Multi-valued Attributes">
<t>The following is a list of multi-valued attributes that may be
used in a software statement.<list hangIndent="4" style="hanging">
<t hangText="contacts"><vspace blankLines="0"/>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.<vspace blankLines="1"/></t>
<t hangText="redirect_uris"><vspace blankLines="0"/>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.<vspace
blankLines="1"/></t>
<t hangText="grant_types"><vspace blankLines="0"/>OPTIONAL. One
or more OAuth 2.0 grant types that the client may use. These
grant types are defined as follows:<list style="symbols">
<t><spanx style="verb">authorization_code</spanx>: The
Authorization Code Grant described in OAuth 2.0 Section
4.1</t>
<t><spanx style="verb">implicit</spanx>: The Implicit Grant
described in OAuth 2.0 Section 4.2</t>
<t><spanx style="verb">password</spanx>: The Resource Owner
Password Credentials Grant described in OAuth 2.0 Section
4.3</t>
<t><spanx style="verb">client_credentials</spanx>: The
"Client credentials Grant" described in OAuth 2.0 Section
4.4</t>
<t><spanx style="verb">refresh_token</spanx>: The Refresh
Token Grant described in OAuth 2.0 Section 6.</t>
<t><spanx style="verb">urn:ietf:params:oauth:grant-type:jwt-bearer</spanx>:
The JWT Bearer grant type defined in <xref
target="I-D.ietf-oauth-jwt-bearer">OAuth JWT Bearer Token
Profiles</xref>.</t>
<t><spanx style="verb">urn:ietf:params:oauth:grant-type:saml2-bearer</spanx>:
The SAML 2 Bearer grant type defined in <xref
target="I-D.ietf-oauth-saml2-bearer">OAuth SAML 2 Bearer
Token Profiles</xref>.</t>
</list>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 <spanx
style="verb">grant_type</spanx> parameter passed to the Token
Endpoint defined in the extension.<vspace blankLines="1"/></t>
<t hangText="response_types"><vspace blankLines="0"/>OPTIONAL.
One or more OAuth 2.0 response types that the client may use.
These response types are defined as follows:<list
style="symbols">
<t><spanx style="verb">code</spanx>: The Authorization Code
response described in OAuth 2.0 Section 4.1.</t>
<t><spanx style="verb">token</spanx>: The Implicit response
described in OAuth 2.0 Section 4.2.</t>
</list>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 <spanx
style="verb">response_type</spanx> parameter passed to the
Authorization Endpoint defined in the extension.</t>
</list></t>
</section>
<section anchor="GrantTypesAndResponseTypes"
title="Relationship Between Grant Types and Response Types">
<t>The <spanx style="verb">grant_types</spanx> and <spanx
style="verb">response_types</spanx> 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 <spanx style="verb">grant_types</spanx> available to a client
influence the <spanx style="verb">response_types</spanx> that the
client is allowed to use, and vice versa. For instance, a <spanx
style="verb">grant_types</spanx> value that includes <spanx
style="verb">authorization_code</spanx> implies a <spanx
style="verb">response_types</spanx> 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.</t>
<t>The correlation between the two fields is listed in the table
below.</t>
<texttable>
<ttcol>grant_types value includes:</ttcol>
<ttcol>response_types value includes:</ttcol>
<c>authorization_code</c>
<c>code</c>
<c>implicit</c>
<c>token</c>
<c>password</c>
<c>(none)</c>
<c>client_credentials</c>
<c>(none)</c>
<c>refresh_token</c>
<c>(none)</c>
<c>urn:ietf:params:oauth:grant-type:jwt-bearer</c>
<c>(none)</c>
<c>urn:ietf:params:oauth:grant-type:saml2-bearer</c>
<c>(none)</c>
</texttable>
<t>Extensions and profiles of this document that introduce new
values to either the <spanx style="verb">grant_types</spanx> or
<spanx style="verb">response_types</spanx> parameter MUST document
all correspondences between these two parameter types.</t>
</section>
<section anchor="HumanReadableClientMetadata"
title="Human Readable Client Metadata">
<t>[[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.]]</t>
<t>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
<spanx style="verb">client_name</spanx>, <spanx style="verb">tos_uri</spanx>,
<spanx style="verb">policy_uri</spanx>, <spanx style="verb">logo_uri</spanx>,
and <spanx style="verb">client_uri</spanx> might have multiple
locale-specific values in some client registrations.</t>
<t>To specify the languages and scripts, <xref
target="RFC5646">BCP47</xref> 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 <xref target="IANA.Language">IANA
Language Subtag Registry</xref>. 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 <spanx style="verb">fr</spanx> might be sufficient in many
contexts, rather than <spanx style="verb">fr-CA</spanx> or <spanx
style="verb">fr-FR</spanx>.</t>
<t>For example, a client could represent its name in English as
<spanx style="verb">"client_name#en": "My Client"</spanx> and its
name in Japanese as <spanx style="verb">"client_name#ja-Jpan-JP": "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D"</spanx>
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.</t>
<t>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.</t>
<t>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 <spanx style="verb">#</spanx> 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, <spanx style="verb">var j = JSON.parse(json);</spanx>,
then the member <spanx style="verb">client_name#en-us</spanx> can be
accessed using the JavaScript syntax <spanx style="verb">j["client_name#en-us"]</spanx>.</t>
</section>
</section>
<section anchor="assertionRequirements"
title="Software Statement Requirements">
<t>In order to create and validate a software assertion, the following
requirements apply in addition to those stated in <xref
target="I-D.ietf-oauth-jwt-bearer">Section 3</xref>.<list
style="numbers">
<t>The JWT MAY contain any claim specified in <xref
target="client-metadata"/>.</t>
<t>The JWT MUST contain an "iss" (issuer) claim that contains a
unique identifier for the entity that issued and signed the JWT.
The value MAY be the client developer, a software API publisher,
or a third-party organization (e.g. a consortium) that would be
trusted by deploying organizations.</t>
<t>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.</t>
<t>The JWT MUST contain an "aud" (audience) claim containing a
value that is ONE of the following:<list style="symbols">
<t>A value that identifies one or more software API
deployments, where the client software MAY be registered.</t>
<t>A value <spanx style="verb">urn:oauth:scim:reg:generic</spanx>
which indicates the assertion MAY be used with any software
API deployment environment.</t>
</list></t>
<t>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.</t>
</list></t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<section anchor="team-registry"
title="OAuth Token Endpoint Authentication Methods Registry">
<t>This specification establishes the OAuth Token Endpoint
Authentication Methods registry.</t>
<t>Additional values for use as <spanx style="verb">token_endpoint_auth_method</spanx>
metadata values are registered with a Specification Required (<xref
target="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.</t>
<t>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").</t>
<t>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.</t>
<t>IANA must only accept registry updates from the Designated
Expert(s) and should direct all requests for registration to the
review mailing list.</t>
<section anchor="team-template" title="Registration Template">
<t><list style="hanging">
<t
hangText="Token Endpoint Authorization Method name:"><vspace/>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.</t>
<t hangText="Change controller:"><vspace/>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.</t>
<t hangText="Specification document(s):"><vspace/>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.</t>
</list></t>
</section>
<section anchor="team-contents" title="Initial Registry Contents">
<t>The OAuth Token Endpoint Authentication Methods registry's
initial contents are:</t>
<t><?rfc subcompact="yes"?> <list style="symbols">
<t>Token Endpoint Authorization Method name: <spanx
style="verb">none</spanx></t>
<t>Change controller: IETF</t>
<t>Specification document(s): [[ this document ]]</t>
</list></t>
<t><list style="symbols">
<t>Token Endpoint Authorization Method name: <spanx
style="verb">bearer</spanx></t>
<t>Change controller: IETF</t>
<t>Specification document(s): [[ this document ]]</t>
</list></t>
<t><list style="symbols">
<t>Token Endpoint Authorization Method name: <spanx
style="verb">client_secret_post</spanx></t>
<t>Change controller: IETF</t>
<t>Specification document(s): [[ this document ]]</t>
</list></t>
<t><list style="symbols">
<t>Token Endpoint Authorization Method name: <spanx
style="verb">client_secret_basic</spanx></t>
<t>Change controller: IETF</t>
<t>Specification document(s): [[ this document ]]</t>
</list></t>
</section>
<?rfc subcompact="no"?>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>The authorization server MUST treat the overall software statements,
as self-asserted since there is no way to prove a client is the software
it asserts to be. 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.</t>
<t>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:<list style="symbols">
<t>Approval of specific clients software for use with specific
protected resources.</t>
<t>Lifecycle management and support of specific software versions as
indicated by software_version.</t>
<t>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.</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml' ?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2246.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4627.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5646.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.6749.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.6750.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-oauth-assertions-12.xml' ?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-oauth-jwt-bearer-06.xml' ?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-oauth-saml2-bearer-17.xml' ?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-jose-json-web-key-16.xml' ?>
<reference anchor="I-D.draft-hunt-oauth-client-association">
<front>
<title>OAuth Client Association</title>
<author fullname="Phil Hunt" initials="P" role="editor"
surname="Hunt">
<organization>Oracle Corporation</organization>
<address>
<email>phil.hunt@yahoo.com</email>
</address>
</author>
<author fullname="Tony Nadalin" initials="T." surname="Nadalin">
<organization>Microsoft</organization>
<address>
<email>tonynad@microsoft.com</email>
</address>
</author>
<date/>
</front>
</reference>
<reference anchor="IANA.Language">
<front>
<title>Language Subtag Registry</title>
<author>
<organization>Internet Assigned Numbers Authority
(IANA)</organization>
</author>
<date year="2005"/>
</front>
<format target="http://www.iana.org/assignments/language-subtag-registry"
type="TXT"/>
</reference>
</references>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>This draft was based upon in large part upon the work in
draft-ietf-oauth-dyn-reg-14, draft-richer-oauth-dyn-reg-core-00 and
draft-richer-oauth-dyn-reg-12 and WG discussions. The authors would like
to thank Justin Richer and the members of the OAuth Working Group.</t>
</section>
<section anchor="History" title="Document History">
<t>[[ to be removed by the RFC editor before publication as an RFC
]]</t>
<t>-00</t>
<t><list style="symbols">
<t>First draft.</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 18:30:30 |