Network Working Group                                      D. Hardt, Ed.
Internet-Draft                                                SignIn.Org
Intended status: Standards Track                         29 January                         8 February 2020
Expires: 1 11 August 2020

                           The XAuth Protocol
                     draft-hardt-xauth-protocol-01
                     draft-hardt-xauth-protocol-02

Abstract

   Client software often desires resources or identity claims that are
   managed
   independent of the client.  This protocol allows a user and/
   or and/or
   resource owner to delegate resource authorization and/or release of
   identity claims to an authorization a server.  Client software can then request access
   to resources and/or identity claims by calling the authorization server.  The authorization
   server acquires consent and authorization from the user and/or
   resource owner if required, and then returns to the client software
   the authorization and identity claims that were approved.  This
   protocol can be extended to support alternative
   client authentication mechanisms, authorizations,
   claims, interactions, and
   interactions.

   [Editor: suggestions on how to improve this are welcome!]

   [Editor: suggestions for other names than XAuth are welcome!] client authentication mechanisms.

Note to Readers

   Source for this draft and an issue tracker can be found at
   https://github.com/dickhardt/hardt-xauth-protocol
   (https://github.com/dickhardt/hardt-xauth-protocol).

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 https://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 1 11 August 2020.

Copyright Notice

   Copyright (c) 2020 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 (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3   4
   2.  Protocol  .  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Parties . . . . . . . . . . . . . . . . . . . . . . . . .   4   5
     2.2.  Handles  Reused Terms  . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  New Terms . . .   5
     2.3.  Reused Terms . . . . . . . . . . . . . . . . . . . . .   6
   3.  Sequences .   5
     2.4.  Sequence . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  AS Request JSON .   7
     3.1.  Create Grant  . . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  Top Level Attributes   7
     3.2.  Reciprocal Grant  . . . . . . . . . . . . . . . . . .  11
     3.2.  "client" Object . .   8
     3.3.  GS Initiated Grant  . . . . . . . . . . . . . . . . . . .  11
     3.3.  "user" Object  10
     3.4.  Create and Update . . . . . . . . . . . . . . . . . . . .  10
     3.5.  Create and Delete . . . . . . . . . . . . . . . . . . . .  12
     3.4.  "authentication" Object
     3.6.  Create, Discover, and Delete  . . . . . . . . . . . . . .  14
     3.7.  Create and Wait . . . .  13
     3.5.  "authorizations" Object . . . . . . . . . . . . . . . . .  13
     3.6.  "claims" Object  14
     3.8.  Read Grant  . . . . . . . . . . . . . . . . . . . . .  14
     3.7.  Authorization Types . .  15
     3.9.  Access Token Refresh  . . . . . . . . . . . . . . . . . .  16
     3.10. GS API Table  .  14 . . . . . . . . . . . . . . . . . . . . .  16
   4.  Interaction Response JSON  Grant and AuthZ Life Cycle  . . . . . . . . . . . . . . . . .  17
   5.  GS APIs .  14
     4.1.  "user" Object . . . . . . . . . . . . . . . . . . . . . .  15
     4.2.  "interaction" Object . . . .  18
     5.1.  Create Grant  . . . . . . . . . . . . . .  15
     4.3.  "authorization" Object . . . . . . . .  18
     5.2.  Read Grant  . . . . . . . . .  16
     4.4.  "authentication" Object . . . . . . . . . . . . . .  20
     5.3.  Update Grant  . . .  16
   5.  Interaction Types . . . . . . . . . . . . . . . . . . .  20
     5.4.  Delete Grant  . . . . .  16
     5.1.  "popup" Type . . . . . . . . . . . . . . . . .  21
     5.5.  Request JSON  . . . . .  16
     5.2.  "redirect" Type . . . . . . . . . . . . . . . . .  22
       5.5.1.  "client" Object . . . .  17
     5.3.  "qrcode" Type . . . . . . . . . . . . . . .  22
       5.5.2.  "interaction" Object  . . . . . . .  17
   6.  AS Response JSON . . . . . . . . .  22
       5.5.3.  "user" Object . . . . . . . . . . . . . . . .  17
     6.1.  Top Level Attributes . . . .  23
       5.5.4.  "authorization" Object  . . . . . . . . . . . . . .  18
     6.2. .  23
       5.5.5.  "authorizations" Object . . . . . . . . . . . . . . .  24
       5.5.6.  "claims" Object . . . . . . . . . . . . . . . . .  18
     6.3.  "claims" . .  24
       5.5.7.  "reciprocal" Object . . . . . . . . . . . . . . . . .  24
     5.6.  Refresh Authorization . . . .  19
     6.4.  Access Methods . . . . . . . . . . . . . .  25
     5.7.  Update Authorization  . . . . . . .  20
   7.  Discovery . . . . . . . . . . .  25
     5.8.  Delete Authorization  . . . . . . . . . . . . . . .  20
   8.  JOSE Client Authentication . . .  25
     5.9.  GS Options  . . . . . . . . . . . . . .  20
     8.1.  JOSE Headers . . . . . . . . .  26
     5.10. Grant Options . . . . . . . . . . . . .  21
     8.2.  Authentication Request Token . . . . . . . . .  27
     5.11. AuthZ Options . . . . .  23
     8.3.  Authorization . . . . . . . . . . . . . . . . .  27
     5.12. Request Token Verification  . . . . . . . . . . . . . . .  24
     8.4.  Refresh Token . . .  27
   6.  GS Initiated Grant  . . . . . . . . . . . . . . . . . . .  25
     8.5.  JOSE Access Token . .  28
   7.  GS API Responses  . . . . . . . . . . . . . . . . . .  25
     8.6.  HTTP Authorization JOSE Header . . . .  28
     7.1.  Grant Response  . . . . . . . . .  26
     8.7.  JOSE Token Verification . . . . . . . . . . . .  28
     7.2.  Interaction Response  . . . . . . .  26
     8.8.  AS Request . . . . . . . . . . .  29
     7.3.  Wait Response . . . . . . . . . . . .  26
     8.9.  Interaction . . . . . . . . . .  30
     7.4.  Response JSON . . . . . . . . . . . . . . . . . .  26
     8.10. Deletion Request . . . .  31
       7.4.1.  "interaction" Object  . . . . . . . . . . . . . . . .  27
     8.11. Authentication Request  31
       7.4.2.  "user" Object . . . . . . . . . . . . . . . . .  27
     8.12. Authentication Response . . .  31
       7.4.3.  "authorization" Object  . . . . . . . . . . . . . .  27
     8.13. Authorization Request .  32
       7.4.4.  "authorizations" Object . . . . . . . . . . . . . . .  32
       7.4.5.  "claims" Object . . . . .  27
     8.14. AS . . . . . . . . . . . . . .  32
       7.4.6.  "reciprocal" Object . . . . . . . . . . . . . . . . .  33
       7.4.7.  Interaction Types . . . . . . . . . . . . . . . . . .  33
       7.4.8.  Signing and Encryption  . . . . . . . . . . . . . . .  34
     7.5.  Response Verification . . . . . . . . . . . . . . . . . .  34
   8.  RS Access . . . . . . .  28
     8.15. . . . . . . . . . . . . . . . . . . .  34
     8.1.  Bearer Token RS Access  . . . . . . . . . . . . . . . . .  28
     8.16. Proof-of-possession RS Access . . . . .  34
   9.  Error Responses . . . . . . . . .  29
     8.17. . . . . . . . . . . . . . .  35
   10. JOSE Authentication . . . . . . . . . . . . . . . . . . . . .  35
     10.1.  GS Access  . . . . . . . . . . . . . . . . . . . . . . .  35
       10.1.1.  Authorization Header . . . . . . . . . . . . . . . .  36
       10.1.2.  Signed Body  . . . . . . . . . . . . . . . . . . . .  37
       10.1.3.  Public Key Resolution  . . . . . . . . . . . . . . .  37
     10.2.  RS Access  . . . . . . . . . . . . . . . . . . .  29
     8.18. Access Refresh . . . .  38
       10.2.1.  JOSE header  . . . . . . . . . . . . . . . . .  29
   9.  Error Messages . . .  38
       10.2.2.  "jose" Mechanism . . . . . . . . . . . . . . . . . .  39
       10.2.3.  "jose+body" Mechanism  . .  30
   10. AS Initiated Sequence . . . . . . . . . . . . .  40
       10.2.4.  Public Key Resolution  . . . . . . . . .  30
     10.1.  Initiation Token . . . . . .  41
     10.3.  Request Encryption . . . . . . . . . . . . . .  32 . . . . .  41
     10.4.  Response Signing . . . . . . . . . . . . . . . . . . . .  41
     10.5.  Response Encryption  . . . . . . . . . . . . . . . . . .  42
   11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . .  32  42
   12. Rational  . . . . . . . . . . . . . . . . . . . . . . . . . .  33  43
   13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  36  47
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  36  47
   15. Security Considerations . . . . . . . . . . . . . . . . . . .  36  47
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  36  47
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  36  47
     16.2.  Informative References . . . . . . . . . . . . . . . . .  38  48
   Appendix A.  Document History . . . . . . . . . . . . . . . . . .  39  49
     A.1.  draft-hardt-xauth-protocol-00 . . . . . . . . . . . . . .  39  49
     A.2.  draft-hardt-xauth-protocol-01 . . . . . . . . . . . . . .  39  50
     A.3.  draft-hardt-xauth-protocol-02 . . . . . . . . . . . . . .  50

   Appendix B.  Comparison with OAuth 2.0 and OpenID Connect . . . .  39  50
   Appendix C.  Open Questions . . . . . . . . . . . . . . . . . . .  51
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  40  51

1.  Introduction

   This protocol supports the widely deployed use cases supported by
   OAuth 2.0 [RFC6749] & [RFC6750], and OpenID Connect [OIDC], an
   extension of OAuth 2.0, as well as other extensions, and other use
   cases that are not supported, such as requesting acquiring multiple
   authorizations in one request. access
   tokens at the same time, and updating the request during user
   interaction.  This protocol also addresses many of the security
   issues in OAuth 2.0 by having parameters securely sent directly
   between parties, rather than via a browser redirection.

   The technology landscape has changed since OAuth 2.0 was initially
   drafted.  More interactions happen on mobile devices than PCs.
   Modern browsers now directly support asymetric cryptographic
   functions.  Standards have emerged for signing and encrypting tokens
   with rich payloads (JOSE) that are widely deployed.

   Additional use cases are now being served with extensions to OAuth
   2.0: OpenID Connect added support for authentication and releasing
   identity claims; [RFC8252] added support for native apps; [RFC8628]
   added support for smart devices; and support for [browser_based_apps]
   is being worked on.  There are numerous efforts on adding proof-of-
   possession to resource access.

   This protocol simplifies the overall architectural model, takes
   advantage of today's technology landscape, provides support for all
   the widely deployed use cases, and offers numerous extension points.

   The

   While this protocol is not backwards compatible with OAuth 2.0, it
   strives to minimize the migration effort.

   This protocol centers around a Grant, a representation of the
   collection of user identity claims and/or resource authorizations the
   Client is requesting, and the resulting identity claims and/or
   resource authorizations granted by the Grant Server.

   [Editor: suggestions on how to improve this are welcome!]

   [Editor: suggestions for other names than XAuth are welcome!]

2.  Protocol  Terminology
2.1.  Parties

   The parties and their relationships to each other:

   +--------+                           +------------+
   |  User  |                           |  Resource  |
   |        |                           | Owner (RO) |
   +--------+                           +------------+
       |      \                       /      |
       |       \                     /       |
       |        \                   /        |
       |         \                 /         |
   +--------+     +---------------+     +------------+
   | Client |---->|     Grant     | _ _ |  Resource  |
   |        |<----|  Server (GS)  |     |   Server   |
   |        |     +---------------+     |    (RS)    |
   |        |-------------------------->|            |
   |        |<--------------------------|            |
   +--------+                           +------------+

   *  *Authorization Server* (AS)  *User* - manages the person interacting with the Client authorization who has delegated
      access to API
      resources and release of identity claims about the User.  The AS
      may require explicit consent from the RO or User to provide these themselves to the Client. Grant Server
      (GS), and can authenticate at the GS.

   *  *Client* - requests authorization a Grant from the GS to API resources, access one or more
      Resource Servers (RSs), and/or identity claims about the User.
      The Client can create, retrieve, update, and delete a Grant.  When
      a Grant is created, the Client receives from the GS the granted
      access token(s) for the RS(s), and identity claims about the User.
      The Client uses an access token to access the RS.  There are two
      types of Clients: Registered Clients and Dynamic Clients.  An AS may support only
      one or both types.  All
      Clients have a key to authenticate with the AS. Grant Server.

   *  *Registered Client* - a Client that has registered with the AS GS and
      has a Client ID to identify itself, and can prove it possesses a
      key that is linked to the Client ID.  The AS GS may have different
      policies for what different Registered Clients can request.  The  A
      Registered Client MAY be interacting with a User.

   *  *Dynamic Client* - a Client that has not been registered with the
      AS,
      GS, and each instance will generate it's own key pair so it can
      prove it is the same instance of the Client on subsequent
      requests.
      requests, and to requests of a Resource Server.  A single-page
      application with no server is an example of a Dynamic Client.  The  A
      Dynamic Client MUST be interacting with a User.

   *  *User*  *Grant Server* (GS) - the person who has delegated making manages Grants for access to APIs at RSs and
      release of identity claims about
      themselves the User.  The GS may require
      explicit consent from the RO or User to provide these to the AS, and
      Client.  An GS may support Registered Clients and/or Dynamic
      Clients.  The GS is interacting with a combination of the Client. Authorization Server (AS)
      in OAuth 2.0, and the OpenID Provider (OP) in OpenID Connect.

   *  *Resource Server* (RS) - has API resources that require an access
      token from the AS for access. GS.  Owned by the Resource Owner.

   *  *Resource Owner* (RO) - owns the RS, and has delegated RS access
      token creation
      management to the AS. GS.  The RO may be the same entity as the User,
      or may be a different entity that the AS GS interacts with
      independent of the Client.

2.2.  Handles

   Handles are strings issued by the AS to the Client that
      independently.  GS and RO interactions are opaque to
   the Client.

   *  *authorization handle* - represents the client request.  Presented
      back to the AS in an Authorization Request.

   *  *authentication handle* - represents the client request for
      authentication first.  Presented back to the AS in an
      Authentication Request, or in the subsequent AS Request.

   *  *access handle* - represents the access the AS has granted the
      Client to the RS.  The Client proves possession of its key when
      presenting an access handle to access an RS.  The RS is able to
      understand the authorizations represented by the access handle
      directly, or through an introspection call.  The RS is able to
      verify the access handle was issued to the Client that presented
      it.

   *  *refresh handle* - represents the access the AS has granted the
      Client to a RS.  Presented back to the AS when the Client wants a
      fresh access token or access handle.

   When presenting any out of the above handles, the Client always proves
   possession scope of its key.

2.3. this
      document.

2.2.  Reused Terms

   *  *access token* - an access token as defined in [RFC6749]
      Section 1.4.

   *  *Claims*  *Claim* - Claims a Claim as defined in [OIDC] Section 5.  Claims may be
      issued by the GS, or by other issuers.

   *  *Client ID* - an AS a GS unique identifier for a Registered Client as
      defined in [RFC6749] Section 2.2.

   *  *ID Token* - an ID Token as defined in [OIDC] Section 2.

   *  *NumericDate* - a NumericDate as defined in [RFC7519] Section 2.

2.4.  Sequence

   1.   *AS Discovery* (Section 7) The

   *  *authN* - short for authentication.

   *  *authZ* - short for authorization.

2.3.  New Terms

   *  *GS URI* - the endpoint at the GS the Client discovers calls to create a
      Grant.  The unique identifier for the AS end
        point, keys, supported GS.

   *  *Grant* - the user identity claims and/or RS authorizations the GS
      has granted to the Client.

   *  *Grant URI* - the URI that represents the Grant.  The Grant URI
      MUST start with the GS URI.

   *  *Authorization* - the access granted by the RO to the Client.
      Contains an access token.

   *  *AuthZ URI* - the URI that represents the Authorization the Client
      was granted by the RO.  The AuthZ URI MUST start with the GS URI.
      The AuthZ URI is used to refresh, update, and authorizations, and other
        capabilities.  Some, or all of delete an access
      token.

   *  *interaction* - [Editor: what do we really mean by this information could term?]

3.  Sequences

   Before any sequence, the Client needs to be manually preconfigured, or dynamically obtained.  Dynamic AS
        discovery is out
   programmatically configured for the GS.  See GS Options Section 5.9
   for details on acquiring GS metadata.

   [Editor: a plethora of scope sequences are included to illustrate all the
   different actions.  Many of this document.

   2.   *AS Request* (Section 8.8) these could potentially be moved to a use
   case document in the future.]

3.1.  Create Grant

   The Client requests a Grant from the GS that requires User
   interaction:

   +--------+                                  +-------+
   | Client |                                  |  GS   |
   |        |--(1)--- Create Grant ----------->|       |
   |        |                                  |  (2)  |
   |        |<--- Interaction Response ---(3)--|  eval |
   |        |                                  |       |
   |        |--(4)--- Read Grant ------------->|       |         +------+
   |        |                                  |       |         | User |
   |        |--(5)--- Interaction Transfer --- | - - - | ------->|      |
   |        |                                  |       |<--(6)-->|      |
   |        |                                  |       |  authN  |      |
   |        |                                  |       |<--(7)-->|      |
   |        |                                  |       |  authZ  |      |
   |        |<--- Interaction Transfer ---(8)- | - - - | --------|      |
   |        |                                  |       |         |      |
   |        |<--------- Grant Response ---(9)--|       |         +------+
   |        |                                  |       |
   +--------+                                  +-------+

   1.  *Create Grant* The Client creates an AS a Grant Request (Section 3) for authorization to API resources and/or identity
        claims about the User 5.1)
       and sends it with an HTTP POST to the AS
        endpoint.  The Client includes requests authentication first if
        the Client wants the AS to authenticate the User prior to
        requesting additional claims and authorizations.

   3.   *AS GS GS URI.

   2.  *Grant Request Evaluation* The AS GS processes the request and
        determines to
       determine if it needs to interact with the RO will send a Interaction Response, Wait Response,
       or User.  If a Grant Response.  The GS determines that interaction is required, with the AS returns
       User is required and sends an Interaction Response
        (Section 4), if no interaction Response.  (For
       readability, this step is required it returns not described in the following
       sequences)

   3.  *Interaction Response* The GS sends an AS Interaction Response
       (Section 6). 7.2) containing the Grant URI and an interaction object.

   4.   *Interaction Response* (Section 8.9)  *Read Grant* The AS will send Client does an
        authentication object unless HTTP GET of the Grant URI
       (Section 5.2).

   5.  *Interaction Transfer* The Client sent authentication
        first, in which case transfers User interaction to
       the AS will send an authentication object. GS.

   6.  *User Authentication* The GS authenticates the User.

   7.  *User Authorization* If required, the AS wants GS interacts with the Client User
       to initiate determine which identity claims and/or authorizations in the
       Grant Request are to be granted.

   8.  *Interaction Transfer* The GS transfers User interaction, it
        will include an interaction object.  If authentication first, to the
       Client.

   9.  *Grant Response* The GS responds with a Grant Response
       (Section 7.1).

