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

[Dick Hardt <[e-mail]>]

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.


ᐧ

On Tue, Aug 18, 2020 at 10:29 AM Denis <[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)
>    - may want access to resources at a Resource Server
>       - may be interacting with a User and want identity claims about the
>       User
>       - requests the Grant Service to grant resource access and identity
>       claims
>    -
>
>    *Grant Server* (GS)
>    - accepts Grant requests from the GC for resource access and identity
>       claims
>       - negotiates the interaction mode with the GC if interaction is
>       required with the User
>       - acquires authorization from the User before granting identity
>       claims to the GC
>       - acquires authorization from the RO before granting resource
>       access to the GC
>       - grants resource access and identity claims to the GC
>    -
>
>    *Resource Server* (RS)
>    - has resources that the GC may want to access
>       - expresses what the GC must obtain from the GS for access through
>       documentation or an API. This is not in scope for this document
>       - verifies the GS granted access to the GC, when the GS makes
>       resource access requests
>
> *Humans*
>
>    -
>
>    *User*
>    - the person interacting with the Grant Client.
>       - has delegated access to identity claims about themselves to the
>       Grant Server.
>       - may authenticate at the GS..
>    -
>
>    *Resource Owner* (RO)
>    - the legal entity that owns resources at the Resource Server (RS).
>       - has delegated resource access management to the GS.
>       - 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]
> https://www.ietf.org/mailman/listinfo/txauth
>