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

[Adrian Gropper <[e-mail]>]

+1 to keep a focus on HTTP and an eye to mobile. The COVID vaccination
credentials use-case is prominent these days. This is my suggestion for
that
https://github.com/smart-on-fhir/health-cards/issues/59#issuecomment-775232188

Adrian

On Mon, Feb 8, 2021 at 9:57 AM Fabien Imbault <[e-mail]>
wrote:

> +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 <[e-mail]>
> wrote:
>
>> Justin +1
>>
>> thx ..Tom (mobile)
>>
>> On Mon, Feb 8, 2021, 5:19 AM Justin Richer <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> on behalf of Fabien Imbault <
>>> [e-mail]>
>>> *Sent:* Friday, February 5, 2021 3:41 PM
>>> *To:* Adrian Gropper <[e-mail]>
>>> *Cc:* Tom Jones <[e-mail]>; txauth gnap <
>>> [e-mail]>; Justin Richer <[e-mail]>
>>> *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 <[e-mail]> 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 <[e-mail]>
>>> 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 <[e-mail]>
>>> 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 <[e-mail]>
>>> 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 <[e-mail]>
>>> 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 <[e-mail]>
>>> 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 <[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
>>>
>>>
>>> --
>>> TXAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>>
>>>