3.2.  Reciprocal Grant

   Party A and Party B are both a Client and a GS, and each Client would
   like a Grant for the other GS.  Party A starts off being the Client will next send (6) Authentication Request, otherwise
   per Create Grant Section 3.1.  Party B then includes a Reciprocal
   Request in its Grant Response.  Party A then gets authorization from
   the User and returns a Grant URI to Party B.  Party A and B swap
   roles, and Party B's Client obtains the Grant from Party A's GS.

                   Party A                                    Party B
                  +--------+                                 +--------+
                  | Client |                                 |   GS   |
                  ~ ~ ~ ~ ~ ~     Same as steps 1 - 8 of    ~ ~ ~ ~ ~ ~
   +------+       |        |        Create Grant above       |        |
   | User |       |        |                                 |        |
   |      |<----- | - - -  | -- Interaction Transfer ------- |        |
   |      |       |        |                                 |        |
   |      |       |        |<------- Grant Response ---(1)---|        |
   |      |       |        |      Reciprocal Grant Request   |        |
   |      |<-(2)->|        |                                 |        |
   |      | AuthZ |        |---(3)--- Update Grant --------->|        |
   +------+       |        |   Reciprocal Grant Response     |        |
                  |        |                                 |        |
                  |        |<-- Empty Grant Response ---(4)--|        |
                  |        |                                 |        |
                  +--------+       (5) Swap Roles            +--------+
                  |   GS   |                                 | Client |
                  |        |<------------ Read Grant ---(6)--|        |
                  |        |                                 |        |
                  |        |--(7)--- Grant Response -------->|        |
                  |        |                                 |        |
                  +--------+                                 +--------+

   1.  *Grant Response* Party B responds with a Grant Response including
       a Reciprocal Object Section 7.4.6 requesting its own Grant.

   2.  *User Authorization* If required, Party A interacts with the User
       to determine which identity claims and/or authorizations in the
       Grant Request are to be granted to Party B.

   3.  *Update Grant* Party A sends an Authorization Request. Update Grant request containing
       the Grant URI in the Reciprocal object Section 5.5.7.

   4.  *Grant Response* Party B responds with an Empty Grant Response as
       there were no other requests in the Update Grant.

   5.   *Authorization Request*  *Swap Roles* Party A now acts as a GS, Party B as a Client.

   6.  *Read Grant* Party B does an HTTP GET of the Grant URI
       (Section 8.13) 5.2).

   7.  *Grant Response* Party A responds with a Grant Response
       (Section 7.1).

3.3.  GS Initiated Grant

   The User is at the GS, and wants to interact with a Registered
   Client.  The GS can redirect the User to the Client:

   +--------+                                  +-------+         +------+
   | Client |                                  |  GS   |         | User |
   |        |                                  |       |<--(1)-->|      |
   |        |                                  |       |         |      |
   |        |<----- GS Initiation Redirect --- | - - - | --(2)---|      |
   |   (3)  |                                  |       |         |      |
   | verify |--(4)--- Read Grant ------------->|       |         +------+
   |        |                                  |       |
   |        |<--------- Grant Response --(5)---|       |
   |        |                                  |       |
   +--------+                                  +-------+

   1.  *User Interaction* The GS interacts with the User to determine
       the Client and what identity claims and authorizations to
       provide.  The GS creates a Grant and corresponding Grant URI.

   2.  *GS Initiated Redirect* The GS redirects the User to the Client's
       interaction_uri, adding a query parameter with the name "Grant
       URI" and the value being the URL encoded Grant URI.

   3.  *Client Verification* The Client verifies the Grant URI is from
       an
        authorization request token Section 8.3 GS the Client trusts, and starts with the GS GS URI.

   4.  *Read Grant* The Client does a an HTTP GET of the
        authorization uri, after waiting Grant URI
       (Section 5.2).

   5.  *Grant Response* The GS responds with a Grant Response
       (Section 7.1).

   See Section 6 for any authorization wait
        time. more details.

3.4.  Create and Update

   The Client then listens requests an identity claim to determine who the User is.
   Once the Client learns who the User is, and the Client updates the
   Grant for (13) AS Response.

   6.   *Authentication Request* (Section 8.11) additional identity claims which the GS prompts the User
   for and returns to the Client.  Once those are received, the Client
   updates the Grant with the remaining identity claims required.

   +--------+                                  +-------+
   | Client |                                  |  GS   |
   |        |--(1)--- Create Grant ----------->|       |
   |        |  "interaction"."keep":true       |       |
   |        |                                  |       |
   |        |<--- Interaction Response ---(2)--|       |
   |        |                                  |       |
   |        |--(3)--- Read Grant ------------->|       |         +------+
   |        |                                  |       |         | User |
   |        |--(4)--- Interaction Transfer --- | - - - | ------->|      |
   |        |                                  |       |         |      |
   |        |                                  |       |<--(5)-->|      |
   |        |                                  |       |  authN  |      |
   |        |<--------- Grant Response ---(6)--|       |         |      |
   |  (7)   |                                  |       |         |      |
   |  eval  |--(8)--- Update Grant ----------->|       |         |      |
   |        |  "interaction"."keep":true       |       |<--(9)-->|      |
   |        |                                  |       |  authZ  |      |
   |        |<--------- Grant Response --(10)--|       |         |      |
   |  (11)  |                                  |       |         |      |
   |  eval  |--(12)-- Update Grant ----------->|       |         |      |
   |        |  "interaction"."keep":false      |       |<--(13)->|      |
   |        |                                  |       |  authZ  |      |
   |        |                                  |       |         |      |
   |        |<--- Interaction Transfer --(14)- | - - - | --------|      |
   |        |                                  |       |         |      |
   |        |<--------- Grant Response --(15)--|       |         +------+
   |        |                                  |       |
   +--------+                                  +-------+

   1.   *Create Grant* The Client creates a Grant Request (Section 5.1)
        including an
        authentication request token identity claim and "interaction"."keep":true, and
        sends it with an HTTP POST to the GS GS URI.

   2.   *Interaction Response* The GS sends an Interaction Response
        (Section 7.2) containing the Grant URI, an interaction object,
        and "interaction"."keep":true.

   3.   *Read Grant* The Client does a an HTTP GET of the
        authentication uri. Grant URI
        (Section 5.2).

   4.   *Interaction Transfer* The Client then listens for (9)
        Authentication Response.

   7.   *Interaction* If the AS sent transfers User interaction instructions to
        the
        Client, the Client executes them.

   8. GS.

   5.   *User Authentication* The AS GS authenticates the User.  If Client
        requested authentication first, the AS

   6.   *Grant Response* The GS responds to with a Grant Response
        (Section 7.1) including the
        Authentication identity claim from User
        authentication and "interaction"."keep":true.

   7.   *Grant Evaluation* The Client queries its User database and does
        not find a User record matching the identity claim.

   8.   *Update Grant* The Client creates an Update Grant Request
        (Section 5.3) including the initial identity claims required and
        "interaction"."keep":true, and sends it with an (9) Authentication Response,
        otherwise HTTP PUT to the AS performs any needed authorizations per step
        (10).
        Grant URI.

   9.   *Authentication Response* (Section 8.12)   *User AuthN* The AS sends an AS
        Response containing GS interacts with the User to determine which
        identity claims in the Client requested.

   10.  *AS Update Grant Request 2* are to be granted.

   10.  *Grant Response* The Client uses GS responds with a Grant Response
        (Section 7.1) including the returned identity claims to
        look up released by the User in its internal database
        and determines what,
        if any, "interaction"."keep":true.

   11.  *Grant Evaluation* The Client evaluates the identity claims and/or authorizations it would like to request
        and includes them in a new AS Request, as well as
        the
        authentication handle.  If Client wants not additional claims
        and/or authorizations, Grant Response and determines the remaining User identity
        claim required.

   12.  *Update Grant* The Client sets creates an Update Grant Request
        (Section 5.3) including the remaining required identity claims object
        and "interaction"."keep":false, and sends it with an HTTP PUT to
        the
        JSON null value. Grant URI.

   13.  *User AuthZ* The Client then listens for (13) AS Response.

   11.  *Authorization* If required, the AS GS interacts with the User and/
        or RO to determine which of any of the authorizations and
        identity claims requests made by in the Client Update Grant Request are to be granted.

   12.  *Redirect* If

   14.  *Interaction Transfer* The GS transfers User interaction to the Client did
        Client.

   15.  *Grant Response* The GS responds with a full browser redirect Grant Response
        (Section 7.1) including the identity claims released by the
        User.

