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

From: Dick Hardt <[email-masked]>
Date: Sat, 15 Aug 2020 16:02:39 -0700

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*
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-1>

*This document captures a number of concepts that may be adopted by the
proposed GNAP working group. Please refer to this document as:*
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-2>

*XAuth*
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-3>

*The use of GNAP in this document is not intended to be a declaration of it
being endorsed by the GNAP working group.*
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-4>

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.
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-5>

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.
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-6>

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.
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-7>

While GNAP is not backwards compatible with OAuth 2.0, it strives to
minimize the migration effort.
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-8>

The suggested pronunciation of GNAP is "guh-nap".
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-9>
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.
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.1-1>

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.
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.1-2>
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:
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-1>

    +--------+                               +------------+
    | Grant  | - - - - - - -(1)- - - - - - ->|  Resource  |
    | Client |                               |   Server   |
    |  (GC)  |       +---------------+       |    (RS)    |
    |        |--(2)->|     Grant     |       |            |
    |        |<-(3)->|     Server    |- (6) -|            |
    |        |<-(4)--|      (GS)     |       |            |
    |        |       +---------------+       |            |
    |        |                               |            |
    |        |--------------(5)------------->|            |
    +--------+                               +------------+

<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-2>

(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.
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-3>

(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>
].
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-4>

(3) The GC and GS may negotiate the Grant.
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-5>

(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>
).
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-6>

(5) The GC accesses resources at the RS (RS Access Section 6
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RSAccess>).
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-7>

(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.
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-8>
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)
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-1>

Below is when the human interactions may occur in the protocol:
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-2>

    +--------+                               +------------+
    |  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

<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-3>

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.
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-4>

*(A) The User is interacting with a GC, and the GC needs resource access
and/or identity claims (a Grant)*
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-5>

(1) The GC may query the RS to determine what the RS requires from a GS for
resource access
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-6>

(2) The GC makes a Grant request to the GS
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-7>

(3) The GC and GS may negotiate the Grant
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-8>

*(B) The GS may interact with the User for grant authorization*
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-9>

*(C) The GS may interact with the RO for grant authorization*
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-10>

(4) The GS returns a Grant to the GC
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-11>

(5) The GC accesses resources at the RS
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-12>

(6) The RS evaluates access granted by the GS to determine access granted
to the GC
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-13>

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.
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-14>
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:
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-1>

   - *Client Owner* (CO) - the legal entity that owns the Grant Client.
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-2.1>
   - *Grant Server Owner* (GSO) - the legal entity that owns the Grant
   Server.
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-2.2>
   - *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.
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-2.3>

These three entities do not interact in the protocol, but are trusted by
the User and the Resource Owner:
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-3>

  +------------+           +--------------+----------+
  |    User    | >> (A) >> | Grant Server |          |
  |            |           | Owner (GSO)  |          |
  +------------+         > +--------------+          |
        V              /          ^       |  Claims  |
       (B)          (C)          (E)      |  Issuer  |
        V          /              ^       | (Issuer) |
  +------------+ >         +--------------+          |
  |  Client    |           |   Resource   |          |
  | Owner (CO) | >> (D) >> |  Owner (RO)  |          |
  +------------+           +--------------+----------+

<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-4>

(A) User trusts the GSO to acquire authorization before making a grant to
the CO
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-5>

(B) User trusts the CO to act in the User's best interest with the Grant
the GSO grants to the CO
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-6>

(C) CO trusts claims issued by the GSO
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-7>

(D) CO trusts claims issued by the RO
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-8>

(E) RO trusts the GSO to manage access to the RO resources
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-9>
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*
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-1>

   -

   *Grant Client* (GC)
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.1.1>
   - may want access to resources at a Resource Server
      <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.1.2.1>
      - may be interacting with a User and want identity claims about the
      User
      <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.1.2.2>
      - requests the Grant Service to grant resource access and identity
      claims
      <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.1.2.3>
   -

   *Grant Server* (GS)
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.2.1>
   - accepts Grant requests from the GC for resource access and identity
      claims
      <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.2.2.1>
      - negotiates the interaction mode with the GC if interaction is
      required with the User
      <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.2.2.2>
      - acquires authorization from the User before granting identity
      claims to the GC
      <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.2.2.3>
      - acquires authorization from the RO before granting resource access
      to the GC
      <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.2.2.4>
      - grants resource access and identity claims to the GC
      <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.2.2.5>
   -

   *Resource Server* (RS)
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.3.1>
   - has resources that the GC may want to access
      <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.3.2.1>
      - expresses what the GC must obtain from the GS for access through
      documentation or an API. This is not in scope for this document
      <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.3.2.2>
      - verifies the GS granted access to the GC, when the GS makes
      resource access requests
      <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.3.2.3>

*Humans*
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-3>

   -

   *User*
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.1.1>
   - the person interacting with the Grant Client.
      <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.1.2.1>
      - has delegated access to identity claims about themselves to the
      Grant Server.
      <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.1.2.2>
      - may authenticate at the GS.
      <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.1.2.3>
   -

   *Resource Owner* (RO)
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.2.1>
   - the legal entity that owns resources at the Resource Server (RS).
      <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.2.2.1>
      - has delegated resource access management to the GS.
      <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.2.2.2>
      - may be the User, or may be a different entity that the GS interacts
      with independently.
      <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.2.2.3>

*Reused Terms*
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-5>

   - *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.
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6.1>
   - *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.
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6.2>
   - *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.
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6.3>
   - *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.
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6.4>
   - *NumericDate* - a NumericDate as defined in [RFC7519
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RFC7519>]
Section
   2.
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6.5>
   - *authN* - short for authentication.
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6.6>
   - *authZ* - short for authorization.
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6.7>

*New Terms*
<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-7>

   - *GS URI* - the endpoint at the GS the GC calls to create a Grant, and
   is the unique identifier for the GS.
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.1>
   - *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.
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.2>
   - *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.
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.3>
   - *Client Handle* - a unique identifier at the GS for a Dynamic Client
   for the Dynamic Client to refer to itself in subsequent requests.
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.4>
   - *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>
   .
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.5>
   - *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.
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.6>
   - *Grant URI* - the URI that represents the Grant. The Grant URI MUST
   start with the GS URI.
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.7>
   - *Access* - the access granted by the RO to the GC and contains an
   access token. The GS may invalidate an Access at any time.
   <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.8>
   - *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.

---

From: Francis Pouatcha <[email-masked]>
Date: Sun, 16 Aug 2020 18:46:35 -0400

Hello Dick, my feedback below:

1.2: Excellent and Focussed
-> The word "Grant Client" looks great for me.

1.3:
Title: Human Interaction -> End User Interaction
I would title this "End User" interaction and not "human ...". It is not
about having a human, but a terminating edge of the protocol. An "End User"
can be either human on an IOT device or a car or ...

Participant: User -> "Requesting Party"
I will still insist on replacing the word "User" with a role name. Maybe
"Requesting Party" as used by UMA.

Participant: "Resource Controller". In past discussions there was a
consensus on using "Resource Controller" instead.

(B) I which the GS never interacts with the "Requesting Party" in a matter
of obtaining a grant to a resource (many reasons: privacy, confidentiality,
abstraction, ...). Generally the GS will need information (claims) about
the "Requesting Party" to proceed with the authorisation decision. In this
case, the GS can instruct the GC to obtain those claims. In some cases,
claims on the "Requesting Party" will be obtained from another
"Authorization Server" (AS). The word AS is intentionally chosen here. In
this same login, the path (C0, C1) below will not only return the RC
consent, but might also return some claims on RC.

ASs provide authentication "of" and consent collection "from" End Users.
End users are in this case the Requesting Party, and the Resource
Controller).

