Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
Fabien Imbault <fabien.imbault@gmail.com> Mon, 08 February 2021 16:44 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 80BD83A118E for <txauth@ietfa.amsl.com>; Mon, 8 Feb 2021 08:44:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 FQX7yWfFVDhw for <txauth@ietfa.amsl.com>; Mon, 8 Feb 2021 08:44:21 -0800 (PST)
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 F05463A118C for <txauth@ietf.org>; Mon, 8 Feb 2021 08:44:20 -0800 (PST)
Received: by mail-il1-x135.google.com with SMTP id a16so13355439ilq.5 for <txauth@ietf.org>; Mon, 08 Feb 2021 08:44:20 -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=txdzOIBQ7SQHtyz3xEn+4ngDWi9DLvGYuVNRbNg08pc=; b=o+EJtTV+IU5lTTQvd+LSmCtY3OOnyEX9LIBmdv4rGUNkk0i/E1r+m5KPw/Tv4LKPH4 qgMpWRFqT+0h2rd+NTFtNgPi0OQqXeCXfNfItAeK6fdFgrAB28I3q71N1yBv0rbgkoUf f+I//J/kKDTl4BJBKBfEXi6uN0RPzNZj0N3/8SIv71ZgOxT6xMDpPzSPSTvJoiTRWNLC ijSKZ+F3g38SegVRMnFkApYsc5/t7vCRNlYCP5zTEvG5qjXlWQCxQSVEPywM6JlMe2mk 2vnxVO+8sb1c/ueyI5hbpFEGpuwbYBhLEzdpjld15ZMFiSm/eBxthDh3Py9mooJDXzeS CSpQ==
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=txdzOIBQ7SQHtyz3xEn+4ngDWi9DLvGYuVNRbNg08pc=; b=RUhSZby8v3+i9XgTuoMVOFFeKBypJX0AIwOOiNGT+q52dHwYiYSTcMPJlvhVQwqWEd u4BHW04A7FXp/1zf1HbE6pA6aqPVbClmVHlk+GW/S89i0t1XoS5zTcoy9f1tCpYBjjfX xHbhEcxI3ZhhtvTmHFM6euU2Uy494qKLhFCZ1q2iUF1LrNGaebSXcRjedRFZ79+MvqA8 czzNs/msy8fAGz44UaYpu3bLF+dSvrdXJ9pTa6PW6ocZGUC+9nUXYJuQhv2SW+81vEc1 FmKpruQ0ewD20G9+DCqKlqDn0rKC2+QrnHdkrfW0PXF/GJgCGWJcBfRDpTEtGjoOw8Dx UtNw==
X-Gm-Message-State: AOAM532fkX+nQB3e6QSXDBGR5ISbxXlxrOvK4UiBXRYUqzw0i+nTYHto igkGaGg/0YImpQzwQ38tKoWaK6YNduv6nArEgcL4khQNkB8Tcw==
X-Google-Smtp-Source: ABdhPJzftUWmTQDxL5c9OxaygK3NXGrasy9zrBL2sa+G2PrBGcg5dn10m0zw8UyrsxJGvQdufZYw9X+GTuBAP3BBpNo=
X-Received: by 2002:a05:6e02:1a03:: with SMTP id s3mr17236160ild.178.1612802660039; Mon, 08 Feb 2021 08:44:20 -0800 (PST)
MIME-Version: 1.0
References: <CANYRo8i=T8bET2K+E0V62iZHxTpVi=ax3of6c6CywUXbTPi9rw@mail.gmail.com> <CAM8feuSQ1_1j=RwHyHnfLGY-WPabaBmjbEUYxdZ2UjDEH5nhqQ@mail.gmail.com> <FR2P281MB0106C0A62253D04A1070873F8DB09@FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM> <7A612194-5C4B-4658-B7F0-E6058D044255@mit.edu> <CAK2Cwb78Ro8EHFkE9O9kCw-2PmCC7BrXh1Th8QGSBewNeVQ1qg@mail.gmail.com> <CAM8feuTOrQ-W7WU0SJ0ZrVKaOfAmhNoCj4qMY8ivbO96mXCzSA@mail.gmail.com> <FR2P281MB010640AE444469D9441687578D8F9@FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM>
In-Reply-To: <FR2P281MB010640AE444469D9441687578D8F9@FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Mon, 08 Feb 2021 17:44:08 +0100
Message-ID: <CAM8feuRoQZa3xM7w17MrumKpT9ZW2RCjB8kA7ce9UQOGhP2wyA@mail.gmail.com>
To: Francis Pouatcha <Francis.Pouatcha@adorsys.com>
Cc: Tom Jones <thomasclinganjones@gmail.com>, Justin Richer <jricher@mit.edu>, Francis Pouatcha <fpo@adorsys.de>, Adrian Gropper <agropper@healthurl.com>, txauth gnap <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a502fe05bad5e14b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/V78a0xtwDvcnhLEXJoGV_p5vAKI>
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: Mon, 08 Feb 2021 16:44:26 -0000
Hi, virtual interim meeting on 2021-02-10 from 16:00 to 17:00 UTC https://intuit.zoom.us/j/99481776837?from=addon - Review of changes since IETF109 (including edits since -03) - Interaction mode changes (issue #122) - Discussion of next steps Cheers. Fabien On Mon, Feb 8, 2021 at 5:33 PM Francis Pouatcha < Francis.Pouatcha@adorsys.com> wrote: > Hello Fabian, > > what time is the interim Meeting on Wednesday? > > Can you forward the invite? > > Best regards, > /Francis > ------------------------------ > *From:* Fabien Imbault <fabien.imbault@gmail.com> > *Sent:* Monday, February 8, 2021 9:57 AM > *To:* Tom Jones <thomasclinganjones@gmail.com> > *Cc:* Justin Richer <jricher@mit.edu>; Francis Pouatcha <fpo@adorsys.de>; > Adrian Gropper <agropper@healthurl.com>; txauth gnap <txauth@ietf.org> > *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 > > +1 > The interim meeting planned on Wednesday will be a good opportunity to > discuss interactions ! > > Fabien > > On Mon, Feb 8, 2021 at 2:22 PM Tom Jones <thomasclinganjones@gmail.com> > wrote: > > Justin +1 > > thx ..Tom (mobile) > > On Mon, Feb 8, 2021, 5:19 AM Justin Richer <jricher@mit.edu> wrote: > > I agree that the focus of this group does need to be on an HTTP-based AS — > this particular use case is the one that we have to solve for, and that’s > why those details are called out in the charter. We aren’t here to try to > build a transport-independent security language, with abstractions and > bindings and things of that sort. But that said, the “on-device AS” use > case is being brought up a lot, and solutions have been hacked together in > the OAuth 2 world in several different ways. As such, we as a WG should be > paying attention to them, and if there are things we can do in our design > to allow for that kind of deployment then we need to consider them. That > doesn’t mean we have to have that fully specified in the core protocol, but > if there’s a way to design this so that it can be extended in that > direction without the kind of hacks that the OAuth 2 solutions have to rely > on, then it’ll be better for everyone. This can’t distract us from solving > the core use cases, or drive us to making the core so complex that it > becomes irrelevant, but we shouldn’t be blind to these other possibilities. > > In my opinion as a contributor, the best opportunities we have for that > kind of extension in the way the protocol’s built right now are in the > interaction and continuation pieces of GNAP. Interaction we’ve always known > was going to allow for a move off-browser, and less dependence on > user-in-a-browser is baked into the charter as well. But we need more > experience and more details about :how: that works, and that’s a lot of > what this current conversation is going to be about. You are completely > right that there are another set of challenges, but in my mind it’s that > the trust model is simply different. What do I trust more, a device in my > pocket or a web server in someone else’s data center? There isn’t an easy > or universal answer to that question, as it turns out. > > — Justin > > On Feb 7, 2021, at 5:51 PM, Francis Pouatcha <fpo@adorsys.de> wrote: > > Hello Fabian, > > I am sorry for the delayed reply, but very busy working on those > decentralized use cases where tokens a produced on the user device. > > > Like we can see in this thread, it is not obvious to have those use cases > considered in GNAP (as the GNAP charter mentions reliance on HTTP based AS). > > If the role of an AS is to produce an authorization, a user device hosted > AS can be build, but the negotiation process will be different from the one > defined by GNAP. Means interaction protocol will need more than just HTTP. > > The biggest challenge we are facing on user device produced auth tokens is > on how to preserve those crypto keys held on user device from malware, loss > of device... > > For the moment keeping focus of GNAP on (http) server-based production of > token looks like a good decision. > > I will review the draft sometime as soon as possible and provide my > feedback. > > Best regards, > > /Francis > > ------------------------------ > *From:* TXAuth <txauth-bounces@ietf.org> on behalf of Fabien Imbault < > fabien.imbault@gmail.com> > *Sent:* Friday, February 5, 2021 3:41 PM > *To:* Adrian Gropper <agropper@healthurl.com> > *Cc:* Tom Jones <thomasclinganjones@gmail.com>; txauth gnap < > txauth@ietf.org>; Justin Richer <jricher@mit.edu> > *Subject:* Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00 > > Hi Adrian, > > We would be glad to get your expertise on that. Not sure DIDComm is > essential yet, so far I see it personally as something to look into, > especially for use cases when we want to reach out to a RO. I agree with > the potential issues. > > I have a few ideas on how to implement privacy, but it's quite involved in > terms of crypto (again using Ristretto groups :-)). > > Of course there will be a question of priority in the features we plan to > implement. I guess we should aim for a first publication without the parts > which are blurry, and take the time to prototype the rest. > > Cheers > Fabien > > Le ven. 5 févr. 2021 à 21:19, Adrian Gropper <agropper@healthurl.com> a > écrit : > > There are privacy implications as well as the cost of processing spam. A > service endpoint associated with a DID can be presumed to be a public > broadcast. Any party can attempt to send a message or an authorization > request to that service endpoint. The operator of that service, typically > the DID controller, will bear the cost and risk of processing the message. > They may request a bond be posted by the party responding to the > "broadcast" in order to mitigate spam and phishing. They may also require > that the party seeking to communicate offer credentials, which poses a > privacy risk to that party in the form of phishing "broadcasts" via DIDs > and lures that lead to DIDs. > > In my role as invited expert on privacy to some W3C WGs and, to some > extent, DIF WGs, I have not managed to understand the privacy engineering > and implications in DIDcomm. I will try harder if DIDcomm has an essential > role with GNAP and I can understand it in the self-sovereign or fiduciary > authorization server context. Does it? > > Adrian > > On Fri, Feb 5, 2021 at 1:08 PM Fabien Imbault <fabien.imbault@gmail.com> > wrote: > > Probably (and to be honest even for industrial users I find it complex), > but alternatives are not ready for prime time either. > Maybe some day DIDComm could be useful as a basic block, what we suggest > is to first use that as a potential interaction (and there's already a lot > of questions that arise just from that). > > Fabien > > On Fri, Feb 5, 2021 at 6:55 PM Tom Jones <thomasclinganjones@gmail.com> > wrote: > > No, you didn't misunderstand me. It's just that the ux for that is not > acceptable to retail users. As long as gnap sticks to industrial users you > should do fine. > > thx ..Tom (mobile) > > On Fri, Feb 5, 2021, 7:56 AM Fabien Imbault <fabien.imbault@gmail.com> > wrote: > > Targeting existing browsers and types of applications (web, pwa, mobile, > etc.) seems like a reasonable option for an industrial standard. Improving > security, privacy, ease of use and interoperability (including > decentralized identity as well) should be good enough objectives. > Plus from our previous discussions, I was under the impression you were > fine with the approach of deploying the AS on the phone as a loopback, for > mobile apps. Did I miss something? > > Cheers, > Fabien > > Le ven. 5 févr. 2021 à 16:33, Tom Jones <thomasclinganjones@gmail.com> a > écrit : > > If you mean can GNAP work on old fashioned apps running with existing > browsers and existing identity providers, then yes, i guess you are ok. > > If you want to work on apps where the user is in control of authn and > authz, then no, GNAP cannot work. It is not alone in that OIDC wont work > there either. > > Be the change you want to see in the world ..tom > > > On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault <fabien.imbault@gmail.com> > wrote: > > Hi Tom, > > Thanks, your responses made it clearer for me what you expect from an AS > deployed on a mobile. > > I think we're on the right path to meet the rest of your concerns. There > are already a few items on these: > - privacy preserving techniques have been discussed and are likely to be > included (I think). It's been recognized as a core concern > - not exactly sure the meaning you give to discovery here (it's already > been used in the WG but with a different meaning I believe). The request or > the continuation api provide entry points to pay attention to. > > Is that enough for your use case ? Do you need something else ? (like SSE?) > > Cheers > Fabien > > Le jeu. 4 févr. 2021 à 22:10, Tom Jones <thomasclinganjones@gmail.com> a > écrit : > > discovery is the prime problem. What causes the wallet/AS to wake up and > pay attention. How does the RP know what to ask for without violating user > privacy rights? > > CHAPI would be ok i guess, but that requires cred man to be fixed. Not > sure if it fixes discovery or privacy even then. > > Be the change you want to see in the world ..tom > > > On Thu, Feb 4, 2021 at 12:45 PM Justin Richer <jricher@mit.edu> wrote: > > Tom, what additional functionality do you see that a browser would need to > support in order for GNAP to be adopted? For the elements of the core > protocol today, nothing is needed to change within the browsers — > everything is built on existing functions. GNAP uses browsers as a tool, > and I would argue depends on them even less so than OAuth 2 does. > Extensions could use browser functionality, like using CHAPI to pass > interaction elements, but the core protocol functions on vanilla browsers > today. > > — Justin > > On Feb 4, 2021, at 3:20 PM, Tom Jones <thomasclinganjones@gmail.com> > wrote: > > i assumed that the wallet (aka AS) needed to be a native app, not a PWA > (which can come from a traditional web server). > There are folks, lke Kim C, who are working on a PWA, but i agree the > blocks there seem to be large. > THe blocks on a native app are simple, easy to describe, and easy to ask > the browser guys to fix. Not sure if they care tho. > I have trouble seeing a path to GNAP adoption for retail customers w/o > some browser support. > That's why i am mostly silent here. > > Be the change you want to see in the world ..tom > > > On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault <fabien.imbault@gmail.com> > wrote: > > Fair enough. But loopback limits a lot what you can do... Just for debug > it's a pain. > But as soon as you try more, it's a bit crazy. Fun to test ipv6 (luckily > supported by my ISP) and ddns. But it feels really hacky. > Also deployment is a pain, compared to a traditional webserver. > > Le jeu. 4 févr. 2021 à 20:20, Tom Jones <thomasclinganjones@gmail.com> a > écrit : > > doesn't work very well on windows uwp. works fine on smartphones > Be the change you want to see in the world ..tom > > > On Thu, Feb 4, 2021 at 11:18 AM Justin Richer <jricher@mit.edu> wrote: > > OK, thanks — in that case, there are no changes at all to GNAP, which is > already HTTP driven. The harder parts tend to be where you can’t (or don’t > want to) use something like that. > > — Justin > > On Feb 4, 2021, at 2:16 PM, Tom Jones <thomasclinganjones@gmail.com> > wrote: > > yes, loopback > > Be the change you want to see in the world ..tom > > > On Thu, Feb 4, 2021 at 11:01 AM Justin Richer <jricher@mit.edu> wrote: > > Tom, can you expand on how exactly the back-channel communication works > between on-device components? Do you use HTTP locally? > > Thanks, > — Justin > > On Feb 4, 2021, at 1:03 PM, Tom Jones <thomasclinganjones@gmail.com> > wrote: > > Justin's analysis of use of the front channel is misleading. > It could equally be argued that what i have done is installed an AS on the > phone and the communications with it & the PR is back channel. > Basically the point is that the old OIDC paradigms are no longer valid. > Be the change you want to see in the world ..tom > > > On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault <fabien.imbault@gmail.com> > wrote: > > Yes, issue (#168) message based interaction / DIDComm is a tentative > alternative mecanism for the interaction part. Not sure how that would work > in details though, prototyping will probably help here. > Token delivery through continuation seems fine to me. The client will > probably have to wait for the next polling before it receives a token > issued as the result of an asynchronous interaction, but that's not a big > issue. > > But the AS on the phone seems like a harder nut to crack, at least at > first sight. I think that would be awesome, but it gives me headaches, so I > think I'll work on easier stuff right now ;-) > > Fabien > > On Thu, Feb 4, 2021 at 4:30 PM Justin Richer <jricher@mit.edu> wrote: > > One of the biggest drawbacks of the current app-centric approaches in OIDC > (self-issued OP, or SIOP) is that they depend on using the front channel > and browser redirects to pass everything, which is something that GNAP is > deliberately getting away from by starting in the back channel. > > That said, once a request is kicked off in GNAP, the interaction and > fulfillment can happen through any number of means. Part of the work that’s > being done with the “interaction” section is going to help facilitate this, > and I think that there are some other potential branches here. > > Token delivery is where things get extra weird though — we are explicitly > not delivering tokens in the front channel in the core of GNAP, we’re using > the response from the continuation API. One idea (that isn’t particularly > well thought out and hasn’t been implemented at all) is to have an > extension declare an alternative response from the “continue” section > that’s defined today, which points to the GNPA continuation API. If an > extension defines some alternative way to deliver tokens, that could live > alongside a continuation API and the client could indicate support for it > in its initial request. > > In any event, alternative interaction and delivery methods are important, > and even if we aren’t going to support every last one of them directly, the > protocol design should at least be aware of them. > > — Justin > > On Feb 4, 2021, at 8:35 AM, Fabien Imbault <fabien.imbault@gmail.com> > wrote: > > Hi Tom, > > Sure, any experience on that would be greatly appreciated, we're calling > for help here (the point being that I suspect what they're doing is not > trivial). > > Fabien > > On Thu, Feb 4, 2021 at 2:21 PM Tom Jones <thomasclinganjones@gmail.com> > wrote: > > I've had such an app working for over a year. There are issues which are > being addressed by the browser Interaction team of oidc. > > thx ..Tom (mobile) > > On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault <fabien.imbault@gmail.com> > wrote: > > Hi Francis, > > I've tried a few things with regards to using the AS on a phone, but it's > really quite complex. > > Making that run on a phone comes with quite a bit of trouble. The most > difficult part if that we'd need to use a secure element, but just > installing and hosting a http server securely is not a standard setup at > all. I suggest interested people step in to work on this, as we already > have a lot of work for the (more usual) server case and already handle a > privacy preserving scheme. > > Please let us know what you think. > > Cheers, > Fabien > > On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault <fabien.imbault@gmail.com> > wrote: > > 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>; Dick Hardt <dick.hardt@gmail.com>; > Tom Jones <thomasclinganjones@gmail.com>; Denis <denis.ietf@free.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>; Denis <denis.ietf@free.fr>; > GNAP Mailing List <txauth@ietf.org>; 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 > > > -- > 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