3.5.  Create and Delete

   The Client requests an identity claim to determine who the AS, User is.
   Once the AS redirects Client learns who the User back to is, and the redirect_uri supplied by Client knows it has
   all the Client, otherwise identity claims and authorizations needed, the AS closes its popup window, or informs Client deletes
   the User Grant which prompts the GS to transfer the interaction is complete.

   13.  *AS back to
   the Client.

   +--------+                                  +-------+
   | Client |                                  |  GS   |
   |        |--(1)--- Create Grant ----------->|       |
   |        |  "interaction"."keep":true       |       |
   |        |                                  |       |
   |        |<--- Interaction Response ---(2)--|       |
   |        |                                  |       |
   |        |--(3)--- Read Grant ------------->|       |         +------+
   |        |                                  |       |         | User |
   |        |--(4)--- Interaction Transfer --- | - - - | ------->|      |
   |        |                                  |       |         |      |
   |        |                                  |       |<--(5)-->|      |
   |        |                                  |       |  authN  |      |
   |        |<--------- Grant Response ---(6)--|       |         |      |
   |  (7)   |                                  |       |         |      |
   |  eval  |--(8)--- Delete Grant ----------->|       |         |      |
   |        |<------- Delete Response ---------|       |         |      |
   |        |                                  |       |         |      |
   |        |<--- Interaction Transfer ---(9)- | - - - | --------|      |
   |        |                                  |       |         |      |
   +--------+                                  +-------+         +------+

   1.  *Create Grant* The Client creates a Grant Request (Section 5.1)
       including an identity claim and "interaction"."keep":true, and
       sends it with an HTTP POST to the GS GS URI.

   2.  *Interaction Response* The GS sends an Interaction Response
       (Section 8.14) 7.2) containing the Grant URI, an interaction object,
       and "interaction"."keep":true.

   3.  *Read Grant* The AS responds to Client does an HTTP GET of the Grant URI
       (Section 5.2).

   4.  *Interaction Transfer* The Client transfers User interaction to
       the GS.

   5.  *User Authentication* The GS authenticates the User.

   6.  *Grant Response* The GS responds with a AS Grant Response
       (Section 6) containing authorized RS access tokens 7.1) including the identity claim from User
       authentication and "interaction"."keep":true.

   7.  *Grant Evaluation* The Client queries its User database and finds
       the User record matching the identity claims.  The AS may provide refresh handles claim, and uris for each access token if they that no
       additional claims or authorizations are authorized.  If
        proof-of-possession is required for accessing required.

   8.  *Delete Grant* The Client no longer needs the RS, Grant and decides
       to Delete Grant (Section 5.4) by sending an HTTP DELETE to the AS
        will provide access handles instead of access tokens.
       Grant URI.  If the AS
        has not completed GS responds with success the interaction, Grant no longer
       exists.

3.6.  Create, Discover, and Delete

   The Client wants to discover if the GS has a User with a given
   identifier.  If not, it will instead return a
        retry response for abort the Client request and not transfer
   interaction to make the GS.

   +--------+                                  +-------+
   | Client |                                  |  GS   |
   |        |--(1)--- Create Grant ----------->|       |
   |        |  "user"."exists":true            |       |
   |        |                                  |       |
   |        |<--- Interaction Response ---(2)--|       |
   |        |     "user"."exists":false        |       |
   |        |                                  |       |
   |        |--(3)--- Delete Grant ----------->|       |
   |        |<------- Delete Response ---------|       |
   |        |                                  |       |
   +--------+                                  +-------+

   1.  *Create Grant* The Client creates a new Authorization
        Request.

   14.  *Resource Request* Grant Request (Section 8.15, Section 8.16, & Section 8.17) 5.1)
       including an identity claim request, a User identifier, and
       "user"."exists":true.  The Client access sends it with an HTTP POST to
       the RS using a bearer token, a proof-of-
        possession token, or a signed request.

   15.  *Access Refresh* GS GS URI.

   2.  *Interaction Response* The GS sends an Interaction Response
       (Section 7.2) containing the Grant URI, an interaction object,
       and "user"."exists":false.

   3.  *Delete Grant* The Client determines the GS cannot fulfil its
       Grant Request, and decides to Delete Grant (Section 8.18) 5.4) by
       sending an HTTP DELETE to the Grant URI.  If the GS responds with
       success the Grant no longer exists.

3.7.  Create and Wait

   The Client received wants access to resources that require the GS to interact
   with the RO, which may not happen immediately, so the GS instructs
   the Client to wait and check back later.

   +--------+                                  +-------+
   | Client |                                  |  GS   |
   |        |--(1)--- Create Grant ----------->|       |
   |        |                                  |       |
   |        |<---------- Wait Response ---(2)--|       |         +------+
   |  (3)   |                                  |       |         |  RO  |
   |  Wait  |                                  |       |<--(4)-->|      |
   |        |                                  |       |  authZ  |      |
   |        |--(5)--- Read Grant ------------->|       |         +------+
   |        |                                  |       |
   |        |<--------- Grant Response --(6)---|       |
   |        |                                  |       |
   +--------+                                  +-------+

   1.  *Create Grant* The Client creates a refresh
        handle Grant Request (Section 5.1)
       and uri, sends it with an HTTP POST to the GS GS URI.

   2.  *Wait Response* The GS sends an Interaction Response
       (Section 7.3) containing the refresh handle Grant URI and wait time.

   3.  *Client Waits* The Client waits the wait time.

   4.  *RO AuthZ* The GS interacts with the RO to determine which
       identity claims in the refresh uri,
        and receives Grant Request are to be granted.

   5.  *Read Grant* The Client does an HTTP GET of the Grant URI
       (Section 5.2).

   6.  *Grant Response* The GS responds with a Grant Response
       (Section 7.1).

3.8.  Read Grant

   The Client wants to acquire fresh access token identity claims and authorizations
   in the Grant.  No User or RO interaction is required as no new
   consent or handle.

   *Sequence Diagram* authorization is required.

   +--------+                                           +---------------+                                  +-------+
   |        |<-(1)------- Discovery ------------------->| Authorization Client |                                  |  GS   |
   |    Server        |--(1)--- Read Grant ------------->|       |
   |        |--(2)------- AS Request ------------------>|        |                                  |       |
   | (3) Request        |<--------- Grant Response --(2)---|       |
   |        |                                  |    Evaluation       |
   +--------+                                  +-------+

   1.  *Read Grant* The Client does an HTTP GET of the Grant URI
       (Section 5.2).

   2.  *Grant Response* The GS responds with a Grant Response
       (Section 7.1) containing updated identity claims and
       authorizations.

3.9.  Access Token Refresh

   The Client has an access token and uses it to access resources at an
   RS.  The access token expires, and the Client acquires a fresh access
   token from the GS.

   +--------+                             +----------+
   |        |<-(4)------- Interaction Client |                             | Resource |
   |        |--(1)--- Access Resource --->|  Server  |
   |        |<------- Resource Response ---------| --|   (RS)   |
   |        |                             |          |
   |        |--(5)------- Authorization Request ------->| -------+        |--(2)--- Access Resource --->|          |
   |        |<------- Error Response -----|          |               or
   |        |                             |          |        |--(6)------- Authentication Request ------>| ---+
   |        |                             +----------+  +-------+
   |        |                                           |  GS   |
   |        |--(3)--- Refresh AuthZ ------------------->|       |
   |        |<------- AuthZ Response -------------------|       |
   |        |                                           |       |
   +--------+                                           +-------+

   1.  *Resource Request* The Client accesses the RS with the access
       token per Section 8 and receives a response from the RS.

   2.  *Resource Request* The Client attempts to access the RS, but
       receives an error indicating the access token has expired.

   3.  *Refresh AuthZ* If the Client received an AuthZ URI in the
       Response JSON "authorization" object (Section 7.4.3), the Client
       can Refresh AuthZ (Section 5.6) with an HTTP GET to the AuthZ URI
       and receive an Response JSON "authorization" object"
       (Section 7.4.3) with a fresh access token.

3.10.  GS API Table

    +--------------+-----------+--------+-----------------------------+
    | request      | http verb | uri    | response                    |        |--(7)--------->|  User  |<------------(8)--|
    +==============+===========+========+=============================+
    | Create Grant | POST      | GS URI | interaction, wait, or grant |  Interaction  +--------+  Authentication
    +--------------+-----------+--------+-----------------------------+
    | Read Grant   | GET       | Grant  | wait, or grant              | Client
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Update Grant | PUT       | Grant  | interaction, wait, or grant |
    |              |        |<-(9)------- Authentication Response ------|<---+           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Delete Grant | DELETE    | Grant  | success                     |        |--(10)------ AS Request 2 ---------------->| -------+
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Refresh      | GET       |               +--------+ AuthZ  | authorization               |
    | AuthZ        |        |<-(12)---------|  User  |<-----------(11)--|           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    |  Redirect Update AuthZ |  / RO PUT       |   Authorization AuthZ  | authorization               |
    |              |           |               +--------+ URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Delete AuthZ | DELETE    | AuthZ  | success                     |
    |              |        |<-(13)------ AS Response ------------------|<-------+           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | GS Options   | OPTIONS   | GS URI |                             +----------+ metadata                    |
    +--------------+-----------+--------+-----------------------------+
    | Grant        |        |--(14)-- Resource Request -->| Resource OPTIONS   | Grant  | metadata                    |
    |        |<------ Resource Response ---|  Server Options      |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    |                             +----------+ AuthZ        | OPTIONS   | AuthZ  | metadata                    |
    | Options      |           |        |--(15)------- Refresh Request ------------>| URI    |                             |        |<----------- Refresh
    +--------------+-----------+--------+-----------------------------+

                                  Table 1

   [ Editor: is there value in an API for listing a Client's Grants?
   eg:]

   List Grants     GET     GS URI    JSON array of Grant URIs

4.  Grant and AuthZ Life Cycle

   [Editor: straw man for life cycles.]

   *Grant life Cycle*

   The Client MAY create, read, update, and delete Grants.  A Grant
   persists until it has expired, is deleted, or another Grant is
   created for the same GS, Client, and User tuple.

   At any point in time, there can only be one Grant for the GS, Client,
   and User tuple.  When a Client creates a Grant at the same GS for the
   same User, the GS MUST invalidate a previous Grant for the Client at
   that GS for that User.

   *Authorization Life Cycle*
   Authorizations are OPTIONALLY included in a Grant Response -------------|               |
   +--------+                                           +---------------+

3.  AS
   "authorization" Object (Section 7.4.3), and are represented by an
   AuthZ URI.  If an AuthZ URI is included, the Client MAY refresh,
   update, and delete Authorizations.

   An Authorization will persist independent of the Grant, and persist
   until invalidated by the GS per GS policy, or deleted by the Client.

5.  GS APIs

   *Client Authentication*

   All APIs except for GS Options require the Client to authenticate.

   This document defines the JOSE Authentication mechanism in
   Section 10.  Other mechanisms include [TBD].

5.1.  Create Grant

   The Client creates a Grant by doing an HTTP POST of a JSON [RFC8259]
   document to the GS URI.

   The JSON document MUST include the following from the Request JSON
   Section 5.5:

   *  iat

   *  nonce

   *  uri set to the GS URI

   *  client

   and MAY include the following from Request JSON Section 5.5

   *  user

   *  interaction

   *  authorization or authorizations

   *  claims

   *  reciprocal

   The GS MUST respond with one of Grant Response Section 7.1,
   Interaction Response Section 7.2, Wait Response Section 7.3, or one
   of the following errors:

   *  TBD

   from Error Responses Section 9.

   Following is a non-normative JSON [RFC8259] document example where the Client wants to
   interact with the User with a popup and is requesting identity claims
   about the User and read access to the User's contacts:

   Example 1

   {
       "as"    :"https://as.example",
       "iat"   :"1579046092",       : 15790460234,
       "uri"       : "https://as.example/endpoint",
       "nonce" :"f6a60810-3d07-41ac-81e7-b958c0dd21e4",     : "f6a60810-3d07-41ac-81e7-b958c0dd21e4",
       "client": {
           "display": {
               "name"  :"SPA  : "SPA Display Name",
               "uri"   :"https://spa.example/about"   : "https://spa.example/about"
           }
       },
       "interaction": {
           "type"  :"popup"
           }      : "popup"
       },
       "authorizations":
       "authorization": {
           "type"      :"oauth_scope",      : "oauth_scope",
           "scope"     :"read_contacts"     : "read_contacts"
       },
       "claims": {
           "oidc": {
               "id_token" : {
                   "email"          : { "essential" : true },
                   "email_verified" : { "essential" : true }
               },
               "userinfo" : {
                   "name"           : { "essential" : true },
                   "picture"        : null
               }
           }
       }
   }

   Following is a non-normative example where the Client has previously
   authenticated is requesting
   the User, GS to keep the interaction with the User after returning the ID
   Token so the Client can update the Grant, and is requesting additional authorization: also asking if the
   user exists:

   Example 2

   {
       "as"    :"https://as.example",
       "iat"   :"1579046092",       : 15790460234,
       "uri"       : "https://as.example/endpoint",
       "nonce" :"0d1998d8-fbfa-4879-b942-85a88bff1f3b",     : "5c9360a5-9065-4f7b-a330-5713909e06c6",
       "client": {
           "id"        : "di3872h34dkJW", "di3872h34dkJW"
       },
       "interaction": {
           "keep"      : true,
           "type"      : "redirect",
           "uri"       : "https://web.example/return"
           }
       },
       "user": {
           "identifiers": {
               "oidc": {
                   "iss"   :"https://as.example",
                   "sub"   :"123456789"
               }
           }
       },
       "authorizations": {
           "type"  :"oauth_scope",
           "scope" :"read_calendar write_calendar"
       }
   }

   Following is a non-normative example where the Client is requesting
   authorization first:

   Example 3

   {
       "as"    :"https://as.example",
       "iat"   :"1579046092",
       "nonce" :"5c9360a5-9065-4f7b-a330-5713909e06c6",
       "client": {
           "id"        : "di3872h34dkJW",
           "interaction": {
               "type"  : "redirect",
               "uri"
               "email" : "https://web.example/return"
           } "jane.doe@example.com"
           },
       "authentication": {
           "first":
           "exists"    : true
       },
       "claims":
       "claims"    : { "oidc": { "id_token" : {} } }
   }

