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

Fabien Imbault <fabien.imbault@gmail.com> Tue, 24 November 2020 04:56 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 A98573A0A9A for <txauth@ietfa.amsl.com>; Mon, 23 Nov 2020 20:56:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.095
X-Spam-Level:
X-Spam-Status: No, score=-0.095 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=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 0ETLAXIh_jGZ for <txauth@ietfa.amsl.com>; Mon, 23 Nov 2020 20:56:03 -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 46FFC3A0A97 for <txauth@ietf.org>; Mon, 23 Nov 2020 20:56:03 -0800 (PST)
Received: by mail-il1-x136.google.com with SMTP id z14so16324765ilm.10 for <txauth@ietf.org>; Mon, 23 Nov 2020 20:56:03 -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=TQA66fd+/+23E6icpgeugowUJP9ocgb/+A/k4rgePY0=; b=rdyIxDEU6sPo2g8Mh5RF742kGG3iph849AaHr9gtsveC8Z4UrX6OSDGAFTEzVIxX6X DrY7MpkRGmVy3Eh/A1JEyg5B6Wwt5s2irf7StSNs5xfTmRCboGH5OCcABBbndvBgT0fP 7ThLuDy8h5a9qztOTegBJ3AmRDT1RSYsx8H6sxOnP0qFSkoMFNfeJLSgXUCOS832hbTC IYt1BR0B0lPDnIWip4X4l8RX4bLKbCge3QTe7ltsnvMfqK+WeDkCFrIuN5uSTocJRlFx RiIs2CuBpL0LS61xoqmhzpC6PWR3CBrk4sJfzyrN+IYc6f3k3xmWA3VgClsr3Gf7IdZS tzMA==
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=TQA66fd+/+23E6icpgeugowUJP9ocgb/+A/k4rgePY0=; b=Zi1X+XJ5cd/dijPM2F7kLXcIhxpsdtAX8mbrR20dJ0HUAlvD3e9KzdZCebUmIdVEBC Cv4lMyK0aYwzPIwGjNaTa7jm38NlLNYkOKRGvefZIXjgcAIypK5KuSv2LRizKorQEQJi oznSqGDnzGTYKA5yvolrxuVjn0CzU+lWSUQ3e3NYTbUeWpp7ooBy0cdP9Rq8LbAkoOAe Rez4qau2K9FVFfY7Qe9w/l+Gx6WEMLT3oKkywIu1DTBfL/TAJHSZMDvXNgtQs5i1lwFA T+HuAKQo2RG3kpWSoi6+dXKw3wnmRwXVBoyDqB75ns5Ep99r6WJfFWJbwl037JMON7X6 sVVA==
X-Gm-Message-State: AOAM530nATz83dcXWugNBNhFL0jofEtbtjTEmrszK1X3NOubIujhqb0C KlxUcBO1YgJkom3aKmxmh7p2eOdLkHfK0dK/wTY=
X-Google-Smtp-Source: ABdhPJxw2HGcp/x3SYaYqYkT2BSfOP9s1A0sH/d5e/rdP8S8lWx5LOZunLaxHYAXcTkzQW/0o7+kNA+8gDLBZL2QsRQ=
X-Received: by 2002:a92:d489:: with SMTP id p9mr2684037ilg.123.1606193761749; Mon, 23 Nov 2020 20:56:01 -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> <CAK2Cwb5ACMxjiph796Lq1U3FZ6Tm_2TCmsKTJZn8Fgc0rzEgZQ@mail.gmail.com> <CAD9ie-vDS9-Cc=cVRc_SDg7z6KxMqySdcfv3ZPSjAzHorZP7UQ@mail.gmail.com> <CAK2Cwb66asqy1MCtW7KNHyW5=H23fWATBds2aKC3Xi88V34=Rw@mail.gmail.com> <CAD9ie-sGRFQMj81g4oWAS=CgHOe5ReDrAXeVzqvW9UL0W0P-Qw@mail.gmail.com> <FR2P281MB0106FEBFFB997265C8A9EF878DE10@FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM> <CAM8feuQiBij5Be2p3he0HwWfC+WaDRVQ6HqEKoq+FfqYJVGNXA@mail.gmail.com> <FR2P281MB0106245AD7828040C4BF0F7E8DE10@FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM>
In-Reply-To: <FR2P281MB0106245AD7828040C4BF0F7E8DE10@FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Tue, 24 Nov 2020 05:55:48 +0100
Message-ID: <CAM8feuQc8Thohftk_=ohNByTvZtxRukdQ3xCzMP3K7zdZBO6Lg@mail.gmail.com>
To: Francis Pouatcha <fpo@adorsys.de>
Cc: GNAP Mailing List <txauth@ietf.org>, Dick Hardt <dick.hardt@gmail.com>, Tom Jones <thomasclinganjones@gmail.com>, Denis <denis.ietf@free.fr>, Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary="0000000000009c0db005b4d320fc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/qsk8wLUilfcQ1i2PkZvxyKvpRG8>
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, 24 Nov 2020 04:56:08 -0000

Hi Francis,

I've thought a bit more to what you said. I think I'll give it a try as a
separate experiment (in code, not in theory). Not that I would expect it to
be included in GNAP, but I kind of like the idea :-)

