[Privacy-pass] Issuer directory representation (#369)

Christopher Wood <caw@heapingbits.net> Thu, 08 June 2023 21:30 UTC

Return-Path: <caw@heapingbits.net>
X-Original-To: privacy-pass@ietfa.amsl.com
Delivered-To: privacy-pass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FA9C15154D for <privacy-pass@ietfa.amsl.com>; Thu, 8 Jun 2023 14:30:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b="cL0P/fxo"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="nZDljF/7"
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 FuIJsTLgwt8r for <privacy-pass@ietfa.amsl.com>; Thu, 8 Jun 2023 14:29:56 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14140C151531 for <privacy-pass@ietf.org>; Thu, 8 Jun 2023 14:29:55 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 725B232003C0; Thu, 8 Jun 2023 17:29:53 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute2.internal (MEProxy); Thu, 08 Jun 2023 17:29:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm1; t=1686259793; x=1686346193; bh=TsA7JmHd2m KKkvZOEPjlEiavXHJPTOWSjOZkee1EM7o=; b=cL0P/fxo4rTNl+FU6NHBRWHxOx JYmEBOJQ3kJBtKgHtuJ9HqOiUl1auRZt4e1bv8L9Dv0D4VVV4jVR/tXMc+rN4OYq NNIy8WDA83Rs7JSg9KhID0eqTgH9DT6Wg5xz8smg7HZURXcolSd/bm+gI6+9ke0H VkXeKL1oeR6k4pT7kPVQjdLb7XPpp5bxxBHDk9sxGwZN+r4WNvHc/q5A1jZs4hKA mc0eqT8lY3kkZB+7f7Oz3d7zGT9OSwqapCrAZY3d1Ps2ALv0GSFNvMK4TzaL6mjI mlHTeM2Fz5Kay4gq3mmzj4bdn06MNufdyW0jYPymBR8XEC10Mi+yt/FXog/A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1686259793; x=1686346193; bh=TsA7JmHd2mKKkvZOEPjlEiavXHJPTOWSjOZ kee1EM7o=; b=nZDljF/7UId0wiKm/iSmVBIgGJgYKPDUl2Pu+hxZm5C/NnB9iZ0 eBAsGCDnJkQ1KM39tl/fBj1iN5TIzIP3N3c6cmEmIuvcVerNszIryNnDLXCNregS Bz/319Aw/s9+iKdmvqvfSI5XGR8zDJX/wUeX7LiKraHHime7S0Lm567jcHybWKwX sBN3Z6uJVBBbiJLFVGa8ikN/qNqC4umqyvqTbDJoNKSBziJJ8ZB3EVzNOguX6dfD yI3IXUdOLc5Fa0McxTvjhH1qwDgZDGdXFBbfkDWAuKaLJ5lXOj6FzQYCdLvXmv8G OrkHISB4TLwT51Dh5086rEALU5aPvbA9XuQ==
X-ME-Sender: <xms:UEiCZBcczLuAx_MXsOONNqrEu2uSP5L3qro_l5X24hz2zU8d-kMFIQ> <xme:UEiCZPO7TnZ_kNhTM_TumiapaGUTGcfkX0NBXHijZJYOGsLtuCISkOq9sJ3XM8gO_ 8WHy-IHzlnz5Gd6TSw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgedtiedgudeivdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvfevufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpeeiieeiudeive ekvdeuvdelveeggfeufeefveffgfelteejjefggfevueejueegkeenucffohhmrghinhep ghhithhhuhgsrdgtohhmpdhishhsuhgvrhhprhhothhotgholhdrmhgupdhivghtfhdroh hrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegt rgifsehhvggrphhinhhgsghithhsrdhnvght
X-ME-Proxy: <xmx:UEiCZKiwxhEzIQ6oNjJNVrT2vKA95ZWc4dv5xXGsrQxp549ca0bPiA> <xmx:UEiCZK-TE-QJ2GKellBD7UjUjp-dL3NrbsIMDiVEAU9daQyUPGtZsw> <xmx:UEiCZNvfnNZd0V5MkEO74JfzGCNkJFGN77Y-ScuY4PGJEGlaq_xE4g> <xmx:UUiCZC5axa2Xb70MchRiUnuwXEIwt5-I3jeAIlZ1S04TxTTVczguCw>
Feedback-ID: i2f494406:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id CD959234007B; Thu, 8 Jun 2023 17:29:52 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-447-ge2460e13b3-fm-20230525.001-ge2460e13
Mime-Version: 1.0
Message-Id: <fa636aa2-d988-42b2-ad9c-fe0fb25bc960@app.fastmail.com>
Date: Thu, 08 Jun 2023 17:29:31 -0400
From: Christopher Wood <caw@heapingbits.net>
To: privacy-pass@ietf.org
Cc: colin.bendell@shopify.com
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/privacy-pass/1hjuHKdAXMQRsvjQwUCuTFCfiFY>
Subject: [Privacy-pass] Issuer directory representation (#369)
X-BeenThere: privacy-pass@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Privacy Pass Protocol <privacy-pass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/privacy-pass>, <mailto:privacy-pass-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/privacy-pass/>
List-Post: <mailto:privacy-pass@ietf.org>
List-Help: <mailto:privacy-pass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/privacy-pass>, <mailto:privacy-pass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jun 2023 21:30:00 -0000

Colin filed #369 [1] to discuss the current representation we are currently using for issuer directories. Basically, Privacy Pass chose to introduce a new representation that bears resemblance to that which is used in Private State Tokens [2] and is already specified in JSON Web Key Sets [3]. We should sort out what to do with this discrepancy.

Speaking for myself, neither a JWK or JWT expert, I think we should stick with what's currently in the draft because (1) all formats seem mostly isomorphic and (2) JWKS are, to my knowledge, meant primarily for JWTs. Moreover, the way that keys are represented seems unnecessarily complex. Why do we need to specify any of the "kty", "alg", or "kid" parameters when they can be inferred from the token type and public key?

Note that this is primarily relevant for origins that consume the directory and use it for the purposes of challenging clients, but it may in the future become relevant for clients that want to consume this resource for consistency checking purposes.

What do others think?

Best,
Chris

[1] https://github.com/ietf-wg-privacypass/base-drafts/issues/369
[2] https://github.com/WICG/trust-token-api/blob/main/ISSUER_PROTOCOL.md
[3] https://datatracker.ietf.org/doc/html/rfc7517