The result can look like the modified diagram below. With this we can
address some privacy concerns that are being discussed on the list.

    +-------------+                        +----------------+
    | Requesting  |                        |  Resource      |
    | Party (RP)  |                        | Controller (RC)|
    +-------------+                        +----------------+
        +     +                             +
        +      +                           +
       (A)     (B1)                      (C1)
        +        +                       +
        +.        +                     +
        +       +--------+       +--------+
        +       | RP-AS  |       | RC-AS  |
        +       |        |       |        |
        +       +--------+       +--------+
        +         +                  +
        +       (B0)                +
        +       +                (C0)
    +--------+ +                  +          +------------+
    | Grant  | - - - -(1)- - - - + - - - - ->|  Resource  |
    | Client |                  +            |   Server   |
    |  (GC)  |       +---------------+       |    (RS)    |
    |        |--(2)->|     Grant     |       |            |
    |        |<-(3)->|     Server    |- (6) -|            |
    |        |<-(4)--|      (GS)     |       |            |
    |        |       +---------------+       |            |
    |        |                               |            |
    |        |--------------(5)------------->|            |
    +--------+                               +------------+

(B0, B1) replace (B). Occur inside step (3), GS asks GC to collect the
claims. GC contacts RP-AS to negotiate those claims. But it is important to
mention that those Claims-RP are not the target Grant being negotiated for
the resource access. They are generally used by GS (and later RS) as input
into performing authz decisions.

(C0, C1) replace (C). They occur after step (3) (Beware of the
difference to Bs that occur inside 3). This separation address the Big
Brother problem we have been discussing in the list.

Essential is to mention that in an instantiation of this model for oAuth
for example:
- GS, RP-AS and RC-AS might be the same entity.
- RP and RC might refer to the same "End User".

Off-topic: The splitting of GS and AS was suggested in some discussions on
the mailing list. But we have no mean yet to isolate good inputs for later
reuse. This is why I suggest we compile some inputs into tickets or wiki
pages (like use cases).

1.4:
The Trust model introduces what I would rather call the trust framework.
The purpose of the trust framework will be to address topics mentioned in
this section. There is still a lot of discussion needed to have a structure
for this section.

1.5
I suggest again we replace Human with "End User" and still make them roles.
This is:
Terminology (Are all roles)
  -> These roles can be borne by End Users
     -> Requesting Party (RP)
     -> Resource Controller (RC)
  -> These role can be borne by Services
     -> GS
     -> GC
     -> RS
     -> RP-AS
     -> RC-AS

I will stop here, as the fundamental agreement on this structure is
necessary for a qualified review of section 2++.

Best regards
/Francis

On Sat, Aug 15, 2020 at 7:03 PM Dick Hardt <[email-masked]> wrote:

> 1.
> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1>
> Introduction
> *The use of GNAP in this document is not intended to be a declaration of
> it being endorsed by the GNAP working group.*
> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RFC6749>] &
> [RFC6750
> <https://tools.ietf..org/id/draft-hardt-xauth-protocol-14.html#JOSE_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.
> 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
> 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) 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.
> (1) The GC may query the RS to determine what the RS requires from a GS
> for resource access
>    - *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.
> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1..5>
> Terminology
>       - acquires authorization from the RO before granting resource
>       access to the GC
> <https://tools.ietf..org/id/draft-hardt-xauth-protocol-14.html#section-1.5-3>
>
>    -
>
>    *User*
>       - may authenticate at the GS..
>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.2.2..2>
>       - may be the User, or may be a different entity that the GS
>       interacts with independently.
>    <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.
>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RFC6749>] Section
>    2.2.
>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RFC7519>] Section
>    2.
>    - *GS URI* - the endpoint at the GS the GC calls to create a Grant,
>    and is the unique identifier for the GS.
>    can prove it is the same instance of the GC on subsequent requests.. The GS
>    by the RO. The Access URI MUST start with the GS URI.. The Access URI is
> --
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/

---

From: Dick Hardt <[email-masked]>
Date: Sun, 16 Aug 2020 16:04:00 -0700

Hi Francis

I was intentional in stating 1.3 that it is human interactions. The
connection lines are '+ + +' rather than '-----' to indicate that it is a
human interaction rather than a protocol between roles. We can't specify
how a human interaction works, but we can show when they might occur
relative to the rest of the protocol

In the abstract diagram in 1.3, I show the interactions between the User
and the GC, the User and the GS, and the RO and the GS. These are NOT
interactions that can be technically specified. The User and RO are not
roles in the protocol, but are entities in the trust model.

I debated keeping the interactions abstract and not stating "what" happened
in each interaction, but thought that might be confusing at this stage or
our discussions.

Since it is just an interaction between human and software, we can have the
User authenticate to the GC as well as authorize (provide consent), and
have no interaction at the GS. We would need to define how to represent the
authorization and the consent for the GC to pass to the GS, but the roles
and entities stay the same. The trust model does change though.

/Dick

On Sun, Aug 16, 2020 at 3:46 PM Francis Pouatcha <[email-masked]> wrote:

> I suggest again we replace Human with "End User" and still make them
> roles. This is:
>>  & [RFC6750
>> <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
>>       - may be interacting with a User and want identity claims about
>>       the User
>>    <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.
>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RFC6749>
>>    ] Section 2.2.
>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RFC7519>
>>    ] Section 2.
>>    - *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
>>    - *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
>>    - *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
>>    - *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.
>>    - *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
>> [email-masked]

---

From: Tom Jones <[email-masked]>
Date: Sun, 16 Aug 2020 16:38:13 -0700

i disagree - end user needs to be a human = use term like subject or
endpoint if you want a non-human
Peace ..tom

On Sun, Aug 16, 2020 at 3:46 PM Francis Pouatcha <fpo=
[email-masked]> wrote:

>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1..2-8>
>> 1.3.
>> 1.4..
>> <https://tools.ietf..org/id/draft-hardt-xauth-protocol-14.html#section-1.4-8>
>>
>>       <https://tools..ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.2.2.3>
>>    different Registered Clients can request.. A Registered Client MAY be
>>    interacting with a User.

---

From: Mark Lizar <[email-masked]>
Date: Sun, 16 Aug 2020 23:58:55 +0000

