httpauth                                                    J. Woodworth
Internet-Draft                                                 D. Ballew
Intended status: Experimental                          CenturyLink, Inc.
Expires: August 31, 2017                               February 28, 2017


                  HTTP Authentication - |JSON| Scheme
                   draft-woodworth-json-http-auth-00

Abstract

   The |JSON| authentication scheme provides a mechanism for exchanging
   authentication challenges and credentials as objects in the form of
   JavaScript Object Notation (JSON).  This scheme offers a secure
   mechanism of providing authenticated access to a set of protected
   HTTP resources which may be handled by scripting utility framework as
   in XMLHttpRequest calls (AJAX) or directly by the client's user
   agent.  This chaining feature is unique to this scheme.

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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

   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."

Copyright Notice

   Copyright (c) 2017 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


Woodworth, et al.       Expires: August 31, 2017                [Page 1]


Internet-Draft    HTTP Authentication - |JSON| Scheme      February 2017


   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.















































Woodworth, et al.       Expires: August 31, 2017                [Page 2]


Internet-Draft    HTTP Authentication - |JSON| Scheme      February 2017


Table of Contents:

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . .   3
      1.1.  Background and Related Documents . . . . . . . . . . .   3
      1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . .   3
   2.  The |JSON| HTTP-Authentication Scheme . . . . . . . . . . .   4
      2.1.  JSON Based Payloads  . . . . . . . . . . . . . . . . .   4
      2.2.  Chained Authentication Cursor (CAC)  . . . . . . . . .   5
      2.3.  Extensible Authentication Indicators (EAI) . . . . . .   5
      2.4.  One-Time Password (OTP) Authentication Capability  . .   5
   3.  |JSON| Authentication Scheme Types  . . . . . . . . . . . .   6
      3.1.  The "password" |JSON| Authentication Type  . . . . . .   6
      3.2.  The "challenge" |JSON| Authentication Type . . . . . .   8
      3.3.  The Hybrid One-Off |JSON| Authentication Type
                            Variant  . . . . . . . . . . . . . . .  12
   4.  Implementation Considerations . . . . . . . . . . . . . . .  12
   4.1  Nonce Generation . . . . . . . . . . . . . . . . . . . . .  13
   4.2  User-Agent Scripted Authentication . . . . . . . . . . . .  14
   5.  Security Considerations . . . . . . . . . . . . . . . . . .  15
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . .  15
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . .  15
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . .  16
      8.1.  Normative References . . . . . . . . . . . . . . . . .  16
      8.2.  Informative References . . . . . . . . . . . . . . . .  16

1.  Introduction

   The |JSON| authentication scheme offers a number of new concepts used
   to extend or enhance current HTTP-Authentication facilities.

   New concepts include; JSON Based Challenge/ Response Payloads,
   Chained Authentication Cursor (CAC), Extensible Authentication
   Indicators (EAI) and One-Time Password (OTP) Authentication Support.

1.1.  Background and Related Documents

   This document assumes the reader is familiar with the basic HTTP and
   HTTP-Authentication concepts described in [RFC7230] and [RFC7235].

   The reader is also assumed to be familiar with the JSON data
   interchange format and associated terminology described in [RFC7159]
   as well as the Base64 encoding methods as described in [RFC4648].

1.2.  Reserved Words

   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].




Woodworth, et al.       Expires: August 31, 2017                [Page 3]


Internet-Draft    HTTP Authentication - |JSON| Scheme      February 2017


2.  The |JSON| HTTP-Authentication Scheme

   The |JSON| scheme provides an extensible mechanism of providing
   primary HTTP authentication to a web-based application.  This section
   will cover a number of new concepts intended to extend the
   flexibility and capabilities of existing HTTP authentication schemes.

   This scheme follows the methods defined in [RFC7235] to provide
   authentication challenge and response via the HTTP-Headers "WWW-
   Authenticate" and "Authorization" respectively.  For the moment at
   least, this document hereby defines proxy authentication as out of
   scope.

