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

[Fabien Imbault <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>> 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 <[e-mail]> 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 <[e-mail]>
>>> 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 <[e-mail]>
>>> 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 <[e-mail]> 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 <[e-mail]>
>>>>> 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 <[e-mail]>
>>>>> 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 <[e-mail]>
>>>>>> 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 <
>>>>>>> [e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>>>>>>>> *Sent:* Wednesday, November 18, 2020 6:35 AM
>>>>>>>>> *To:* Francis Pouatcha <[e-mail]>
>>>>>>>>> *Cc:* [e-mail] <[e-mail]>; Dick Hardt <
>>>>>>>>> [e-mail]>; Tom Jones <[e-mail]>;
>>>>>>>>> Denis <[e-mail]>; Justin Richer <[e-mail]>
>>>>>>>>> *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 <[e-mail]>
>>>>>>>>> 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 <[e-mail]> on behalf of Dick Hardt <
>>>>>>>>> [e-mail]>
>>>>>>>>> *Sent:* Tuesday, November 17, 2020 1:28 PM
>>>>>>>>> *To:* Tom Jones <[e-mail]>
>>>>>>>>> *Cc:* Fabien Imbault <[e-mail]>; Denis <
>>>>>>>>> [e-mail]>; GNAP Mailing List <[e-mail]>; Justin
>>>>>>>>> Richer <[e-mail]>
>>>>>>>>> *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 <
>>>>>>>>> [e-mail]> 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 <[e-mail]>
>>>>>>>>> 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 <
>>>>>>>>> [e-mail]> 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 <[e-mail]>
>>>>>>>>> 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 <
>>>>>>>>> [e-mail]> 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 <[e-mail]> 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
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> TXAuth mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> TXAuth mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> TXAuth mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>>>>
>>>>>>>>>
>>>>> --
>>> TXAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>>
>>>
>> --
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>