- consent is the human management of a permission grant the system manages .   +1 for not mixing human and system terms for the same endpoint.

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: TXAuth <[email-masked]> on behalf of Tom Jones <[email-masked]>
Sent: Sunday, August 16, 2020 7:38:13 PM
To: Francis Pouatcha <fpo=[email-masked]>
Cc: GNAP Mailing List <[email-masked]>; Dick Hardt <[email-masked]>
Subject: Re: [GNAP] draft-hardt-xauth-protocol-14 update - reworked introduction

i disagree - end user needs to be a human = use term like subject or endpoint if you want a non-human
Peace ..tom

On Sun, Aug 16, 2020 at 3:46 PM Francis Pouatcha <fpo=[email-masked]<mailto:[email-masked]>> wrote:
Hello Dick, my feedback below:

1.3:
Title: Human Interaction -> End User Interaction
I would title this "End User" interaction and not "human ....". It is not about having a human, but a terminating edge of the protocol. An "End User" can be either human on an IOT device or a car or ...

Participant: User -> "Requesting Party"
I will still insist on replacing the word "User" with a role name. Maybe "Requesting Party" as used by UMA.

Participant: "Resource Controller". In past discussions there was a consensus on using "Resource Controller" instead.

(B) I which the GS never interacts with the "Requesting Party" in a matter of obtaining a grant to a resource (many reasons: privacy, confidentiality, abstraction, ...). Generally the GS will need information (claims) about the "Requesting Party" to proceed with the authorisation decision. In this case, the GS can instruct the GC to obtain those claims. In some cases, claims on the "Requesting Party" will be obtained from another "Authorization Server" (AS). The word AS is intentionally chosen here. In this same login, the path (C0, C1) below will not only return the RC consent, but might also return some claims on RC.

ASs provide authentication "of" and consent collection "from" End Users. End users are in this case the Requesting Party, and the Resource Controller).

The result can look like the modified diagram below. With this we can address some privacy concerns that are being discussed on the list.

(B0, B1) replace (B). Occur inside step (3), GS asks GC to collect the claims. GC contacts RP-AS to negotiate those claims. But it is important to mention that those Claims-RP are not the target Grant being negotiated for the resource access. They are generally used by GS (and later RS) as input into performing authz decisions.

(C0, C1) replace (C). They occur after step (3) (Beware of the difference to Bs that occur inside 3). This separation address the Big Brother problem we have been discussing in the list.

Essential is to mention that in an instantiation of this model for oAuth for example:
- GS, RP-AS and RC-AS might be the same entity.
- RP and RC might refer to the same "End User".

Off-topic: The splitting of GS and AS was suggested in some discussions on the mailing list. But we have no mean yet to isolate good inputs for later reuse. This is why I suggest we compile some inputs into tickets or wiki pages (like use cases).

1.4:
The Trust model introduces what I would rather call the trust framework. The purpose of the trust framework will be to address topics mentioned in this section. There is still a lot of discussion needed to have a structure for this section.

1.5
I suggest again we replace Human with "End User" and still make them roles. This is:

I will stop here, as the fundamental agreement on this structure is necessary for a qualified review of section 2++.

Best regards
/Francis

On Sat, Aug 15, 2020 at 7:03 PM Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
Hello

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.

/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<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-1>

This document captures a number of concepts that may be adopted by the proposed GNAP working group. Please refer to this document as:<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-2>

XAuth<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-3>

The use of GNAP in this document is not intended to be a declaration of it being endorsed by the GNAP working group.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-4>

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.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-5>

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.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-6>

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.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-7>

While GNAP is not backwards compatible with OAuth 2.0, it strives to minimize the migration effort.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-8>

The suggested pronunciation of GNAP is "guh-nap".<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-9>

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.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.1-1>

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.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.1-2>

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:<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-1>