2.1.  JSON Based Payloads

   A primary motivation for this document is to offer the ability to
   leverage scripting capabilities within the client application.  While
   this does fall outside the HTTP protocol itself, modern HTTP clients
   have advanced to a point where scripting and asynchronous calls to
   back-end web services have become quite common.  These advancements
   offer an integration between the HTTP protocol and client side logic
   processing (i.e. scripting).

   One such advancement along this path is the ubiquity of JSON encoded
   objects.  These objects can be quickly processed and passed over-the-
   wire to almost any programming language and are native to the default
   scripting engine of modern browsers.

   By leveraging the JSON format for passing challenges and responses
   back and forth a type of protocol-logic bridge can be easily
   established.

   This document defines a single JSON object containing zero or more
   elements where the set of elements is defined by its authentication
   "type" and whether it is a challenge or response.  This document
   defines 3 types, "password", "challenge", and a hybrid one-off
   variant each described in detail in sections to follow.  This object
   is Base64 encoded and assigned to the "data" auth-param as defined in
   [RFC7235], Section 2.1.  Additionally, while many examples show JSON
   object definitions in this document are shown in a "pretty" format to
   improve readability the over-the-wire encoding is expected to be in a
   condensed form (minimum whitespace) prior to Base64 encoding.

   Below is a simple example demonstrating the "password" type:

      WWW-Authenticate: |JSON| realm="Test Realm",
                        data="eyAidHlwZSIgOiAicGFzc3dvcmQiIH0="





Woodworth, et al.       Expires: August 31, 2017                [Page 4]


Internet-Draft    HTTP Authentication - |JSON| Scheme      February 2017


2.2.  Chained Authentication Cursor (CAC)

   Beyond the utilization of the JSON format to exchange and validate
   authentication credentials, this document establishes the concept of
   a Chained Authentication Cursor (CAC).

   The logic used to implement CAC is simpler than the name may imply.
   In essence, the client's user-agent is currently aware of several
   authentication schemes, each with their own handler.  For example, a
   handler is defined for the "Basic" scheme, another for the "Digest"
   scheme, etc.  When a challenge is received from the server as a
   result of a "401 Unauthorized" response, a cursor is assigned and
   attached to this challenge.  This cursor follows the challenge
   throughout its short life-cycle "Chained" in succession to each of
   the available user-agent authentication handlers in order to provide
   the client's response.  Each handler may either accept or reject the
   authentication cursor based entirely upon the scheme passed to it.
   If the cursor is accepted, it MUST provide a response to be used for
   the follow-up request.

   Some handlers in the chain MAY be defined as Extensible
   Authentication Handlers (EAH) others as Native Authentication
   Handlers (NAH).  EAHs are extensions to the built-in NAHs and are
   generally provided as either a client extension or scripted handler
   and can be used to provide custom or interim authentication
   solutions.  Additional recommendations are provided in this document
   to avoid "Chicken and Egg" scenarios where EAHs are concerned.

2.3.  Extensible Authentication Indicators (EAI)

   Schemes used by Extensible Authentication Handlers (EAH) MUST have
   their intent formally identified by an Extensible Authentication
   Indicator (EAI).  The [US-ASCII] pipe character (|) is reserved for
   this purpose and if the HTTP-Authentication scheme is surrounded by
   this character (e.g. "|JSON|", "|Basic|", "|example|", "|pdmk|",
   "|random|", etc.) an EAH MUST be assumed.  If no EAH are defined for
   an EAI indicated scheme, the indicators MUST be removed and the CAC
   passed to a handler for the new scheme as next in the chain.  For
   example, if the scheme "|Basic|" is provided in the challenge and no
   EAH is defined for "|Basic|", then an attempt to pass the CAC to a
   "Basic" NAH MUST be attempted.  This logic MUST be attempted for each
   EAH in the chain for the active CAC.

2.4.  One-Time Password (OTP) Authentication Capability

   This document defines provisions for One-Time Password (OTP)
   Authentication.  This concept, while simple to grasp, causes
   difficulty in a stateless protocol such as HTTP.  Recommendations for
   overcoming such difficulties are provided in sections which follow.



