Subject: [GNAP] I-D Action: draft-ietf-gnap-core-protocol-01.txt

From: [email-masked]
Date: Mon, 02 Nov 2020 07:56:16 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Grant Negotiation and Authorization Protocol WG of the IETF.

        Title           : Grant Negotiation and Authorization Protocol
        Authors         : Justin Richer
                          Aaron Parecki
                          Fabien Imbault
	Filename        : draft-ietf-gnap-core-protocol-01.txt
	Pages           : 119
	Date            : 2020-11-02

Abstract:
   This document defines a mechanism for delegating authorization to a
   piece of software, and conveying that delegation to the software.
   This delegation can include access to a set of APIs as well as
   information passed directly to the software.

   This document has been prepared by the GNAP working group design team
   of Kathleen Moriarty, Fabien Imbault, Dick Hardt, Mike Jones, and
   Justin Richer.  This document is intended as a starting point for the
   working group and includes decision points for discussion and
   agreement.  Many of the features in this proposed protocol can be
   accomplished in a number of ways.  Where possible, the editor has
   included notes and discussion from the design team regarding the
   options as understood.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-01.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-gnap-core-protocol-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Justin Richer <[email-masked]>
Date: Mon, 2 Nov 2020 11:11:52 -0500

This version adds Aaron and Fabien as authors (welcome, folks!), and also incorporates some small editorial changes to fix typos, update examples, and clean up the document itself. The one normative change is the “updated_at” field for subject information is now an ISO 8601 date string instead of an integer timestamp, which was suggested as part of Yaron’s review and was a very simple change to capture — and didn’t have any detractors to the suggested change on the list. If this change is a problem, please raise an issue with the document.

Other suggested changes have not been incorporated into the document itself (either as comments or substantive changes) as the working group is defining and adopting a new change management process for the document to ensure transparency, clarity, and consensus. I’ll let the chairs speak to the details on this as we all figure it out as a group.

Thank you,
 — Justin

> On Nov 2, 2020, at 10:56 AM, [email-masked] wrote:
> 
> 
> -- 
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Francis Pouatcha <[email-masked]>
Date: Tue, 3 Nov 2020 22:00:18 +0000

sort of late but find below are my initial remarks after the first thorough reading of the draft-ietf-gnap-core-protocol-00.

A) Structure of the document

Grant negotiation is of an importance that requires the draft document to have a clean and understandable structure. This is missing. An example Structure could be:

1- Introduction
2- Abstract Protocol Flow
3- Roles
    3.1- Role 1
        3.1.1 Definition
        3.1.2 Scenario
        3.1.3 Authentication
        3.1.4 Capabilities
    3.2- Role 2
4- Requests
   4.1 Resource Request
   4.2 Access Request
5- Elements
   5.1 Element 1
6. Interactions
   6.1- Interaction Type 1
        6.1.1 Protocol Flow
        6.1.2 Roles/Parties
        6.1.3 Elements
        6.1.4 Requests
   6.2- Interaction Type 2
        6.2.1 Protocol Flow
        6.2.2 Roles/Parties
        ....
   6.3- Interaction Type 3

B) Current Document

Roles description shall not hold any assumption on the physical structure of the party fulfilling the roles.

Roles:
-> grant endpoint of the AS: Why is this a post request? This eliminates the chance of having user device hosted AS (no server).
-> Resource Owner (RO) : Authorizes the request? Does it authorize the request or the access to a resource?

Missing Section Interactions:
--> This section shall introduce the notion of interaction before we start listing interaction types.

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.

Resource Access Request vs. Resource Request
--> Both are mixed up. No clarification of the context of each section.

Token Content Negotiation
--> Not expressed as such. This is central to GNAP and not represented enough  in the document.

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.

Dealing with the RC. Here we need a clean structure:
  -> Identification
     --> Entity vs. Instance
     --> Display Information
  -> Key location, legitimation
     --> Authentication
  -> Capability representation

Dealing with Users? This belongs to two sections:

Handling RQ
  -> Identification
     --> Display Information
  -> Credentials
     --> Authentication

Handling RO
  -> Identification
     --> Display Information
  -> Credentials
     --> Authentication

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.

Best regards
/Francis

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 13 Nov 2020 13:57:35 +0100

Hi Francis,

Thanks a lot for your feedback, never to late :-) - including I hope for my
late answer.

Reviewing the structure of the document might be useful indeed. I've opened
a new issue https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30

