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

[Fabien Imbault <[e-mail]>]

Hi Francis,

Thanks a lot for your feedback, never to late :-) - including I hope for my
late answer.

Reviewing the structure of the document might be useful indeed. I've opened
a new issue https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30

As for the rest of your comments B: embedded as a comment with [FI] (i
removed the parts related to the structure of the spec).

Cheers
Fabien


On Tue, Nov 3, 2020 at 11:00 PM Francis Pouatcha <fpo=
[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
>


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


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


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

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

>
>
> Best regards
> /Francis
>
> --
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>