(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.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-3>

(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>].<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-4>

(3) The GC and GS may negotiate the Grant.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-5>

(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>).<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-6>

(5) The GC accesses resources at the RS (RS Access Section 6<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RSAccess>).<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-7>

(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.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1..2-8>

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)<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-1>

Below is when the human interactions may occur in the protocol:<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-2>

Legend

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.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-4>

(A) The User is interacting with a GC, and the GC needs resource access and/or identity claims (a Grant)<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-5>

(1) The GC may query the RS to determine what the RS requires from a GS for resource access<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-6>

(2) The GC makes a Grant request to the GS<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-7>

(3) The GC and GS may negotiate the Grant<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-8>

(B) The GS may interact with the User for grant authorization<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-9>

(C) The GS may interact with the RO for grant authorization<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-10>

(4) The GS returns a Grant to the GC<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-11>

(5) The GC accesses resources at the RS<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-12>

(6) The RS evaluates access granted by the GS to determine access granted to the GC<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-13>

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.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-14>

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:<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-1>

  *   Client Owner (CO) - the legal entity that owns the Grant Client.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-2.1>
  *   Grant Server Owner (GSO) - the legal entity that owns the Grant Server.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-2.2>
  *   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.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-2.3>

These three entities do not interact in the protocol, but are trusted by the User and the Resource Owner:<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-3>

(A) User trusts the GSO to acquire authorization before making a grant to the CO<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-5>

(B) User trusts the CO to act in the User's best interest with the Grant the GSO grants to the CO<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-6>

(C) CO trusts claims issued by the GSO<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-7>

(D) CO trusts claims issued by the RO<https://tools.ietf..org/id/draft-hardt-xauth-protocol-14.html#section-1.4-8>

(E) RO trusts the GSO to manage access to the RO resources<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-9>

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<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-1>

  *   Grant Client (GC)<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.1.1>

     *   may want access to resources at a Resource Server<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.1.2.1>
     *   may be interacting with a User and want identity claims about the User<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.1.2.2>
     *   requests the Grant Service to grant resource access and identity claims<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.1.2.3>
  *   Grant Server (GS)<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.2.1>

     *   accepts Grant requests from the GC for resource access and identity claims<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.2.2.1>
     *   negotiates the interaction mode with the GC if interaction is required with the User<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.2.2.2>
     *   acquires authorization from the User before granting identity claims to the GC<https://tools..ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.2.2.3>
     *   acquires authorization from the RO before granting resource access to the GC<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.2.2.4>
     *   grants resource access and identity claims to the GC<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.2.2.5>
  *   Resource Server (RS)<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.3.1>

     *   has resources that the GC may want to access<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.3.2.1>
     *   expresses what the GC must obtain from the GS for access through documentation or an API. This is not in scope for this document<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.3.2.2>
     *   verifies the GS granted access to the GC, when the GS makes resource access requests<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.3.2.3>

Humans<https://tools.ietf..org/id/draft-hardt-xauth-protocol-14.html#section-1.5-3>

  *   User<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.1.1>

     *   the person interacting with the Grant Client.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.1.2.1>
     *   has delegated access to identity claims about themselves to the Grant Server.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.1.2.2>
     *   may authenticate at the GS..<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.1.2.3>
  *   Resource Owner (RO)<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.2.1>

     *   the legal entity that owns resources at the Resource Server (RS).<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.2.2.1>
     *   has delegated resource access management to the GS.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.2.2..2>
     *   may be the User, or may be a different entity that the GS interacts with independently.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.2.2.3>

Reused Terms<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-5>

  *   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.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1..5-6.1>
  *   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.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6.2>
  *   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.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6.3>
  *   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.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6.4>
  *   NumericDate - a NumericDate as defined in [RFC7519<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RFC7519>] Section 2.<https://tools..ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6.5>
  *   authN - short for authentication.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6.6>
  *   authZ - short for authorization.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6.7>

New Terms<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-7>

  *   GS URI - the endpoint at the GS the GC calls to create a Grant, and is the unique identifier for the GS.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.1>
  *   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.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.2>
  *   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.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.3>
  *   Client Handle - a unique identifier at the GS for a Dynamic Client for the Dynamic Client to refer to itself in subsequent requests.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.4>
  *   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>.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.5>
  *   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.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.6>
  *   Grant URI - the URI that represents the Grant. The Grant URI MUST start with the GS URI.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.7>
  *   Access - the access granted by the RO to the GC and contains an access token. The GS may invalidate an Access at any time.<https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.8>
  *   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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

--
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/
--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

---

From: Francis Pouatcha <[email-masked]>
Date: Sun, 16 Aug 2020 22:37:42 -0400

Hello Dick,

Thanks for pointing this out. This is the new diagram where ++++ refers to
what Endpoint/Human interaction and ----> refers to interaction among
services.

    +-------------+                        +----------------+
    | Requesting  |                        |  Resource      |
    | Party (RP)  |                        | Controller (RC)|
    +-------------+                        +----------------+
        +     +                             +
        +      +                           +
       (A)     (B1)                      (C1)
        +        +                       +
        +.        +                     +
        +       +--------+         +--------+
        +       | RP-AS  |         | RC-AS  |
        +  +--->|        |     +-->|        |
        +  |    +--------+     |   +--------+
        +  |                   |
        + (B0)                 |
        +  |                  (C0)
    +--------+                 |             +------------+
    | Grant  |--------(1)------|------------>|  Resource  |
    | Client |                 |             |   Server   |
    |  (GC)  |       +---------------+       |    (RS)    |
    |        |--(2)->|     Grant     |       |            |
    |        |<-(3)->|     Server    |- (6) -|            |
    |        |<-(4)--|      (GS)     |       |            |
    |        |       +---------------+       |            |
    |        |                               |            |
    |        |--------------(5)------------->|            |
    +--------+                               +------------+

It is still important to know what is part of the protocol:
Alt-1: only (1..6). This is what you specified in section 1.2, and I am
fine with that.
Alt-2: Alt-1 + (B0, C0). This is a result of the discussion we have been
having around privacy, GS as big brother, aso...

P.S.: an authentication [RP]+++(A)+++>[GC] can be assumed, but shall be
irrelevant for the protocol. [RP]+++(B1)+++>[RP-AS] is important for later
instantiation of the model. As in many cases, like in oAuth [RP-AS] could
be the same entity like [GS].

Best regards.
/Francis

On Sun, Aug 16, 2020 at 7:04 PM Dick Hardt <[email-masked]> wrote:

> I debated keeping the interactions abstract and not stating "what"
> happened in each interaction, but thought that might be confusing at this
> stage or our discussions.
>
> Since it is just an interaction between human and software, we can have
> the User authenticate to the GC as well as authorize (provide consent), and
>> (B) I which the GS never interacts with the "Requesting Party" in a
>> matter of obtaining a grant to a resource (many reasons: privacy,
>> confidentiality, abstraction, ...). Generally the GS will need information
>> (claims) about the "Requesting Party" to proceed with the authorisation
>> decision. In this case, the GS can instruct the GC to obtain those claims.
>> In some cases, claims on the "Requesting Party" will be obtained from
>> another "Authorization Server" (AS). The word AS is intentionally chosen
>> here. In this same login, the path (C0, C1) below will not only return the
>> RC consent, but might also return some claims on RC.
>>
>> Off-topic: The splitting of GS and AS was suggested in some discussions
>> on the mailing list. But we have no mean yet to isolate good inputs for
>> later reuse. This is why I suggest we compile some inputs into tickets or
>> wiki pages (like use cases).
>>
>> 1.4:
>>> 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.
>>> (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.
>>> 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)
>>> (6) The RS evaluates access granted by the GS to determine access
>>> granted to the GC
>>> (A) User trusts the GSO to acquire authorization before making a grant
>>> to the CO
>>>       - requests the Grant Service to grant resource access and
>>>       identity claims
>>>    - accepts Grant requests from the GC for resource access and
>>>       identity claims
>>>       - expresses what the GC must obtain from the GS for access
>>>       through documentation or an API. This is not in scope for this document
>>>    - *Grant URI* - the URI that represents the Grant. The Grant URI
>>>    MUST start with the GS URI.

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 17 Aug 2020 08:13:11 +0200

Not necessarily. It is a human when user=RO (which is indeed a very common
case).
But when the 2 roles are handled by different persons, then most often we
end up using an automated policy engine.

Cheers
Fabien

Le lun. 17 août 2020 à 01:59, Mark Lizar <[email-masked]> a écrit :

> - consent is the human management of a permission grant the system manages
> .   +1 for not mixing human and system terms for the same endpoint.
>
> Get Outlook for iOS <https://aka.ms/o0ukef>
> ------------------------------
> *From:* TXAuth <[email-masked]> on behalf of Tom Jones <
> [email-masked]>
> *Sent:* Sunday, August 16, 2020 7:38:13 PM
> *To:* Francis Pouatcha <fpo=[email-masked]>
> *Cc:* GNAP Mailing List <[email-masked]>; Dick Hardt <
> [email-masked]>
> *Subject:* Re: [GNAP] draft-hardt-xauth-protocol-14 update - reworked
> introduction
>
> I would title this "End User" interaction and not "human .....". It is not
> I will still insist on replacing the word "User" with a role name.. Maybe
> <https://tools.ietf..org/id/draft-hardt-xauth-protocol-14.html#section-1.3-5>
>
> <https://tools.ietf..org/id/draft-hardt-xauth-protocol-14.html#name-trust-model>
>
> <https://tools.ietf..org/id/draft-hardt-xauth-protocol-14.html#name-terminology>
>
> *Roles*
>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14..html#section-1.5-2.2.2.2>
>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14..html#section-1.5-2.3.2.3>
>
> *Humans*
>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4..2.2.1>
>       <https://tools..ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.2.2..2>
>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1..5-6.1>
>    <https://tools.ietf..org/id/draft-hardt-xauth-protocol-14.html#OIDC>] Section
>    <https://tools..ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6.5>
>    <https://tools..ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.1>
>    <https://tools..ietf.org/id/draft-hardt-xauth-protocol-14.html#InteractionModes>
>    .
>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1..5-8.8>

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 17 Aug 2020 12:56:03 +0200

Hi Francis,

I like that alt2 introduces the additional discussions we had previously
(on privacy and other topics) but I think this schema is too prescriptive.

Depending on the situation, one may either require the GS to provide the
front-channel, or decide to separate it.
Why mandate that interaction B shall always occur through the GC? If I' a
GC, I could just as well decide that it's enough to just separate the
front-channel from the GS, without handling it myself.
Why mandate that interaction C shall always occur through a GS? (I'm sure
Denis will not want this, for instance).
Are we sure we need to formally separate B and C? This goes beyond previous
discussions of separating the front and back channels, and I don't really
see the advantage (maybe there is: which use cases would be impossible to
do otherwise?).

So overall, I think Alt2 over-complexifies the situation. We need to remain
flexible.
Why not simply have an (optional) way of separating these flows from the
GS?

For instance, an (optional) Interact Server (IS) could provide support for
a decoupled front-channel:
- it does not change the interaction between a GC and a GS. It does change
the trust model though, depending on which options are chosen. In practice,
the GC may specify which IS it wants to use (it can be his own, for
instance). In case nothing is specified, the GS decides.
- the IS is able to handle the front-channel for idclaims and consent, and
return back to the GS what access tokens are required.
- notice that although the IS is focused on front-channel interaction,
there are cases where the consent needs to be based on policies instead of
a direct human interaction (typically when end-user is not the RC, and
therefore the end-user is not the one that is asked for consent / then of
course, if the RC logs in, he would be able to manage his consent
policies).

So there's really no obligation that B occurs through the GC and C occurs
through the GS. It depends on where your front-channel is located (GC, GS,
third-party).
This I think makes it a very flexible model, while enabling what we're
after.

Fabien

On Mon, Aug 17, 2020 at 4:38 AM Francis Pouatcha <fpo=
[email-masked]> wrote:

>>>> https://tools..ietf.org/id/draft-hardt-xauth-protocol-14.html
>>>> <https://tools.ietf..org/id/draft-hardt-xauth-protocol-14.html>
>>>>
>>>> Highlights:
>>>>
>>>>    - Reworked diagram an intro to focus on Grant, and separate
>>>>    protocol roles from human interactions.
>>>>
>>>> *The use of GNAP in this document is not intended to be a declaration
>>>> of it being endorsed by the GNAP working group.*
>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14..html#section-1.2-1>
>>>>
>>>> <https://tools..ietf.org/id/draft-hardt-xauth-protocol-14.html#name-human-interactions>
>>>>
>>>> *(A) The User is interacting with a GC, and the GC needs resource
>>>> access and/or identity claims (a Grant)*
>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14..html#section-1.4-1>
>>>>
>>>> These three entities do not interact in the protocol, but are trusted
>>>> by the User and the Resource Owner:
>>>> (B) User trusts the CO to act in the User's best interest with the
>>>> Grant the GSO grants to the CO
>>>>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14..html#section-1.5-2.2.2.1>
>>>>       - has delegated access to identity claims about themselves to
>>>>       the Grant Server.
>>>>    - *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
>>>>    <https://tools..ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.5>

---

From: Francis Pouatcha <[email-masked]>
Date: Mon, 17 Aug 2020 07:27:49 -0400

Hello Fabian, inline

> (on privacy and other topics) but I think this schema is too prescriptive.
This is why I pushed them into Alt-2.
In the most common use case at sight (oAuth2), GS, RC-AS,  RP-AS are roles
that might be represented by the same entity. This means the oAuth2
instantiated model might look very simple.

> front-channel, or decide to separate it.
Yes. This is why exposing RC-AS in the diagram makes that case visible. In
those situations, [GS]=[RC-AS]=[RP-AS]=GS resulting  in the original model
of Dick.

> front-channel from the GS, without handling it myself.
Having GS +++(B)+++> RP is the oAuth2 model again. THis is what Dick has in
the original diagram.

There are some cases where GS might need to gain knowledge of some claims
about RP, but do not need to know their identity. E.g.: age(RP) > 18.
In those cases [GS] --(3)-->[GC]++(B)++>[RP] makes sense.

And in some cases RP-AS resides on RP's device (SSI). And we find ourself
with:
[GS] --(3)-->[GC]-->(B0)-->[RP-AS]++(B1)++>[RP]

> Denis will not want this, for instance).
This is not a mandate, but an abstract model. In SSI/DID most of the time,
RP-RC will also reside on a user device.