As for the rest of your comments B: embedded as a comment with [FI] (i
removed the parts related to the structure of the spec).

Cheers
Fabien

On Tue, Nov 3, 2020 at 11:00 PM Francis Pouatcha <fpo=
[email-masked]> wrote:

> [FI] not sure what you mean
>

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

> request or the access to a resource?
[FI] yes, we should make the wording clearer

> 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

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

> --> Not expressed as such. This is central to GNAP and not represented
[FI] right. This should be a specific discussion item.

> 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

---

From: Francis Pouatcha <[email-masked]>
Date: Mon, 16 Nov 2020 16:35:42 +0000

On Tue, Nov 3, 2020 at 11:00 PM Francis Pouatcha <fpo=[email-masked]<mailto:[email-masked]>> wrote:

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

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.

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)

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

[FP] Will these and into tickets?

Best regards.
/Francis

---

From: Denis <[email-masked]>
Date: Tue, 17 Nov 2020 17:45:00 +0100

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

See the above comment. Please, do not confuse an Identity Wallet with an 
Authentication Server (AS).

Denis

>     --> 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:
>
>   * 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.
>     [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
>
>

---

From: Fabien Imbault <[email-masked]>
Date: Tue, 17 Nov 2020 18:03:35 +0100

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:

> 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,
>    - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF Working
>    Group Draft
>
>    - 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
>    - 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

---

From: Justin Richer <[email-masked]>
Date: Tue, 17 Nov 2020 12:19:00 -0500

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 <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,
> 
>>  [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".
> 
> See the above comment. Please, do not confuse an Identity Wallet with an Authentication Server (AS).
> 
> Denis
> 
>> 
>> 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)
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> TXAuth mailing list
> [email-masked]

---

From: Tom Jones <[email-masked]>
Date: Tue, 17 Nov 2020 09:46:06 -0800

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
>
>>    - 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: Dick Hardt <[email-masked]>
Date: Tue, 17 Nov 2020 09:58:46 -0800

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.
>> 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
>>> 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: Tom Jones <[email-masked]>
Date: Tue, 17 Nov 2020 10:05:58 -0800

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:

>> (whether this is front-channel or back channel is no longer an
>> interesting question.)
>>>>    - Resource Access Request: Requesting Access to a resource.
>>>>    Response is an access token (or any type of grant)
>>>> -> 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: Dick Hardt <[email-masked]>
Date: Tue, 17 Nov 2020 10:07:07 -0800

Justin: there is no assumption in OIDC or OAuth that the user is in a web
browser.

There is an assumption that the client can load a URL -- but the OS can
load the URL and launch an app -- a common practice now.

Lots of examples of app to app flows on mobile today doing OAuth.

I don't know of any way for independent mobile apps on iOS to communicate
other than a deep links -- which is effectively an HTTP redirect. Do you?

ᐧ

---

From: Dick Hardt <[email-masked]>
Date: Tue, 17 Nov 2020 10:28:23 -0800

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:

> This is the one step that still needs to be optimized for SIOP to have
> good UX.
> Peace ..tom
>
>
>>> 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
>>>>>    - Self-Issued OpenID Connect Provider DID Profile v0.1. DIF
>>>>>    Working Group Draft
>>>>>
>>>>> 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: Dick Hardt <[email-masked]>
Date: Tue, 17 Nov 2020 11:02:10 -0800

It would seem that the mobile OSes would need to support a new scheme
"openid:" ... and provide a mechanism in both the mobile browser and mobile
apps to detect if an "openid:" handler has been installed.
ᐧ

On Tue, Nov 17, 2020 at 10:32 AM Tom Jones <[email-masked]>
wrote:

> yes - this is the sticking point for siop - not sure how it will get
> resolved.
> Peace ..tom
>
>
> On Tue, Nov 17, 2020 at 10:29 AM Dick Hardt <[email-masked]> wrote:
>
>> Got it.
>>
>> convinced to make openid: a managed scheme similar to mailto:, tel:,
>> sms:, facetime: ?
>>
>> [1]
>>>>> 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).
>>>>>>
>>>>>>>  [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".
>>>>>>>
>>>>>>> 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)
>>>>>>>
>>>>>>>
>>>>>>> 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: Francis Pouatcha <[email-masked]>
Date: Wed, 18 Nov 2020 11:16:41 +0000

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

