Internet DRAFT - draft-hunt-oauth-software-statement
draft-hunt-oauth-software-statement
OAuth P. Hunt, Ed.
Internet-Draft Oracle Corporation
Intended status: Standards Track T. Nadalin
Expires: March 31, 2014 Microsoft
September 27, 2013
OAuth 2.0 Software Statement
draft-hunt-oauth-software-statement-00
Abstract
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.
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 March 31, 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
Hunt & Nadalin Expires March 31, 2014 [Page 1]
Internet-Draft OAuth-Software-Statement-00 September 2013
include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . . . . . . 3
2. Software Statement . . . . . . . . . . . . . . . . . . . . . 4
2.1. Software Statement Lifecycle . . . . . . . . . . . . . . 4
2.2. Statement Attributes . . . . . . . . . . . . . . . . . . 6
2.2.1. Singular Attributes . . . . . . . . . . . . . . . . . 7
2.2.2. Multi-valued Attributes . . . . . . . . . . . . . . . 9
2.2.3. Relationship Between Grant Types and Response Types . 10
2.2.4. Human Readable Client Metadata . . . . . . . . . . . 11
2.3. Software Statement Requirements . . . . . . . . . . . . . 12
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
3.1. OAuth Token Endpoint Authentication Methods Registry . . 13
3.1.1. Registration Template . . . . . . . . . . . . . . . . 14
3.1.2. Initial Registry Contents . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. Normative References . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16
Appendix B. Document History . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
The OAuth 2.0 Authorization Framework [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.
This specification defines a JWT authorization assertion
[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 [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.
Applications using software statements, may typically go through 3
phases where:
Hunt & Nadalin Expires March 31, 2014 [Page 2]
Internet-Draft OAuth-Software-Statement-00 September 2013
o A software statement is generated and associated with a client
application.
o A service provider approves client software for use within its
domain on the basic of software_id, developer, or software
statment signing organization.
o And finally, where a particular instance of a client possessing a
software statement associates with a particular serivce provider.
1.1. Notational Conventions
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].
This specification uses the following additional terms:
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
Hunt & Nadalin Expires March 31, 2014 [Page 3]
Internet-Draft OAuth-Software-Statement-00 September 2013
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.
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.
Software Statement A signed JWT authorization token
[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.
2. Software Statement
As per the introduction, a software statement is an 'authorization'
bearer token (as defined in Section 2.1 of
[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.
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.
2.1. Software Statement Lifecycle
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.
Client App
Developer
O (A) Obtain Software Statement ****************
\|/ <-------------------------------------- * Software API *
Hunt & Nadalin Expires March 31, 2014 [Page 4]
Internet-Draft OAuth-Software-Statement-00 September 2013
| * 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
* *
******
Figure 1: Client Statement Lifecycle
(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
Hunt & Nadalin Expires March 31, 2014 [Page 5]
Internet-Draft OAuth-Software-Statement-00 September 2013
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.
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.
(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.
(C) A client instance conveys the software statement to the service
provider, as described in
[I-D.draft-hunt-oauth-client-association].
2.2. Statement Attributes
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.
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.
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.
Hunt & Nadalin Expires March 31, 2014 [Page 6]
Internet-Draft OAuth-Software-Statement-00 September 2013
2.2.1. Singular Attributes
The following is a list of attributes that MUST have only a SINGLE
value in a software statement.
software_id
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.
"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 the
OAuth"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 "software_id" 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 Human
Readable Client Metadata (Section 2.2.4).
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.2.4).
jwks_uri
OPTIONAL. A URL for the client's JSON Web Key Set
[I-D.ietf-jose-json-web-key] document representing the client's
Hunt & Nadalin Expires March 31, 2014 [Page 7]
Internet-Draft OAuth-Software-Statement-00 September 2013
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.2.4).
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.2.4).
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 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.
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.
* "bearer": The client is will use a bearer assertion as defined
in Section 4.2 of [I-D.ietf-oauth-assertions].
Additional values can be defined via the IANA OAuth Token
Endpoint Authentication Methods registry Section 3.1. Absolute
URIs can also be used as values for this parameter. If
unspecified or omitted, the default is "bearer".
Hunt & Nadalin Expires March 31, 2014 [Page 8]
Internet-Draft OAuth-Software-Statement-00 September 2013
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.2.4).
2.2.2. Multi-valued Attributes
The following is a list of multi-valued attributes that may be used
in a software statement.
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
[I-D.ietf-oauth-jwt-bearer].
Hunt & Nadalin Expires March 31, 2014 [Page 9]
Internet-Draft OAuth-Software-Statement-00 September 2013
* "urn:ietf:params:oauth:grant-type:saml2-bearer": The SAML 2
Bearer grant type defined in OAuth SAML 2 Bearer Token
Profiles [I-D.ietf-oauth-saml2-bearer].
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
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.2.3. 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.
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 |
| | |
Hunt & Nadalin Expires March 31, 2014 [Page 10]
Internet-Draft OAuth-Software-Statement-00 September 2013
| 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.2.4. 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.
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".
Hunt & Nadalin Expires March 31, 2014 [Page 11]
Internet-Draft OAuth-Software-Statement-00 September 2013
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.3. Software Statement Requirements
In order to create and validate a software assertion, the following
requirements apply in addition to those stated in Section 3
[I-D.ietf-oauth-jwt-bearer].
1. The JWT MAY contain any claim specified in Section 2.2.
2. 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.
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:
Hunt & Nadalin Expires March 31, 2014 [Page 12]
Internet-Draft OAuth-Software-Statement-00 September 2013
* 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.
3. IANA Considerations
3.1. OAuth Token Endpoint Authentication Methods Registry
This specification establishes the OAuth Token Endpoint
Authentication Methods registry.
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.
Hunt & Nadalin Expires March 31, 2014 [Page 13]
Internet-Draft OAuth-Software-Statement-00 September 2013
3.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.
3.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
o Specification document(s): [[ this document ]]
o Token Endpoint Authorization Method name: "bearer"
o Change controller: IETF
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 ]]
4. Security Considerations
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
Hunt & Nadalin Expires March 31, 2014 [Page 14]
Internet-Draft OAuth-Software-Statement-00 September 2013
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.
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.
5. Normative References
[I-D.draft-hunt-oauth-client-association]
Hunt, P., Ed. and T. Nadalin, "OAuth Client Association",
.
[I-D.ietf-jose-json-web-key]
Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web-
key-16 (work in progress), September 2013.
[I-D.ietf-oauth-assertions]
Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
"Assertion Framework for OAuth 2.0 Client Authentication
and Authorization Grants", draft-ietf-oauth-assertions-12
(work in progress), July 2013.
[I-D.ietf-oauth-jwt-bearer]
Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", draft-ietf-oauth-jwt-bearer-06
(work in progress), July 2013.
[I-D.ietf-oauth-saml2-bearer]
Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0
Profile for OAuth 2.0 Client Authentication and
Hunt & Nadalin Expires March 31, 2014 [Page 15]
Internet-Draft OAuth-Software-Statement-00 September 2013
Authorization Grants", draft-ietf-oauth-saml2-bearer-17
(work in progress), July 2013.
[IANA.Language]
Internet Assigned Numbers Authority (IANA), "Language
Subtag Registry", 2005.
[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.
[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.
[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-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.
Appendix B. Document History
[[ to be removed by the RFC editor before publication as an RFC ]]
Hunt & Nadalin Expires March 31, 2014 [Page 16]
Internet-Draft OAuth-Software-Statement-00 September 2013
-00
o First draft.
Authors' Addresses
Phil Hunt (editor)
Oracle Corporation
Email: phil.hunt@yahoo.com
Tony Nadalin
Microsoft
Email: tonynad@microsoft.com
Hunt & Nadalin Expires March 31, 2014 [Page 17]
