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

Tom Jones <thomasclinganjones@gmail.com> Thu, 04 February 2021 18:18 UTC

Return-Path: <thomasclinganjones@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 0CEC03A16E3 for <txauth@ietfa.amsl.com>; Thu, 4 Feb 2021 10:18:01 -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 d1XargBFSeQJ for <txauth@ietfa.amsl.com>; Thu, 4 Feb 2021 10:17:57 -0800 (PST)
Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (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 2157B3A0DCD for <txauth@ietf.org>; Thu, 4 Feb 2021 10:17:57 -0800 (PST)
Received: by mail-oi1-x22a.google.com with SMTP id j25so4718796oii.0 for <txauth@ietf.org>; Thu, 04 Feb 2021 10:17:57 -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=3nFt59SzNgXHg4SsD1QVvFxarfNqdMtXWVHBcU/ze+4=; b=bzWau9I+1tl99s2rPnb9lLpk8mRci0/lxzdYq7PtmJVNMlfxnNkgTotDXfxPrHz55X naa7QOIr42nukDERAoTgJHwD8UPj1zURzoRgfPBZLy0A3UBFUv35g09r9KNY674AgBNa eaqX9MFnxfCYlZk46x1X2iY7jud2s9uc8tgZ8uQNRCCseKVpXo5mR3rcZ5VS684X/7qj 3HQMSViDshO94ajjeLBWf1T5E5+g4NmdDmgpDbth5ssHes/l+B+CS0fLRXGr+MPyBzk6 6AaZHsIjjJMDLbRHKQ6/X4iUjAjEztjBJiqGbb8vSp9BfegSyy6mFlDMk/iKvW2P1JIE kuAA==
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=3nFt59SzNgXHg4SsD1QVvFxarfNqdMtXWVHBcU/ze+4=; b=ZlHWV7t2IUQbYEMwURdhUnW76eOtJov8zSzU2XV/6CUOIwY2W7zVh26k+OgcTZzbjL cH0SNf/95ya9XBWVBYk3DeVs/c4r3mFOTS6INCe4WmFXVTsPzj0LMBGRDf1OK4b6OiMp 9EDW27zm4vazcRvedBkU4mrm4SKxYY9eGOmR7dD+f+12bjEQ2FpnUQKlU44Dbk5CXz/C fhhlN3sUTfutTzUKXRj/vEMaXgAEKLt1mMpru5V8dMYDY8j+2AQwlLyORxugZKFgofc1 v1Ycigby8h52DT85hw1eI88mL9OFYfEMBn6opKzpFdUbf2Wsp/uJQg7uYVwc2GAZK9aH blpg==
X-Gm-Message-State: AOAM532b3X1albBLTHEwQhwuU+v6aNXMSxqo+FvNgCGDwXrAl5Q4ENAp lmV77GQ95ysgLOBXGLm+OkA5VYKemzmWSTGCh8g=
X-Google-Smtp-Source: ABdhPJyLTH5wRf0589a8ykJ15/7ngEYnIidv0jkcSHqXgdUdBGW52E06Nue4JhtQAbJYS4yx87zs8+BAUkuMbc5Xmlk=
X-Received: by 2002:aca:4fd5:: with SMTP id d204mr518699oib.172.1612462676294; Thu, 04 Feb 2021 10:17:56 -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> <CAM8feuQc8Thohftk_=ohNByTvZtxRukdQ3xCzMP3K7zdZBO6Lg@mail.gmail.com> <CAM8feuRU-MKuta6fejsLsYXRhpWwfKqZ6D8VaVvkFhbo+sH9pw@mail.gmail.com> <CAK2Cwb4MrJoRc-oohQdAag_rNdecC75xEG1W1JDOLp6me8-KCw@mail.gmail.com> <CAM8feuT6EsJ+jAQ59CKbgkQ9akBLY2aEkLR4Ng_SN8rS_JHHqA@mail.gmail.com> <28180624-08AA-4659-BB22-5D86034E6F51@mit.edu> <CAM8feuQyXv8FtQkZkKgLrJZ6s7J6QvbzXEz1tgctUQmKs9NYeQ@mail.gmail.com> <CAK2Cwb4CFaePZjqmF6xmvrKcPiDCkW3Sahchiy0MP33zTYZOpg@mail.gmail.com> <CAM8feuTJCaVMjXDEu6S=scNP2bdaWBz2UmG6b55u197FfQiOPQ@mail.gmail.com>
In-Reply-To: <CAM8feuTJCaVMjXDEu6S=scNP2bdaWBz2UmG6b55u197FfQiOPQ@mail.gmail.com>
From: Tom Jones <thomasclinganjones@gmail.com>
Date: Thu, 04 Feb 2021 10:17:44 -0800
Message-ID: <CAK2Cwb50jPSM7AknfhkRuL8=cKJQtumB0KfU3YxMdwG6T_Af8g@mail.gmail.com>
To: Fabien Imbault <fabien.imbault@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, Francis Pouatcha <fpo@adorsys.de>, GNAP Mailing List <txauth@ietf.org>, Dick Hardt <dick.hardt@gmail.com>, Denis <denis.ietf@free.fr>
Content-Type: multipart/alternative; boundary="00000000000008c29905ba86b98b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/XCPPdofBjsW-EO_DWfsI70Zv2qc>
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, 04 Feb 2021 18:18:01 -0000

The problem IMHO is getting support from the browsers. That is what the new
task group is attempting to do. W/O that phones will not IMHO be very
successful with things like GNAP.  (HTTP really is not the issue)

Be the change you want to see in the world ..tom


On Thu, Feb 4, 2021 at 10:07 AM Fabien Imbault <fabien.imbault@gmail.com>
wrote:

> Ok, to be enablers of change, we'd need to specify how this would work in
> detail. Again I find the objective attractive, it's just there a few
> technical hurdles along the way. HTTP has never been designed for this use
> case.
>
> On Thu, Feb 4, 2021 at 7: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
>>>>>>>>
>>>>>>>>
>>>>