5.2.  Read Grant

   The Client reads a Grant by doing an HTTP GET of the corresponding
   Grant URI.

   The GS MUST respond with one of Grant Response Section 7.1,
   Interaction Response Section 7.2, Wait Response Section 7.3, or one
   of the following errors:

   *  TBD

   from Error Responses Section 9.

5.3.  Update Grant

   The Client updates a Grant by doing an HTTP PUT of a JSON document to
   the corresponding Grant URI.

   The JSON document MUST include the following from the Request JSON
   Section 5.5

   *  iat

   *  uri set to the Grant URI
   and MAY include the following from Request JSON Section 5.5

   *  user

   *  interaction

   *  authorization or authorizations

   *  claims

   *  reciprocal

   The GS MUST respond with one of Grant Response Section 7.1,
   Interaction Response Section 7.2, Wait Response Section 7.3, or one
   of the following errors:

   *  TBD

   from Error Responses Section 9.

   Following is a non-normative example where the Client previously
   requested authorization first (Example 3), the response was a new
   User, made an
   "interaction"."keep":true request, and now makes wants to update the following AS Request:
   request with additional claims:

   Example 4 3

   {
       "as"    :"https://as.example",
       "iat"   :"1579046092",
       "nonce" :"0a74f51f-514a-4821-b71f-01c252223f2f",
       "authentication": {
           "handle": "eyJhb958.example.authentication.handle.9yf3szM"
       },       : 15790460234,
       "uri"       : "https://as.example/endpoint/grant/example3",
       "claims": {
           "oidc": {
               "userinfo" : {
                   "email"          : { "essential" : true },
                   "phone_number"   : { "essential" : true },
                   "name"           : { "essential" : true },
                   "picture"        : null
               }
           }
       }
   }

3.1.  Top Level Attributes

   *as* -

5.4.  Delete Grant

   The Client deletes a Grant by doing an HTTP DELETE of the unique string identifier for
   corresponding Grant URI.

   The GS MUST respond with OK 200, or one of the AS.  This attribute is
   REQUIRED. following errors:

   *  TBD
   from Error Responses Section 9.

5.5.  Request JSON

   [Editor: do we want to reuse the JWT claims "iat", "jti", etc.? ]

   *  *iat* - the time of the request as a NumericDate.

   *  *nonce* - a unique identifier for this request.  This attribute is
   REQUIRED.  Note the AS Grant
      Response MUST contain a matching nonce
   attribute.

3.2. attribute value.

   *  *uri* - the GS URI if in a Create Grant Section 5.1, or the Grant
      URI if in an Update Grant Section 5.3.

5.5.1.  "client" Object

   The client object MUST contain either the client_id id attribute for Registered
   Clients, or the display object for Dynamic Clients.  If
   the Client can interact with the User, then an interaction object
   MUST be included.  If there is an authentication handle, then the
   client object MUST not be included.

   *client_id*

   *  *id* - the identifier Client ID the AS GS has for the Registered Client.

   *  *display* - the display object contains the following attributes:

   *

      -  *name* - a string that represents the Dynamic Client

   [Editor: a max length for the name?]

   *

      -  *uri* - a URI representing the Dynamic Client

   [Editor: a max length for the name?]  [Editor: a max length for the
   URI?]

   The name and uri will be displayed by the AS GS when prompting for
   authorization.

   *interaction* - the

5.5.2.  "interaction" Object

   The interaction object contains the type of interaction the Client
   will provide the User.  Other attributes are
   dependent on

   *  *keep* - a JSON boolean.  If set to the JSON value true, the GS
      will not transfer the User interaction type value.

   * back to the Client after
      processing the Grant request.  The JSON value false is equivalent
      to the attribute not being present, and the GS will transfer the
      User interaction back to the Client after processing the request.
      This attribute is OPTIONAL

      -  *type* - contains one of the following values: "popup",
         "redirect", or "qrcode".  Details in Section 5.

   * 7.4.7.  This
         attribute is REQUIRED.

      -  *redirect_uri* - this attribute is included REQUIRED if the type is
         "redirect".  It is the URI that the Client requests the AS GS to
         redirect the User to after the AS GS has completed interacting
         with the User.  If the Client manages session state in URIs,
         then the redirect_uri should SHOULD contain that state.

   *

      -  *ui_locales* - End-User's preferred languages and scripts for
         the user interface, represented as a space-separated list of
         [RFC5646] language tag values, ordered by preference.  This
         attribute is OPTIONAL.

   [Editor: do we need max pixels or max chars for qrcode interaction?
   Either passed to AS, GS, or max specified values here?]

   [Editor: other possible interaction models could be a "webview",
   where the Client can display a web page, or just a "message", where
   the client can only display a text message]

   [Editor: we may need to include interaction types for iOS and Android
   as the mobile OS APIs evolve.]

   [Editor: does

5.5.3.  "user" Object

   *  *exists* - MUST contain the JSON true value.  Indicates the Client include parameters if it wants
      requests the AS GS to return a "user"."exists" value in an
      Interaction Response signed and/or encrypted?]

3.3.  "user" Object

   The user object Section 7.2.  This attribute is optional. OPTIONAL, and
      MAY be ignored by the GS.

   *  *identifiers* - REQUIRED if the identifiers object contains one or exists attribute is present.  The
      values MAY be used by the GS to improve the User experience.
      Contains one or more of the following identifiers for the User:

   *

      -  *phone_number* - contains a phone number per Section 5 of
         [RFC3966].

   *

      -  *email* - contains an email address per [RFC5322].

   *

      -  *oidc* - is an object containing both the "iss" and "sub"
         attributes from an OpenID Connect ID Token per [OIDC]
         Section 2.

   The user and identifiers objects MAY be included to improve the user
   experience by the AS.  The AS MUST authenticate the User independent
   of these values.  The user object MUST not be included if there is an
   authentication handle.

   *discovery* - MUST contain the JSON true value.  Indicates the Client
   requests the AS to return a "discovered" attribute in the Interaction
   Response if the AS has a User at the AS with one or more of the
   identifiers.  This attribute is OPTIONAL.  Support of the discovery
   attribute by the AS is OPTIONAL.  The AS MAY return the [TBD] error
   if discovery is not supported, or ignore the request.

3.4.  "authentication" Object

   This OPTIONAL object MUST contain one of the following attributes:

   *  *first* - Must have the JSON value true.  Indicates the Client is
      requesting authentication first, and an authentication object in
      the Interaction Response.  If present, the AS will ignore the
      authorizations object.  [Editor: any use case where the Client
      needs an authorization at Authentication?]  The Client SHOULD
      limit the claims requested to only those needed to identify the
      User at the Client.  [Editor: this works if it is only a directed
      identifier, but consent would be required to return a verified
      phone or email.  Hmmm.]

   *  *handle* - the authentication handle.  MUST be included in the AS
      Request following an Authentication Response.

3.5.  "authorizations"

5.5.4.  "authorization" Object

   The optional authorizations object contains a dictionary of resource
   objects the Client is requesting authorization to access.  The
   authorizations object may contain one or more of:

   *  *type* - one of the following values: "oauth_scope", "oauth_rich", "oauth_scope" or "oauth_rich_list".  See Section 3.7 for details.
      "oauth_rich".  This attribute is REQUIRED.

   *  *scope* - a string containing the OAuth 2.0 scope per [RFC6749]
      section 3.3.  Present  MUST be included if type is "oauth_scope" or
      "oauth_rich".

   *  *authorization_details* - an authorization_details object per
      [RAR].  Present  MUST be included if type is "oauth_rich".

   *  *list* - an array of objects containing "scope" and
      "authorization_details".  Present if type is "oauth_rich_list".
      Used when requesting multiple access tokens and/or handles.

   [Editor: details may change as the [RAR] document evolves]

3.6.

5.5.5.  "authorizations" Object

   A JSON array of "authorization" objects.  Only one of "authorization"
   or "authorizations" may be in the Request JSON.

   [Editor: instead of an array, we could have a Client defined
   dictionary of "authorization" objects]

5.5.6.  "claims" Object

   The optional claims object contains

   Includes one or more identity claims being
   requested.  The claims may contain: of the following:

   *  *oidc* - an object that contains one or both of the following
      objects:

      -  *userinfo* - Claims that will be returned as a JSON object

      -  *id_token* - Claims that will be included in the returned ID
         Token.  If the null value, an ID Token will be returned
         containing no additional Claims.

   The contents of the userinfo and id_token objects are Claims as
   defined in [OIDC] Section 5.

   *  *oidc4ia* - OpenID Connect for Identity Assurance claims request
      per [OIDC4IA].

   *  *vc* - [Editor: define how W3C Verifiable Credentials [W3C_VC] can
      be requested.]

3.7.  Authorization Types

5.5.7.  "reciprocal" Object

   *  *oauth_scope*  *uri* - an OAuth 2.0 authorization request per [RFC6749]
      section 3.3 the Grant URI for the Reciprocal Grant.  This attribute is
      REQUIRED.

   *  *oauth_rich*  *client* - a rich authorization request per [RAR] the client object must contain the "id" attribute with
      the Client ID the Grant was issued to.  This attribute is
      REQUIRED.

   *  *oauth_rich_list*  *authorization* - a list of rich an authorization requests

4.  Interaction object per Section 7.4.3 in the
      Response JSON

   A non-normative example of JSON.

   *  *authorizations* - an Interaction authorizations object per Section 7.4.4 in
      the Response follows:

   {
       "user": {
           "discovered": true
       },
       "interaction": {
           "type"   : "popup",
           "uri"    : "https://as.example/endpoint/ey5gs32..."
       },
       "authorization": {
           "handle" : "eyJhb958.example.authorization.handle.9yf3szM",
           "uri"    : "https://as.example/authorization/ey7snHGs",
           "wait"   : "10"
       }
   }

4.1.  "user" Object

   MUST contain one of "authorization" object, or "authentication"
   object. JSON.

   *  *discovery*  *claims* - if the AS Request included a discovery attribute,
      then the AS MAY return a "user" claims object with the "discovered"
      property set to the JSON value true if one or more of the
      identifiers provided per Section 7.4.5 in the AS Request identify a User at the AS,
      or the JSON value false if not.  If the Client received a false
      return, it may Response JSON.

   [Editor: reference a security consideration parameters for this functionality.]

4.2.  "interaction" Object

   If the AS Client to request it wants the Grant
   Response signed and/or encrypted?]

5.6.  Refresh Authorization

   The Client updates an Authorization by doing an HTTP GET to start the interaction, the AS
   corresponding AuthZ URI.

   The GS MUST
   select respond with an Response JSON "authorization" object
   Section 7.4.3, or one of the interaction mechanisms provided by the following errors:

   *  TBD

   from Error Responses Section 9.

5.7.  Update Authorization

   The Client in updates an Authorization by doing an HTTP PUT to the AS Request, and include
   corresponding AuthZ URI of the matching attribute in following JSON.  All of the interaction
   object: following
   MUST be included.

   *  *type*  *iat* - this MUST match the type provided by the Client in time of the AS
      Request client.interaction object. response as a NumericDate.

   *  *uri* - the URI to interact with AuthZ URI.

   *  *authorization* - the User new authorization requested per the type.  This may
      be a temporary short URL if Request
      JSON "authorization" object Section 5.5.4.

   The GS MUST respond with an Response JSON "authorization" object
   Section 7.4.3, or one of the type is qrcode so that it is easy
      to scan. following errors:

   *  *message* - a text string to display  TBD

   from Error Responses Section 9.

5.8.  Delete Authorization

   The Client deletes an Authorization by doing an HTTP DELETE to the User if type is
      qrcode.

   [Editor: do we specify a maximum length
   corresponding AuthZ URI.

   The GS MUST respond with OK 200, or one of the following errors:

   *  TBD

   from Error Responses Section 9.

5.9.  GS Options

   The Client can get the metadata for the uri and message so
   that a device knows GS by doing an HTTP OPTIONS
   of the maximum it needs corresponding GS URI.  This is the only API where the GS MAY
   respond to support?  A smart device
   may have limited screen real estate.]

4.3.  "authorization" Object an unauthenticated request.

   The authorization object has GS MUST respond with the following attributes:

   *  *handle* - the authorization handle.  This attribute following JSON document:

   [Editor: this section is REQUIRED. a work in progress]

   *  *uri* - the authorization GS URI.  This attribute is REQUIRED.

   *  *wait*  *client_authentication* - the amount an array of time in integer seconds the Client MUST
      wait before making the Authorization Request.  This attribute is
      OPTIONAL.

4.4.  "authentication" Object

   Returned if the Client requested authentication first.  The
   authentication object has Authentication
      mechanisms supported by the following attributes: GS

   *  *handle*  *interactions* - an array of the authentication handle.  This attribute is REQUIRED. interaction types supported by
      the GS.

   *  *uri*  *authorization* - an object containing the authentication URI.  This attribute is REQUIRED.

5.  Interaction Types

   If the AS wants authorizations the
      Client to initiate the interaction with the User,
   then may request from the AS will return GS, if any.

      -  Details TBD

   *  *claims* - an interaction object Section 4.2 so that containing the identity claims the Client can can hand off interactions with may
      request from the User to GS, if any, and what public keys the AS.  The
   Client claims will initiate
      be signed with.

      -  Details TBD

   *  *algorithms* - a list of the interaction with cryptographic algorithms supported by
      the User in GS.

   *  *features* - an object containing feature support

      -  *user_exists* - boolean indicating if "user"."exists" is
         supported.

      -  *authorizations* - boolean indicating if a request for multiple
         authorizations is supported.

   [Editor: keys used by Client to encrypt requests, or verify signed
   responses?]

   [Editor: namespace metadata for extensions?]

   or one of the following ways:

