Re: [OAUTH-WG] Call for adoption - SD-JWT

Kristina Yasuda <Kristina.Yasuda@microsoft.com> Fri, 05 August 2022 20:00 UTC

Return-Path: <Kristina.Yasuda@microsoft.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FA9C13C50C for <oauth@ietfa.amsl.com>; Fri, 5 Aug 2022 13:00:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.589
X-Spam-Level:
X-Spam-Status: No, score=-7.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.582, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAUj05lj8y8U for <oauth@ietfa.amsl.com>; Fri, 5 Aug 2022 13:00:16 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640128.outbound.protection.outlook.com [40.107.64.128]) (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 5AE04C1907A9 for <oauth@ietf.org>; Fri, 5 Aug 2022 13:00:16 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RYLEUiloaAdTfStpjTqVBIh6SttQkCRjctiNF5Rqc8BS+Oxy2BlBeBZQQp6vhYv9CEyT+uxvGpYIAqus7zlIfsimpIhUtwDniVBVYudxfP6LpvQOEibdnmMWj5dxuhNWqM8+cHs3Y91xd66cLTyfuAieeflUZFfxnpTQhX3c/OQXm8niGbdAyaiFvbzxhzx9vHJKNecKXt4XwnT+2elfrf//2T/MBYt7Eu6mhhe8ugoQn3sssagweHu8/8NKy0M7MMwxNdzl0Ee4rbe8mPLnFZerWK+2PEiLqPzYTpkmKfEuzvmneDC8BejoMb9Z4BVqyYi1HofXn3fa6eG/2dPGJw==
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=sCiLjME9Eh6G5DQYFxQnzZK/TmryPqjl1LXKXWZmu78=; b=ntl/JESG/74VyitrjyOgc+MUsi2RS4NM0+FBGAWLEasoqrCmsoadorMb/PPKz06c9az+ahLJhZAaevupJP7NBnGcAZVCXv/KT30pGOQKwVbx7STQ8C5lzi3zZ2xv7agqj5ATAtnCK3WlFy40OWGm/A1StYKx8QSizG8+EzkZKG+xuRPNfuc4b2bOTWqAfWVEfqB3fpzStvWjPo8b5oLkX7Kpa7ScuBmmu01XJqxKZ0sp1PslQcdYd9fkl2dnRWdy32IED71WJ+9OIabRzH11KxWH0MG2svoHAp2aSEQ1CJ0PTjH5UgCZFM06jaXU8T9+/r5t1n9Fs/shSOX8oY8i3g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sCiLjME9Eh6G5DQYFxQnzZK/TmryPqjl1LXKXWZmu78=; b=YvjAWnZvztCPudt7EHoIoQgQiSDdSDS/0SF6aaCH9XN9SgeIzzOGhZamRBdqcoKBg+f+sJA0r2u1ubLx6C2St3E2J8D9WlAoDxYpc1SlC3BfvTetQs45/IgnqVN2VTVkEd5NTMjHK4AUPWSG2ZLKNQsko2X0FIS/O3fzz39b1ZE=
Received: from MN2PR00MB0895.namprd00.prod.outlook.com (2603:10b6:208:3d::15) by CO1PR00MB1289.namprd00.prod.outlook.com (2603:10b6:303:15c::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5544.0; Fri, 5 Aug 2022 20:00:11 +0000
Received: from MN2PR00MB0895.namprd00.prod.outlook.com ([fe80::b0b9:eb2d:58f8:2f01]) by MN2PR00MB0895.namprd00.prod.outlook.com ([fe80::b0b9:eb2d:58f8:2f01%6]) with mapi id 15.20.5544.000; Fri, 5 Aug 2022 20:00:11 +0000
From: Kristina Yasuda <Kristina.Yasuda@microsoft.com>
To: Warren Parad <wparad=40rhosys.ch@dmarc.ietf.org>
CC: Warren Parad <wparad@rhosys.ch>, Daniel Fett <mail@danielfett.de>, "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Call for adoption - SD-JWT
Thread-Index: AQHYouCSYdQ/0/bazkK0Blh3C8f3dq2VSeCQgAX6OICAAAXOgIAABfqAgAACfACAAAEgAIAAAY4AgAADjwCAAAtOAIAAgX+AgAFWp4CAAbDrgIAAMDMAgADj2oCAAAIbgIAAATmAgAARb4CAAAdZgIAACF+AgAAwMNWAAEmTgIAAJhCg
Date: Fri, 05 Aug 2022 20:00:11 +0000
Message-ID: <MN2PR00MB089571D9A7032670A5D99D78E59E9@MN2PR00MB0895.namprd00.prod.outlook.com>
References: <7f46f3f1-d384-37ef-9e76-8cb80995fb4c@verifiablecredentials.info> <1D2C56C5-8155-40A3-BC00-2EF7D12C9122@lodderstedt.net> <9c1c8d86-ed98-a4e3-e864-a00c82a24134@verifiablecredentials.info> <CAODMz5EKYo19JK8Zs0=UhCNdHZM9SddOpCNjqOAA=LpeMXPJ_Q@mail.gmail.com> <5c0091b0-a8ed-3690-fc86-3fa662af0d15@danielfett.de> <CAJot-L3ZQQa0Rragt+ds8bkhHtjXM1hMVgvcShGYxdxYFYAhhg@mail.gmail.com> <937ef7f5-163c-aaab-3f62-bdffb17bf150@danielfett.de> <CAJot-L2vBxsEhPt55o6cxrrdT1TvfWpQKwxGH49UnXK2FqG8Vg@mail.gmail.com> <BAA30BFB-A157-40AC-8199-A1FC0B3DF9DD@danielfett.de> <CAJot-L2+t-7-==+22=sqaC7y7A5O7yGzojRnJF5M8oUHSRJP6g@mail.gmail.com> <MN2PR00MB0895DA567B6ACD8DBE3EBAAEE59E9@MN2PR00MB0895.namprd00.prod.outlook.com> <CAJot-L2zr+XYoKfg3NYNAn8xSPT=-EhrwEVpp=aT+LotDrgj7w@mail.gmail.com>
In-Reply-To: <CAJot-L2zr+XYoKfg3NYNAn8xSPT=-EhrwEVpp=aT+LotDrgj7w@mail.gmail.com>
Accept-Language: en-US, ja-JP
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microsoft.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 287bc010-3255-4064-5595-08da771d1ab6
x-ms-traffictypediagnostic: CO1PR00MB1289:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ryyE8Hj5tW7yIxe28x45R5lx3bjsBvB4+9qWC61Ul34pnenOZcsOeEAJI204CBQqu2q3qAoJs8SPHNlc7G7lo+oOcGumu0TIRaNTge3ux0fjwb8DmZoBK3G78kcGSnMhQUfmf7ofVBindHgVksax4wDkH16/WidppFyyC/WLsU4f/g3LfvHNkq1GAJdzF7deVKoU+m7HpVqHOFEVhloiIANlzIBcruKLFK6V7vit4hvuxxNqHN7LrD9I5bBcIziDsUmz0zFZ+60xDDnwuB7gYXQJ775KlbgF2DuSXKnMgO6cKochL1gid3uYk715IRKOrsbdTaZmenbT9cuZtE2q6OX4TQzbpoXnv9vMUkEe4LTApjkcmxYXqPwUmJa7jswbjxUwYegvxWA6Gc6YwPrEYCi2rSV9K+zoZP4oH/FBopDb3TtVuXZUapeoLpmsisO4GHMgT4KB75Rd0pBOYZDVQYl7CkX9GwgaYyD1OTAyM/hm0CaINW5htRbAlr9tpcqFvdWkTUT1goWYEbyacn2wNJe3TuKTBvQYzOOs1bOYKYRsEiGYJEas6mg/8VXhZGvo9SaDko/p6nxCYCXEbTXZv+l5y0CvvUt1+gRclsK4R4MHExHSecjex0+DoXzdmgOWX1UhVLrQcdrzVPRIQWvr7hN42ASNKln7TAXOtVONUyqCy06h0AdzThBl3njay0DKa0SK7Q+m1xGrgkxVIMi8qqM2qBPZgKEsL+hwGQHLsYwqeoKnOxLqZrFj2BBI3ufBom/7e17E63OiaDMS+qFlDdWky7vOQTamZeXkXdeeEv4+WEDheJf0s3QxRYYmGe1fNnfD0LyHUAxqCTwSj0LxOzo/eN3mjdo6eLteheMGNDrYvtBru6xRGfr0uD69Dzev
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0895.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(136003)(346002)(376002)(366004)(396003)(39860400002)(451199009)(7696005)(186003)(53546011)(9686003)(86362001)(6506007)(10290500003)(54906003)(41300700001)(71200400001)(166002)(966005)(122000001)(55016003)(38070700005)(478600001)(82950400001)(82960400001)(38100700002)(4326008)(66946007)(8676002)(76116006)(8936002)(64756008)(66446008)(66556008)(66476007)(33656002)(8990500004)(2906002)(52536014)(66574015)(5660300002)(83380400001)(316002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: Rt6QLErcsr5LzIdwb1CN7eooq1IsBnTiC9GdiZ7+wEOZDXvMEGGRLzIrR3dSAe79GYNQwvjiTZUiC4KZhbo/Gykc+Qy48h6Ph1foV1l0TehbiY2d2ncK6sdJh6MQfGnGi+8u2uG1btIY19+dl8/CzMmyUOFIL+qDX9ZMJ3AZTrmEoc4Mu49mcQFCI4MfC93qr4oD2XWjxvp/1U3zCPqWVnOJm4Ah2Eysy9g52Rr/dggm8UAQ+s1pVT1q+WuCCMg3t7DdRWOmlVz5T0krD85qq+bgbWHjZ/nAkSbWhPP6+WwmyTMAJ8/8c3tW1F+tUrumcC0eeAdn+2Mz5RK9Tp3mf5s9jnOCVuWQ389ywFeIxzQrWIPCjvLR9D5i4gdTdsMy/F0/MD9+3otmr2Q0KNiXh/KcIPqrHg0S3naFqIuEnIqOs01+DoxPYw/PQPxe0SqIKpv++e9sKdOZUUJQYWTzL/R3sj67lAUlIFm3ImpCWMHUTqvhsMLCdkE9swi3PN/WBQW4wbn2PjcAXmpO5ZI8JGDnYBFWMA/bHuqrGx62KT8A/ilbJUOt8ycU86waq+KsOLORpEIl5rKASKDsD888LqZeUeyC1FFOp788POnWQTMR/0RI3vj8sPDZmyDx90cObzSnN+qI6yi0A1exrQMFPkfhmr31RIfp21a90AT7ogG+FnhwAh7a3EpGAONIro/UquKtxi98bTHgletWY7ji/bt+oyDOJ4/vtOxQ4l4lWYrElRONWDeY9YSuElmec9AhUo39zzneOKAg2dosQAxX8eP6rkz59hdT499nxiR2+NS5MoVpxqijqkcTHqcSGWV1avNy/0UpURp5HbXHsInVfvpsL8FmKr26EHlNyuXFHZfb5tyY4PaorLuHJZ6Eih5MzRHBUvMhr2cgExj3ao2vJdRZRD9umPptS3abWnFS5n5mAmjkyGb5nw433sfKQ2bd3XFQSR5awD2mSeF/HrVQUppq1iDCXz8wkSSruo80WbXBOZPWOMia2ialGe/+avfgoPSGUK8O4+JxuVng4C/m5yAHkvXFS8pcG5P9vS9YyNuSKIPqyGPw0cGXbtSe5/y1PwzCoOWE0g7CTLMQp6eYbMxWHyv0Xqd1TafW1z7hZZNrMiQRtg1JNI57MyvVzM7FNDS7wklOARJVlPV3blC1xBIc3+mi/4yADrRa2Fd0gHVz4EC8B149LA6LE9jq6fAmfFnCsJ3d3jQ+KVZ+gweLlMp3ke8OIg5Gmh2DTeMLAovhNxsnzF/rc/I0e92GoUzhfsmu9hknPtS2LGmKZHN8kxC6BnfH1lPssFnU5xRRy2pF9qH2i9JWWHu3jSKfsGPE6yhQD4MMbRWbdwtzMJVi/ApH85aGp5jG5t0l+IZ3YsPZNrBiCvribD7yabLgNDrWT3cziuAEe5x4Or1ZsmbQkYuqdB2ijOAXEpLu5C687NBHYUPWofzfHxLMIVDfU8ru3j/NFHDhJndKrtX70XN/5MwXBE2xXm7I0w3biT5g+Xg+FMrXuAhrav+nywaLmD8UDdHliSDtRS/xGhEdcKyCa4cdFKxAoaEJdy1o7C9VPpQWvzBY8s2ceI4D4btObWcpa6AF5N63Me6sBDM/9uSVvCDQ93qCoCa5MuLIFO+CGVT1P6/wGItJA3Rx5PNRiRPf
Content-Type: multipart/alternative; boundary="_000_MN2PR00MB089571D9A7032670A5D99D78E59E9MN2PR00MB0895namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR00MB1289
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/t-peZAoI-ILOTZHOm_u4XpHkjLs>
Subject: Re: [OAUTH-WG] Call for adoption - SD-JWT
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Aug 2022 20:00:20 -0000

"the AS can directly issue the restricted token"
-> The use-case is issuance decoupled (ie happens asynchronously) from presentation, so AS cannot directly issue a restricted token.

"Can you list them out succinctly"
-> For example this thread talked in detail about issuer issuing usbsets of JWTs vs SD-JWT approach in a decoupled flow. https://mailarchive.ietf.org/arch/msg/oauth/_nf1_4GOefLtjMz2uvzdd0E3D_0/


From: Warren Parad <wparad=40rhosys.ch@dmarc.ietf.org>
Sent: Friday, August 5, 2022 1:41 PM
To: Kristina Yasuda <Kristina.Yasuda@microsoft.com>
Cc: Warren Parad <wparad@rhosys.ch>; Daniel Fett <mail@danielfett.de>; oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for adoption - SD-JWT

Can you list them out succinctly, because I don't feel like they have been? The reason I say that, is if all the entities are online, then the AS can directly issue the restricted token. So the only argument I can see there is "We want to reduce the load on AS by delegating some proportion of the AS responsibilities to the user's client". Although in that case, should we really stop at SD-JWT, or should we go for a solution that actually allows user-clients issued tokens to do more than share user claim values?

On Fri, Aug 5, 2022 at 3:32 PM Kristina Yasuda <Kristina.Yasuda=40microsoft.com@dmarc.ietf.org<mailto:40microsoft.com@dmarc.ietf.org>> wrote:
Yes, SD-JWT is not complete and that's exactly why we are asking for a WG adoption. The questions you are asking are better answered in the WG, post-adoption.

Thank you,
Kristina

PS. Offline claim transmission is not the only "feature" of SD-JWT for all of the reasons that have been previously outlined in this thread.

________________________________
De : OAuth <oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org>> de la part de Warren Parad <wparad=40rhosys.ch@dmarc.ietf.org<mailto:40rhosys.ch@dmarc.ietf.org>>
Envoyé : vendredi, août 5, 2022 6:25 AM
À : Daniel Fett
Cc : oauth@ietf.org<mailto:oauth@ietf.org>
Objet : Re: [OAUTH-WG] Call for adoption - SD-JWT

It's clear that good thought has been put into the core of it, more so than other drafts submitted, but not yet feature complete.

For example there is no sense of how the private/public key exchange actually happens. In holder binding scenario, it isn't detailed how to actually include the public key in the sub_jwk claim, or what a "reference" to the public key actually means. Is the server an AS as in OAuth?, or are we building on top of another token creation standard? If it is OAuth, It isn't clear if we need a new indicator in the token response that tells us that the salt container is attached to the token and that it shouldn't blindly be passed along. It isn't clear from this discussion if we need token revocation.

Assuming it is the OAuth token exchange that we are building on top of, there are lots of open questions of interoperability. I.e. Does the digest go in the access token? If it isn't OAuth, we don't have any guide on how to actually do the token generation, how to verify the signature of the token with the digest, and I'm sure there are more things.

We don't need to have both in the same WG, that wasn't my point, the point is if there is a concrete reason that others aren't working on it, I wanted to know why. There are JWPs, I don't know anything about them, but it doesn't really matter if they have different approaches, different cryptos, etc... Let's look at the features, that's at the core of what matters. So far the only feature we've been able to nail down is offline claim transmission. Will JWPs support offline claim transmission?

On Fri, Aug 5, 2022 at 11:55 AM Daniel Fett <mail=40danielfett.de@dmarc.ietf.org<mailto:40danielfett.de@dmarc.ietf.org>> wrote:
It's not that the people I have spoken to didn't like the idea of SD-JWT. It's just on a different layer than JWPs, using a different approach, different crypto, providing different features, and on a different timeline. There's no compelling reason to have both in the same WG. There are nonetheless good reasons to have SD-JWT. Having SD-JWT in OAuth WG is not an attempt to "backdoor" anything in!

I also didn't say that we should adopt SD-JWT because it has been implemented. You took my statement out of context. I wanted to underline that the spec is practically feature-complete and can be implemented today, providing the features promised. Meanwhile, JWP is not there yet.

But, SD-JWT is not in production yet. If the OAuth WG decides that substantial changes are required, now is the best time for that.

Also, I wanted to highlight with my statement that SD-JWT is easy to implement due to its simplicity.

-Daniel
Am 5. August 2022 11:28:49 MESZ schrieb Warren Parad <wparad=40rhosys.ch@dmarc.ietf.org<mailto:40rhosys.ch@dmarc.ietf.org>>:
Maybe they have a good reason for not wanting it, and then we shouldn't be the WG that backdoor's it in. Also: "other people have already implemented it" is a cognitive fallacy, so let's not use that as a justification we have to make the standard.

We should get a concrete reason why a WG that seems like the appropriate one, thinks it wouldn't make sense. If it is just a matter of timing, then whatever. But if there are concrete recommendations from that group, I would love to hear them.

On Fri, Aug 5, 2022 at 10:26 AM Daniel Fett <fett=40danielfett.de@dmarc.ietf.org<mailto:40danielfett.de@dmarc.ietf.org>> wrote:
Am 05.08.22 um 10:22 schrieb Warren Parad:
> and nobody involved in the JWP effort thinks that SD-JWT should be in that WG once created

Why?

For the reasons listed, I guess?

Also, mind the "As far as I am aware" part, but I don't remember any discussions in that direction at IETF114.

-Daniel

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Ca35566de5c2a48e5717208da7709af03%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637953180743495603%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=x%2FqkyLZ%2B9ePkG6vn3qZ5nGXGDb52BqX0jYAu4mSufnw%3D&reserved=0>
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Ca35566de5c2a48e5717208da7709af03%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637953180743495603%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=x%2FqkyLZ%2B9ePkG6vn3qZ5nGXGDb52BqX0jYAu4mSufnw%3D&reserved=0>