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

[Francis Pouatcha <[e-mail]>]

On Tue, Nov 3, 2020 at 11:00 PM Francis Pouatcha <fpo=[e-mail]<mailto:[e-mail]>> wrote:

B) Current Document

Roles description shall not hold any assumption on the physical structure of the party fulfilling the roles.
[FI] not sure what you mean
 [FP] for example, we assume the AS is a server! In most SSI based use cases, the AS will be running on the user device. See SIOP (https://identity.foundation/did-siop/).

Roles:
-> grant endpoint of the AS: Why is this a post request? This eliminates the chance of having user device hosted AS (no server).
[FI] what would you propose instead?
Would also be interested to understand better the deployment model when there is no server. That's something that was discussed several times but I'm still missing the underlying architecture and use case.
 [FP] See above (SIOP). There will be a lot of identity wallets operated on end user device.

-> Resource Owner (RO) : Authorizes the request? Does it authorize the request or the access to a resource?
[FI] yes, we should make the wording clearer

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

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.
[FI] this should be handled as a specific discussion item. As a reminder, how would you define embedded?

In practice there's at least these modes:
- redirect and redirect back
- redirect to different browser or device
- user code
- CIBA
[FP] This classification is limited.

  *   Redirect: same device, same or different user agents (browser, mobile app, desktop app, ...)
  *   Decoupled: different devices
  *   Embedded : RC carries RO authorization to AS


Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the context of each section.
[FI] could you clarify what you'd expect.  Btw on this topic, there's a more general discussion on whether we should make a distinction or not.
​[FP]: Here:

  *   Resource Access Request: Requesting Access to a resource. Response is an access token (or any type of grant)
  *   Resource Request: Request the resource. Response is the resource (or a corresponding execution)

Token Content Negotiation
--> Not expressed as such. This is central to GNAP and not represented enough  in the document.
[FI] right. This should be a specific discussion item.

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.
[FI] yes that would avoid potential misunderstandings. Although in the end, people will translate RQ into user or end-user most of the time. Cf in definition, currently we have Requesting Party (RQ, aka "user")


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.
[FI] yes

[FP] Will these and into tickets?

Best regards.
/Francis