Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
Fabien Imbault <fabien.imbault@gmail.com> Thu, 19 November 2020 15:17 UTC
Return-Path: <fabien.imbault@gmail.com>
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 448133A09CC for <txauth@ietfa.amsl.com>; Thu, 19 Nov 2020 07:17:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 74wbE_kfJbKn for <txauth@ietfa.amsl.com>; Thu, 19 Nov 2020 07:17:02 -0800 (PST)
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9ECB3A0B0B for <txauth@ietf.org>; Thu, 19 Nov 2020 07:16:43 -0800 (PST)
Received: by mail-il1-x136.google.com with SMTP id h6so5636828ilj.8 for <txauth@ietf.org>; Thu, 19 Nov 2020 07:16:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0Z+8r11ySq41kExNDUuDLAi1d+BIqvY+Y9ne/rkbkao=; b=pT4fpzh2rV+9f7mzQYnzyTtMCXSlB6Q46RIE+/6VQ7bhce1pzWZTbzh2tPs/IWB9t+ Ii9YojMH9NQp3x3zTh4DG75GERneO289jk/lxhCeVYVr6fkoIskZ99ISpRc20rlH0IIG nZ54l2xBN0rEw2H6egjmbDbkfh4Mbmyn8lusKwYjm3uEWHk91o46KR+E/yPQky/eK7ei C5pszP3Cb7f9UtVEgyfNVKnzrJGRaSAVlNpCFPF68+NtACV1b3VUt2aDOQYQT66WemGl +BQ5I5OJKisra1KUcZssKwx3uzU5haM3LKu6+q3hdkJhDvuTp1//+5v8myULPXJ+rhMZ jLFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0Z+8r11ySq41kExNDUuDLAi1d+BIqvY+Y9ne/rkbkao=; b=Y5YNvqF/SFFfacO/Yq6q9PNS+kF9HOwLKhEnu1LC30fdxGTBr+3ZQ+cl3Eqy4/1mX+ eK/KMtnVJ3DFeAlZaaqzgibCfw3ggtTgv6ZWlE6LDYM4s/0he+zMHRh8PNiHUUJ5jobh k0NbWIV+ABxtSdMVh0kk4u1eIbxL1Yft98zKB1Jz7AaOUxsBelfBFkQVVg96099IZYDg lWYiUNPLiqNsKKwB4fStSjDFrPOke1g5+1VHfdoxG3gSnUSK2/Y7sYWt0VAOZfrbgoP1 M5z9eTDM/fZqEoAt3UP7nqXmC+qnGtGSXzoUoH8RAz19cjsTedFr9lhsDtFm+eqot1t+ Bl4Q==
X-Gm-Message-State: AOAM533TgHgDe7bUr9ft87GEK3+EltxwnujwxZqLRz+dpc6nHH4poaIR 6E9QiY7Q4PTccDFuQ9iFtymOWenSt1CtB49h5jg=
X-Google-Smtp-Source: ABdhPJyeJYwFrIAPDCwDW4D0yXIQgsB0D1AKx6hrN+Ago3ek7z4e+sO4eHZVk/uDXvHJPnb9jmUFalmfWFrVbR3UsSY=
X-Received: by 2002:a92:9a51:: with SMTP id t78mr6211282ili.178.1605799002872; Thu, 19 Nov 2020 07:16:42 -0800 (PST)
MIME-Version: 1.0
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> <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu> <CAK2Cwb4jHMnDqfW=EPUwSi5c+T0bFft9TRQUHUy2s22BjjmKug@mail.gmail.com> <CAM8feuQ=pNLdysthCB-_aqSr1AakO=STn8bYRx46Xie6_giv_A@mail.gmail.com> <CAK2Cwb453q52qtzwiFNz6sNgmgWJGnOUhhVi6BZDjEsUKZx-3w@mail.gmail.com>
In-Reply-To: <CAK2Cwb453q52qtzwiFNz6sNgmgWJGnOUhhVi6BZDjEsUKZx-3w@mail.gmail.com>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Thu, 19 Nov 2020 16:16:31 +0100
Message-ID: <CAM8feuQS-ZoWSBHdP_xr00K9KJqO3nKawEUx+sFJLqiqK+ArEQ@mail.gmail.com>
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, Denis <denis.ietf@free.fr>, GNAP Mailing List <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000025a24405b477370b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/-87X2Pyucxy4MI8T0d1n-gGsNG8>
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: Thu, 19 Nov 2020 15:17:05 -0000
I suppose trusted institutional actors (hospitals, NGO, etc.) might be willing to support that scenario? Just like in SSI, there's a body of work that is concerned with providing identity to people, https://sovrin.org/identity-for-good-program-helps-provide-ssi-to-ngos-and-nonprofits/ But unfortunatly many people won't have access to a phone... Cheers Fabien On Thu, Nov 19, 2020 at 4:01 PM Tom Jones <thomasclinganjones@gmail.com> wrote: > that would certainly work. But my use case of interest is healthcare, and > I cannot imagine forcing users to pay to get an identifier for health care. > The other major problem is the 80% of the world's population that lives in > what you and I consider to be poverty. > Peace ..tom > > > On Wed, Nov 18, 2020 at 10:13 PM Fabien Imbault <fabien.imbault@gmail.com> > wrote: > >> Hi Tom, >> >> My answer is completely speculative. >> But I guess it would probably involve the end-user paying to some sort of >> service provider (just like one pays for having a VPN). With the same >> potential risks (i.e free tiers that serve ads or resell your data, or >> limit volumes of connections)? >> >> Cheers >> Fabien >> >> >> Le jeu. 19 nov. 2020 à 06:23, Tom Jones <thomasclinganjones@gmail.com> a >> écrit : >> >>> Actually that's not the hard problem, which is, once the user wanders >>> off on some path that is not anchored in the browser, how does the path get >>> back to the same place in the browser? >>> This is "straightforward" when the path from siop to some url in the >>> cloud is completely separated from the path between the user and the >>> client, but that is not the path usually taken. >>> We need some new entity to pull this off. Call it the AS proxy if you >>> will. The problem I have with that is who is going to pay the AS proxy? >>> If I can figure that payment issue out, I think I can complete the rest >>> of the flows. >>> >>> Peace ..tom >>> >>> >>> On Tue, Nov 17, 2020 at 9:20 AM Justin Richer <jricher@mit.edu> wrote: >>> >>>> 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). >>>> 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> 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 >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>
- [GNAP] I-D Action: draft-ietf-gnap-core-protocol-… internet-drafts
- Re: [GNAP] I-D Action: draft-ietf-gnap-core-proto… Justin Richer
- [GNAP] Review of draft-ietf-gnap-core-protocol-00 Francis Pouatcha
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Fabien Imbault
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Francis Pouatcha
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Denis
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Fabien Imbault
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Justin Richer
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Tom Jones
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Dick Hardt
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Tom Jones
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Dick Hardt
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Dick Hardt
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Dick Hardt
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Francis Pouatcha
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Fabien Imbault
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Francis Pouatcha
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Fabien Imbault
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Justin Richer
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Fabien Imbault
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Tom Jones
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Fabien Imbault
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Tom Jones
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Fabien Imbault
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Fabien Imbault
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Fabien Imbault
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Fabien Imbault
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Tom Jones
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Justin Richer
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Fabien Imbault
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Tom Jones
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Fabien Imbault
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Tom Jones
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Justin Richer
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Justin Richer
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Tom Jones
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Fabien Imbault
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Tom Jones
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Justin Richer
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Tom Jones
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Fabien Imbault
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Tom Jones
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Fabien Imbault
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Tom Jones
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Fabien Imbault
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Adrian Gropper
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Fabien Imbault
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Francis Pouatcha
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Justin Richer
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Tom Jones
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Fabien Imbault
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Adrian Gropper
- Re: [GNAP] Review of draft-ietf-gnap-core-protoco… Fabien Imbault