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

Mike Varley <mike.varley@securekey.com> Tue, 25 January 2022 16:49 UTC

Return-Path: <mike.varley@securekey.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC49E3A1151 for <txauth@ietfa.amsl.com>; Tue, 25 Jan 2022 08:49:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=securekey.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXSOUpwCAiuM for <txauth@ietfa.amsl.com>; Tue, 25 Jan 2022 08:49:04 -0800 (PST)
Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-to1can01on0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5d::720]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB033A114F for <txauth@ietf.org>; Tue, 25 Jan 2022 08:49:03 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aGSTwQl8di8pqgEViT5JURDE9B6MJFkaNmNQ2iCs0CkR0+S3D+s+dGg3f4zpMeU7iL44DyRuWHGcHGUGcN3uU50Mn87bTa6EJsb7/orwcLdN3/9h4MJqOQg3fyCRCytVkHE89Y/mJPzc92i29iNFpdvtQ/G7vIucArXU1F5Z+9nkxTbYzlj7cxV4O+ZNHi77zR5Oh2MoUa67IFf49lqMmODhmOvAJuhIbh8tI0q8qQWtU/iE8rB1ksd+TZjFdbY3fgt1xGl0P3LIMcbc1d5LhsMHZH85uyVJQakomoJFCoOGXFYzzYElsC3WcISwoxzsKTLf4mz7D2ZkZfhTko+Jiw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QoiNNnmmyYV4P7dX81eDSPZ8HPmOUxRQvY8l3Vr/iQY=; b=mzTXT043Ob7zyk/YCm3fZhJFN0mLLnThoh2quxcamuPNxDBiP7kq9PpLI+oDSMb1rjSVospTxFcYx0P6jtWzYjLkcwqCR93Dfjexcgaw8eE+3pv6L6yRj0DEZP5audokRd/ZsXQrrbcaJzkmqLCfgQiNocdc/Uz7Sb7ctkJ4heIxUBoMT+k/gt1YxgpZLJHpxxH1CNvrjYqnS5kog6qE2rVbGDxyYFhV+cp/mahCQ9oPI98JUb4IfNx14GMUiH8H6nvpbbN24W78pZap2TIzZP+6Faw6mtimBSrSwBnYZfUeMT/UDFJvEOK6UpWtJ29EGbrlqNhr+HFHlKM+ttpr8g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securekey.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QoiNNnmmyYV4P7dX81eDSPZ8HPmOUxRQvY8l3Vr/iQY=; b=rTNZxW6/mjuve8vc/VQalhfbkAQC+Ve1JBxWz3GeffsJQl0/SQ2itM9p56QDB0RU3BZGr1oPIsIaa/bRfXTftM9bw2Du6OXhgM8OOFtC9or7JziiXj1JVi2z7oq/9j+gcDDAjsRFxsGKyUVVyprbd33I4iKmGB/AhH0Axgx+tqk=
Received: from YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:8::32) by YQXPR01MB4739.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:19::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.15; Tue, 25 Jan 2022 16:48:57 +0000
Received: from YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM ([fe80::5d08:8315:57f9:617f]) by YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM ([fe80::5d08:8315:57f9:617f%6]) with mapi id 15.20.4909.019; Tue, 25 Jan 2022 16:48:57 +0000
From: Mike Varley <mike.varley@securekey.com>
To: Fabien Imbault <fabien.imbault@gmail.com>, Justin Richer <jricher@mit.edu>
CC: GNAP Mailing List <txauth@ietf.org>
Thread-Topic: [GNAP] Addition of optional 'access_token' in interact callback section
Thread-Index: AQHYCVuLXSjiHDOFqEeTmBF69QY8cqxtlXdWgABFAoCAAOaKgIAFPbc7
Date: Tue, 25 Jan 2022 16:48:57 +0000
Message-ID: <YT1PR01MB309982FF5EB0D8D217537777E45F9@YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM>
References: <YT1PR01MB30997386FF4252950B34E9F2E4549@YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM> <YT1PR01MB3099EEADBB4C78C6BD0807D5E45B9@YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM> <EC5B1BAD-6526-434B-A6CF-9CF656124C9B@mit.edu> <CAM8feuSC2vxHWTu4SkcXZDMs19H25Ep05fZUHo0zznJj0nDdnw@mail.gmail.com>
In-Reply-To: <CAM8feuSC2vxHWTu4SkcXZDMs19H25Ep05fZUHo0zznJj0nDdnw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-CA
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=securekey.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 89cd48b9-bb78-49de-6e60-08d9e0229493
x-ms-traffictypediagnostic: YQXPR01MB4739:EE_
x-microsoft-antispam-prvs: <YQXPR01MB4739D3DCB3064B72ABE2B98FE45F9@YQXPR01MB4739.CANPRD01.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: pRE8b3cQSyxnBnu/uC4w98KJSWb8GDcE66QdHyi+DbW8Gi6GOD++HUV+ztHN77cynZklBlw1qsZe0tnfM+GSZ76L/NIvqZK3sR3yf3yFnXFGuEBVPSsuDPHuTbX3tmDY9D//txadPP0/IZSqDxubhtj7tTeIOPBOfzwEBQZDVs1jJny1VmBSxcg9KsrBBp4dnuro1WplpnsOcRwBRgGXNvpY8WvTrHU7kThzs2xa2UH/D8bkm6MMOpHjdbgxhYVGwJq1Prz7PO05uptR5R0vvK0i6ZriRdUYOkvaKNW8pXyT8Sk08ibhsHZ7qqSU3kEj6HriKKIZl4katDm/XfTWbV5KrJWFxkSuQBK2bEZTORkJxiSX3VNvVdIXszcQOhqBfqr05FQHwkCYPZXHb/Ll7o/tpJB8F+d2RW0QR+b1ZsoUSeGQ7Cwr5CJQRGl+RBYrhfNXwahdDgd7Nqy9zbhWHuLEpRfVYMS6cQic6li875z8DbvheAHAiOCjoimk9P2UhPHTuKN+pdWXkiAC+UJVIDfXLyWf//w4PV7HdKALmSKnqKiUxJwslzJcQBMDd+55eOWCyxbj5jwmvvZZOHo2aLYbS7aO24cisV6kD3emejfSWFEoNZQJZzluehq3RrWsepZaNGVfSfqKeuqk+Qlrr+RU/8NBYp1dycYSnXBqldFcewuBLIOLkVNId0dfd1gPp4aRi8jA6aoOiU5KcNZQVJyu3iyrRhe3BK96m3aOAjg+xV54gD5hWC3fnB7Ymg+mX+YozYmkipnpQiZybzZlT+/jhmnmOFIAzEquxR7hZFU=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(186003)(38100700002)(66946007)(26005)(8676002)(76116006)(66556008)(2906002)(9326002)(64756008)(66446008)(5660300002)(33656002)(52536014)(8936002)(4326008)(55016003)(44832011)(66476007)(166002)(508600001)(9686003)(316002)(110136005)(86362001)(7696005)(6506007)(38070700005)(71200400001)(53546011)(83380400001)(122000001)(966005)(20210929001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?2eW6jKRGwcOw0Olfg9zQq2ieN9ZIHSCVv5xlonB2LC2EFqjlQto45edb?= =?Windows-1252?Q?xuRRgHUAIXoCQ3bl4Tx4KGKIOtPr0ie5BCqDc0ADSvdAh7up6qqhtf5K?= =?Windows-1252?Q?mhdRbF2rbG7h3wH0Ct2L4txSonWYj4CgPvYZ4lVRj+pv+/QK1Dd+ErRp?= =?Windows-1252?Q?5BNgZGi6eYhJvy4LGLRdoX5ph6x1qJ7P6/+q3lHNdnR2SGnJgPl2mEMH?= =?Windows-1252?Q?wzhefDmwImj3yTRAvOhUD2tOznskmYmqXd50jD3xt4MplR5yksfv9vVc?= =?Windows-1252?Q?7+/+lckS5SMpS23/YJFNClsbvF08yofCQf51v5dyj5ghH1kpMk6bPhr6?= =?Windows-1252?Q?t7hU88fnSnfwze+xbpJlGvLHN2ZUa+oA6hzQkv/xhBIcLt/xDvOvPS/B?= =?Windows-1252?Q?tYowG+rWSRIG2fzA8nmPDSc7rYWaFcCugs2mC67bT74DvDJmdLnkpvw0?= =?Windows-1252?Q?zIzEA+TQCA8WBGzOcXM+cCqwLdcJAEyw+uIBOws8zss98E8GGRWjk1q/?= =?Windows-1252?Q?SVr9RkE2ZYkeitWFLsdZ5bndU2wy9/6royxvtNsQgNU4NyozBEQO9+QY?= =?Windows-1252?Q?iCacNjRKzqF1ZSI77lO64mPKWBYLFCLlhGO8XZA/apl04muogaSJXyIj?= =?Windows-1252?Q?jUjxF5RiQkd+9hXwA9UZngLz0o0wKQWByNWJEoUY5uWgzmuqAX10avpq?= =?Windows-1252?Q?chKtuaXJ62ZeoUGOXvfU4PznIGho89Qr/qVgNAyHv1WIyTciG/ZdNzGu?= =?Windows-1252?Q?B9nLhTojD2KqFrVOq4T6U0lbBpFZ2BfZf78T5nNtK5vjDUAYYj7LsTRZ?= =?Windows-1252?Q?A92KiPdzPKQOsf9e6AizqTS+1UjoaKa8OheAEc+BuLKGSEIe9cLGPBkQ?= =?Windows-1252?Q?DKxP5uzJh+1RV8cAar0koXfMO2d1Z9yKuwVItJJPMu0E/fIU/cqrWBzV?= =?Windows-1252?Q?bAqDrM47kP4asWAf49AW36qKioqG6nBsxs0SfA515qTnIcCTae3WfAep?= =?Windows-1252?Q?GgCC2yMZNlHOIBPxjLZgT6Ns0iC0UBTqDqwygLP8MszfHMAA/+McKBdR?= =?Windows-1252?Q?JgpIYszDPX+XMBnLPLxZxRBnIC6/ocvTmYGWiL5tbaUnoD6PRLAgZ8Im?= =?Windows-1252?Q?JJdXVYmEr2J8p3Nql9I7z6OtmOiVOHZboMTinrAq/BoWW4A/HXigv0HZ?= =?Windows-1252?Q?hMQt7KkhbsIQZ2zEAV0skDRSMog0lRAtEJFYXf9ghGkZf21ONb1Wo3p1?= =?Windows-1252?Q?OXoJukv9haxdxM3B6p9+MVQJ4EeFDT2sLpEN5XGBNDSWTvoIrrKSqc19?= =?Windows-1252?Q?8M52W9Zm5fPyzhNGspdU/C5vIB2P2sjXVqOS0wl5PlLnZ+Po6nW+OxOb?= =?Windows-1252?Q?IV+LRSkXeGLbrRiJ4ErDRqxUUL3ZGabqOt8KGEOZlMPwmEqwC7Fulznt?= =?Windows-1252?Q?kEGFvStlQYOEHrMtcRUkAQnrk/QDj6Yj0e544X4jRPGscr+iz3piSvmZ?= =?Windows-1252?Q?5up6tZOdUBNBPlMj0IqLSfwLVBI5H2H/fb/1+FE75J/4sgkEOK99vWpz?= =?Windows-1252?Q?O4XE82grYhtjvFYTuK4ZfXxNy42cnHNHlpSiSeN1XxQkrTyY2uRKOmO5?= =?Windows-1252?Q?t3uDIcYyFgn+Lkk19GCvLwL9P126BNlWBNpjyNJmGX72fX3U8wR841aW?= =?Windows-1252?Q?uQjQinWmCVJ1yW15v2M0XoSN045bjMclcZqtJ3AHomZP4R9sM849etp6?= =?Windows-1252?Q?be7L9nHo3bqfxfJ42AnfMTccnSdUXb/7dOABNLiZifeGrrq4MVGXBoO4?= =?Windows-1252?Q?68nAVtwBRJB1SJYQEk7qsNzDkw8=3D?=
Content-Type: multipart/alternative; boundary="_000_YT1PR01MB309982FF5EB0D8D217537777E45F9YT1PR01MB3099CANP_"
MIME-Version: 1.0
X-OriginatorOrg: securekey.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 89cd48b9-bb78-49de-6e60-08d9e0229493
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2022 16:48:57.5054 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e211fbf0-7d88-4a7c-b5b5-09a66b0b7ad0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: diJQhvSZ+CcmumTRkWsOdQsUU3rsn4I91wJIow7+Qdbxf0SFngMUA9lItyVc/RzB4HxcZT0I5hrx3IhXn63RROdY8wS4MxhwX2UbjETLxso=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB4739
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/qOWiqd8Op-DmncXcD00AoTGDmfA>
Subject: Re: [GNAP] Addition of optional 'access_token' in interact callback section
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2022 16:49:09 -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 <fabien.imbault@gmail.com>
Date: Saturday, January 22, 2022 at 3:27 AM
To: Justin Richer <jricher@mit.edu>
Cc: Mike Varley <mike.varley@securekey.com>, GNAP Mailing List <txauth@ietf.org>
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, <jricher@mit.edu<mailto:jricher@mit.edu>> 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<http://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 <mike.varley@securekey.com<mailto:mike.varley@securekey.com>> 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",
            "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                                       mike.varley@securekey.com<mailto:mike.varley@securekey.com>
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
TXAuth@ietf.org<mailto:TXAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth

--
TXAuth mailing list
TXAuth@ietf.org<mailto:TXAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/txauth