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

[Fabien Imbault <[e-mail]>]

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
>>>>>>>>
>>>>>>>
>>>>>>