Subject: [GNAP] Addition of optional 'access_token' in interact callback section

From: Mike Varley <[email-masked]>
Date: Fri, 21 Jan 2022 14:39:31 +0000

Hello GNAP’ers,

I would like to float the idea of adding an optional core parameter to the ‘interact’ request object parameter called ‘access_token’. Specifically relevant to the finish.method = push function.

For example:
{
    "client" : "protected.client.ca",
    "access_token" : {
        "access" : [  "idproof1"],
        "flags" : "bearer"
    }
    "interact" : {
        "start" : [ "app", "user_code" ],
        "finish" : {
            "method" : "push",
            "uri" : "https://protected.client.ca/callback/session/abc-123",
            "nonce" : "client_nonce_random",
            "access_token" : "callback_access_token"
        }
    }
}

The result of the above would be that when the POST callback is made to the client API endpoint, the bearer access token would be included as authorization.

The motivation is clients who have API endpoints may require that all API calls be made with an access token -  there are no open server API endpoints. The motivation for including it in the core spec is too ensure there is a standard way of providing this security parameter, and AS developers are not left re-inventing this parameter for clients. Some clients I have worked with have been adverse to putting access tokens in the URI as parameters as these may get logged by proxies and gateways.

There are a couple drawbacks that I see to supporting this parameter; first, it currently only covers “bearer” tokens – so other security parameters or requirements either get included (making the protocol and the AS life much more difficult), and second there wouldn’t be much guidance on how the client is expected to generate this access token (most access_token generating services require a client request to kick things off…) and then this may cascade into more complicated nuanced steps.

I am very much interested in other’s experience on this topic; “this is a good idea/bad idea because…” and also “this should be core/extension because”. I believe adding lots of optional parameters for not-so-well defined use cases that may never practically occur in the wild to be detrimental to a spec as it just leads to more developer guesswork and customization, so I would like to avoid that also :)

Thanks all!

MV

---
Mike Varley                                       [email-masked]
Architect – Office of the CTO
SecureKey Technologies Inc.

This email and any attachments are for the sole use of the intended recipients and may be privileged, confidential or otherwise exempt from disclosure under law. Any distribution, printing or other use by anyone other than the intended recipient is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and its attachments.

---

From: Justin Richer <[email-masked]>
Date: Fri, 21 Jan 2022 13:42:09 -0500

Hi Mike, thanks for bringing this to the WG. My gut instinct is that we could potentially re-use a similar construct we have in other parts of the protocol, where we’re sending a URI and an access token to use at the URI, with all of its parameters. I think it’s important that we don’t slip into the OAuth 2 over-simplification of “access_token” being a simple string value, because then you need to invent a whole bunch of other things to talk about non-bearer tokens or other attributes. But we could take the same kind of construct we use for the continuation endpoint response and use it again with what you have below: you have a  URI and an access token, and the access token is a fully defined GNAP access token structure. So the “continue” section looks like this:

{
    "continue": {
        "access_token": {
            "value": "80UPRY5NM33OMUKMKSKU"
        },
        "uri": "https://server.example.com/continue",
        "wait": 60
    }
}
The access token here is, by default, bound to the client’s presented key — it’s the same structure that you get back from a “real” access token response, only embedded. This is what I’m thinking that might look like in the example below:

{
		“value”: “callback_access_token”,
		“flags”: [ “bearer” ]
	    }
        }
    }
}

This way, we’re not inventing a new structure, it’s just another GNAP token. And  yes, it would need to be optional, and only defined for the “push” method (at least with what’s defined in core). 

I agree that the security and privacy considerations of something like this would be pretty intense, though, since now we’re having the client instance create and manage a token. Maybe it’s a good extension? But if so, how can we define the “finish” section such that it can be extended this way?

Would love to hear if anyone else has this use case, too.

 — Justin