Woodworth, et al.       Expires: August 31, 2017                [Page 5]


Internet-Draft    HTTP Authentication - |JSON| Scheme      February 2017


3.  |JSON| Authentication Scheme Types

   The following three authentication types are explicitly defined by
   this document but others may exist under its umbrella so long as none
   of the defined requirements are violated.

   Additionally, the objects and internal elements defined are to be
   considered a super-set of those implemented and extension or
   "enrichment" is to be expected and are considered OPTIONAL.  However,
   in order to ensure compatibility all objects and internal elements
   defined by a type and not defined as OPTIONAL MUST be implemented as
   defined.

3.1.  The "password" |JSON| Authentication Type

   This is the simplest authentication type offered.  This type is
   provided in order to offer scripted capability without a lot of
   knowledge in cryptography.  Due to its clear-text nature it is highly
   recommended to only be used in an encrypted environment (i.e.
   SSL/TLS, etc.).

   The HTTP-Authentication challenge for this type includes the
   following elements (with definitions):

      type:      REQUIRED

         The |JSON| Authentication Scheme type of "password"

      cookie:    OPTIONAL

         This is the name of the HTTP-Cookie as defined by [RFC6265]
         which will be used by the server for continuing the session
         after initial HTTP based authentication has completed

      version:   OPTIONAL

         The |JSON| Authentication Scheme version.  This document
         defines this as 1.0 and version 1.0 MUST be assumed if no
         version is provided

   An example challenge for this type is simply:

      { "type" : "password" }

   The HTTP-Authentication challenge MUST be Base64 encoded and applied
   to the "WWW-Authenticate" HTTP-Header as defined by [RFC7235],
   Section 4.1.





Woodworth, et al.       Expires: August 31, 2017                [Page 6]


Internet-Draft    HTTP Authentication - |JSON| Scheme      February 2017


   The Base64-encoded header with associated realm appears as:

      WWW-Authenticate: |JSON| realm="Test Realm",
                        data="eyAidHlwZSIgOiAicGFzc3dvcmQiIH0="

   The HTTP-Authentication response for this type includes the following
   elements (with definitions):

      type:      REQUIRED

         The |JSON| Authentication Scheme type of "password"

      username:  REQUIRED

         The user associated with this protected resource

      password:  REQUIRED

         The password associated with this protected resource

      version:   OPTIONAL

         The |JSON| Authentication Scheme version.  This document
         defines this as 1.0 and version 1.0 MUST be assumed if no
         version is provided

   NOTE: Since no protection of credentials is offered by the "password"
   type, the need for other protections such as replay-prevention is
   unnecessary and therefore not offered as part of this type.

   For an example username of "MyUser" and password of "MyPassword" the
   JSON representation of the response would be:

      {
         "type"     : "password"
        ,"username" : "MyUser"
        ,"password" : "MyPassword"
      }

   The Base64-encoded header with associated realm appears as:

      Authorization: |JSON| realm="Test Realm",
                     data="eyAidHlwZSIgOiAicGFzc3dvcmQiLCAi
                     dXNlcm5hbWUiIDogIk15VXNlciIsICJwYXNzd2
                     9yZCIgOiAiTXlQYXNzd29yZCIgfQ=="

   NOTE: The "data" element has been expanded to multiple lines for
   readability purposes only




Woodworth, et al.       Expires: August 31, 2017                [Page 7]


Internet-Draft    HTTP Authentication - |JSON| Scheme      February 2017


