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

[Fabien Imbault <[e-mail]>]

Hi Denis, hi Francis,

At some point integration with SSI (on the authentication side) will
probably occur, including amongst other possibilities SIOP (since they work
with OpenID a part of the work will probably be made easier).

That being said, Denis is right. It's not an AS. Technically it's entirely
possible to rely on a decentralized wallet (for instance on your phone) and
a centralized AS. I know of a few studies on how to decentralize the AS
itself (for instance
https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-02).
Maybe it exists, but I'm still looking for real scenarios (or even
architectures) where an AS is deployed directly on a phone, and under the
sole authority of the RO, while being compatible with the rest of the
world.

Cheers,
Fabien

On Tue, Nov 17, 2020 at 5:45 PM Denis <[e-mail]> wrote:

> 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
>
>
>
> --
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>