> see the advantage (maybe there is: which use cases would be impossible to
We have a situation where RP =!= RC. And each of them have their own AS.

> So overall, I think Alt2 over-complexifies the situation. We need to
> remain flexible.
With GNAP, we are at an abstraction level-0, like referred to in my former
post. At level-1 we can address concrete protocols like oAuth, OIDC,
[SSI/DiD/VC] and the diagram will look simple.

> course, if the RC logs in, he would be able to manage his consent
What you mention here is why I display RP-AS and RC-AS!

> through the GS. It depends on where your front-channel is located (GC, GS,
Yes. I agree with you. How can we make this  visible in a diagram?

> after.
Yes.
/Francis

> [email-masked] <40adorsys.de@dmarc..ietf.org>> wrote:
>
>> Hello Dick,
>>
>> Thanks for pointing this out. This is the new diagram where ++++
>> refers to what Endpoint/Human interaction and ----> refers to interaction
>> among services.
>>
>> having around privacy, GS as big brother, aso....
>>
>>>> I would title this "End User" interaction and not "human ...". It is
>>>> not about having a human, but a terminating edge of the protocol. An "End
>>>> User" can be either human on an IOT device or a car or ...
>>>>
>>>> ASs provide authentication "of" and consent collection "from" End
>>>> Users. End users are in this case the Requesting Party, and the Resource
>>>> Controller).
>>>>
>>>> The Trust model introduces what I would rather call the trust
>>>> framework. The purpose of the trust framework will be to address topics
>>>> mentioned in this section. There is still a lot of discussion needed to
>>>> have a structure for this section.
>>>>
>>>>
>>>> 1.5
>>>>> <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:*
>>>>> ] & [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#name-protocol-roles>
>>>>>
>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14..html#section-1..2-1>
>>>>>
>>>>> (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.
>>>>> <https://tools..ietf..org/id/draft-hardt-xauth-protocol-14.html#name-human-interactions>
>>>>>
>>>>> <https://tools..ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-5>
>>>>>
>>>>> (1) The GC may query the RS to determine what the RS requires from a
>>>>> GS for resource access
>>>>>    - *Grant Server Owner* (GSO) - the legal entity that owns the
>>>>>    Grant Server.
>>>>>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.1..2.3>
>>>>>    -
>>>>>
>>>>>    *Grant Server* (GS)
>>>>>       <https://tools.ietf..org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.3.2.1>
>>>>>       - may authenticate at the GS...
>>>>>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1..5-4.2.2.1>
>>>>>    ] Section 1.4.. An GC uses an access token for resource access at
>>>>>    a RS.
>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#OIDC>
>>>>>    ] Section 5. Claims are issued by a Claims Issuer.
>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6..2>
>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1..5-6.3>
>>>>>    <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.
>>>>>    - *GS URI* - the endpoint at the GS the GC calls to create a
>>>>>    Grant, and is the unique identifier for the GS.
>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14..html#section-1.5-8.7>
>>>>>    - *Access* - the access granted by the RO to the GC and contains
>>>>>    an access token. The GS may invalidate an Access at any time.

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 17 Aug 2020 14:16:49 +0200