> On Jan 21, 2022, at 9:39 AM, Mike Varley <[email-masked]> wrote:
> 
> Hello GNAP’ers,
>  
>     "client" : "protected.client.ca <http://protected.client.ca/>",
>     "access_token" : {
>             "uri" : "https://protected.client.ca/callback/session/abc-123 <https://protected.client.ca/callback/session/abc-123>",
> Mike Varley                                       [email-masked] <mailto:[email-masked]>
> -- 
> 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: Sat, 22 Jan 2022 09:27:17 +0100

Hi Mike,

I think the idea is interesting. I agree with the technicalities described
by Justin.

Could you describe an example, without resorting to the GNAP start/finish
parlance ? I think it would help us identity similar patterns more easily.

Best,
Fabien

On Fri, 21 Jan 2022, 19:42 Justin Richer, <[email-masked]> wrote:

> Hi Mike, thanks for bringing this to the WG. My gut instinct is that we
> could potentially re-use a similar construct we have in other parts of the
> protocol, where we’re sending a URI and an access token to use at the URI,
> with all of its parameters. I think it’s important that we don’t slip into
> the OAuth 2 over-simplification of “access_token” being a simple string
> value, because then you need to invent a whole bunch of other things to
> talk about non-bearer tokens or other attributes. But we could take the
> same kind of construct we use for the continuation endpoint response and
> use it again with what you have below: you have a  URI and an access token,
> and the access token is a fully defined GNAP access token structure. So the
> “continue” section looks like this:
>
> {
>     "continue": {
>         "access_token": {
> The access token here is, by default, bound to the client’s presented key
> — it’s the same structure that you get back from a “real” access token
> response, only embedded. This is what I’m thinking that might look like in
> the example below:
>
> {
> *            "uri" : "https://protected.client.ca/callback/session/abc-123
> <https://protected.client.ca/callback/session/abc-123>",
> "access_token" : {*
> * “value”: “callback_access_token”,*
> * “flags”: [ “bearer” ]*
> *     }*
>         }
>     }
> }
>
> This way, we’re not inventing a new structure, it’s just another GNAP
> token. And  yes, it would need to be optional, and only defined for the
> “push” method (at least with what’s defined in core).
>
> I agree that the security and privacy considerations of something like
> this would be pretty intense, though, since now we’re having the client
> instance create and manage a token. Maybe it’s a good extension? But if so,
> how can we define the “finish” section such that it can be extended this
> way?
>
> I would like to float the idea of adding an optional core parameter to the
> ‘interact’ request object parameter called ‘access_token’. Specifically
> relevant to the finish.method = push function.
>
> For example:
> {
> The result of the above would be that when the POST callback is made to
> the client API endpoint, the bearer access token would be included as
> authorization.
>
> The motivation is clients who have API endpoints may require that all API
> calls be made with an access token -  there are no open server API
> endpoints. The motivation for including it in the core spec is too ensure
> there is a standard way of providing this security parameter, and AS
> developers are not left re-inventing this parameter for clients. Some
> clients I have worked with have been adverse to putting access tokens in
> the URI as parameters as these may get logged by proxies and gateways.
>
> There are a couple drawbacks that I see to supporting this parameter;
> first, it currently only covers “bearer” tokens – so other security
> parameters or requirements either get included (making the protocol and the
> AS life much more difficult), and second there wouldn’t be much guidance on
> how the client is expected to generate this access token (most access_token
> generating services require a client request to kick things off…) and then
> this may cascade into more complicated nuanced steps.
>
> I am very much interested in other’s experience on this topic; “this is a
> good idea/bad idea because…” and also “this should be core/extension
> because”. I believe adding lots of optional parameters for not-so-well
> defined use cases that may never practically occur in the wild to be
> detrimental to a spec as it just leads to more developer guesswork and
> customization, so I would like to avoid that also :)
>
> Thanks all!
>
> MV
>
> ---
> Mike Varley
> This email and any attachments are for the sole use of the intended
> recipients and may be privileged, confidential or otherwise exempt from
> disclosure under law. Any distribution, printing or other use by anyone
> other than the intended recipient is prohibited. If you are not an intended
> recipient, please contact the sender immediately, and permanently delete
> this email and its attachments.
> --
> 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: Mike Varley <[email-masked]>
Date: Tue, 25 Jan 2022 16:48:57 +0000

Hi Fabien,

A very generic example is a Relying Party wishing to receive a ‘POST’ callback, but their callback API requires authentication. But I guess in this generic situation the RP and AS could establish that authentication channel out-of-band…

A more specific example is the AS delegating the callback to another AS, and the secondary AS may not be registered with the RP beforehand.
Examples  of a Secondary AS are: a federated AS (primary AS is a proxy for other AS/RS services that the user can select, like, “which bank do you belong to?”), or a mobile app/personal agent app that will make the callback, and may also provide the RP data directly.

In the personal agent case, having the personal agent make the callback allows for the RP and the Agent to establish a direct communication channel for other app specific protocols – and there may be other/better ways for that to happen rather than handling the GNAP callback I’ll admit…

Thoughts?

Thanks,

MV

From: Fabien Imbault <[email-masked]>
Date: Saturday, January 22, 2022 at 3:27 AM
To: Justin Richer <[email-masked]>
Cc: Mike Varley <[email-masked]>, GNAP Mailing List <[email-masked]>
Subject: Re: [GNAP] Addition of optional 'access_token' in interact callback section
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. To report a phish, click on the “Report Phish” button.

Hi Mike,

I think the idea is interesting. I agree with the technicalities described by Justin.

Could you describe an example, without resorting to the GNAP start/finish parlance ? I think it would help us identity similar patterns more easily.

Best,
Fabien

On Fri, 21 Jan 2022, 19:42 Justin Richer, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mike, thanks for bringing this to the WG. My gut instinct is that we could potentially re-use a similar construct we have in other parts of the protocol, where we’re sending a URI and an access token to use at the URI, with all of its parameters. I think it’s important that we don’t slip into the OAuth 2 over-simplification of “access_token” being a simple string value, because then you need to invent a whole bunch of other things to talk about non-bearer tokens or other attributes. But we could take the same kind of construct we use for the continuation endpoint response and use it again with what you have below: you have a  URI and an access token, and the access token is a fully defined GNAP access token structure. So the “continue” section looks like this:

{

    "continue": {

        "access_token": {

        },

        "wait": 60

    }

}

{
    "client" : "protected.client.ca<http://protected.client.ca>",
    "access_token" : {

 — Justin

On Jan 21, 2022, at 9:39 AM, Mike Varley <[email-masked]<mailto:[email-masked]>> wrote:

Hello GNAP’ers,

For example:
{
    "client" : "protected.client.ca<http://protected.client.ca/>",
    "access_token" : {

Thanks all!

MV

---
Mike Varley                                       [email-masked]<mailto:[email-masked]>
Architect – Office of the CTO
SecureKey Technologies Inc.

This email and any attachments are for the sole use of the intended recipients and may be privileged, confidential or otherwise exempt from disclosure under law. Any distribution, printing or other use by anyone other than the intended recipient is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and its attachments.
--
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