The direct impact for GNAP would be to think about multiple ASs.

Will let you know.

Fabien


Le mer. 18 nov. 2020 à 13:06, Francis Pouatcha <fpo@adorsys.de> a écrit :

> It would be nice if the protocol was designed at many layers of
> abstraction.
>
>
>    - The first layer shall design abstract protocol flows, without
>    specification of the mode and mechanism of interaction.
>    - The second layer can instantiate the first layer for dedicated
>    interaction. Here we can talk http, we can define interactions that presume
>    server based token generation, we can define interaction that run on user
>    device based token generation.
>
> This is also the fundament of the structure I proposed for the spec (
> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30).
>
> /Francis
>
> ------------------------------
> *From:* Fabien Imbault <fabien.imbault@gmail.com>
> *Sent:* Wednesday, November 18, 2020 6:35 AM
> *To:* Francis Pouatcha <fpo@adorsys.de>
> *Cc:* txauth@ietf.org <txauth@ietf.org>rg>; Dick Hardt <dick.hardt@gmail.com>om>;
> Tom Jones <thomasclinganjones@gmail.com>om>; Denis <denis.ietf@free.fr>fr>;
> Justin Richer <jricher@mit.edu>
> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
>
> Would make sense, but not so easy as we rely heavily on HTTP. Hence the
> discussion about deep links and so on.
>
> An alternative might be provided by wasm/wasi (running a local sandbox on
> your phone, for your own AS), but it's really early stage. This also poses
> another question that Denis has put forward, i.e. how do we handle the
> multiple AS scenario (likely to occur then).
>
> Fabien
>
> On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha <fpo@adorsys.de> wrote:
>
> We are drifting away from the original problem space.
>
>    - My original mention was about the "POST" request, that subsumes that
>    the "AS" is a "Server". Designing a new protocol, we cannot afford this
>    limitation.
>    - I just mentioned SIOP to show a known and closed example? Let us not
>    focus on the device local discovery scheme (like openid:) for now.
>    - As capability of holding private keys on user device evolves,
>    server-based issuing of token will be fading out giving way to device local
>    generation of token.
>
> While designing GNAP, let us assume the AS-Role can be exercised on a user
> device and design the protocol to honor that.
>
> Best regards,
> /Francis
> ------------------------------
> *From:* TXAuth <txauth-bounces@ietf.org> on behalf of Dick Hardt <
> dick.hardt@gmail.com>
> *Sent:* Tuesday, November 17, 2020 1:28 PM
> *To:* Tom Jones <thomasclinganjones@gmail.com>
> *Cc:* Fabien Imbault <fabien.imbault@gmail.com>om>; Denis <denis.ietf@free.fr>fr>;
> GNAP Mailing List <txauth@ietf.org>rg>; Justin Richer <jricher@mit.edu>
> *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
>
> Got it.
>
> So web apps invoke a openid: deep link and hope there is an app to handle
> the openid: scheme? ... and that it is the user's wallet rather than some
> malware that has registered openid: on the mobile device?
>
> A native app can attempt to open a deep link associated with an app, and
> will fail if the app is not there. If the app is there, it will be opened,
> so this can't be used to silently test if an app is present, but it does
> allow a native app to provide an alternative experience if an app is not
> present. I don't think this works with custom schemes ... and I don't know
> how it could work from a web app on the phone with the current Safari APIs.
>
> Apple warns against using custom schemes [1] ... but perhaps they can be
> convinced to make openid: a managed scheme similar to mailto:, tel:,
> sms:, facetime: ?
>
> [1]
> https://developer.apple.com/documentation/xcode/allowing_apps_and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app
>
>
> ᐧ
>
> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <thomasclinganjones@gmail.com>
> wrote:
>
> You are - that is not standard which is opeind://
> This is the one step that still needs to be optimized for SIOP to have
> good UX.
> Peace ..tom
>
>
> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <dick.hardt@gmail.com> wrote:
>
> Hi Tom
>
> I watched your video (I watched at 2X speed)
>
> Looks like the employment website app that is using localhost:8765 to
> communicate with the wallet. Am I correct?
>
> /Dick
> ᐧ
>
> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <thomasclinganjones@gmail.com>
> wrote:
>
> Well, here's a demo. Note that in this case the AS is not online all of
> the time, so it is really implicit flow and the OIDC id-token comes from
> the siop device directly.
> (whether this is front-channel or back channel is no longer an interesting
> question.)
> Now if an always-on AS is required, that is possible, but probably beyond
> the scope of this effort and would require something like an
> agent-in-the-sky (with diamonds).
> here is the link to the 9 min video   https://youtu.be/Tq4hw7X5SW0
> <https://urldefense.us/v2/url?u=https-3A__youtu.be_Tq4hw7X5SW0&d=DwMFaQ&c=2plI3hXH8ww3j2g8pV19QHIf4SmK_I-Eol_p9P0CttE&r=D5lnfoa2MVZWELqVbbz71ooelbP7rVGCjGDSBNvUpYQ&m=ixsudGSr_dhG-SLiatb4Sz9FWslmywnYyZAOLgZxhl8&s=jdLLy0G1JTQCAOBZ6PeUgI0kiCtVJXrru0VToYWlNZ8&e=>
> 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
>
> --
> TXAuth mailing list
> TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
>