Hi Francis,

Thanks for your comments. Mine are inline (marked with "FI"). I think most
of that is clear now (except from the way to make it visible on a diagram).

I'd actually like to focus more specifically on the previous exchange:

> In most cases, getting the asynchronous consent from the RC (distinct
from the end-user) would be an issue (unless the end-user is ok to wait).
> Here I guess you're considering the case where you want to interactively
ask the RC (distinct from the end-user) to consent, instead of making a
policy based decision.

A practical scenario where we may encounter a synchronous consent request
between distinct end-user/RP and RC: a patient has a medical appointment
with a new doctor.
The doctor needs to access the medical record of the patient. Here the
doctor is the end-user/requestor and the patient is the RC.
Since they're already interacting face to face (physically or through
video), the patient takes his decision (yes/no for each requested item) as
soon as the doctor asks him to provide some information.

Is this type of synchronous interaction what you had in mind?

As for SSI, I think there should be a dedicated use case.

Cheers
Fabien

On Mon, Aug 17, 2020 at 1:28 PM Francis Pouatcha <[email-masked]> wrote:

> FI ; yes

> Having GS +++(B)+++> RP is the oAuth2 model again. THis is what Dick has
> in the original diagram.
>

FI : yes, although in practice most verified credentials are bundled with
some claims about identity. Like I'm a student in a bar, I'm going to show
the proof of age (instead of date of birth) but am still required to show
my name too (or a picture, or whatever that proves I didn't get a proof
which belongs to someone else).

> [GS] --(3)-->[GC]-->(B0)-->[RP-AS]++(B1)++>[RP]

FI : this type of interaction with SSI wallets directly on the mobile
device would be interesting to dig into. If it hasn't been done yet, we
should add a use case.

> RP-RC will also reside on a user device.

FI : problem is that if you show that, most people will assume it's
mandatory (as least for the alt2 part). At least I think that's what most
readers would assume from reading the schema.

> Are we sure we need to formally separate B and C? This goes beyond
>> previous discussions of separating the front and back channels, and I don't
>> really see the advantage (maybe there is: which use cases would be
>> impossible to do otherwise?).
>>

FI : see discussion at the start of the message

> [SSI/DiD/VC] and the diagram will look simple.

FI : yes.

>
>
>> For instance, an (optional) Interact Server (IS) could provide support
>> for a decoupled front-channel:
>> - it does not change the interaction between a GC and a GS. It does
>> change the trust model though, depending on which options are chosen. In
>> practice, the GC may specify which IS it wants to use (it can be his own,
>> for instance). In case nothing is specified, the GS decides.
>> - the IS is able to handle the front-channel for idclaims and consent,
>> and return back to the GS what access tokens are required.

FI : let me think about it ;-)

>>>> In the abstract diagram in 1.3, I show the interactions between the
>>>> User and the GC, the User and the GS, and the RO and the GS. These are NOT
>>>>> Off-topic: The splitting of GS and AS was suggested in some
>>>>> discussions on the mailing list. But we have no mean yet to isolate good
>>>>> inputs for later reuse. This is why I suggest we compile some inputs into
>>>>> tickets or wiki pages (like use cases).
>>>>>
>>>>> 1.4:
>>>>>> 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:
>>>>>> (A) User trusts the GSO to acquire authorization before making a
>>>>>> grant to the CO
>>>>>>       - may be interacting with a User and want identity claims
>>>>>>       about the User
>>>>>>       - 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
>>>>>>    - *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
>>>>>>    - *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.

---

From: Francis Pouatcha <[email-masked]>
Date: Mon, 17 Aug 2020 10:01:56 -0400

Hello Fabian,

> Is this type of synchronous interaction what you had in mind?
Yes. There are a lot of such use cases in banking, government, health.

>> In the most common use case at sight (oAuth2), GS, RC-AS,  RP-AS are
>> roles that might be represented by the same entity. This means the oAuth2
>> Yes. This is why exposing RC-AS in the diagram makes that case visible.
>> In those situations, [GS]=[RC-AS]=[RP-AS]=GS resulting  in the original
>> model of Dick.
>>
>>
>>> Why mandate that interaction B shall always occur through the GC? If I'
>>> a GC, I could just as well decide that it's enough to just separate the
RP-AS will verify RP identity and produce different RP-identifiers for each
grant negotiation use case [GC,RS,GS], thereby preservice RP privacy and
preventing correlations.

> device would be interesting to dig into. If it hasn't been done yet, we
Yes...

>>
>>> Why mandate that interaction C shall always occur through a GS? (I'm
>>> sure Denis will not want this, for instance).
>>>
>> This is not a mandate, but an abstract model. In SSI/DID most of the
>> time, RP-RC will also reside on a user device.
>>
>
Therefore it is essential to have Dick introduce the section 1.3 with the
notion that this is an abstract model that might take a different concrete
form for each problem domain (resp. trust model)

errata: Above i meant [RP-AS will also reside on a user device] and not
[RP-RC].
/Francis

>> With GNAP, we are at an abstraction level-0, like referred to in my
>> former post. At level-1 we can address concrete protocols like oAuth, OIDC,
>>> So there's really no obligation that B occurs through the GC and C
>>> occurs through the GS. It depends on where your front-channel is located
>>> (GC, GS, third-party).
>>>
>>>> Alt-2: Alt-1 + (B0, C0). This is a result of the discussion we have
>>>> been having around privacy, GS as big brother, aso....
>>>>
>>>>> Since it is just an interaction between human and software, we can
>>>>> have the User authenticate to the GC as well as authorize (provide
>>>>> consent), and have no interaction at the GS. We would need to define how to
>>>>> represent the authorization and the consent for the GC to pass to the GS,
>>>>> but the roles and entities stay the same. The trust model does change
>>>>> though.
>>>>>
>>>>> /Dick
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> (B0, B1) replace (B). Occur inside step (3), GS asks GC to collect
>>>>>> the claims. GC contacts RP-AS to negotiate those claims. But it is
>>>>>> important to mention that those Claims-RP are not the target Grant being
>>>>>> negotiated for the resource access. They are generally used by GS (and
>>>>>> later RS) as input into performing authz decisions.
>>>>>>
>>>>>>> *The use of GNAP in this document is not intended to be a
>>>>>>> declaration of it being endorsed by the GNAP working group.*
>>>>>>> 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)
>>>>>>> In addition to the User and the Resource Owner, there are three
>>>>>>> other entities that are part of the trust model:
>>>>>>> These three entities do not interact in the protocol, but are
>>>>>>> trusted by the User and the Resource Owner:
>>>>>>>    ] Section 1.4.. An GC uses an access token for resource access
>>>>>>>    at a RS.
>>>>>>>    - *Client ID* - a GS unique identifier for a Registered Client
>>>>>>>    as defined in [RFC6749
>>>>>>>    - *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.

---

From: Fabien Imbault <[email-masked]>
Date: Tue, 18 Aug 2020 10:57:42 +0200

Hi Francis,

To clarify the various interaction modes, I've entered a new use case:
https://github.com/ietf-wg-gnap/general/wiki/Categories-of-interaction
Compared to the other cases, I think the use case "User != RO and
interact_mode = synchronous" is challenging, but SSI could be of great
help.

I've also entered a SSI use case:
https://github.com/ietf-wg-gnap/general/wiki/SSI-integration (very high
level, more as a reminder for now).

