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

[Fabien Imbault <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>> 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 <[e-mail]>
>> 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 <[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
>>>>
>>>
>>