3.2.  The "challenge" |JSON| Authentication Type

   The challenge authentication type provides features to protect the
   credentials against replay-prevention and over-the-wire interception.

   The HTTP-Authentication challenge for this type includes the
   following elements (with definitions).  More details are provided in
   the implementation considerations sections below.

      type:         REQUIRED

         The |JSON| Authentication Scheme type of "challenge"

      algorithms:   REQUIRED

         A comma separated list of accepted algorithms as defined by
         [FIPS-180-4] and [FIPS-202] in order of preference (OPTIONAL
         whitespace MUST be ignored during selection described below).

         NOTE: Use of the SHA-1 algorithm is highly discouraged at the
         time this document is being written and SHOULD NOT be used.

      nonce:        REQUIRED

         A one-time-only value calculated by the server to be used in
         client calculations

      cookie:       OPTIONAL

         This is the name of the HTTP-Cookie as defined by [RFC6265]
         which will be used by the server for continuing the session
         after initial HTTP based authentication has completed

      message:      OPTIONAL

         A string value which MAY be presented to the user as additional
         information about the authentication challenge or previous
         attempt.  An example would be "Unable to authenticate
         credentials at this time, please try again later."

      opaque:       OPTIONAL

         A value calculated by the server to provide additional
         protection against tampering and session management

      path:         OPTIONAL

         A value representing the protected resource path.  The provided
         path does not need to be the literal path but can be a symbolic
         path or hash which can be used by the client and server to


Woodworth, et al.       Expires: August 31, 2017                [Page 8]


Internet-Draft    HTTP Authentication - |JSON| Scheme      February 2017


         limit a set of resources beyond what has been provided by the
         realm

      version:      OPTIONAL

         The |JSON| Authentication Scheme version.  This document
         defines this as 1.0 and version 1.0 MUST be assumed if no
         version is provided

      window:       OPTIONAL

         An integer value (in seconds) the challenge will be valid for.
         This value is informational and MAY be used by the client to
         determine why a previous authentication attempt failed
         (challenge is no longer valid)

   An example challenge for this type is:

      {
         "type"       : "challenge"
        ,"algorithms" : "SHA-384,SHA-256,SHA-224"
        ,"nonce"      : "1488442706.13154/
                         339158aa-2504-44a4-bd7a-c86a85c4c7a8,
                         320afaed21f1827383194b49c02008909cf28
                         3ca2f3dca190c2ab958ea580a28"
      }
   NOTE: Elements in the object above have been expanded to multiple
   lines for readability purposes only

   The Base64-encoded header with associated realm appears as:

      WWW-Authenticate: |JSON| realm="Test Realm",
                        data="eyJ0eXBlIjoiY2hhbGxlbmdlIiwiYWxnb3JpdG
                              htcyI6IlNIQS0yNTYsU0hBLTEiLCJub25jZSI6
                              IjE0ODg0NDI3MDYuMTMxNTQvMzM5MTU4YWEtMj
                              UwNC00NGE0LWJkN2EtYzg2YTg1YzRjN2E4LDMy
                              MGFmYWVkMjFmMTgyNzM4MzE5NGI0OWMwMjAwOD
                              kwOWNmMjgzY2EyZjNkY2ExOTBjMmFiOTU4ZWE1
                              ODBhMjgifQ=="

   The HTTP-Authentication response for this type includes the following
   elements (with definitions).  More details are provided in the
   implementation considerations sections below.

      type:         REQUIRED

         The |JSON| Authentication Scheme type of "challenge"

      username:     REQUIRED



Woodworth, et al.       Expires: August 31, 2017                [Page 9]


Internet-Draft    HTTP Authentication - |JSON| Scheme      February 2017


         The user associated with this protected resource

      algorithm:    REQUIRED

         The algorithm selected from the challenge's algorithms element.
          If no compatible algorithm can be established, the client MUST
          fail and if applicable provide additional details to the user

      nonce:        REQUIRED

         This value MUST match the nonce value provided by the server's
         challenge verbatim

      token:        REQUIRED

         This value MUST be generated by the client according to the
         following rules:

            - A hash of the client provided password MUST be generated
            using the cryptographic algorithm specified as "algorithm"
            above.

               password_hash = ALGORITHM ( password )

            - The following values (including quoted colon values ":")
            MUST be concatenated into a single string value.  Optional
            values which are not defined MUST be replaced by an empty
            string.  Any required field which is not defined MUST fail
            and if applicable provide additional details to the user

               pre_token = username + ":" + password_hash + ":" +
                           nonce + ":" + opaque + ":" +
                           algorithm + ":" + cnonce + ":" +
                           message

            - A hash of the string provided in the previous step MUST be
            generated using the cryptographic algorithm specified as
            "algorithm" above.

               token = ALGORITHM ( pre_token )

         NOTE: The output of the ALGORITHM function MUST be encoded as a
         lowercase hexadecimal value

      cnonce:       OPTIONAL

         A one-time-only value calculated by the client to be used for
         further limiting replay-attacks

      message:      OPTIONAL


