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

From: Fabien Imbault <[email-masked]>
Date: Thu, 4 Feb 2021 12:12:27 +0100

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

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 4 Feb 2021 14:35:03 +0100

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 <[email-masked]>
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 <[email-masked]>
> 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 :-)
>>>
>>>> *Cc:* [email-masked] <[email-masked]>; Dick Hardt <
>>>> [email-masked]>; Tom Jones <[email-masked]>; Denis
>>>> <[email-masked]>; Justin Richer <[email-masked]>
>>>> 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
>>>>
>>>> [email-masked]>; GNAP Mailing List <[email-masked]>; Justin
>>>> Richer <[email-masked]>
>>>> 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]
>>>> On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <
>>>> [email-masked]> wrote:
>>>>
>>>> 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
>>>> Roles description shall not hold any assumption on the physical
>>>> structure of the party fulfilling the roles.
>>>> -> grant endpoint of the AS: Why is this a post request? This
>>>> eliminates the chance of having user device hosted AS (no server).
>>>>  [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
>>>>
>>>>
>>>> [FI] this should be handled as a specific discussion item. As a
>>>> reminder, how would you define embedded?
>>>>
>>>>    - Resource Access Request: Requesting Access to a resource.
>>>>    Response is an access token (or any type of grant)
>>>> 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.
>>>> -> 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
>>>>
>>>>

---

From: Tom Jones <[email-masked]>
Date: Thu, 4 Feb 2021 05:21:47 -0800

thx ..Tom (mobile)

On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault <[email-masked]>
wrote:

>>> [email-masked]>; Tom Jones <[email-masked]>; Denis <
>>> [email-masked]>; Justin Richer <[email-masked]>
>>> [email-masked]>; GNAP Mailing List <[email-masked]>; Justin Richer
>>> <[email-masked]>

---

From: Justin Richer <[email-masked]>
Date: Thu, 4 Feb 2021 10:30:22 -0500

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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. 
> 
> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault <[email-masked] <mailto:[email-masked]>> 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 :-)
> 
> Le mer. 18 nov. 2020 à 13:06, Francis Pouatcha <[email-masked] <mailto:[email-masked]>> 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 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30>).
> 
> /Francis
> 
> From: Fabien Imbault <[email-masked] <mailto:[email-masked]>>
> Sent: Wednesday, November 18, 2020 6:35 AM
> To: Francis Pouatcha <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>; Dick Hardt <[email-masked] <mailto:[email-masked]>>; Tom Jones <[email-masked] <mailto:[email-masked]>>; Denis <[email-masked] <mailto:[email-masked]>>; Justin Richer <[email-masked] <mailto:[email-masked]>>
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 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 <[email-masked] <mailto:[email-masked]>> on behalf of Dick Hardt <[email-masked] <mailto:[email-masked]>>
> Sent: Tuesday, November 17, 2020 1:28 PM
> To: Tom Jones <[email-masked] <mailto:[email-masked]>>
> Cc: Fabien Imbault <[email-masked] <mailto:[email-masked]>>; Denis <[email-masked] <mailto:[email-masked]>>; GNAP Mailing List <[email-masked] <mailto:[email-masked]>>; Justin Richer <[email-masked] <mailto:[email-masked]>>
> 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 <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 <[email-masked] <mailto:[email-masked]>> wrote:
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Tom
> 
> 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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 <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 <[email-masked] <mailto:[email-masked]>> wrote:
>> Hello  Francis,
>> 
>>> Roles description shall not hold any assumption on the physical structure of the party fulfilling the roles.
>>>  [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/ <https://identity.foundation/did-siop/>).
>> 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".
>> 
>>       "Unlike the OIDC Authorization Code Flow as per [OIDC.Core], the SIOP will not return an access token to the RP".
>> 
>>> -> grant endpoint of the AS: Why is this a post request? This eliminates the chance of having user device hosted AS (no server).
>>> 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?
>>> --> 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?
>>> 
>>> Redirect: same device, same or different user agents (browser, mobile app, desktop app, ...)
>>> Decoupled: different devices
>>> Embedded : RC carries RO authorization to AS
>>> 
>>> 
>>> [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)
>>> 
>>> --> Not expressed as such. This is central to GNAP and not represented enough  in the document.
>>> 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  
>>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>> -- 
>> TXAuth mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> 
> -- 
> TXAuth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> TXAuth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 4 Feb 2021 16:47:34 +0100

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 <[email-masked]> 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
>
>>>>> [email-masked]>; Tom Jones <[email-masked]>;
>>>>> Denis <[email-masked]>; Justin Richer <[email-masked]>
>>>>> Would make sense, but not so easy as we rely heavily on HTTP. Hence
>>>>> the discussion about deep links and so on.
>>>>>
>>>>> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <
>>>>> 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
>>>>> 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).
>>>>>
>>>>>    - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF
>>>>>    Working Group Draft
>>>>>
>>>>> 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.
>>>>>
>>>>> --> 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] 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:
>>>>>