5.1.  "popup" Type errors:

   *  TBD

   from Error Responses Section 9.

5.10.  Grant Options

   The Client will create a new popup child browser window containing can get the value of metadata for the uri attribute Grant by doing an HTTP
   OPTIONS of the interaction object.  [Editor:
   more details on how to do this] corresponding Grant URI.

   The AS will close GS MUST respond with the window when the interactions with following JSON document:

   *  *verbs* - an array of the User are
   complete.  [Editor: confirm AS can do this still on all browsers, HTTP verbs supported at the GS URI.

   or
   does Client need to close] one of the following errors:

   *  TBD

   from Error Responses Section 9.

5.11.  AuthZ Options

   The AS MAY respond to Client can get the metadata for the AuthZ by doing an outstanding Authorization Request
   Section 8.13 before HTTP
   OPTIONS of the popup window has been closed.

5.2.  "redirect" Type corresponding AuthZ URI.

   The Client will redirect GS MUST respond with the User to the value following JSON document:

   *  *verbs* - an array of the uri attribute HTTP verbs supported at the GS URI.

   or one of the interaction object.  When following errors:

   *  TBD

   from Error Responses Section 9.

5.12.  Request Verification

   On receipt of a request, the AS interactions with GS MUST verify the User following:

   *  TBD

6.  GS Initiated Grant

   [Editor: In OAuth 2.0, all flows are complete, initiated at the Client.  If the
   AS will redirect wanted to initiate a flow, it redirected to the User Client, that
   redirected back to the redirect_uri AS to initiate a flow.

   Here is a proposal to support GS initiated: authentication; just-in-
   time (JIT) provisioning; and authorization]

   *initiation_uri* A URI at the Client provided in that contains no query or
   fragment.  How the AS Request.

   If GS learns the Client made initiation_uri is out of
   scope.

   The GS creates a Authorization Request when starting the
   interaction, Grant and Grant URI, and redirects the AS MAY respond User to the Authorization Request
   Section 8.13 before
   initiation_uri with the User has been redirected back to query parameter "grant" and the Client.

5.3.  "qrcode" Type

   The Client will create a [QR_Code] value of
   Grant URI.

   See Section 3.3 for the uri attribute of sequence diagram.

7.  GS API Responses

7.1.  Grant Response

   The Grant Response MUST include the
   interaction object and display following from the resulting graphic Response JSON
   Section 7.4

   *  iat

   *  nonce

   *  uri

   *  expires_in

   and MAY include the message
   attribute of following from the interaction object as a text string.

6.  AS Response JSON Section 7.4

   *  authorization or authorizations

   *  claims

   *  reciprocal

   Example non-normative AS Grant Response JSON document for Example 1 in
   Section 3: 3.1:

   {
       "iat":"15790460234",
       "nonce":"f6a60810-3d07-41ac-81e7-b958c0dd21e4",
       "authorizations":
       "iat"           : 15790460234,
       "nonce"         : "f6a60810-3d07-41ac-81e7-b958c0dd21e4",
       "uri"           : "https://as.example/endpoint/grant/example1",
       "expires_in"    : 300
       "authorization": {
           "type"          : "oauth_scope",
           "scope"         : "read_contacts",
           "expires_in"    : "3600",
           "method" 3600,
           "mechanism"     : "bearer",
           "token"         : "eyJJ2D6.example.access.token.mZf9p"
       },
       "claims": {
           "oidc": {
               "id_token"      : "eyJhbUzI1N.example.id.token.YRw5DFdbW",
               "userinfo" : {
                   "name"      : "John Doe",
                   "picture"   : "https://photos.example/p/eyJzdkiO"
               }
           }
       }
   }

   Example non-normative AS Grant Response JSON document for Example 2 in
   Section 3: 3.1:

   {
       "iat"   :"15790460234",   : 15790460234,
       "nonce" :"0d1998d8-fbfa-4879-b942-85a88bff1f3b",
       "authorizations": : "5c9360a5-9065-4f7b-a330-5713909e06c6",
       "uri"   : "https://as.example/endpoint/grant/example2",
       "authorization": {
           "type"          : "oauth_scope",
           "scope"         : "read_calendar write_calendar",
           "expires_in"    : "3600",
           "method" 3600,
           "mechanism"     : "pop",
           "access": {
               "handle" "jose",
           "token"         : "ey.example.access.handle.9yf3szM",
               "jwk": "eyJJ2D6.example.access.token.mZf9p"
           "certificate": {
               "x5u"   : "https://as.example/jwk/VBUEOIQA82"
               } "https://as.example/cert/example2"
           },
           "refresh":
           "uri"       : "https://as.example/endpoint/authz/example2"
       }
   }

7.2.  Interaction Response

   The Interaction Response MUST include the following from the Response
   JSON Section 7.4
   *  iat

   *  nonce

   *  uri

   *  interaction

   and MAY include the following from the Response JSON Section 7.4

   *  user

   *  wait

   A non-normative example of an Interaction Response follows:

   {
       "iat"       : 15790460234,
       "nonce"     : "0d1998d8-fbfa-4879-b942-85a88bff1f3b",
       "uri"       : "https://as.example/endpoint/grant/example4",
       "interaction" : {
               "handle"
           "type"      : "ey.example.refresh.handle.Jl4FzM", "popup",
           "uri"       : "https://as.example/refresh/eyj34" "https://as.example/popup/example4"
       },
       "user": {
           "exists" : true
       }
   }

7.3.  Wait Response

   The Wait Response MUST include the following from the Response JSON
   Section 7.4

   *  iat

   *  nonce

   *  uri

   *  wait

   A non-normative example of an Wait Response follows:

   {
       "iat"       : 15790460234,
       "nonce"     : "0d1998d8-fbfa-4879-b942-85a88bff1f3b",
       "uri"       : "https://as.example/endpoint/grant/example5",
       "wait"      : 300
   }

7.4.  Response JSON

   Details of the JSON document:

6.1.  Top Level Attributes

   *  *iat* - the time of the response as a NumericDate.

   *  *nonce* - the nonce that was included in the AS Request JSON
      Section 3.

6.2.  "authorizations" Object

   There 5.5.

   *  *uri* - the Grant URI.

   *  *wait* - a numeric value representing the number of seconds the
      Client should want before making a Read Grant request to the Grant
      URI.

   *  *expires_in* - a numeric value specifying how many seconds until
      the Grant expires.  This attribute is an authorizations object OPTIONAL.

7.4.1.  "interaction" Object

   If the GS wants the Client to start the interaction, the GS MUST
   select one of the interaction mechanisms provided by the Client in
   the AS Response if there was an
   authorizations object Grant Request, and include the matching attribute in the AS Request.
   interaction object:

   *  *type* - this MUST match the type of claim request: "oauth_scope", "oauth_rich",
      or "oauth_rich_list".  See Section 3.7 for details. provided by the Client in the
      Grant Request client.interaction object.

   *  *list*  *uri* - an array of objects the URI to interact with the User per the type.  This may
      be a temporary short URL if the type was "oauth_rich_list".
      The objects have is qrcode so that it is easy
      to scan.

   *  *message* - a text string to display to the following attributes just as User if type is
      qrcode.

   [Editor: do we specify a maximum length for the uri and message so
   that a device knows the maximum it needs to support?  A smart device
   may have limited screen real estate.]

7.4.2.  "user" Object
   *  *exists* - a boolean value indicating if the GS has a user with
      one or more of the provided identifiers in the Request
      "user"."identifiers" object Section 5.5.3

7.4.3.  "authorization" Object

   The "authorization" object is a response to the Request
   "authorization" object Section 5.5.4, the Refresh Authorization
   Section 5.6, or the Update Authorization Section 5.7.

   *  *type* - the type was
      "oauth_rich" of claim request: "oauth_scope" or "oauth_rich".
      See the "type" object in Section 5.5.4 for details.

   *  *scope* - the scopes the Client was granted authorization for.
      This will be all, or a subset, of what was requested.  This
      attribute is OPTIONAL.

   *  *authorization_details* - the authorization details granted.  Only
      returned for "oauth_rich" and "oauth_rich_list". granted per
      [RAR].  Included if type is "oauth_rich".

   *  *method*  *mechanism* - one of the access method: mechanisms: "bearer", "pop", "jose", or "jws".
      "jose+body".  See Section 6.4 8 for details.

   *  *token* - an the access token for accessing the resource(s).  Included
      if the access method an RS.  This attribute is "bearer".
      REQUIRED.

   *  *expires_in* - an optional a numeric value specifying how many seconds until
      the access token or handle expire. expires.  This attribute is OPTIONAL.

   *  *refresh* - an optional object containing parameters required to
      refresh an access token or handle.  See refresh request
      Section 8.18.

      -  *handle*  *certificate* - an refresh handle used to create MUST be included if the JSON refresh
         token.

      -  *uri* - mechanism is "jose" or
      "jose+body".  Contains the refresh uri jwk header values for the Client will use to refresh.
      include in the JWS header when calling the RS using the "jose" or
      "jose+body" mechanisms.  See Section 10.2.1.

   *  *access*  *uri* - an object containing the parameters needed AuthZ URI.  Used to access
      resources requiring proof-of-possession.  Included if refresh, update, and delete the access
      method
      authorization.  This attribute is "pop".

      -  *handle* - OPTIONAL.

   [Editor: any value in an expiry for the access handle.

      -  *jwk* - Authorization?]

7.4.4.  "authorizations" Object

   A JSON array of authorization objects.  Support for the jwk
   authorizations object to use.

6.3. is OPTIONAL.

7.4.5.  "claims" Object

   There is a

   The claims object in the AS Response if there was is a claims
   object in response to the AS Request. Request "claims" object
   Section 5.5.4.

   *  *oidc*

      -  *id_token* - an OpenID Connect ID Token containing the Claims
         the User consented to be released.

      -  *userinfo* - the Claims the User consented to be released.

      Claims are defined in [OIDC] Section 5.

   *  *oidc4ia* - OpenID Connect for Identity Assurance claims response
      per [OIDC4IA].

   *  *vc*

      The verified claims the user consented to be released.  [Editor:
      details TBD]

6.4.  Access Methods

7.4.6.  "reciprocal" Object

   The are three different methods for the Client to access an RS: following MUST be included

   *  *bearer*  *nonce* - the AS provides a bearer access token that unique identifier for this request.  Note the Client
      can use to access an RS per Section 8.15. Grant
      Response MUST contain a matching nonce attribute value.

   *  *pop*  *client*

      -  *id* - the AS provides an access handle that the Client presents
      in a proof-of-possession RS access ID making the request per

   One or more of the following objects from the Request JSON
   Section 8.16. 5.5 are included:

   *  *pop_body* -  *authorization* Section 7.4.3

   *  *authorizations* Section 7.4.4

   *  *claims* Section 7.4.5

7.4.7.  Interaction Types

   If the Client signs GS wants the JSON payload sent Client to initiate the RS per
      Section 8.17.

   In interaction with the AS Response, User,
   then the AS GS will return an Interaction Response.  The Client will
   initiate the method interaction with the User in one of the following ways:

   *  *popup* The Client MUST use will create a new popup child browser window
      containing the "interaction"."uri" attribute.  [Editor: more
      details on how to do this]

   The GS will close the popup window when accessing the RS.

7.  Discovery interactions with the
   User are complete.  [Editor: confirm GS can do this still on all
   browsers, or does Client need to close]

   *  *redirect* The Client obtains the following metadata about will redirect the AS prior User to
   initiating a request:

   *Endpoint* - the endpoint of
      "interaction"."uri" attribute.  When the AS.

   *"as"* - GS interactions with the unique string identifier for
      User are complete, the AS.

   *Algorithms* - GS will redirect the asymetric cryptographic algorithms supported by User to the AS.

   *Authorizations* -
      "interaction"."redirect_uri" attribute the authorizations Client provided in the
      Grant Request.

   *  *qrcode* The Client may request, if any.

   *Identity Claims* - will create a [QR_Code] of the identity claims
      "interaction"."uri" attribute and display the Client may request, if
   any, resulting graphic
      and what public keys the claims will be signed with.

   The client may also obtain information about how "interaction"."message" attribute as a character string.

   An GS MUST support the AS will sign "popup", "redirect", and "qrcode" interaction
   types.

7.4.8.  Signing and Encryption

   [Editor: TBD - how response is signed and/or encrypt encrypted by the AS Response, as well as any other metadata
   required GS.  Is
   there a generalized description, or is it mechanism specific?]

7.5.  Response Verification

   On receipt of a response, the Client MUST verify the following:

   *  TBD

8.  RS Access

   This document specifies three different mechanisms for extensions the Client to this protocol, as
   access an RS ("bearer", "jose", and "jose+body").  The "bearer"
   mechanism is defined in those
   extension specifications.

8.  JOSE Client Authentication {BearerToken}. The "jose" and "jose+body"
   mechanisms are proof-of-possession mechanisms and are defined in
   Section 10.2.2 and Section 10.2.3 respectively.  Additional proof-of-
   possession mechanisms may be defined in other documents.  The default
   mechanism for the Client is to authenticate to the AS and
   the use with an RS is signing a the Response JSON document with JWS per [RFC7515].  The
   resulting tokens always use compact serialization.

   It
   "authorization"."mechanism" attribute Section 7.4.3.

8.1.  Bearer Token

   If the access mechanism is expected that extensions "bearer", then the Client accesses the RS
   per Section 2.1 of [RFC6750]

   A non-normative example of the HTTP request headers follows:

   GET /calendar HTTP/2
   Host: calendar.example
   Authorization: bearer eyJJ2D6.example.access.token.mZf9pTSpA

9.  Error Responses

   *  TBD