[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

Looks like the employment website app that is using localhost:8765 to communicate with the wallet. Am I correct?

/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

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

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

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 18 Nov 2020 12:35:08 +0100

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:

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

---

From: Francis Pouatcha <[email-masked]>
Date: Wed, 18 Nov 2020 12:06:51 +0000

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]<mailto:[email-masked]>> wrote:
We are drifting away from the original problem space.

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.

/Dick

 — Justin

Hi Denis, hi Francis,

Cheers,
Fabien

B) Current Document

Roles:

Denis

Interaction Types:

Interaction Again

Best regards.
/Francis

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 18 Nov 2020 13:46:36 +0100

I find the proposal interesting. This is achievable for instance by
leveraging TAPS https://tools.ietf.org/html/draft-ietf-taps-arch-09

Yet, if I remember correctly, the charter states that we rely on HTTP, so
I'm not sure we're in the scope.

On Wed, Nov 18, 2020 at 1:06 PM Francis Pouatcha <[email-masked]> wrote:

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

---

From: Justin Richer <[email-masked]>
Date: Wed, 18 Nov 2020 10:49:36 -0500

One of the core enhancements of GNAP over OAuth 2 is that the protocol always starts same way, and we’re doing that by using an HTTP POST request. In OAuth 2, the client could start off by doing a redirect through the browser to the authorization endpoint, or calling the token endpoint, or calling the device endpoint, or calling the PAR endpoint, or calling the RS (in UMA), or …

This is something that GNAP can make better, and in the current design everything starts the same way by calling the same endpoint, and so it’s always HTTP POST to start. 

However, what I was trying to point out earlier in the thread is that the steps :after: that initial request could move to other protocols and communication methods, to allow for on-device AS functions once that bootstrap starts things off. So that initial HTTP POST could be handled by a surrogate service that will hand off the processing to another system. That next step, as we’re defining it right now with the “continue” function, is still HTTP and JSON based. But that’s not to say that an extension could define another response field, separate from “continue”, that uses a different communication mechanism like DIDComm.

I get the desire to have an abstraction built into the protocol. In my experience with many different specs over the years, having deep abstractions over one instantiation tend to not help, because the abstraction inevitably bakes in a bunch of assumptions about the only concrete abstraction and you don’t realize these assumptions are there until you try to add another abstraction. Therefore, GNAP is taking the approach of doing a strong binding to HTTP/JSON to start, and if we can abstract the pieces and concepts and extend beyond that, then we’ll do so when we’ve got items we can abstract over.

 — Justin

> On Nov 18, 2020, at 7:46 AM, Fabien Imbault <[email-masked]> wrote:
> 
> I find the proposal interesting. This is achievable for instance by leveraging TAPS https://tools.ietf.org/html/draft-ietf-taps-arch-09 <https://tools.ietf.org/html/draft-ietf-taps-arch-09>
> 
> Yet, if I remember correctly, the charter states that we rely on HTTP, so I'm not sure we're in the scope. 
> 
> On Wed, Nov 18, 2020 at 1:06 PM Francis Pouatcha <[email-masked] <mailto:[email-masked]>> wrote:
> 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]>>
> 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]>>
> 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.
> From: TXAuth <[email-masked] <mailto:[email-masked]>> on behalf of Dick Hardt <[email-masked] <mailto:[email-masked]>>
> 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]>>
> [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:
> On Tue, Nov 17, 2020 at 9:59 AM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Tom
> 
> On Tue, Nov 17, 2020 at 9:46 AM Tom Jones <[email-masked] <mailto:[email-masked]>> wrote:
> 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:
>> On Nov 17, 2020, at 12:03 PM, Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Denis, hi Francis, 
>>

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 18 Nov 2020 17:17:53 +0100

Hi Justin,

As described by Justin in a previous comment, GNAP already gets us closer
to the ultimate goal of security and privacy. But I'd agree we need to be
very pragmatic.

The issue here, in all cases, is that we're on unchartered territory. And
even if we had a solution, it's unlikely most people would be able to
implement it, as the underlying frameworks (TAPS, DIDComm, etc.) are really
early stage.
We already have concerns on how to implement some features in all
mainstream languages, this would really make it a lot more complicated.

I would suggest we first focus on designing GNAP around the lines we know
should work well (while still having the idea of future extensions in mind,
of course). There's already a lot to be done.
So for now, I would keep the hypothesis that the AS is/are server(s) - just
not limiting to a single AS is not that easy, so we could take it as a
first step.

Last I think we need to keep in mind that GNAP is probably not suitable for
end-users directly, one would most probably expect that third-party
services still provide the infrastructure. And since the business model
around that exists, it also makes the dissemination of GNAP realistic.

Fabien

On Wed, Nov 18, 2020 at 4:49 PM Justin Richer <[email-masked]> wrote:

> One of the core enhancements of GNAP over OAuth 2 is that the protocol
> always starts same way, and we’re doing that by using an HTTP POST request.
> In OAuth 2, the client could start off by doing a redirect through the
> browser to the authorization endpoint, or calling the token endpoint, or
> calling the device endpoint, or calling the PAR endpoint, or calling the RS
> (in UMA), or …
>
> This is something that GNAP can make better, and in the current design
> everything starts the same way by calling the same endpoint, and so it’s
> always HTTP POST to start.
>
> However, what I was trying to point out earlier in the thread is that the
> steps :after: that initial request could move to other protocols and
> communication methods, to allow for on-device AS functions once that
> bootstrap starts things off. So that initial HTTP POST could be handled by
> a surrogate service that will hand off the processing to another system.
> That next step, as we’re defining it right now with the “continue”
> function, is still HTTP and JSON based. But that’s not to say that an
> extension could define another response field, separate from “continue”,
> that uses a different communication mechanism like DIDComm.
>
> I get the desire to have an abstraction built into the protocol. In my
> experience with many different specs over the years, having deep
> abstractions over one instantiation tend to not help, because the
> abstraction inevitably bakes in a bunch of assumptions about the only
> concrete abstraction and you don’t realize these assumptions are there
> until you try to add another abstraction. Therefore, GNAP is taking the
> approach of doing a strong binding to HTTP/JSON to start, and if we can
> abstract the pieces and concepts and extend beyond that, then we’ll do so
> when we’ve got items we can abstract over.
>
>  — Justin
>
>>    - 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]>