---

From: Tom Jones <[email-masked]>
Date: Thu, 4 Feb 2021 10:03:38 -0800

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 <[email-masked]>
wrote:

> 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
>
>> 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.
>>
>>>> On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault <
>>>> [email-masked]> 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 :-)
>>>>>
>>>>>> 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
>>>>>>
>>>>>>    - 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.
>>>>>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault <
>>>>>> [email-masked]> wrote:
>>>>>>
>>>>>> Hi Denis, hi Francis,
>>>>>>
>>>>>>  [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 (
>>>>>> At no place within these two documents, it is possible to imagine
>>>>>> that "the AS will be running on the user device".
>>>>>>
>>>>>>       "Unlike the OIDC Authorization Code Flow as per [OIDC.Core],
>>>>>> the SIOP will not return an access token to the RP".
>>>>>>
>>>>>>    - Resource Request: Request the resource. Response is the
>>>>>>    resource (or a corresponding execution)
>>>>>>
>>>>>>
>>>>>> [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

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 4 Feb 2021 19:07:14 +0100

Ok, to be enablers of change, we'd need to specify how this would work in
detail. Again I find the objective attractive, it's just there a few
technical hurdles along the way. HTTP has never been designed for this use
case.

On Thu, Feb 4, 2021 at 7:03 PM Tom Jones <[email-masked]>
wrote:

>>> 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
>>>
>>>> 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)
>>>>
>>>>>>>    - 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.
>>>>>>> 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
>>>>>>> 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]
>>>>>>> Looks like the employment website app that is using localhost:8765
>>>>>>> to communicate with the wallet. Am I correct?
>>>>>>>
>>>>>>> /Dick
>>>>>>> ᐧ
>>>>>>>
>>>>>>> [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:
>>>>>>>

---

From: Tom Jones <[email-masked]>
Date: Thu, 4 Feb 2021 10:17:44 -0800

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

On Thu, Feb 4, 2021 at 10:07 AM Fabien Imbault <[email-masked]>
wrote:

>> 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.
>>>> 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
>>>>
>>>>>> 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
>>>>>>>>    - 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
>>>>>>>>
>>>>>>>> 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
>>>>>>>> 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.
>>>>>>>> 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).
>>>>>>>>
>>>>>>>>    - Redirect: same device, same or different user agents
>>>>>>>>    (browser, mobile app, desktop app, ...)

---

From: Justin Richer <[email-masked]>
Date: Thu, 4 Feb 2021 14:01:40 -0500

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 <[email-masked]> wrote:
> 
> 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.
> On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>> On Feb 4, 2021, at 8:35 AM, Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Tom, 
>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 4 Feb 2021 14:18:00 -0500

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 <[email-masked]> wrote:
> 
> yes, loopback
> 
> On Thu, Feb 4, 2021 at 11:01 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Feb 4, 2021, at 1:03 PM, Tom Jones <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Tom Jones <[email-masked]>
Date: Thu, 4 Feb 2021 11:19:25 -0800

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 <[email-masked]> 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 Thu, Feb 4, 2021 at 11:01 AM Justin Richer <[email-masked]> wrote:
>
>> Tom, can you expand on how exactly the back-channel  communication works
>> between on-device components? Do you use HTTP locally?
>>
>> Thanks,
>>  — Justin
>>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 4 Feb 2021 20:43:32 +0100

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 <[email-masked]> a
écrit :

>>>>>>>> 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 first layer shall design abstract protocol flows,
>>>>>>>>>    without specification of the mode and mechanism of interaction.
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> Would make sense, but not so easy as we rely heavily on HTTP.
>>>>>>>>> Hence the discussion about deep links and so on.
>>>>>>>>>
>>>>>>>>>    - 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
>>>>>>>>>    - Decentralized Identifiers (DIDs) v1.0 Core architecture,
>>>>>>>>>    data model, and representations W3C Working Draft 08 November 2020
>>>>>>>>> --> I prefer a classification with Redirect, Decoupled and
>>>>>>>>> Embedded is. In the draft, we have one redirect and 2 decouple interactions
>>>>>>>>> and nothing else.
>>>>>>>>> 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.
>>>>>>>>> -> 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
>>>>>>>>>
>>>>>>>>>

---

From: Tom Jones <[email-masked]>
Date: Thu, 4 Feb 2021 12:20:17 -0800

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.

On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault <[email-masked]>
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 Thu, Feb 4, 2021 at 2:21 PM Tom Jones <
>>>>>>> On Thu, Feb 4, 2021, 3:12 AM Fabien Imbault <
>>>>>>>>>> spec (
>>>>>>>>>> *From:* TXAuth <[email-masked]> on behalf of Dick Hardt
>>>>>>>>>> <[email-masked]>
>>>>>>>>>> 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?
>>>>>>>>>>
>>>>>>>>>> Looks like the employment website app that is using
>>>>>>>>>> localhost:8765 to communicate with the wallet. Am I correct?
>>>>>>>>>>
>>>>>>>>>> /Dick
>>>>>>>>>> ᐧ
>>>>>>>>>>
>>>>>>>>>> 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).
>>>>>>>>>> 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
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>  [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 (
>>>>>>>>>>       "Unlike the OIDC Authorization Code Flow as per
>>>>>>>>>> [OIDC.Core], the SIOP will not return an access token to the RP".
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> -> Resource Owner (RO) : Authorizes the request? Does it
>>>>>>>>>> authorize the request or the access to a resource?
>>>>>>>>>> [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

---

From: Justin Richer <[email-masked]>
Date: Thu, 4 Feb 2021 15:45:01 -0500

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 <[email-masked]> 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.
> On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault <[email-masked] <mailto:[email-masked]>> 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. 
> Le jeu. 4 févr. 2021 à 20:20, Tom Jones <[email-masked] <mailto:[email-masked]>> a écrit :
> On Thu, Feb 4, 2021 at 11:18 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Feb 4, 2021, at 2:16 PM, Tom Jones <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> yes, loopback
>>

---

From: Tom Jones <[email-masked]>
Date: Thu, 4 Feb 2021 13:10:05 -0800

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.

On Thu, Feb 4, 2021 at 12:45 PM Justin Richer <[email-masked]> 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
>
>>>> 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 Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault <
>>>>>>> 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
>>>>>>>> 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)
>>>>>>>>
>>>>>>>>>>> *From:* TXAuth <[email-masked]> on behalf of Dick
>>>>>>>>>>> Hardt <[email-masked]>
>>>>>>>>>>> [email-masked]>; GNAP Mailing List <[email-masked]>;
>>>>>>>>>>> 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]
>>>>>>>>>>> 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
>>>>>>>>>>> At no place within these two documents, it is possible to
>>>>>>>>>>> imagine that "the AS will be running on the user device".
>>>>>>>>>>>
>>>>>>>>>>> --> This section shall introduce the notion of interaction
>>>>>>>>>>> before we start listing interaction types.
>>>>>>>>>>> [FI] yes
>>>>>>>>>>>
>>>>>>>>>>> Interaction Types:

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 5 Feb 2021 12:19:27 +0100

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 <[email-masked]> a
écrit :

> CHAPI would be ok i guess, but that requires cred man to be fixed. Not
> sure if it fixes discovery or privacy even then.
>
>> 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
>>> Le jeu. 4 févr. 2021 à 20:20, Tom Jones <[email-masked]>
>>> a écrit :
>>>
>>>>>> 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.
>>>>>>> Token delivery through continuation seems fine to me. The client
>>>>>>> will probably have to wait for the next polling before it receives a token
>>>>>>> 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
>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>> 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.
>>>>>>>>>>>> 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).
>>>>>>>>>>>>
>>>>>>>>>>>> See the above comment. Please, do not confuse an Identity
>>>>>>>>>>>> Wallet with an Authentication Server (AS).
>>>>>>>>>>>>
>>>>>>>>>>>> Denis
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> [FP]: Here:
>>>>>>>>>>>> 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.
>>>>>>>>>>>> time. Cf in definition, currently we have Requesting Party
>>>>>>>>>>>> (RQ, aka "user")
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Interaction Again

---

From: Tom Jones <[email-masked]>
Date: Fri, 5 Feb 2021 07:33:29 -0800

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.

On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault <[email-masked]>
wrote:

>>>> 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.
>>>>>>>> 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.
>>>>>>>>>>> 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
>>>>>>>>>>>> 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
>>>>>>>>>>>>>    - 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.
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>> 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).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Roles description shall not hold any assumption on the
>>>>>>>>>>>>> physical structure of the party fulfilling the roles.
>>>>>>>>>>>>>    - Self-Issued OpenID Connect Provider DID Profile v0.1.
>>>>>>>>>>>>>    DIF Working Group Draft
>>>>>>>>>>>>>
>>>>>>>>>>>>> [FI] this should be handled as a specific discussion item. As
>>>>>>>>>>>>> a reminder, how would you define embedded?
>>>>>>>>>>>>>
>>>>>>>>>>>>>    - Resource Access Request: Requesting Access to a
>>>>>>>>>>>>>    resource. Response is an access token (or any type of grant)
>>>>>>>>>>>>> [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

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 5 Feb 2021 16:56:07 +0100

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 <[email-masked]> 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?
>>>
>>>> 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.
>>>> On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault <
>>>>>>> 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
>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>>>>>> [email-masked]>; Tom Jones <
>>>>>>>>>>>>>> [email-masked]>; Denis <[email-masked]>;
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>    - Decentralized Identifiers (DIDs) v1.0 Core
>>>>>>>>>>>>>>    architecture, data model, and representations W3C Working Draft 08 November
>>>>>>>>>>>>>>    2020

---

From: Tom Jones <[email-masked]>
Date: Fri, 5 Feb 2021 09:55:24 -0800

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 <[email-masked]>
wrote:

>>> Le jeu. 4 févr. 2021 à 22:10, Tom Jones <[email-masked]>
>>> a écrit :
>>>
>>>>> 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 —
>>>>> i assumed that the wallet (aka AS) needed to be a native app, not a
>>>>> PWA (which can come from a traditional web server).
>>>>>>>>> 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.
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>>>>> 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 :-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Would make sense, but not so easy as we rely heavily on
>>>>>>>>>>>>>>> HTTP. Hence the discussion about deep links and so on.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -> grant endpoint of the AS: Why is this a post request?
>>>>>>>>>>>>>>> This eliminates the chance of having user device hosted AS (no server).
>>>>>>>>>>>>>>> [FI] this should be handled as a specific discussion item.
>>>>>>>>>>>>>>> As a reminder, how would you define embedded?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [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 Request: Request the resource. Response is
>>>>>>>>>>>>>>>    the resource (or a corresponding execution)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 5 Feb 2021 19:07:29 +0100

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 <[email-masked]>
wrote:

>>>> 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
>>>>>>> Le jeu. 4 févr. 2021 à 20:20, Tom Jones <
>>>>>>> [email-masked]> a écrit :
>>>>>>>
>>>>>>>>>> Tom, can you expand on how exactly the back-channel
>>>>>>>>>>  communication works between on-device components? Do you use HTTP locally?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>  — Justin
>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>    - 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.
>>>>>>>>>>>>>>>> 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]
>>>>>>>>>>>>>>>> Ultimately, in most situations like these in the real
>>>>>>>>>>>>>>>> world, the hurdle isn’t technical compatibility so much as it is trust
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>  [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 (
>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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.

---

From: Adrian Gropper <[email-masked]>
Date: Fri, 5 Feb 2021 15:19:45 -0500

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 <[email-masked]>
wrote:

> 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
>
>>> Le ven. 5 févr. 2021 à 16:33, Tom Jones <[email-masked]>
>>> a écrit :
>>>
>>>>> - 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.
>>>>>
>>>>>> CHAPI would be ok i guess, but that requires cred man to be fixed.
>>>>>> Not sure if it fixes discovery or privacy even then.
>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>>>> 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)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>    - The first layer shall design abstract protocol
>>>>>>>>>>>>>>>>>    flows, without specification of the mode and mechanism of interaction.
>>>>>>>>>>>>>>>>> *From:* TXAuth <[email-masked]> on behalf of
>>>>>>>>>>>>>>>>> Dick Hardt <[email-masked]>
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>    - Self-Issued OpenID Connect Provider DID Profile
>>>>>>>>>>>>>>>>>    v0.1. DIF Working Group Draft
>>>>>>>>>>>>>>>>>

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 5 Feb 2021 21:41:45 +0100

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 <[email-masked]> a
écrit :

>>>> 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
>>>>> On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault <
>>>>>>> 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?
>>>>>>>
>>>>>>>> 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.
>>>>>>>>>>>> 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.
>>>>>>>>>>>>>> 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”
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>    - 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.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    - 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.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --> 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?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    - Redirect: same device, same or different user
>>>>>>>>>>>>>>>>>>    agents (browser, mobile app, desktop app, ...)
>>>>>>>>>>>>>>>>>> -> 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
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>

---

From: Francis Pouatcha <[email-masked]>
Date: Sun, 7 Feb 2021 22:51:20 +0000

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 <[email-masked]> on behalf of Fabien Imbault <[email-masked]>
Sent: Friday, February 5, 2021 3:41 PM
To: Adrian Gropper <[email-masked]>
Cc: Tom Jones <[email-masked]>; txauth gnap <[email-masked]>; Justin Richer <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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.

On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault <[email-masked]<mailto:[email-masked]>> 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.

Cheers
Fabien

Le jeu. 4 févr. 2021 à 22:10, Tom Jones <[email-masked]<mailto:[email-masked]>> 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.

On Thu, Feb 4, 2021 at 12:45 PM Justin Richer <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Feb 4, 2021 at 11:43 AM Fabien Imbault <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:

yes, loopback

On Thu, Feb 4, 2021 at 11:01 AM Justin Richer <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Feb 4, 2021 at 7:47 AM Fabien Imbault <[email-masked]<mailto:[email-masked]>> 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.

Fabien

On Thu, Feb 4, 2021 at 4:30 PM Justin Richer <[email-masked]<mailto:[email-masked]>> 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.

 — Justin

On Feb 4, 2021, at 8:35 AM, Fabien Imbault <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tom,

Fabien

On Thu, Feb 4, 2021 at 2:21 PM Tom Jones <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Francis,

Cheers,
Fabien

On Tue, Nov 24, 2020 at 5:55 AM Fabien Imbault <[email-masked]<mailto:[email-masked]>> wrote:
Hi Francis,

Will let you know.

Fabien

Le mer. 18 nov. 2020 à 13:06, Francis Pouatcha <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, November 18, 2020 6:35 AM
To: Francis Pouatcha <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Dick Hardt <[email-masked]<mailto:[email-masked]>>; Tom Jones <[email-masked]<mailto:[email-masked]>>; Denis <[email-masked]<mailto:[email-masked]>>; Justin Richer <[email-masked]<mailto:[email-masked]>>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00

Fabien

On Wed, Nov 18, 2020 at 12:16 PM Francis Pouatcha <[email-masked]<mailto:[email-masked]>> 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.

Best regards,
/Francis
________________________________
From: TXAuth <[email-masked]<mailto:[email-masked]>> on behalf of Dick Hardt <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, November 17, 2020 1:28 PM
To: Tom Jones <[email-masked]<mailto:[email-masked]>>
Cc: Fabien Imbault <[email-masked]<mailto:[email-masked]>>; Denis <[email-masked]<mailto:[email-masked]>>; GNAP Mailing List <[email-masked]<mailto:[email-masked]>>; Justin Richer <[email-masked]<mailto:[email-masked]>>
Subject: Re: [GNAP] Review of draft-ietf-gnap-core-protocol-00

Got it.

[1] https://developer.apple.com/documentation/xcode/allowing_apps_and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=011490be-d3a0-4b2c-8abb-e51175e3ae19]ᐧ

On Tue, Nov 17, 2020 at 10:06 AM Tom Jones <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tom

/Dick
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=11a62ce6-9b4a-4d5f-86c5-d2c114395aee]ᐧ

On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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).

 — Justin