Woodworth, et al.       Expires: August 31, 2017               [Page 10]


Internet-Draft    HTTP Authentication - |JSON| Scheme      February 2017


         A string value which MAY be presented to the server as
         additional information about the authentication response for
         logging and debugging purposes.  An example would be "CoolAuth-
         Client/1.0"

      opaque:       OPTIONAL

         This value MUST match the opaque value provided by the server's
         challenge verbatim.  If no opaque value was provided by the
         server's challenge, the client MUST NOT provide one in the
         response

      version:      OPTIONAL

         The |JSON| Authentication Scheme version.  This document
         defines this as 1.0 and version 1.0 MUST be assumed if no
         version is provided

   For an example username of "MyUser", a  password of "MyPassword" and
   the "SHA-256" hashing algorithm the JSON representation of the
   response would be:

      {
         "type"       : "challenge"
        ,"algorithm"  : "SHA-256"
        ,"username"   : "MyUser"
        ,"nonce"      : "1488442706.13154/
                         339158aa-2504-44a4-bd7a-c86a85c4c7a8,
                         320afaed21f1827383194b49c02008909cf28
                         3ca2f3dca190c2ab958ea580a28"
        ,"token"      : "03066bdf1244be4c458fd6ef46af52acceea2
                         0d90ee979b10231018a52d92e66"
      }
   NOTE: Elements in the object above have been expanded to multiple
   lines for readability purposes only

















Woodworth, et al.       Expires: August 31, 2017               [Page 11]


Internet-Draft    HTTP Authentication - |JSON| Scheme      February 2017


   The Base64-encoded header with associated realm appears as:

      Authorization: |JSON| realm="Test Realm",
                     data="eyJ0eXBlIjoiY2hhbGxlbmdlIiwiYWxnb3JpdG
                           htIjoiU0hBLTI1NiIsInVzZXJuYW1lIjoiTXlV
                           c2VyIiwibm9uY2UiOiIxNDg4NDQyNzA2LjEzMT
                           U0LzMzOTE1OGFhLTI1MDQtNDRhNC1iZDdhLWM4
                           NmE4NWM0YzdhOCwzMjBhZmFlZDIxZjE4MjczOD
                           MxOTRiNDljMDIwMDg5MDljZjI4M2NhMmYzZGNh
                           MTkwYzJhYjk1OGVhNTgwYTI4IiwidG9rZW4iOi
                           IwMzA2NmJkZjEyNDRiZTRjNDU4ZmQ2ZWY0NmFm
                           NTJhY2NlZWEyMGQ5MGVlOTc5YjEwMjMxMDE4YT
                           UyZDkyZTY2In0="

   NOTE: The "data" element has been expanded to multiple lines for
   readability purposes only

3.3.  The Hybrid One-Off |JSON| Authentication Type Variant

   This document defines a "One-Off" feature which informs the client's
   user agent the intent of the server's challenge is to fulfill a One-
   Time-Password (OTP) and client credentials MUST NOT be cached and
   reused for multiple responses.

   It must be noted this is a deviation from the standard client
   behavior in that caching and reusing credentials expected as OTP can
   have the side-effect of locking the account upon reuse of successful
   credentials.  It is highly recommended a cookie authentication
   mechanism be used to continue a successfully authenticated session.
   More details are provided in the implementation considerations
   sections below.

   This feature is available for either the "password" or "challenge"
   types explained in the sections above and is enabled by setting the
   type to the type prepended by a single exclamation character (!).

   For an example username of "MyUser" and password of "MyPassword" the
   JSON representation of the response would be:

      {
         "type"     : "!password"
        ,"username" : "MyUser"
        ,"password" : "MyPassword"
      }