10.  JOSE Authentication

   How the Client authenticates to this protocol that specify the GS and RS are independent of each
   other.  One mechanism can be used to authenticate to the GS, and a
   different mechanism for to authenticate to the RS.

   Other documents that specify other Client to authenticate, would over ride authentication mechanisms
   will replace this section.

   The Authorization Request JSON is signed with JWS and passed as

   In the
   body of JOSE Authentication Mechanism, the POST.

   The authorization, refresh, and access handles are signed Client authenticates by
   using its private key to sign a JSON document with JWS
   resulting per [RFC7515]
   which results in authorization request, refresh, and access tokens
   respectively.  These a token using JOSE tokens compact serialization.

   [Editor: are passed there advantages to using JSON serialization in the HTTP Authorization
   header with
   body?]

   Different instances of a Registered Clients MAY have different
   private keys, but certificates bind them to a public key the GS has
   for the "JOSE" parameter per Section 8.6.

   The Client ID.  An instance of a Client will use the same private
   key to create for all tokens. signing.

   The Client and the AS GS MUST both use HTTP/2 ([RFC7540]) or later, and
   TLS 1.3 ([RFC8446]) or later, when communicating with each other.

   [Editor: too aggressive to mandate HTTP/2 and TLS 1.3?]

8.1.  JOSE Headers

   A non-normative example of a JOSE header for a Registered Client
   using a key id to identify the Client's public key:

   {
       "alg":"ES256",
       "typ":"JOSE",
       "kid":"1"
   }

   A non-normative example of a JOSE header for a Registered Client
   using a certificate to assert the Client's public key:

   {
       "alg":"ES256",
       "typ":"JOSE",
       "jwk":
           {"kty":"RSA",
           "use":"sig",
           "kid":"1b94c",
           "n":"vrjOfz9Ccdgx5nQudyhdoR17V-IubWMeOZCwX_jj0hgAsz2J_pqYW08
           PLbK_PdiVGKPrqzmDIsLI7sA25VEnHU1uCLNwBuUiCO11_-7dYbsr4iJmG0Q
           u2j8DsVyT1azpJC_NG84Ty5KKthuCaPod7iI7w0LK9orSMhBEwwZDCxTWq4a
           YWAchc8t-emd9qOvWtVMDC2BXksRngh6X5bUYLy6AyHKvj-nUy1wgzjYQDwH
           MTplCoLtU-o-8SNnZ1tmRoGE9uJkBLdh5gFENabWnU5m1ZqZPdwS-qo-meMv
           VfJb6jJVWRpl2SUtCnYG2C32qvbWbjZ_jBPD5eunqsIo1vQ",
           "e":"AQAB",
           "x5c":
           ["MIIDQjCCAiqgAwIBAgIGATz/FuLiMA0GCSqGSIb3DQEBBQUAMGIxCzAJB
           gNVBAYTAlVTMQswCQYDVQQIEwJDTzEPMA0GA1UEBxMGRGVudmVyMRwwGgYD
           VQQKExNQaW5nIElkZW50aXR5IENvcnAuMRcwFQYDVQQDEw5CcmlhbiBDYW1
           wYmVsbDAeFw0xMzAyMjEyMzI5MTVaFw0xODA4MTQyMjI5MTVaMGIxCzAJBg
           NVBAYTAlVTMQswCQYDVQQIEwJDTzEPMA0GA1UEBxMGRGVudmVyMRwwGgYDV
           QQKExNQaW5nIElkZW50aXR5IENvcnAuMRcwFQYDVQQDEw5CcmlhbiBDYW1w
           YmVsbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL64zn8/QnH
           YMeZ0LncoXaEde1fiLm1jHjmQsF/449IYALM9if6amFtPDy2yvz3YlRij66
           s5gyLCyO7ANuVRJx1NbgizcAblIgjtdf/u3WG7K+IiZhtELto/A7Fck9Ws6
           SQvzRvOE8uSirYbgmj6He4iO8NCyvaK0jIQRMMGQwsU1quGmFgHIXPLfnpn
           fajr1rVTAwtgV5LEZ4Iel+W1GC8ugMhyr4/p1MtcIM42EA8BzE6ZQqC7VPq
           PvEjZ2dbZkaBhPbiZAS3YeYBRDWm1p1OZtWamT3cEvqqPpnjL1XyW+oyVVk
           aZdklLQp2Btgt9qr21m42f4wTw+Xrp6rCKNb0CAwEAATANBgkqhkiG9w0BA
           QUFAAOCAQEAh8zGlfSlcI0o3rYDPBB07aXNswb4ECNIKG0CETTUxmXl9KUL
           +9gGlqCz5iWLOgWsnrcKcY0vXPG9J1r9AqBNTqNgHq2G03X09266X5CpOe1
           zFo+Owb1zxtp3PehFdfQJ610CDLEaS9V9Rqp17hCyybEpOGVwe8fnk+fbEL
           2Bo3UPGrpsHzUoaGpDftmWssZkhpBJKVMJyf/RuP2SmmaIzmnw9JiSlYhzo
           4tpzd5rFXhjRbg4zW9C+2qok+2+qDM1iJ684gPHMIY8aLWrdgQTxkumGmTq
           gawR+N5MDtdPTEQ0XfIBc2cJEUyMTY5MPvACWpkA6SdS4xSvdXK3IVfOWA=="]
           }
   }

   [Editor: the jwk above was copy and pasted from the JWK example.
   Replace? ]

   The certificate could token may be signed by the AS, allowing the AS to verify
   the signature using the AS public key, included in an HTTP header, or as the certificate could be
   signed by a private key the AS has bound to the Registered Client,
   allowing each instance of the Registered Client to have its own
   asymetric key pair.

   A non-normative example of a JOSE header for a Dynamic Client
   including the public key generated by the Client that matches its its
   private key:

   {
       "alg":"ES256",
       "typ":"JOSE",
       "jwk":{
           "kty":"EC",
           "crv":"P-256",
           "x":"Kgl5DJSgLyV-G32osmLhFKxJ97FoMW0dZVEqDG-Cwo4",
           "y":"GsL4mOM4x2e6iON8BHvRDQ6AgXAPnw0m0SfdlREV7i4"
       }
   }

   A non-normative example of a JOSE header for a JOSE access token for
   a Client accessing an RS that requires proof-of-possession:

   {
       "alg":"ES256",
       "typ":"JOSE",
       "jwk":{
           "x5u":"https://as.example/jwk/VBUEOIQA82"
       }
   } HTTP message
   body.

   The "jwk" object in a JOSE access token Section 8.5 MUST be the AS
   jwk object the AS provided with the access handle.

   This decouples how the AS communicates the Client's public key to the
   RS from following sections specify how the AS asserts the Client's public key.  The RS can have
   a consistent mechanism assert the Client's public key across all
   Clients.

   One advantage of this is the AS can create a certificate of a Dynamic
   Client's public key, and pass it by value or reference to the Client uses JOSE to present
   authenticate to the GS and RS.

   All JOSE headers MUST have: + the "alg" attribute. + the "typ"
   attribute set

10.1.  GS Access

   The Client authenticates to "jose". + the GS by passing either a "kid" or "jwk" attribute.

   [Editor: should we use indicate the type of token (authorization,
   refresh, access) using "typ" signed header
   parameter, or "cty"?]

8.2.  Authentication Request Token

   A non-normative example of a payload follows:

   {
       "as"    :"https://as.example",
       "type"  :"authentication",
       "iat"   :"1579046092",
       "jti"   :"f6d72254-4f23-417f-b55e-14ad323b1dc1",
       "handle":"eyJhb958.example.authentication.handle.9yf3szM"
   } signed message body.  The payload of the authentication token contains:

   *as* - the unique string identifier for the AS.

   *type* - the string "authentication", indicating the type of token.

   *iat* - the time following table shows the authentication
   verb, uri and token was created as a
   NumericDate.

   *jti* - a unique identifier location for each Client request to the authentication GS:

           +---------------+-----------+-----------+----------+
           | request       | http verb | uri       | token per
   [RFC7519] section 4.1.7.

   *handle* the authentication handle the AS provided the Client in the
   Interaction Response Section 4.

8.3. |
           +===============+===========+===========+==========+
           | Create Grant  | POST      | GS URI    | body     |
           +---------------+-----------+-----------+----------+
           | Read Grant    | GET       | Grant URI | header   |
           +---------------+-----------+-----------+----------+
           | Update Grant  | PUT       | Grant URI | body     |
           +---------------+-----------+-----------+----------+
           | Delete Grant  | DELETE    | Grant URI | success  |
           +---------------+-----------+-----------+----------+
           | Refresh AuthZ | GET       | AuthZ URI | body     |
           +---------------+-----------+-----------+----------+
           | Update AuthZ  | PUT       | AuthZ URI | body     |
           +---------------+-----------+-----------+----------+
           | Delete AuthZ  | DELETE    | AuthZ URI | header   |
           +---------------+-----------+-----------+----------+
           | GS Options    | OPTIONS   | GS URI    | header   |
           +---------------+-----------+-----------+----------+
           | Grant Options | OPTIONS   | Grant URI | header   |
           +---------------+-----------+-----------+----------+
           | AuthZ Options | OPTIONS   | AuthZ URI | header   |
           +---------------+-----------+-----------+----------+

                                 Table 2

10.1.1.  Authorization Request Token

   A non-normative example of a payload follows:

   {
       "as"    :"https://as.example",
       "type"  :"authorization",
       "iat"   :"1579046092",
       "jti"   :"f6d72254-4f23-417f-b55e-14ad323b1dc1",
       "handle":"eyJhb958.example.authorization.handle.9yf3szM"
   }

   The payload of Header

   For requests with the authorization token contains:

   *as* - the unique string identifier for in the AS.

   *type* - header, the string "authorization", indicating JWS payload MUST
   contain the type of token. following attributes:

   *iat* - the time the authorization token was created as a NumericDate.

   *jti* - a unique identifier for the authorization token per [RFC7519] section
   4.1.7.

   *handle* the authorization handle the AS provided the Client in the
   Interaction Response Section 4.

8.4.  Refresh Token

   A non-normative example of a payload follows:

   {
       "as"    :"https://as.example",
       "type"  :"refresh",
       "iat"   :"1579049876",
       "jti"   :"4342046d-83c4-4725-8c72-e9a49245f791",
       "handle":"eyJhb958.example.refresh.handle.9yf3szM"
   }

   The payload of the authorization token contains:

   *as* - the unique string identifier for the AS.

   *type*

   *uri* - the string "refresh", indicating the type value of token.

   *iat* - the time the refresh request token was created as a
   NumericDate.

   *jti* URI being called (GS URI, Grant URI, or
   AuthZ URI).

   *verb* - a unique identifier for the refresh request token.

   *handle* the refresh handle the AS provided the Client HTTP verb being used in the AS
   Response Section 6 or access refresh response Section 8.18.

8.5.  JOSE Access Token call ("GET", "DELETE",
   "OPTIONS")

   The "jwk" object in a JOSE access token HTTP authorization header MUST be is set to the
   "jwk" value the AS provided for "jose" parameter followed
   by one or more white space characters, followed by the access handle. resulting
   token.

   A non-normative example of a JWS payload and the HTTP request
   follows:

   {
       "type"  :"access",
       "iat"   :"1579046092",   : 15790460234,
       "jti"   :"5ef47057-08f9-4763-be8d-162824d43dfb",
       "handle":"eyJhb958.example.access.handle.9yf3szM"   : "f6d72254-4f23-417f-b55e-14ad323b1dc1",
       "uri"   : "https://as.example/endpoint/grant/example6",
       "verb"  : "GET"
   }

   GET /endpoint/example.grant HTTP/2
   Host: as.example
   Authorization: jose eyJhbGciOiJIUzI1NiIsIn ...

   [Editor: make a real example token]

   *GS Verification*

   The payload of GS MUST verify the JOSE access token contains:

   *type* - the string "access", indicating the type of token.

   *iat* - the time by:

   *  TBD

10.1.2.  Signed Body

   For requests with the JOSE access token was created as a NumericDate.

   *jti* - a unique identifier for the JOSE access token.

   *handle* the access handle in the AS provided body, the Client in uses the AS
   Response Section 6 or access refresh response Section 8.18.

   [Editor: should we include Request
   JSON as the called URI payload in the token?]

8.6.  HTTP Authorization JOSE Header a JWS.  The Client authenticates requests by setting resulting token is sent with the HTTP Authorization
   header
   content-type set to include the "JOSE" parameter, followed by one or more space
   characters, followed by the appropriate JOSE token. "application/jose".

   A non-normative example:

   Authorization: JOSE eyJhb.example.authorization.token.haDwskpFDBW example (line breaks added to the body for
   readability):

   POST /endpoint HTTP/2
   Host: as.example
   Content-Type: application/jose
   Content-Length: 155

   eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyzdWIiOiIxMjM0NTY3ODkwIiwibmF
   tZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMe
   Jf36POk6yJV_adQssw5c

   [Editor: make a real example token]

   *GS Verification*

   The authorization request token, refresh request token, and GS MUST verify the JOSE
   access token are all passed in this manner.

8.7.  JOSE Token Verification by:

   *  TBD

8.8.  AS Request

   The Client creates a JSON document per Section 3, signs it using JWS
   [RFC7515], and sends

10.1.3.  Public Key Resolution
   *  *Registered Clients* can use any of the JWS token header values to
      direct the AS end point using HTTP
   POST, with a content-type of application/jose.

   *  *Payload Encryption*

   The AS may require the AS Request GS to be encrypted.  If so, the JWS
   token is encrypted per JWE [RFC7516] using resolve the public key and
   algorithm specified by the AS.

8.9.  Interaction Response

   If the Client set the authenticate_first flag, the response includes
   an authentication object, otherwise it includes an authorization
   object.  If the AS wants matching the Client private key
      used to initiate the User interaction,
   it sends an interaction object.

   If no interaction is required the AS will return an AS Response per
   Section 8.14, otherwise the AS will return an Interaction Response
   per Section 4.

   If the AS wants the Client to start the interaction, an interaction
   object will be returned in the response.

   *  *Error Responses* ID.  The AS GS MAY respond restrict with one of the following errors defined in
   Section 9:

   TBD

8.10.  Deletion Request

   The JWS headers a
      Client MAY delete an outstanding request using can use.

   [Editor: would examples help here so that implementors understand the authorization
   token by making
   full range of options, and how an HTTP DELETE call to the authorization uri, setting
   the HTTP Authorization instance can have its own asymetric
   key pair]

   A non-normative example of a JOSE header per Section 8.6 for a Registered Client with
   a key identifier of "12":

   {
       "alg"   : "ES256",
       "typ"   : "JOSE",
       "kid"   : "12"
   }

   *  *Dynamic Clients* include their public key in the authorization
   request token. "jwk" JWS
      header.

   A non-normative deletion request example:

   DELETE /authorization/ey7snHGs HTTP/2
   Host: as.example
   Authorization: JOSE eyJhb.example.authorization.token.haDwskpFDBW

   *  *Error Responses*

   The AS MAY respond with one example of a JOSE header for a Dynamic Client:

   {
       "alg"   : "ES256",
       "typ"   : "JOSE",
       "jwk"   : {
           "kty"   : "EC",
           "crv"   : "P-256",
           "x"     : "Kgl5DJSgLyV-G32osmLhFKxJ97FoMW0dZVEqDG-Cwo4",
           "y"     : "GsL4mOM4x2e6iON8BHvRDQ6AgXAPnw0m0SfdlREV7i4"
       }
   }

10.2.  RS Access

   In the following errors defined in
   Section 9:

   TBD

8.11.  Authentication Request "jose" mechanism Section 8.2

8.12.  Authentication Response

8.13.  Authorization Request

   The 10.2.2, all Client makes an HTTP GET call requests to the authorization uri, setting RS
   include a proof-of-possession token in the HTTP Authorization header per authorization header.
   In the "jose+body" mechanism Section 8.6 with 10.2.3, the Client signs the
   JSON document in the authorization request token.

   A non-normative Authorization Request example:

   GET /authorization/ey7snHGs HTTP/2
   Host: as.example
   Authorization: if the POST or PUT verbs are used,
   otherwise it is the same as the "jose" mechanism.

10.2.1.  JOSE eyJhb.example.authorization.token.haDwskpFDBW

8.14.  AS Response header

   The AS verifies GS provides the authorization request token, Client one or more JWS header parameters and then provides
   values for a
   response according to what the User and/or RO have authorized if
   required.  If no signature a certificate, or encryption was required, the AS will
   respond with a JSON document with content-type set reference to application/
   json.

   *  *Response Signing*

   The AS MAY sign the response with a JWS per [RFC7515] and certificate or
   certificate chain, that the private
   key matching RS can use to resolve the public key
   matching the AS defined as its AS Response signing
   key.  The AS will respond with the content-type set to application/
   jose.

   *  *Response Encryption*

   The AS MAY encrypt the response using the public private key provided being used by the
   Client, using JWE per [RFC7516].  The AS will respond with the
   content-type set Client.

   A non-normative examples JOSE header:

   {
       "alg"   : "ES256",
       "typ"   : "JOSE",
       "x5u"   : "https://as.example/cert/example2"
   }

   [Editor: this enables Dynamic Clients to application/jose.

   *  *Error Responses* make proof-of-possession API
   calls the same as Registered Clients.]

10.2.2.  "jose" Mechanism

   The AS MAY respond with one of JWS payload MUST contain the following errors defined in
   Section 9:

   TBD

8.15.  Bearer Token RS Access

   If attributes:

   *iat* - the access method in time the AS Response authorizations object
   Section 6.2 token was "bearer", then the Client accesses created as a NumericDate.

   *jti* - a unique identifier for the RS token per
   Section 2.1 of [RFC6750]

   A non-normative example [RFC7519] section
   4.1.7.

   *uri* - the value of the HTTP request headers follows:

   GET /calendar HTTP/2
   Host: calendar.example
   Authorization: bearer eyJJ2D6.example.access.token.mZf9pTSpA

   *  *Error Responses*

   TBD

8.16.  Proof-of-possession RS Access

   If URI being called.

   *verb* - the access method HTTP verb being used in the AS Response authorizations object
   Section 6.2 was "pop", then call

   *token* - the Client creates a JOSE access token
   per Section 8.5 for each call to provided by the RS, setting GS to the Client

   The HTTP
   Authorization authorization header per Section 8.6 with is set to the JOSE access "jose" parameter followed
   by one or more white space characters, followed by the resulting
   token.

   A non-normative example of a JWS payload and the HTTP request headers
   follows:

   {
       "iat"   : 15790460234,
       "jti"   : "f6d72254-4f23-417f-b55e-14ad323b1dc1",
       "uri"   : "https://calendar.example/calendar",
       "verb"  : "GET",
       "token" : "eyJJ2D6.example.access.token.mZf9pTSpA"
   }

   GET /calendar HTTP/2
   Host: calendar.example
   Authorization: JOSE eyJhbG.example.JOSE.access.token.kwwQb958

   *  *Error Responses*

   TBD

8.17.  JOSE Body jose eyJhbG.example.jose.token.adks

   [Editor: make a real example token]

   *RS Verification*
   The RS Access

   If the access method in the AS Response authorizations object
   Section 6.2 was "pop_body", then MUST verify the Client creates a JOSE token by:

   *  verify access token per Section 8.5 for each call is bound to the RS, setting the HTTP
   Authorization header per Section 8.6 with the JOSE access token.

   The Client creates a JSON document per the RS requirements.  The
   document MUST public key - include the key
      fingerprint in access handle. token?

   *  TBD

10.2.3.  "jose+body" Mechanism

   The CLient then signs the
   document using JWS [RFC7515], and sends "jose+body" mechanism can only be used if the resulting compact
   notation JWS token content being sent
   to the RS end point using HTTP POST, with a
   content-type of application/jose.  Note this is similar to a JSON document.

   Any requests not sending a message body will use the AS
   Request "jose" mechanism
   Section 8.8.

   [Editor: any isues here?  Anything missing that 10.2.2.

   Requests sending a message body MUST be in the
   payload?  Would an HTTP Authorization header make sense?]

8.18.  Access Refresh

   If have the Client received a refresh handle and uri from following JWS payload:

   *iat* - the AS in time the
   Interaction Response, and it wants a fresh access token or handle, it
   creates was created as a refresh request NumericDate.

   *jti* - a unique identifier for the token per Section 8.4.  setting [RFC7519] section
   4.1.7.

   *uri* - the value of the RS URI being called.

   *verb* - the HTTP
   Authorization header per Section 8.6 with verb being used in the refresh request token.
   The AS will then respond with a refresh response.

   *  *Refresh Response* call

   *token* - the access token provided by the GS to the Client

   *body* - the message body being sent to the RS

   A non-normative example refresh response with an access handle: of a JWS payload and the HTTP request
   follows:

   {
       "type"
       "iat"   : "oauth_scope",
       "scope" 15790460234,
       "jti"   : "read_calendar write_calendar",
       "expires_in" "f6d72254-4f23-417f-b55e-14ad323b1dc1",
       "uri"   : "3600",
       "method" "https://calendar.example/calendar",
       "verb"  : "pop",
       "access": {
           "handle" "POST",
       "token" : "eyJJ2D6.example.access.token.mZf9pTSpA",
       "payload" : "ey.example.access.handle.9yf3iWszM",
           "jwk": {
               "x5u"
           "event" : "https://as.example/jwk/VBUEOIQA82"
           }
       },
       "refresh": {
           "handle"
               "title"             : "ey.example.refresh.handle.4SkjIi",
           "uri" "meeting with joe",
               "start_date_utc"    : "2020-02-21 11:00:00",
               "end_date_utc"      : "https://as.example/refresh/eyJl4FzM" "2020-02-21 11:00:00"
           }
       }

   The refresh response is the same as the authorizations object
   Section 6.2 in the AS Response.

   If a new refresh handle and/or refresh uri is returned, the Client
   MUST use the new refresh handle and/or refresh uri

   [Editor: are there other results relevant for [RAR]?]

   *  *Error Responses*

   The AS MAY respond with one of the following errors defined in
   Section 9:

   TBD

9.  Error Messages
   }

   POST /calendar HTTP/2
   Host: calendar.example
   Content-Type: application/jose
   Content-Length: 155

   eyJhbGciOi.example.jose+body.adasdQssw5c

   [Editor: return "wait" time in AS Response when AS wants Client to
   wait before retying make a Authorization Request. real example token]

   *RS Verification*

   The Client RS MUST
   generate a fresh authorization token when retrying the Authorization
   Request. ]

   TBD

