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

[Justin Richer <[e-mail]>]

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:

{
    "client" : "protected.client.ca",
    "access_token" : {
        "access" : [  "idproof1"],
        "flags" : "bearer"
    }
    "interact" : {
        "start" : [ "app", "user_code" ],
        "finish" : {
            "method" : "push",
            "nonce" : "client_nonce_random",
            "uri" : "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?

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

 — Justin

> On Jan 21, 2022, at 9:39 AM, Mike Varley <[e-mail]> wrote:
> 
> 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 <http://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 <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                                       [e-mail] <mailto:[e-mail]>
> 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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>