4.  Implementation Considerations

   This document provides the following recommendations to improve
   overall compatibility between implementations.



Woodworth, et al.       Expires: August 31, 2017               [Page 12]


Internet-Draft    HTTP Authentication - |JSON| Scheme      February 2017


4.1  Nonce Generation

   The authors of this document highly recommended two factors when
   implementing the generation of nonce values.

   1) Time Component

      The two main goals for the nonce field is to; a) provide
      protection against replays of captured credential payloads; and
      b) make cryptographic analysis more difficult.  A simple
      implementation to meet both of these goals is to provide a time
      component to the nonce string.

      The examples in this document use a hi-resolution "epoch" (or unix
      time) at the start of each nonce followed by a [US-ASCII] forward-
      slash character "/" and a generated portion.

         The string "1488442706.13154" from the examples above
         represents "Thu Mar  2 08:18:26 2017" referenced to the GMT
         timezone.

      Using a component like this greatly reduces the risk of nonce
      reuse and allows for a validity window to easily be established.
      Since this is generated at the server, no time synchronization
      needs to be performed with the client and when used for the
      response, can be directly compared with the same time source.

   2) Validation Component

      Since the nonce is used as a component of the client's response
      and the HTTP protocol is stateless, it is highly recommended the
      validity of the nonce be confirmed prior to authenticating the
      request.  If, for example, a malicious user was to modify the
      nonce and use this modified nonce in the response, the security of
      the requested resource may be jeopardized.

      This document recommends adding a component which can be easily
      self-validated and offers protection against such tampering.  This
      can be done by using a secret known only to the server (or set of
      servers).

      The examples in this document use a Universally Unique Identifier
      UUID generator to provide a bit of uniqueness beyond simply the
      time component discussed above.  Most UUID implementations
      leverage a source of entropy to nearly eliminate the risk of
      collisions and this along with the time component should make this
      safe within a reasonable validation window.





Woodworth, et al.       Expires: August 31, 2017               [Page 13]


Internet-Draft    HTTP Authentication - |JSON| Scheme      February 2017


      The UUID is combined with the time component, optional opaque
      value and secret key to form the full nonce string using the
      following pattern:

         time_component + ":" + uuid_component + ":" +
                          opaque + ":" + secret

      The examples in this document use the following values for this:

         time_component = "1488442706.13154"

         uuid_component = "339158aa-2504-44a4-bd7a-c86a85c4c7a8"

         opaque         = ""

         secret         = "MyKey"

      This equates to the string:

         1488442706.13154:339158aa-2504-44a4-bd7a-c86a85c4c7a8::MyKey

      The SHA-256 output of this is:

         320afaed21f1827383194b49c02008909cf283ca2f3dca19
         0c2ab958ea580a28

         NOTE: The above example has been expanded to multiple lines for
         readability purposes only

      The final string for this nonce is:

         1488442706.13154/339158aa-2504-44a4-bd7a-c86a85c4c7a8,
         320afaed21f1827383194b49c02008909cf283ca2f3dca190c2ab
         958ea580a28

         NOTE: The above example has been expanded to multiple lines for
         readability purposes only

4.2  User-Agent Scripted Authentication

   A highlighted feature of this document is its ability to pass
   authentication to a scripting facility within the client.  This
   section provides recommendations for implementing this feature.

      1) Chicken and Egg avoidance:

         A complication to tying scripts to authentication is the
         scripts must be loaded prior to the authentication challenge in
         order for this to work.  One way to avoid this is to provide
         the authentication handler in a script above other scripts in


Woodworth, et al.       Expires: August 31, 2017               [Page 14]