On Nov 17, 2020, at 12:03 PM, Fabien Imbault <[email-masked]<mailto:[email-masked]>> wrote:

Hi Denis, hi Francis,

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hello  Francis,

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/).

  *   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

Roles:

Denis

Interaction Types:

  *   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: 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)

Interaction Again

Best regards.
/Francis

--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

---

From: Justin Richer <[email-masked]>
Date: Mon, 8 Feb 2021 08:19:32 -0500

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 <[email-masked]> wrote:
> 
> Hello Fabian,
> 
> Le ven. 5 févr. 2021 à 21:19, Adrian Gropper <[email-masked] <mailto:[email-masked]>> a écrit :
> On Fri, Feb 5, 2021 at 1:08 PM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> On Fri, Feb 5, 2021 at 6:55 PM Tom Jones <[email-masked] <mailto:[email-masked]>> wrote:
> On Fri, Feb 5, 2021, 7:56 AM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> Le ven. 5 févr. 2021 à 16:33, Tom Jones <[email-masked] <mailto:[email-masked]>> a écrit :
> On Fri, Feb 5, 2021 at 3:19 AM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Tom, 
> 
> Le jeu. 4 févr. 2021 à 22:10, Tom Jones <[email-masked] <mailto:[email-masked]>> a écrit :
> On Thu, Feb 4, 2021 at 12:45 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Feb 4, 2021, at 3:20 PM, Tom Jones <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Tom Jones <[email-masked]>
Date: Mon, 8 Feb 2021 05:21:47 -0800

