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

[Fabien Imbault <[e-mail]>]

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, <[e-mail]> 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": {
>             "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
> <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",
>     "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
> [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]
> https://www.ietf.org/mailman/listinfo/txauth
>
>
> --
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>