Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00
Dick Hardt <dick.hardt@gmail.com> Tue, 17 November 2020 18:07 UTC
Return-Path: <dick.hardt@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 228653A14FE for <txauth@ietfa.amsl.com>; Tue, 17 Nov 2020 10:07:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, 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 b1iNYyFQL-hU for <txauth@ietfa.amsl.com>; Tue, 17 Nov 2020 10:07:47 -0800 (PST)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 EC4033A14EF for <txauth@ietf.org>; Tue, 17 Nov 2020 10:07:46 -0800 (PST)
Received: by mail-lj1-x236.google.com with SMTP id s9so25280562ljo.11 for <txauth@ietf.org>; Tue, 17 Nov 2020 10:07:46 -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=hCutSrj636+ceNdXJfe2wfzXLSzPqJQGBVqQZMlImKE=; b=M8e1UjOI396chqdj0YlEVN1wWl74uzDHsfh3j2hOQhxKNBCjNdQk4LNvrxphM9i0Xl eH3LZfjDKOrgiV8475T0MRlaB+LLeaw9SrCRhHZS72BeKHK7feTDSn4LxHWII9vLTuUk ysG6G36xwxQBImedmKbOr171KgfbdWYgQytx6u0W9eLWviuqeHtC/0S9sn9M0Fya42ui 8IaItGHziitvkliFviicsAzRW6okjy+bnCo2bectCLQvLLx5VCbnc4L1BGN++4i+wMYp +r7Ykho3ssA8u54mmGGBceRSwILWySyNWRbc/dv4dFUhi4Haycnk6JhTuxbPhsVHARUt n3vg==
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=hCutSrj636+ceNdXJfe2wfzXLSzPqJQGBVqQZMlImKE=; b=XGGHjqpdq4UDcn8E4IRbVCOWTxkGjB/FNEZ1W3WT28vppEqfIO/AH1vWnz3q2EJvqe JJ0Q8c7ELLEd0Da9oiv+99NOrPCGnXx0uPS/45V11h6vITdpAX/vWVIxFEBpdFCSr4Gd l+sYFXUGG5je8A7DqyDD2JJydwJfNCVrykm0emEvRALItFyxicaeLa3MRGibcRY7Rycg rutxxzKHO0465+BJ8l34JXz9NBY/6EfLr5uAwb+CZ58sYvCy01pExQ5UF5AynQrZB3si EDdEYNMLH+RXbZRA8T0Wu+S5aFLVKbOKftZPNDGPD4yvIn5hnKZ/BKC3BwTf4TiTYbgS PVKQ==
X-Gm-Message-State: AOAM53067yp+RlcgOBbIcOubVlryEtZ7Rdzpqi3M0SHrKoAgDxhDeHDZ pganUzAMNRNpAaJZjKOSmc6ZPxph8lhQKpdX54k=
X-Google-Smtp-Source: ABdhPJxTmOmcA4esLTrWJH0aqXGbOxADUmUooCwBp8Cm1SJecE1NuRBKIpYRS0DgdTl7etAQvRMW4oVXsZdQT9caX8s=
X-Received: by 2002:a2e:9b13:: with SMTP id u19mr2167010lji.437.1605636464937; Tue, 17 Nov 2020 10:07:44 -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>
In-Reply-To: <5E214281-2974-4632-AB74-4E068B7EE66B@mit.edu>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 17 Nov 2020 10:07:07 -0800
Message-ID: <CAD9ie-vhmtabE5czsWsAi4+bujuBYuHwSfgiE-NT=btCLe+eLQ@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Fabien Imbault <fabien.imbault@gmail.com>, Denis <denis.ietf@free.fr>, GNAP Mailing List <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000021904005b4515f56"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/bn1QmdMwvjRGPBYXdjaa45V0haA>
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 18:07:50 -0000
Justin: there is no assumption in OIDC or OAuth that the user is in a web browser. There is an assumption that the client can load a URL -- but the OS can load the URL and launch an app -- a common practice now. Lots of examples of app to app flows on mobile today doing OAuth. I don't know of any way for independent mobile apps on iOS to communicate other than a deep links -- which is effectively an HTTP redirect. Do you? ᐧ 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