---

From: Tom Jones <[email-masked]>
Date: Wed, 18 Nov 2020 21:23:40 -0800

Actually that's not the hard problem, which is, once the user wanders off
on some path that is not anchored in the browser, how does the path get
back to the same place in the browser?
This is "straightforward" when the path from siop to some url in the cloud
is completely separated from the path between the user and the client, but
that is not the path usually taken.
We need some new entity to pull this off. Call it the AS proxy if you will.
The problem I have with that is who is going to pay the AS proxy?
If I can figure that payment issue out, I think I can complete the rest of
the flows.

Peace ..tom

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 19 Nov 2020 07:13:34 +0100

Hi Tom,

My answer is completely speculative.
But I guess it would probably involve the end-user paying to some sort of
service provider (just like one pays for having a VPN). With the same
potential risks (i.e free tiers that serve ads or resell your data, or
limit volumes of connections)?

Cheers
Fabien

Le jeu. 19 nov. 2020 à 06:23, Tom Jones <[email-masked]> a
écrit :

> We need some new entity to pull this off. Call it the AS proxy if you
> will. The problem I have with that is who is going to pay the AS proxy?

---

From: Tom Jones <[email-masked]>
Date: Thu, 19 Nov 2020 07:01:12 -0800

that would certainly work. But my use case of interest is healthcare, and I
cannot imagine forcing users to pay to get an identifier for health care.
The other major problem is the 80% of the world's population that lives in
what you and I consider to be poverty.
Peace ..tom

On Wed, Nov 18, 2020 at 10:13 PM Fabien Imbault <[email-masked]>
wrote:

>> This is "straightforward" when the path from siop to some url in the
>> cloud is completely separated from the path between the user and the
>> client, but that is not the path usually taken.
>> If I can figure that payment issue out, I think I can complete the rest
>> of the flows.
>>
>> Peace ..tom
>>
>>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 19 Nov 2020 16:16:31 +0100

I suppose trusted institutional actors (hospitals, NGO, etc.) might be
willing to support that scenario?
Just like in SSI, there's a body of work that is concerned with providing
identity to people,
https://sovrin.org/identity-for-good-program-helps-provide-ssi-to-ngos-and-nonprofits/
But
unfortunatly many people won't have access to a phone...
Cheers
Fabien

On Thu, Nov 19, 2020 at 4:01 PM Tom Jones <[email-masked]>
wrote:

> that would certainly work. But my use case of interest is healthcare, and
> I cannot imagine forcing users to pay to get an identifier for health care.
>>> Actually that's not the hard problem, which is, once the user wanders
>>> off on some path that is not anchored in the browser, how does the path get

---

From: Fabien Imbault <[email-masked]>
Date: Tue, 24 Nov 2020 05:55:48 +0100

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