10.  AS Initiated Sequence

   [Editor: AS initiated flows have been challenging to implement as
   OAuth 2.0 did not directly support them, so deployments bounced back
   and forth between the Client and AS to create a Client initiated
   flow.  Here is a proposal to support AS initiated: authentication;
   just-in-time (JIT) provisioning; and authorization]
   In this sequence the User starts at the AS, and then based on User
   input, the AS redirects verify the User to a Client, passing an initiation token Section 10.1, and then the Client retrieves authorizations and/
   or identity claims about the User. by:

   *  TBD

10.2.4.  Public Key Resolution

   The Client MUST be RS has a Registered
   Client.  The sequence follows:

   1.  The User is interacting at public key for the AS and wants GS that it uses to use the Client,
       and provide the Client identity claims and/or authorizations from verify the AS that
   certificate or certificate chain the Client has pre-configured.

   2.  The AS creates a authorization handle and uri representing includes in the
       identity claims and authorizations JWS
   header.

10.3.  Request Encryption

   [Editor: to be provided to the Client. fleshed out]

   The AS creates an initiation token containing the AS identifier,
       the authorization handle, and the authorization uri.

   3.  The AS redirects the User to a URI the Client has configured to
       accept initiation tokens, passing the initiation token as encrypts a query
       parameters with request when ??? using the name "token".

   4.  The Client verifies GS public key
   returned as the initiation token.

   5.  The Client makes an Authorization Request per ??? attribute in GS Options Section 8.13.

   6.  The AS responds with an AS 5.9.

10.4.  Response JSON document Section 6 per
       Section 8.14. Signing

   [Editor: to be fleshed out]
   The Client now has the User identity claims and/or authorizations.
   If Client policy permits, verifies a signed response ??? using the Client can perform JIT provisioning if GS public key
   returned as the User is new ??? attribute in GS Options Section 5.9.

10.5.  Response Encryption

   [Editor: to the Client.

   *AS Initiated Sequence Diagram*

   +--------+              +-------------+             +---------------+
   |        |              |             |             |               |
   |        |              |    User     |-------(1)-->|               |
   |        |              |             |             |               |
   |        |              +-------------+             |  (2)          |
   |        |                    /\                    |               |
   | be fleshed out]

   The Client |<--- initiation ---/  \-------------(3)---| Authorization |
   |        |         token                            |    Server     |
   |    (4) |                                          |               |
   |        |                                          |               |
   |        |--(5)------- Authorization Request ------>|               |
   |        |                                          |               |
   |        |<-(6)------- AS Response -----------------|               |
   |        |                                          |               |
   +--------+                                          +---------------+

10.1.  Initiation Token

   A non-normative example of an initiation token payload follows:

   {
       "as": "https://as.example",
       "authorization": {
           "handle" : "eyJhb958.example.authorization.handle.9yf3szM",
           "uri"    : "https://as.example/authorization/ey7snHGs"
       }
   }

   *  *as* - the "as" identifier for the AS.  This attribute is
      REQUIRED.

   *  *authorization* - decrypts a response when ??? using the authorization object has private key
   matching the following
      attributes:

      -  *handle* - public key included in the authorization handle.  This attribute is
         REQUIRED.

      -  *uri* - request as the authorization URI.  This ??? attribute is REQUIRED.

   The initiation token is signed with JWS and uses the compact
   serialization.
   in Section 5.5.

11.  Extensibility

   This standard can be extended in a number of areas:

   *  *Client Authentication Mechanisms*

      -  An extension could define other mechanisms for the Client to
         authenticate and replace JOSE in Section 8 with to the GS and/or RS such as Mutual TLS or HTTP
         Signing.  Constrained environments could use CBOR [RFC7049]
         instead of JSON, and COSE [RFC8152] instead of JOSE, and CoAP
         [RFC8323] instead of HTTP/2.

   *  *AS Request*  *Grant*

      -  An additional top extension can define new objects in the Grant Request and
         Grant Response JSON.

   *  *Top Level*

      -  Top level object could objects SHOULD only be added defined to the AS Request
   payload if the AS can manage delegations other than authorizations or
   claims, or some represent
         functionality other functionality. the existing top level objects and
         attributes.

   *  *"client" Object*

      -  Additional information about the Client that the AS GS would
         require related to an extension.

   *  *"user" Object*

      -  Additional information about the Client User that the AS GS would require
         related to an extension.

   *  *"authorizations"  *"authorization" Object*

      -  Additional types of authorizations in addition to OAuth 2.0
         scopes and RAR.

   *  *"claims" Object*

      -  Additional types of identity claims in addition to OpenID
         Connect claims and Verified Credentials.

   *  *Interaction*  *Interaction types*

      -  Additional mechanisms for the types of interactions a Client to can start an interaction with the
         User.

   *  *Access Methods*

   Additional mechanisms for the Client to present authorization to a
   resource.

   *  *Continuous Authentication*

      -  An extension could define a new handle mechanism for the Client to use to
         regularly provide continuous authentication signals and receive
         responses.

   [Editor: do we specify access token / handle introspection in this
   document, or leave that to an extension?]

   [Editor: do we specify access token / handle revocation in this
   document, or leave that to an extension?]

