Re: [GNAP] draft-hardt-xauth-protocol-14 update - reworked introduction

[Denis <[e-mail]>]

Hi Dick,
> Hi Denis
>
> Thanks for taking the time to review the latest draft
>
> While *your* cases may require certain conditions, other use cases 
> have other conditions.
>
> For example, existing OAuth 2 flows do NOT have the client query the 
> RS first. Per the charter, supporting OAuth 2 use cases is in scope.

  I don't believe so.  The charter states: "It will *expand *upon the 
uses cases currently supported by OAuth 2.0 and OpenID Connect ..."

The charter also states: "This group is not chartered to develop 
extensions to OAuth 2.0, and as such *will focus on new technological 
solutions **
**not necessarily compatible with OAuth 2.0*".

We are not necessarily going to support all the current OAuth 2.0 uses 
cases, since such use cases can already be supported using OAuth 2.0.

Denis

> ᐧ
>
> On Tue, Aug 18, 2020 at 10:29 AM Denis <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi Dick,
>
>     I have taken a look at the specification and there are good news
>     but unfortunately also bad news.
>
>     The good news: There is a Privacy considerations section (section 11)
>
>     The bad news: There is the title of that section, but no text in it.
>
>     The good news: The first exchange is now between the client and
>     the RS:
>
>         (1) The GC may query the RS to determine what the RS requires
>         from a GS for resource access.
>
>     The bad news: The text is using a "may" and continues with: "This
>     step is not in scope for this document".
>
>     This first flow is fundamental and if the client has never
>     contacted the RS before, that step shall be performed.
>     Hence, the use of the word "may" is inappropriate. In addition,
>     using the singular "for a GS" is also inappropriate since a RS
>     may trust more than one GS.
>
>     Please take a look at the uses cases I have posted today called:
>     "Enterprise servers and Internet servers use cases"
>     The document is available at :
>     https://github.com/ietf-wg-gnap/general/wiki/Enterprise-servers-and-Internet-servers-use-cases
>
>     This post attempts to explain why this first flow is the most
>     important. IMHO, it should be within the scope.
>
>     BTW, I don't like the wording "Grant Client" since it is ambiguous
>     as it does not make any difference between what I call
>     a "User Client" and an "Enterprise Client".
>
>     The text then uses the following sentence which is inappropriate
>     for various reasons:
>
>         The Grant Client may be interacting with a human end-user (User),
>
>     A user client *must *be interacting with a human end-user (User).
>     The User must interact using, what I call, a "User Agent".
>
>         and the Grant Client may need to get authorization to release
>         the Grant from the User,
>
>     Further down, a grant is defined as: "the user identity claims
>     and/or resource access the GS has granted to the Client".
>
>     Such a definition is inappropriate since a grant is first of all
>     an access token issued by an AS that contains attributes and/or
>     capabilities that allow to perform some method(s) on a data object.
>
>     Before an access token is issued for a User, a User Consent, as
>     well as some choices, made by the User shall be obtained.
>     This does not apply when an access token is issued for a client
>     (i.e. a piece of software). The vocabulary that is being used
>     does not allow to make these major differences.
>
>         or from the owner of the resources at the Resource Server, the
>         Resource Owner (RO).
>
>     No authorization is needed by the owner of the resource. A
>     Resource Controller (RC) is a piece of software that applies a set
>     of rules
>     to grant or to deny access to a data object using some method. No
>     human interaction from a human being sitting next to the RS is
>     ever needed.
>
>     The uses cases I posted today contain a more detailed model that
>     is able to support both capabilities and ABAC (Attribute-based
>     Access Control).
>
>     Denis
>
>>     Hello
>>
>>     I just pushed an updated version of XAuth:
>>
>>     https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html
>>
>>     Highlights:
>>
>>       * renamed Client -> Grant Client
>>       * Introduced Client Owner, Grant Server Owner as new entities
>>       * renamed Authorizations -> Access
>>       * An Access contains an array of RAR objects now
>>       * Reworked diagram an intro to focus on Grant, and separate
>>         protocol roles from human interactions.
>>
>>     New introduction included below for your convenience
>>
>>     /Dick
>>
>>      *
>>
>>
>>         1.
>>         <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1>Introduction
>>         <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#name-introduction>
>>
>>     *EDITOR NOTE*
>>
>>     /This document captures a number of concepts that may be adopted
>>     by the proposed GNAP working group. Please refer to this document
>>     as:/
>>
>>     *XAuth*
>>
>>     /The use of GNAP in this document is not intended to be a
>>     declaration of it being endorsed by the GNAP working group./
>>
>>     This document describes the core Grant Negotiation and
>>     Authorization Protocol (GNAP). The protocol supports the widely
>>     deployed use cases supported by OAuth 2.0 [RFC6749
>>     <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RFC6749>] &
>>     [RFC6750
>>     <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RFC6750>],
>>     OpenID Connect [OIDC
>>     <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#OIDC>] -
>>     an extension of OAuth 2.0, as well as other extensions. Related
>>     documents include: GNAP - Advanced Features [GNAP_Advanced
>>     <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#GNAP_Advanced>] and
>>     JOSE Authentication [JOSE_Authentication
>>     <https://tools.ietf..org/id/draft-hardt-xauth-protocol-14.html#JOSE_Authentication>] that
>>     describes the JOSE mechanisms for client authentication.
>>
>>     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.
>>
>>     GNAP simplifies the overall architectural model, takes advantage
>>     of today's technology landscape, provides support for all the
>>     widely deployed use cases, offers numerous extension points, and
>>     addresses many of the security issues in OAuth 2.0 by passing
>>     parameters securely between parties rather than via a browser
>>     redirection.
>>
>>     While GNAP is not backwards compatible with OAuth 2.0, it strives
>>     to minimize the migration effort.
>>
>>     The suggested pronunciation of GNAP is "guh-nap".
>>
>>
>>           1.1.
>>           <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.1>The
>>           Grant
>>           <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#name-the-grant>
>>
>>     The Grant is at the center of the protocol between a client and a
>>     server. A Grant Client requests a Grant from a Grant Server. The
>>     Grant Client and Grant Server negotiate the Grant. The Grant
>>     Server acquires authorization to grant the Grant to the Grant
>>     Client. The Grant Server then returns the Grant to the Grant Client.
>>
>>     The Grant Request may contain information about the User, the
>>     Grant Client, the interaction modes supported by the Grant
>>     Client, the requested identity claims, and the requested resource
>>     access. Extensions may define additional information to be
>>     included in the Grant Request.
>>
>>
>>           1.2.
>>           <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2>Protocol
>>           Roles
>>           <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#name-protocol-roles>
>>
>>     There are three roles in GNAP: the Grant Client (GC), the Grant
>>     Server (GS), and the Resource Server (RS). Below is how the roles
>>     interact:
>>
>>          +--------+                               +------------+
>>          | Grant  | - - - - - - -(1)- - - - - - ->|  Resource  |
>>          | Client |                               |   Server   |
>>          |  (GC)  |       +---------------+       |    (RS)    |
>>          |        |--(2)->|     Grant     |       |            |
>>          |        |<-(3)->|     Server    |- (6) -|            |
>>          |        |<-(4)--|      (GS)     |       |            |
>>          |        |       +---------------+       |            |
>>          |        |                               |            |
>>          |        |--------------(5)------------->|            |
>>          +--------+                               +------------+
>>
>>     (1) The GC may query the RS to determine what the RS requires
>>     from a GS for resource access. This step is not in scope for this
>>     document.
>>
>>     (2) The GC makes a Grant request to the GS (Create Grant Section
>>     3.2
>>     <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#CreateGrant>).
>>     How the GC authenticates to the GS is not in scope for this
>>     document. One mechanism is [JOSE_Authentication
>>     <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#JOSE_Authentication>].
>>
>>     (3) The GC and GS may negotiate the Grant.
>>
>>     (4) The GS returns a Grant to the GC (Grant Response Section 4.1
>>     <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#GrantResponse>).
>>
>>     (5) The GC accesses resources at the RS (RS Access Section 6
>>     <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RSAccess>).
>>
>>     (6) The RS evaluates access granted by the GS to determine access
>>     granted to the GC. This step is not in scope for this document.
>>
>>
>>           1.3.
>>           <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3>Human
>>           Interactions
>>           <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#name-human-interactions>
>>
>>     The Grant Client may be interacting with a human end-user (User),
>>     and the Grant Client may need to get authorization to release the
>>     Grant from the User, or from the owner of the resources at the
>>     Resource Server, the Resource Owner (RO)
>>
>>     Below is when the human interactions may occur in the protocol:
>>
>>          +--------+                               +------------+
>>          |  User  |                               |  Resource  |
>>          |        |                               | Owner (RO) |
>>          +--------+                               +------------+
>>              +     +                             +
>>              +      +                           +
>>             (A)     (B)                       (C)
>>              +        +                       +
>>              +         +                     +
>>          +--------+     +                   +     +------------+
>>          | Grant  | - - -+- - - -(1)- - - -+- - ->|  Resource  |
>>          | Client |       +               +       |   Server   |
>>          |  (GC)  |       +---------------+       |    (RS)    |
>>          |        |--(2)->|     Grant     |       |            |
>>          |        |<-(3)->|     Server    |- (6) -|            |
>>          |        |<-(4)--|      (GS)     |       |            |
>>          |        |       +---------------+       |            |
>>          |        |                               |            |
>>          |        |--------------(5)------------->|            |
>>          +--------+                               +------------+
>>
>>     Legend
>>     + + + indicates an interaction with a human
>>     ----- indicates an interaction between protocol roles
>>
>>     Steps (1) - (6) are the same as Section 1.2
>>     <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#ProtocolRoles>.
>>     The addition of the human interactions (A) - (C) are *bolded* below.
>>
>>     *(A) The User is interacting with a GC, and the GC needs resource
>>     access and/or identity claims (a Grant)*
>>
>>     (1) The GC may query the RS to determine what the RS requires
>>     from a GS for resource access
>>
>>     (2) The GC makes a Grant request to the GS
>>
>>     (3) The GC and GS may negotiate the Grant
>>
>>     *(B) The GS may interact with the User for grant authorization*
>>
>>     *(C) The GS may interact with the RO for grant authorization*
>>
>>     (4) The GS returns a Grant to the GC
>>
>>     (5) The GC accesses resources at the RS
>>
>>     (6) The RS evaluates access granted by the GS to determine access
>>     granted to the GC
>>
>>     Alternatively, the Resource Owner could be a legal entity that
>>     has a software component that the Grant Server interacts with for
>>     Grant authorization. This interaction is not in scope of this
>>     document.
>>
>>
>>           1.4.
>>           <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4>Trust
>>           Model
>>           <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#name-trust-model>
>>
>>     In addition to the User and the Resource Owner, there are three
>>     other entities that are part of the trust model:
>>
>>       * *Client Owner* (CO) - the legal entity that owns the Grant
>>         Client.
>>       * *Grant Server Owner* (GSO) - the legal entity that owns the
>>         Grant Server.
>>       * *Claims Issuer* (Issuer) - a legal entity that issues
>>         identity claims about the User. The Grant Server Owner may be
>>         an Issuer, and the Resource Owner may be an Issuer.
>>
>>     These three entities do not interact in the protocol, but are
>>     trusted by the User and the Resource Owner:
>>
>>        +------------+           +--------------+----------+
>>        |    User    | >> (A) >> | Grant Server |          |
>>        |            |           | Owner (GSO)  |          |
>>        +------------+         > +--------------+          |
>>              V              /          ^       |  Claims  |
>>             (B)          (C)          (E)      |  Issuer  |
>>              V          /              ^       | (Issuer) |
>>        +------------+ >         +--------------+          |
>>        |  Client    |           |   Resource   |          |
>>        | Owner (CO) | >> (D) >> |  Owner (RO)  |          |
>>        +------------+           +--------------+----------+
>>
>>     (A) User trusts the GSO to acquire authorization before making a
>>     grant to the CO
>>
>>     (B) User trusts the CO to act in the User's best interest with
>>     the Grant the GSO grants to the CO
>>
>>     (C) CO trusts claims issued by the GSO
>>
>>     (D) CO trusts claims issued by the RO
>>
>>     (E) RO trusts the GSO to manage access to the RO resources
>>
>>
>>           1.5.
>>           <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1..5>Terminology
>>           <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#name-terminology>
>>
>>     *Roles*
>>
>>      *
>>
>>         *Grant Client* (GC)
>>
>>           o may want access to resources at a Resource Server
>>           o may be interacting with a User and want identity claims
>>             about the User
>>           o requests the Grant Service to grant resource access and
>>             identity claims
>>      *
>>
>>         *Grant Server* (GS)
>>
>>           o accepts Grant requests from the GC for resource access
>>             and identity claims
>>           o negotiates the interaction mode with the GC if
>>             interaction is required with the User
>>           o acquires authorization from the User before granting
>>             identity claims to the GC
>>           o acquires authorization from the RO before granting
>>             resource access to the GC
>>           o grants resource access and identity claims to the GC
>>      *
>>
>>         *Resource Server* (RS)
>>
>>           o has resources that the GC may want to access
>>           o expresses what the GC must obtain from the GS for access
>>             through documentation or an API. This is not in scope for
>>             this document
>>           o verifies the GS granted access to the GC, when the GS
>>             makes resource access requests
>>
>>     *Humans*
>>
>>      *
>>
>>         *User*
>>
>>           o the person interacting with the Grant Client.
>>           o has delegated access to identity claims about themselves
>>             to the Grant Server.
>>           o may authenticate at the GS..
>>      *
>>
>>         *Resource Owner* (RO)
>>
>>           o the legal entity that owns resources at the Resource
>>             Server (RS).
>>           o has delegated resource access management to the GS.
>>           o may be the User, or may be a different entity that the GS
>>             interacts with independently.
>>
>>     *Reused Terms*
>>
>>       * *access token* - an access token as defined in [RFC6749
>>         <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RFC6749>] Section
>>         1.4.. An GC uses an access token for resource access at a RS.
>>       * *Claim* - a Claim as defined in [OIDC
>>         <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#OIDC>] Section
>>         5. Claims are issued by a Claims Issuer.
>>       * *Client ID* - a GS unique identifier for a Registered Client
>>         as defined in [RFC6749
>>         <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RFC6749>] Section
>>         2.2.
>>       * *ID Token* - an ID Token as defined in [OIDC
>>         <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#OIDC>] Section
>>         2. ID Tokens are issued by the GS. The GC uses an ID Token to
>>         authenticate the User.
>>       * *NumericDate* - a NumericDate as defined in [RFC7519
>>         <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RFC7519>] Section
>>         2.
>>       * *authN* - short for authentication.
>>       * *authZ* - short for authorization.
>>
>>     *New Terms*
>>
>>       * *GS URI* - the endpoint at the GS the GC calls to create a
>>         Grant, and is the unique identifier for the GS.
>>       * *Registered Client* - a GC that has registered with the GS
>>         and has a Client ID to identify itself, and can prove it
>>         possesses a key that is linked to the Client ID. The GS may
>>         have different policies for what different Registered Clients
>>         can request. A Registered Client MAY be interacting with a User.
>>       * *Dynamic Client* - a GC that has not been previously
>>         registered with the GS, and each instance will generate it's
>>         own asymetric key pair so it can prove it is the same
>>         instance of the GC on subsequent requests.. The GS MAY return
>>         a Dynamic Client a Client Handle for the Dynamic Client to
>>         identify itself in subsequent requests. A single-page
>>         application with no active server component is an example of
>>         a Dynamic Client.
>>       * *Client Handle* - a unique identifier at the GS for a Dynamic
>>         Client for the Dynamic Client to refer to itself in
>>         subsequent requests.
>>       * *Interaction* - how the GC directs the User to interact with
>>         the GS. This document defines the interaction modes:
>>         "redirect", "indirect", and "user_code" in Section 5
>>         <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#InteractionModes>.
>>       * *Grant* - the user identity claims and/or resource access the
>>         GS has granted to the Client. The GS MAY invalidate a Grant
>>         at any time.
>>       * *Grant URI* - the URI that represents the Grant. The Grant
>>         URI MUST start with the GS URI.
>>       * *Access* - the access granted by the RO to the GC and
>>         contains an access token. The GS may invalidate an Access at
>>         any time.
>>       * *Access URI* - the URI that represents the Access the GC was
>>         granted by the RO. The Access URI MUST start with the GS
>>         URI.. The Access URI is used to refresh an access token.
>>
>>
>>
>>
>
>     -- 
>     TXAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/txauth
>