[GNAP] Review of draft-ietf-gnap-core-protocol-00

[Francis Pouatcha <[e-mail]>]

sort of late but find below are my initial remarks after the first thorough reading of the draft-ietf-gnap-core-protocol-00.


A) Structure of the document

Grant negotiation is of an importance that requires the draft document to have a clean and understandable structure. This is missing. An example Structure could be:

1- Introduction
2- Abstract Protocol Flow
3- Roles
    3.1- Role 1
        3.1.1 Definition
        3.1.2 Scenario
        3.1.3 Authentication
        3.1.4 Capabilities
    3.2- Role 2
4- Requests
   4.1 Resource Request
   4.2 Access Request
5- Elements
   5.1 Element 1
6. Interactions
   6.1- Interaction Type 1
        6.1.1 Protocol Flow
        6.1.2 Roles/Parties
        6.1.3 Elements
        6.1.4 Requests
   6.2- Interaction Type 2
        6.2.1 Protocol Flow
        6.2.2 Roles/Parties
        ....
   6.3- Interaction Type 3


B) Current Document

Roles description shall not hold any assumption on the physical structure of the party fulfilling the roles.

Roles:
-> grant endpoint of the AS: Why is this a post request? This eliminates the chance of having user device hosted AS (no server).
-> Resource Owner (RO) : Authorizes the request? Does it authorize the request or the access to a resource?


Missing Section Interactions:
--> This section shall introduce the notion of interaction before we start listing interaction types.

Interaction Types:
--> I prefer a classification with Redirect, Decoupled and Embedded is. In the draft, we have one redirect and 2 decouple interactions and nothing else.

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the context of each section.

Token Content Negotiation
--> Not expressed as such. This is central to GNAP and not represented enough  in the document.

Requesting "User" Information
we identify two types of users: RQ and RO. It will be better not to refer to a user in this draft, but either to a RQ or an RO.


Dealing with the RC. Here we need a clean structure:
  -> Identification
     --> Entity vs. Instance
     --> Display Information
  -> Key location, legitimation
     --> Authentication
  -> Capability representation

Dealing with Users? This belongs to two sections:

Handling RQ
  -> Identification
     --> Display Information
  -> Credentials
     --> Authentication

Handling RO
  -> Identification
     --> Display Information
  -> Credentials
     --> Authentication


Interaction Again
-> For each interaction type, we will have to describe the protocol flow and the nature and behavior of involved Roles (Parties), Elements, Requests.



Best regards
/Francis