Justin +1

thx ..Tom (mobile)

On Mon, Feb 8, 2021, 5:19 AM Justin Richer <[email-masked]> 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
>
> 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...
>
> *From:* TXAuth <[email-masked]> on behalf of Fabien Imbault <
> [email-masked]>
> *Sent:* Friday, February 5, 2021 3:41 PM
> *To:* Adrian Gropper <[email-masked]>
> *Cc:* Tom Jones <[email-masked]>; txauth gnap <
> [email-masked]>; Justin Richer <[email-masked]>
>    - 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.
> 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
> *Cc:* Fabien Imbault <[email-masked]>; Denis <[email-masked]>;
> GNAP Mailing List <[email-masked]>; Justin Richer <[email-masked]>
> 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
>
> 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
>    - Decentralized Identifiers (DIDs) v1.0 Core architecture, data model,
>    and representations W3C Working Draft 08 November 2020
> --> I prefer a classification with Redirect, Decoupled and Embedded is. In
> the draft, we have one redirect and 2 decouple interactions and nothing
> else.
>    - Resource Request: Request the resource. Response is the resource (or
>    a corresponding execution)
>
>

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 8 Feb 2021 15:57:24 +0100

+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 <[email-masked]>
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
>> 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...
>>
>> I have a few ideas on how to implement privacy, but it's quite involved
>> in terms of crypto (again using Ristretto groups :-)).
>>

---

From: Adrian Gropper <[email-masked]>
Date: Mon, 8 Feb 2021 10:41:55 -0500

+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 <[email-masked]>
wrote:

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

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 8 Feb 2021 17:44:08 +0100

Hi,

virtual interim meeting on 2021-02-10 from 16:00 to 17:00 UTC
https://intuit.zoom.us/j/99481776837?from=addon

- Review of changes since IETF109 (including edits since -03)
- Interaction mode changes (issue #122)
- Discussion of next steps

Cheers.
Fabien

On Mon, Feb 8, 2021 at 5:33 PM Francis Pouatcha <
[email-masked]> wrote:

> Hello Fabian,
>
> what time is the interim Meeting on Wednesday?
>
> Can you forward the invite?
>
> Best regards,
> /Francis
> *Sent:* Monday, February 8, 2021 9:57 AM
> *Cc:* Justin Richer <[email-masked]>; Francis Pouatcha <[email-masked]>;
> Adrian Gropper <[email-masked]>; txauth gnap <[email-masked]>