Fabien

On Mon, Aug 17, 2020 at 4:02 PM Francis Pouatcha <[email-masked]> wrote:

>> Thanks for your comments. Mine are inline (marked with "FI"). I think
>> most of that is clear now (except from the way to make it visible on a
>> diagram).
>>
>> > Here I guess you're considering the case where you want to
>> interactively ask the RC (distinct from the end-user) to consent, instead
>> of making a policy based decision.
>>
>>>> I like that alt2 introduces the additional discussions we had
>>>> previously (on privacy and other topics) but I think this schema is too
>>>> prescriptive.
>>>>
>>>> Depending on the situation, one may either require the GS to provide
>>>> the front-channel, or decide to separate it.
>>>>
>>> There are some cases where GS might need to gain knowledge of some
>>> claims about RP, but do not need to know their identity. E.g.: age(RP) >
>>> 18.
> RP-AS will verify RP identity and produce different RP-identifiers for
> each grant negotiation use case [GC,RS,GS], thereby preservice RP privacy
> and preventing correlations.
>
>
>>
>>>
>>> And in some cases RP-AS resides on RP's device (SSI). And we find
>>> ourself with:
>>>> Why not simply have an (optional) way of separating these flows from
>>>> the GS?
>>>>
>>>>> Alt-1: only (1..6). This is what you specified in section 1.2, and I
>>>>> am fine with that.
>>>>> P.S.: an authentication [RP]+++(A)+++>[GC] can be assumed, but shall
>>>>> be irrelevant for the protocol. [RP]+++(B1)+++>[RP-AS] is important for
>>>>> later instantiation of the model. As in many cases, like in oAuth [RP-AS]
>>>>> could be the same entity like [GS].
>>>>>
>>>>> Best regards.
>>>>> /Francis
>>>>>
>>>>>
>>>>>>> The result can look like the modified diagram below. With this we
>>>>>>> can address some privacy concerns that are being discussed on the list.
>>>>>>>
>>>>>>>> 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
>>>>>>>> ] - an extension of OAuth 2.0, as well as other extensions.
>>>>>>>> Related documents include: GNAP - Advanced Features [GNAP_Advanced
>>>>>>>> While GNAP is not backwards compatible with OAuth 2.0, it strives
>>>>>>>> to minimize the migration effort.
>>>>>>>> (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.
>>>>>>>> (1) The GC may query the RS to determine what the RS requires from
>>>>>>>> a GS for resource access
>>>>>>>> Alternatively, the Resource Owner could be a legal entity that has
>>>>>>>> a software component that the Grant Server interacts with for Grant
>>>>>>>>    - *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.
>>>>>>>>       - acquires authorization from the RO before granting
>>>>>>>>       resource access to the GC
>>>>>>>>       - verifies the GS granted access to the GC, when the GS
>>>>>>>>       makes resource access requests
>>>>>>>>       - has delegated access to identity claims about themselves
>>>>>>>>       to the Grant Server.
>>>>>>>>    - *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.
>>>>>>>>    - *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.

---

From: Denis <[email-masked]>
Date: Tue, 18 Aug 2020 19:29:27 +0200

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:

    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:

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

>     <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1>Introduction
> /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./
>
> 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.
>
> browsers now directly support asymetric cryptographic functions. 
> Standards have emerged for signing and encrypting tokens with rich 
> payloads (JOSE) that are widely deployed.
>
> 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.
>
> authorization to grant the Grant to the Grant Client. The Grant Server 
> then returns the Grant to the Grant Client.
>
> 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.
> 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>].
>
> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#GrantResponse>).
>
> 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)
>
>   * *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,
>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1..5>Terminology
>       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
>       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
>   * *access token* - an access token as defined in [RFC6749
>   * *Claim* - a Claim as defined in [OIDC
>   * *Client ID* - a GS unique identifier for a Registered Client as
>     defined in [RFC6749
>   * *ID Token* - an ID Token as defined in [OIDC
>     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
>   * *authN* - short for authentication.
>   * *authZ* - short for authorization.
>
> *New Terms*
>
>   * *GS URI* - the endpoint at the GS the GC calls to create a Grant,
>   * *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
>   * *Interaction* - how the GC directs the User to interact with the
>     GS. This document defines the interaction modes: "redirect",
>     <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#InteractionModes>.
>   * *Grant* - the user identity claims and/or resource access the GS
>   * *Grant URI* - the URI that represents the Grant. The Grant URI
>   * *Access* - the access granted by the RO to the GC and contains an
>   * *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.
>
>
>
>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 18 Aug 2020 10:45:21 -0700

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 <[email-masked]> wrote:

> for resource access.
> The bad news: The text is using a "may" and continues with: "This step is
> not in scope for this document".
>
> Hence, the use of the word "may" is inappropriate. In addition, using the
> singular "for a GS" is also inappropriate since a RS
> from the User,
> Such a definition is inappropriate since a grant is first of all an access
> token issued by an AS that contains attributes and/or
> or from the owner of the resources at the Resource Server, the Resource
> Owner (RO).
>

---

From: Denis <[email-masked]>
Date: Tue, 18 Aug 2020 21:46:06 +0200

Hi Dick,
> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Dick,
>
>     I have taken a look at the specification and there are good news
>     but unfortunately also bad news.
>
>         (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
>     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
>     The text then uses the following sentence which is inappropriate
>     for various reasons:
>
>     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
>     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
>     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
>>
>>     /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./
>>
>>     Authorization Protocol (GNAP). The protocol supports the widely
>>     deployed use cases supported by OAuth 2.0 [RFC6749
>>     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.
>>
>>     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.
>>     (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.
>>
>>     How the GC authenticates to the GS is not in scope for this
>>     document. One mechanism is [JOSE_Authentication
>>     Grant from the User, or from the owner of the resources at the
>>     Resource Server, the Resource Owner (RO)
>>
>>     (1) The GC may query the RS to determine what the RS requires
>>     from a GS for resource access
>>
>>     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.
>>       * *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.
>>
>>     (B) User trusts the CO to act in the User's best interest with
>>     the Grant the GSO grants to the CO
>>
>>           o may be interacting with a User and want identity claims
>>             about the User
>>           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
>>           o acquires authorization from the RO before granting
>>           o verifies the GS granted access to the GC, when the GS
>>           o has delegated access to identity claims about themselves
>>             to the Grant Server.
>>       * *Client ID* - a GS unique identifier for a Registered Client
>>         as defined in [RFC6749
>>       * *GS URI* - the endpoint at the GS the GC calls to create a
>>       * *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.
>>       * *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
>>       * *Grant* - the user identity claims and/or resource access the
>>       * *Grant URI* - the URI that represents the Grant. The Grant
>>       * *Access* - the access granted by the RO to the GC and
>>         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
>     [email-masked] <mailto:[email-masked]>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 18 Aug 2020 12:57:12 -0700

While I disagree with your interpretation of the charter -- I'll give you
another example.

One of my use cases is for the GC to retrieve Claims directly from the GS.
There is no RS, so querying an RS first does not make sense.

ᐧ

On Tue, Aug 18, 2020 at 12:46 PM Denis <[email-masked]> wrote:

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

---

From: Francis Pouatcha <[email-masked]>
Date: Tue, 18 Aug 2020 16:46:08 -0400

Hello Fabien,

Thank you for creating the page. I dropped the first SSI use case at:
https://github.com/ietf-wg-gnap/general/wiki/SSI-integration#alice-purchasing-a-concert-ticket-without-disclosing-her-identity

Best regards
/Francis

>>> A practical scenario where we may encounter a synchronous consent
>>> request between distinct end-user/RP and RC: a patient has a medical
>>> appointment with a new doctor.
>>>> On Mon, Aug 17, 2020 at 6:56 AM Fabien Imbault <
>>>> [email-masked]> wrote:
>>>>
>>>>> Hi Francis,
>>>>>
>>>>> Why mandate that interaction B shall always occur through the GC? If
>>>>> I' a GC, I could just as well decide that it's enough to just separate the
>>>> Having GS +++(B)+++> RP is the oAuth2 model again. THis is what Dick
>>>> has in the original diagram.
>>>>
>>> FI : yes, although in practice most verified credentials are bundled
>>> with some claims about identity. Like I'm a student in a bar, I'm going to
>>> show the proof of age (instead of date of birth) but am still required to
>>> show my name too (or a picture, or whatever that proves I didn't get a
>>> proof which belongs to someone else).
>>>
>>>>>>>> I would title this "End User" interaction and not "human ...". It
>>>>>>>> is not about having a human, but a terminating edge of the protocol. An
>>>>>>>> "End User" can be either human on an IOT device or a car or ...
>>>>>>>>
>>>>>>>>> *This document captures a number of concepts that may be adopted
>>>>>>>>> by the proposed GNAP working group. Please refer to this document as:*
>>>>>>>>> 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.
>>>>>>>>> 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.
>>>>>>>>>       - negotiates the interaction mode with the GC if
>>>>>>>>>    - *Client Handle* - a unique identifier at the GS for a
>>>>>>>>>    Dynamic Client for the Dynamic Client to refer to itself in subsequent
>>>>>>>>>    requests.
>>>>>>>>>    - *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.

---

From: Denis <[email-masked]>
Date: Wed, 19 Aug 2020 10:41:53 +0200

Hi Dick,

> While I disagree with your interpretation of the charter -- I'll give 
> you another example.
>
> One of my use cases is for the GC to retrieve Claims directly from the 
> GS. There is no RS, so querying an RS first does not make sense.

So, let us notice this disagreement.

I was only discussing the very first exchange from the figure inserted 
in section 1.2. The use case you mention has nothing to do with section 1.2.
Moreover, the example you mention is not described, nor illustrated by 
any figure in the draft.

Nevertheless, the use case you mention is straightforward.  A User 
should be able to query at any time both the attributes _/and the 
capabilities,/_
if any, that are registered by the AS. We should define a protocol for 
this retrieval.

BTW, the sentence you are using includes the word "Claims" which is 
currently left undefined, since Section 5 from [OIDC] does not provide
any formal definition for it.

Denis

> On Tue, Aug 18, 2020 at 12:46 PM Denis <[email-masked] 
>>     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
>     ..."
>
>     extensions to OAuth 2.0, and as such *will focus on new
>     technological solutions **
>     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
>
>>     ᐧ
>>
>>         I have taken a look at the specification and there are good
>>         news but unfortunately also bad news.
>>
>>             (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".
>>
>>         Hence, the use of the word "may" is inappropriate. In
>>         addition, using the singular "for a GS" is also inappropriate
>>         since a RS
>>         Please take a look at the uses cases I have posted today
>>         called: "Enterprise servers and Internet servers use cases"
>>         BTW, I don't like the wording "Grant Client" since it is
>>         ambiguous as it does not make any difference between what I call
>>         The text then uses the following sentence which is
>>         inappropriate for various reasons:
>>
>>         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
>>         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
>>             or from the owner of the resources at the Resource
>>             Server, the Resource Owner (RO).
>>
>>         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
>>>
>>>           * Reworked diagram an intro to focus on Grant, and
>>>             separate protocol roles from human interactions.
>>>
>>>         /This document captures a number of concepts that may be
>>>         adopted by the proposed GNAP working group. Please refer to
>>>         this document as:/
>>>
>>>         *XAuth*
>>>
>>>         Authorization Protocol (GNAP). The protocol supports the
>>>         widely deployed use cases supported by OAuth 2.0 [RFC6749
>>>         an extension of OAuth 2.0, as well as other extensions.
>>>         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)
>>>         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
>>>         While GNAP is not backwards compatible with OAuth 2.0, it
>>>         strives to minimize the migration effort.
>>>
>>>         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
>>>         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
>>>         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:
>>>
>>>         (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.
>>>
>>>         (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.
>>>         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)
>>>
>>>         *(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
>>>
>>>         (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.
>>>         In addition to the User and the Resource Owner, there are
>>>         three other entities that are part of the trust model:
>>>
>>>           * *Grant Server Owner* (GSO) - the legal entity that owns
>>>             the Grant Server.
>>>             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:
>>>
>>>         (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
>>>
>>>               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 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 has delegated access to identity claims about
>>>                 themselves to the Grant Server.
>>>               o may be the User, or may be a different entity that
>>>                 the GS interacts with independently.
>>>
>>>         *Reused Terms*
>>>
>>>           * *Client ID* - a GS unique identifier for a Registered
>>>             Client as defined in [RFC6749
>>>             2. ID Tokens are issued by the GS. The GC uses an ID
>>>           * *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.
>>>             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
>>>           * *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 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