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

Justin Richer <jricher@mit.edu> Tue, 17 November 2020 17:19 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25383A15B3 for <txauth@ietfa.amsl.com>; Tue, 17 Nov 2020 09:19:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23tdnUi9MrWV for <txauth@ietfa.amsl.com>; Tue, 17 Nov 2020 09:19:07 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE2CB3A1564 for <txauth@ietf.org>; Tue, 17 Nov 2020 09:19:05 -0800 (PST)
Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0AHHJ07a027295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Nov 2020 12:19:00 -0500
From: Justin Richer <jricher@mit.edu>
Message-Id: <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7461F44E-B264-4FF2-AF07-0D9E424C7DE3"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Tue, 17 Nov 2020 12:19:00 -0500
In-Reply-To: <CAM8feuQ346w9EL=-qpJRmMOO_YUp_14gShxcro+pVxnfXTvkzw@mail.gmail.com>
Cc: Denis <denis.ietf@free.fr>, GNAP Mailing List <txauth@ietf.org>
To: Fabien Imbault <fabien.imbault@gmail.com>
References: <160433257633.23038.15047041472414640530@ietfa.amsl.com> <AB11DC08-C6ED-4045-A8F5-872AD263035D@mit.edu> <FR2P281MB01063C2EA739E892B549611D8D110@FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM> <CAM8feuQcCdQFGUKy-ou7H3Ta38yyN1LR+0XJd9WophRMRdPDEA@mail.gmail.com> <FR2P281MB0106C83420ED3F8DF2723BFD8DE30@FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM> <5b8ac79b-0c0e-18e9-9f80-b5d79e9ae59b@free.fr> <CAM8feuQ346w9EL=-qpJRmMOO_YUp_14gShxcro+pVxnfXTvkzw@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/dzGJr5zbvWj9wBHxuh2Ta4JaZko>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Nov 2020 17:19:15 -0000

Ultimately, in most situations like these in the real world, the hurdle isn’t technical compatibility so much as it is trust compatibility. The RP (client) needs to have some incentive to trust the assertions and identity information that’s coming from the AS. The same is true for an RS trusting tokens from the AS. The hard question is less “how” to do that (which SSI answers), but more “why” to do that (which SSI doesn’t answer very well, because it’s a hard question).

Still: it’s definitely a question about how to support this “AS on device” element. We’ve got the start of it more than OAuth2/OIDC have by allowing the bootstrap of the process from a starting call: the interaction and continuation URIs handed back by the AS don’t need to be the same URIs that the client starts with, so just like SIOP the process can start in HTTP and potentially move to other communication channels. A major difference is that we aren’t dependent on the assumption that the user will always be in a browser at some stage, and so the whole raft of front-channel messages that SIOP relies on doesn’t fly. That said, we’ve got an opportunity to more explicitly open up alternative communication channels here, and that’s something I’d like to see engineered, even if it’s an extension. I’d love to see a concrete proposal as to how that would work over specific protocols, starting with what we’ve got today. 

 — Justin

> On Nov 17, 2020, at 12:03 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:
> 
> 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 <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 <denis.ietf@free.fr <mailto:denis.ietf@free.fr>> 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/ <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
> TXAuth@ietf.org <mailto:TXAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> TXAuth mailing list
> TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth