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

[Denis <[e-mail]>]

Hello  Francis,

See two comments in line.

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

I browsed through the two drafts, i.e. :

  * Decentralized Identifiers (DIDs) v1.0 Core architecture, data model,
    and representations W3C Working Draft 08 November 2020
  * Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working
    Group Draft

At no place within these two documents, it is possible to imagine that 
"the AS will be running on the user device".

 From section 3 of the DIF Working Group Draft:

       "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the 
SIOP will not return an access token to the RP".

An Identity Wallet is not an AS.

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

See the above comment. Please, do not confuse an Identity Wallet with an 
Authentication Server (AS).

Denis

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