Internet-Draft    HTTP Authentication - |JSON| Scheme      February 2017


         the main document.  The main document will need to be able to
         load without initial authentication for this to work.  This
         solution will not work where Asynchronous Module Definition
         (AMD) is deployed.

         Another solution would be to use an authentication entry-point
         page which would be in an unauthenticated "zone" of the
         application and once successfully authenticated redirect to the
         authenticated "zone" leveraging cookies for the transition.

      2) Where do the Scripted Handlers Live?

         Assuming this document has found a large adoption, it is
         recommended the user agent hosts this as a function of the root
         of in its HTML DOM tree (e.g. "window.AuthHandler();").

         This function could provide:

            a) A test for the existence of an EAH handler for a
            particular scheme

            b) Invoke an EAH handler for a particular

            c) Install an EAH handler for a particular scheme

         Until interest for such an adoption, we recommended this to be
         where developers host their EAHs and invoke such EAHs where
         appropriate.

5.  Security Considerations

   This document provides methods for transmitting credentials (or the
   implicit knowledge of these credentials) from an HTTP client agent
   (e.g. "browser") to an HTTP server.  Methods have been provided in
   some instances to protect the actual credentials from tampering
   between this connection but steps must be taken on each side to
   protect the credential collection and validation points.  Any weak
   point in a security system makes that system in its entirety just as
   weak.

6.  IANA Considerations

   IANA is requested to update their http-authschemes registry
   <http://www.iana.org/assignments/http-authschemes> to include the
   "|JSON|" and "|*|" schemes where "|*|" represents any valid token
   surrounded by [US-ASCII] pipe characters "|" (e.g. "|pdmk|").

7.  Acknowledgments

   This document leans heavily on on the work of others, specifically


Woodworth, et al.       Expires: August 31, 2017               [Page 15]


Internet-Draft    HTTP Authentication - |JSON| Scheme      February 2017


   those responsible for the RFCs listed below.  The authors of this
   document wish to thank each author involved to help get us here.  The
   authors also extend a special thanks to Kathleen Moriarty, for
   encouraging us to finish this draft.

8.  References

8.1.  Normative References

   [US-ASCII]   American National Standards Institute, "Coded Character
                Set -- 7-bit American Standard Code for Information
                Interchange", ANSI X3.4, 1986.

   [FIPS-180-4] National Institute of Standards and Technology (NIST),
                United States of America, "Secure Hash Standard (SHS)",
                FIPS PUB 180-4, August 2015 , <http://nvlpubs.nist.gov/
                nistpubs/FIPS/NIST.FIPS.180-4.pdf>.

   [FIPS-202]   National Institute of Standards and Technology (NIST),
                United States of America, "SHA-3 Standard:
                Permutation-Based Hash and Extendable-Output Functions",
                FIPS PUB 202, August 2015 , <http://nvlpubs.nist.gov/
                nistpubs/FIPS/NIST.FIPS.202.pdf>.

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4648]    S. Josefsson, SJD, "The Base16, Base32, and Base64
                Data Encodings", RFC 4648, October 2006.

   [RFC6265]    A. Barth, "HTTP State Management Mechanism", RFC 6265,
                April 2011.

   [RFC7159]    T. Bray, "The JavaScript Object Notation (JSON) Data
                Interchange Format", RFC 7159, March 2014.

   [RFC7230]    R. Fielding, J. Reschke, "Hypertext Transfer Protocol
                (HTTP/1.1): Message Syntax and Routing", RFC 7230,
                June 2014.

   [RFC7235]    R. Fielding, J. Reschke, "Hypertext Transfer Protocol
                (HTTP/1.1): Authentication", RFC 7235, June 2014.

8.2.  Informative References

Authors' Addresses






Woodworth, et al.       Expires: August 31, 2017               [Page 16]


Internet-Draft    HTTP Authentication - |JSON| Scheme      February 2017


   John Woodworth
   4250 North Fairfax Drive
   Arlington, VA 22203
   USA

   EMail: John.Woodworth@CenturyLink.com


   Dean Ballew
   2355 Dulles Corner Boulevard Suite 200 300
   Herndon, VA 20171
   USA

   EMail: Dean.Ballew@CenturyLink.com

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

































Woodworth, et al.       Expires: August 31, 2017               [Page 17]