[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/