12.  Rational

   1.   *Why is there only one mechanism for the Client to authenticate
        with the AS? GS?  Why not support other mechanisms?*

        Having choices requires implementers to understand which choice
        is preferable for them.  Having one default mechanism in the
        document for the Client to authenticate simplifies most
        implementations.  Extensions  Deployments that have unique characteristics
        can specify select other mechanisms that are preferable in specific
        environments.

   2.   *Why is the default Client authentication JOSE rather than
        MTLS?*

        MTLS cannot be used today by a Dynamic Client.  MTLS requires
        the application to have access below what is typically the
        application layer, that is often not available on some
        platforms.  JOSE is done at the application layer.  Many AS GS
        deployments will be an application behind a proxy performing
        TLS, and there are risks in the proxy passing on the results of
        MTLS.

   3.   *Why is the default Client authentication JOSE rather than HTTP
        signing?*
        There is currently no widely deployed open standard for HTTP
        signing.  Additionally, HTTP signing requires passing all the
        relevant parts of the HTTP request to downstream services within
        an AS GS that may need to independently verify the Client identity.

   4.   *What are the advantages of using JOSE for the Client to
        authenticate to the AS GS and a resource?*

        Both Registered Clients and Dynamic Clients can have a private
        key, eliminating the public Client issues in OAuth 2.0, as a
        Dynamic Client can create an ephemeral key pair.  Using
        asymetric cryptography also allows each instance of a Registered
        Client to have its own private key if it can obtain a
        certificate binding its public key to the public key the AS GS has
        for the Client.  Signed tokens can be passed to downstream
        components in a AS GS or RS to enable independent verification of
        the Client and its request.  The AS GS Initiated Sequence Section 10 6
        requires a URL safe parameter, and JOSE is URL safe.

   5.   *Why does the AS GS not return parameters to the Client in the
        redirect url?*

        Passing parameters via a browser redirection is the source of
        many of the security risks in OAuth 2.0.  It also presents a
        challenge for smart devices.  In this protocol, the redirection
        from the Client to the AS GS is to enable the AS GS to interact with
        the User, and the redirection back to the Client is to hand back
        interaction control to the Client if the redirection was a full
        browser redirect.  Unlike OAuth 2.0, the identity of the Client
        is independent of the URI the AS GS redirects to.

   6.   *Why is there not a UserInfo endpoint as there is with OpenID
        Connect?*
        In OpenID Connect, obtaining claims over

        Since the redirect or Client can Read Grant at any time, it get the
        Token Endpoint are problematic.  The redirect is limited in
        size, and is not secure.  The Token Endpoint is intended to
        return tokens, and is limited by same
        functionality as the "application/x-www-form-
        urlencoded" format.  A UserInfo endpoint returns "application/
        json", endpoint, without the Client
        having to manage a separate access token and refresh token.  If
        the Client would like additional claims, it can return rich Update Grant,
        and the GS will let the Client know if an interaction is
        required to get any of the additional claims, just as which the authorization uri
        in this protocol. Client
        can then start.

        [Editor: is there some other reason to have the UserInfo
        endpoint?  What are industry best practices now? ]
        endpoint?]

   7.   *Why is there still a Client ID?  Could we not use ID?*
        The GS needs an identifier to fetch the meta data associated
        with a fingerprint
        of Client such as the public key name and image to display to identify the Client?*

        Some AS deployments do not allow calls from Registered Clients, User,
        and provide different functionality to different Clients.  A
        permanent identifier for the policies on what a Client is needed for the Client
        developer and the AS admin to ensure they are referring allowed to the
        same Client. do.  The Client
        ID was used in OAuth 2.0, and it served 2.0 for the same purpose. purpose, which simplifies
        migration.  Dynamic Clients do not have a Client ID.

   8.   *Why have both claims and authorizations?*

        There are use cases for each that are independent:
        authenticating a user vs granting access to a resource.  A
        request for an authorization returns an access token or handle,
        while a request for a claim returns the claim.

   9.   *Why specify HTTP/2 or later and TLS 1.3 or later for Client and
        AS
        GS communication in ?*Section 8 10

        Knowing the AS GS supports HTTP/2 enables a Client to set up a
        connection faster.  HTTP/2 will be more efficient when Clients
        have large numbers of access tokens and are frequently
        refreshing them at the AS GS as there will be less network traffic.
        Mandating TLS 1.3 similarly improves the performance and
        security of Clients and AS GS when setting up a TLS connection.

   10.  *Why do some of the JSON objects only have one child, such as
        the identifiers object in the user object in the AS Grant Request?*

        It is difficult to forecast future use cases.  Having more
        resolution may mean the difference between a simple extension,
        and a convoluted extension.

   11.  *Why is the "iss" included in the "oidc" identifier object?
        Would the "sub" not be enough for the AS GS to identify the User?*

        This decouples the GS from the OpenID Provider (OP).  The AS may use another AS to authenticate Users.  The "iss" and
        "sub" combination GS
        identifier is required to uniquely identify the User for
        any AS. GS URI, which is the endpoint at the GS.  The
        OP issuer identifier will likely not be the same as the GS URI.
        The GS may also provide claims from multiple OPs.

   12.  *Why complicate the sequence with authentication first?* "interaction"."keep"?*

        A common pattern is to use an AS GS to authenticate the User at the
        Client.  The Client does not know a priori if the User is a new
        User, or a returning User.  Asking a returning User to consent
        releasing identity claims and/or authorizations they have
        already provided is a poor User experience, as is sending the
        User back to the AS. GS.  The Client requesting identity first
        enables the Client to get a response from the AS GS while the AS GS is
        still interacting with the User, so that the Client can request
        any identity claims/or authorizations required or desired.
        Additionally, the claims a Client may want about a User may be
        dependent on some initial Claims.  For example, if a User is in
        a particular country, additional or different Claims my be
        required by the Client

   13.  *Why is there a JOSE Body "jose+body" RS access mechanism method for the
        Client?*Section 8.17 10.2.3

        There are numerous use cases where the RS wants non-repudiation
        and providence of the contents of an API calls. call.  For example, the UAS
        UGS Service Supplier Framework for Authentication and
        Authorization [UTM].

   14.  *Why use URIs to instead of handles for the Grant and
        Authorization?*

        A URI is an identifier just like a handle that can contain GS
        information that is opaque to the Client - so it has all the
        features of a handle, plus it can be the URL that is resolved to
        manipulate a Grant or an Authorization.  As the Grant URI and
        AuthZ URI are defined to start with the GS URI, the Client (and
        GS) can easily determine which GS a Grant or Authorization
        belong to.  URIs also enable a RESTful interface to the GS
        functionality.

   15.  *Why have an OPTIONS verb on the GS URI?  Why not use a .well-
        known mechanism?*

        Having the GS URI endpoint respond to the metadata allows the GS
        to provide Client specific results using the same Client
        authentication used for other requests to the GS.  It also
        reduces the risk of a mismatch between what the advertised
        metadata, and the actual metadata.  A .well-known discovery
        mechanism may be defined to resolve from a hostname to the GS
        URI.

   16.  *Why have an UPDATE, DELETE, and OPTIONS verbs on the AuthZ
        URI?*

        Maybe there are no use cases for them [that the editor knows
        of], but the GS can not implement, and they are available if use
        cases come up.

   17.  *Why list explicit interactions, instead of the Client and GS
        negotiating interaction capabilities?*
        The Client knows what interactions it is capable of, and
        prefers.  Telling the GS the interaction allows the GS to know
        what interaction the User will have.  Knowing how the Client
        will transition the interaction will enable the GS to provider a
        better User experience.  For example, the GS may want to provide
        a short URL if it knows the Client will be showing a QR code vs
        a redirect, or have a different layout if it is a popup vs a
        redirect.

13.  Acknowledgments

   This draft derives many of its concepts from Justin Richer's
   Transactional Authorization draft [TxAuth].

   Additional thanks to Justin Richer for his strong critique of earlier
   drafts.

14.  IANA Considerations

   [ JOSE parameter for Authorization HTTP header ]

   TBD

15.  Security Considerations

   TBD

16.  References

16.1.  Normative References

   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
              RFC 3966, DOI 10.17487/RFC3966, December 2004,
              <https://www.rfc-editor.org/info/rfc3966>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [RFC5646]  Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
              Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
              September 2009, <https://www.rfc-editor.org/info/rfc5646>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
              Framework: Bearer Token Usage", RFC 6750,
              DOI 10.17487/RFC6750, October 2012,
              <https://www.rfc-editor.org/info/rfc6750>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/info/rfc7515>.

   [RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
              RFC 7516, DOI 10.17487/RFC7516, May 2015,
              <https://www.rfc-editor.org/info/rfc7516>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015,
              <https://www.rfc-editor.org/info/rfc7540>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [OIDC]     Sakimora, N., Bradley, J., Jones, M., de Medeiros, B., and
              C. Mortimore, "OpenID Connect Core 1.0", November 2014,
              <https://openiD.net/specs/openiD-connect-core-1_0.html>.

   [OIDC4IA]  Lodderstedt, T. and D. Fett, "OpenID Connect for Identity
              Assurance 1.0", October 2019, <https://openid.net/specs/
              openid-connect-4-identity-assurance-1_0.html>.

16.2.  Informative References

   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
              October 2013, <https://www.rfc-editor.org/info/rfc7049>.

   [RFC8252]  Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",
              BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017,
              <https://www.rfc-editor.org/info/rfc8252>.

   [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              RFC 8152, DOI 10.17487/RFC8152, July 2017,
              <https://www.rfc-editor.org/info/rfc8152>.

   [RFC8323]  Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
              Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
              Application Protocol) over TCP, TLS, and WebSockets",
              RFC 8323, DOI 10.17487/RFC8323, February 2018,
              <https://www.rfc-editor.org/info/rfc8323>.

   [RFC8628]  Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,
              "OAuth 2.0 Device Authorization Grant", RFC 8628,
              DOI 10.17487/RFC8628, August 2019,
              <https://www.rfc-editor.org/info/rfc8628>.

   [browser_based_apps]
              Parecki, A. and D. Waite, "OAuth 2.0 for Browser-Based
              Apps", September 2019, <https://tools.ietf.org/html/draft-
              ietf-oauth-browser-based-apps-04>.

   [RAR]      Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
              Rich Authorization Requests", January 2020,
              <https://tools.ietf.org/html/draft-ietf-oauth-rar-00>.

   [W3C_VC]   Sporny, M., Noble, G., and D. Chadwick, "Verifiable
              Credentials Data Model 1.0", November 2019,
              <https://w3c.github.io/vc-data-model/>.

   [QR_Code]  "ISO/IEC 18004:2015 - Information technology - Automatic
              identification and data capture techniques - QR Code bar
              code symbology specification", February 2015,
              <https://www.iso.org/standard/62021.html>.

   [TxAuth]   Richer, J., "Transactional Authorization", AuthN", December 2019,
              <https://tools.ietf.org/html/draft-richer-transactional-
              authz-04>.

   [UTM]      Rios, J., Smith, I., and P. Venkatesen, "UAS "UGS Service
              Supplier Framework for Authentication and Authorization", AuthN",
              September 2019, <https://utm.arc.nasa.gov/docs/2019-
              UTM_Framework-NASA-TM220364.pdf>.
              UTM_Framework-NGSA-TM220364.pdf>.

Appendix A.  Document History

A.1.  draft-hardt-xauth-protocol-00

   *  Initial version

A.2.  draft-hardt-xauth-protocol-01

   *  text clean up

   *  added OIDC4IA claims

   *  added "jws" method for accessing a resource.

   *  renamed Initiation Request -> AS Grant Request

   *  renamed Initiation Response -> Interaction Response

   *  renamed Completion Request -> Authorization Request

   *  renamed Completion Response -> AS Grant Request

   *  renamed completion handle -> authorization handle

   *  added Authentication Request, Authentication Response,
      authentication handle

A.3.  draft-hardt-xauth-protocol-02

   *  handles are now URIs

   *  the

   *  the collection of claims and authorizations are a Grant

Appendix B.  Comparison with OAuth 2.0 and OpenID Connect

   *Changed Features*

   The major differences changes between this protocol and OAuth 2.0 and OpenID
   Connect are:

   *  The Client uses a private key to authenticate in this protocol
      instead of the client secret in OAuth 2.0 and OpenID Connect.

   *  The Client initiates the protocol by making a signed request
      directly to the AS GS instead of redirecting the User to the AS. GS.

   *  The Client does not receive pass any parameters from a redirection of in redirecting the User to
      the GS, nor receive any parameters in the redirection back from
      the AS. GS.

   *  Refreshing an access token requires creating a refresh token from
      a refresh handle, rather than an authenticated call  The refresh_token has been replaced with a AuthZ URI that both
      represents the access, and is the URI to call to refresh
      token. access.

   *  The Client can request identity claims to be returned independent
      of the ID Token.  There is no UserInfo endpoint to query claims as
      there is in OpenID Connect.

   *  The GS URI is the token endpoint.  CHECK!!!s

   *Preserved Features*

   *  This protocol reuses the OAuth 2.0 scopes, Client IDs, and access
      tokens of OAuth 2.0.

   *  This protocol reuses the Client IDs, Claims and ID Token of OpenID
      Connect.

   *  No change is required by the Client or the RS for existing bearer
      token protected APIs.

   *New Features*

   *  A Grant represents the user identity claims and RS access granted
      to the Client.

   *  The Client can update, retrieve, and delete a Grant.

   *  The GS can initiate a flow by creating a Grant and redirecting the
      User to the Client with the Grant URI.

   *  The Client can discovery if an GS has a User with an identifier
      before the GS interacts with the User.

   *  The Client can request the GS to first authenticate the User and
      return User identity claims, and then the Client can update Grant
      request based on the User identity.

   *  Support for QR Code initiated interactions.

   *  Each Client instance can have its own private / public key pair.

   *  More Extensibility dimensions.

Appendix C.  Open Questions

Author's Address
   Dick Hardt (editor)
   SignIn.Org
   United States

   Email: dick.hardt@gmail.com