Return-Path: X-Original-To: jose@mail2.ietf.org Delivered-To: jose@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 458DF110D7034; Mon, 6 Jul 2026 12:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783366085; bh=EOW6LASVEcoy+GssQnvpYG0dHZnyK7EwxXWb0WBc3Wo=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=c3KbdhsN/w35lvcbYL0dQhWEu20dlFjQfI7qgqKQQ1DFQo0GirAaEszvc+nxDauuH tCIbcgzY0083pjoX/QhT0zBRQsyFG2+U5HYBoPugXKBknid8mpOE1Ct6IOfPfjWBM9 5+vJ4CeFmIUHwCExvlg5FV67ExYQg4RgPM5s4dvU= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.795 X-Spam-Level: X-Spam-Status: No, score=-2.795 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmx.de Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdl3vCxcjoW7; Mon, 6 Jul 2026 12:28:03 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id B489E110CE4D1; Mon, 6 Jul 2026 12:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1783364746; x=1783969546; i=chris.bormann@gmx.de; bh=yxT3ISmd229WKXJ9ArEyM7bj9XIezyGB04Rhmy79DIQ=; h=X-UI-Sender-Class:From:Message-Id:Content-Type:Mime-Version: Subject:Date:In-Reply-To:Cc:To:References:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=nBjnWPkeOntPCZfH/M1Cp/zkBeL/0AXKpEmlXFzfU/Q1OLlFQam0jNmpJcPvmNK5 2vit6s/kthmq6WMiO/z5bGiEjbGQQNxI+Eg3jlb9p1U4EH+Acqk+OI5nvs+T1G+Cw ymB1MHQKjq9mc0T4ofkSEvt65OhmUtbO22fVaUwWzdPmkkS7mLaRw9uiUG6A4xd/X R1SwYClic4mKnZGdmYEpDUpKZklQ+rM4bAxCLw7xi8kpo9/P4PPaHWwZKWReB+Etz e166uta2PN2w10UQMNCLDFNS7xFDhuPno8LK22rqsd9rj7ZmdmlviwyxQtI6v71ev SjHl1CVnlBaMmxCYyg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from client.hidden.invalid by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MDhlV-1wpr3t0UB5-006iHT; Mon, 06 Jul 2026 21:05:46 +0200 From: Christian Bormann Message-Id: <10CD5211-3B69-4B29-B10D-2E6877F4C54C@gmx.de> Content-Type: multipart/alternative; boundary="Apple-Mail=_2FF214E6-4EDA-4B61-8CAB-334102EA6CE3" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\)) Date: Mon, 6 Jul 2026 21:05:35 +0200 In-Reply-To: <0AE12CC6-108D-4F55-BEA4-B16EA7642FB4@alkaline-solutions.com> To: David Waite References: <178283255465.2087397.4256787017301844320@dt-datatracker-f9b87776f-xzl65> <00CEC1D1-A817-4517-9B10-74B26D6D2F39@gmx.de> <0AE12CC6-108D-4F55-BEA4-B16EA7642FB4@alkaline-solutions.com> X-Mailer: Apple Mail (2.3864.600.51.1.1) X-Provags-ID: V03:K1:2MsLYarNRiqUN4Pyz0pfNEwJvEwue1Cy6ARLaWisqNGMqS/DoVt BEEeBTimJrIp9SWHaO60E5zcMEm/xYmOhXRBV35qKxtxf8w1PgxRL3VXtiGEMJKki93Dxbj eK+b82is+2k71GteTRw5y1nxWbZrLjAADBZZbxoajS+jj6PzbwWRnOoDuCtcSb4cK2DmGhP +2aYJVvtoe4ccAM+14KMQ== UI-OutboundReport: notjunk:1;M01:P0:qMNyzr90eew=;IMVuO6567ZTZoTi3ihdCzeVxTWb 0/MypQWbEePHENNiPkKmNZHPmjDMyw8cmD6yOOeujPTrffbcSJclzG4cfQ5gsTFBR1xjIiGJV Z8monMASTGuicRCi1pOwrzmhgDMbsjIf0fJX+2H7zij+Iamvk9D4VSL/f7IOHEDMl7ES+eC1E wHwEYgn1WZbXRjdRHO1Mq+8h4WVX/IHvCeRDGEC0wFTgWJUoOrSDzjno/txFJQ5pP8Xoc9FJJ +sjKeYc6J7eKFgI9AmXAjWG6s+w0KmFZojYqkzK5XeW2GglxgKFxapkTDg/P3Vt2fYmTKQPug ntrxVlWFj/IdL+zl3nEBLiHtNYOhzhhkQhnKogQfmsXhh1ZxYlXepN7v9auevvDSmtAwtTDQX getnzgD4AXGNvxnjwe5/AZlfbKfVtvzEiY/Q2KyL7Yi3da2jMhQfcrfzY52R3YOErq5ZCQNIM dODQg/ijyYBVaIrxcUVkTqc6HutWwdhMmXtJgj0aiXAtCg6T7jZnzNHp+a9lUtvq+YINi/eb0 1IMrwjan+DQRJB+ac3Rg+MRluf7ORgAEIJmGF0eVd10aaNuHHboUQi34gSPcDprqtcjDXIPrK ybYdhyqxxRT/cRZiM17FeKx/T9JecN/zk+g5HVeG+b5rJsPQloCXvVhmfC7MhI3Tt9gAScc56 3ai5FcamUT8wQJwA7gRrdBlHlGIP0Msmydc8RxIkjs3ZRwC01uFGJwMMoozwT2B7PKX6yta0C sx4gmfTHvXVvFiLBQA0V6qxIrb46MSm7Omg+Y5kzBE3RvVQsjkMcggxcHTx0/cBE0+NT7dBYK 1NMuEEUm83lzVQC7dwMhrGUrXUlrYbcQKClUrIf4MapF2/hr1UqFPVbaX6ddwNRBXFC+Jb4N2 9Xq/VzSPHITOobipvx1re8ZaJKHh6f8zLyWpT1iZOtmSKvfvqUVU39FZu+NwODo0tjD/+iar8 vLVVh5EaUOyp+myw89EtBwgppJ2TD1faIsu7bhjcTG6g2Vhj34k+x0XgWoQP64aas7iynmXVp HPImKY9NfzCzQB/Ha2BzqmBfWKlafmFuVQrTIkfvC9xOBK/ohv4hUnyC6mdcOlgIR7g9wUBpy uZu8xidub/kITtwpbLPbWeSj9cbjBoQfQPVZBw1a9TFUaMHWi/l1Ttio4wSkWwSmSpDEjSL6k dQ5fuOXkaZNNlXg3+OqOhRCeWtWWxYS7kGVMgDfh2kk0vHJRXyHFMAhDbVlDv9DapPfnAVmU5 Kw+iT1mTrOYrOm02NrgzzMArxXvBm08YRQ2Xk7v+0XNbRfTJdvdKqm8JAjqqXdp3arngoESwu Vgd9IombocrZ8qjHX/Pf4swb2juuxeuCCf4e32CcoHGevgODLbjhY7ZrEI3H3Vh+guBFhf/1L GTKfRv1ThfJGr7SU9UbvlAtm0phmK91pn0Xrjt817zr+Lt0L6GvEMpfjPMU4p2LrJxfv6pT05 R8Sy1q8mqlvZlsHgDmIZTYjEBoisk57N5qTtZhqY5iyw5mhtEn8zqg075QFvpu/vxYaKnSZUB nzOL9BpGhnmsZhkgpc2fPNNl6GB3RZBSF4v9Ryy1sO3gkrDHMlqfPh6RL3ldSGVF7KdM+zj2+ QdvZo88r+O800Qg/sZVWHdEB7tWdmu71IO3yd4lBJFzcMBI3WlGAyPxngNJqhxKk8jKce9n7X g7iXyRipI9z/IAFyPurgaA3tJ8R3OsyNLFAWa9+9Qcra+ZR7zCB/fBDHIgKjteCBdhSd19xEr UH1GK2fKBPXSaFVbN3rxXAFxIcEMPEtLO8UNifwnMGOLuBuj0ssTuRHEmBL2L2icrILYKzvlI zzuE9WmjPuNuLMdiSLQE6+tJC2qAOMQFt8DtFXf7ByU50PBh7gUAx1VBowghiJvyWBGsHKWdK iZWMrTth+P33wj2vmBIJGy9+/LiLj0JX09FBZXHZm8S2oVbgIVtZPzXupdXmhMiVZ/CghHjjw G2MUkMhsCPPn5FGETyTxoOnvbkOfgfQFGyx1zlY/u+YzqkGa8/QmtcWaMHf/0LQEVUmHotrGj T+ijlu14pCq5Gdb47C6r3aAtt1B8ZOnd3KliEQhVRrAhCrWK2gu5tU3FCq9LxrXdfhqw1YMRs b8tG5sl2bLrIPIT6iLt6WSdd856GVmx8K0yuPmdrXizQiDw5BH4Uc7l0m1Idm64dt1SWuqxD5 qh4ZHmBTmINy/Hv62Q2SFw/bps7pn1trrJUrKFiCwH5AlVPDXkwkqW7ctGj6BTX6kg+r+Sdxq LLzu6U2XwqFpitpm5fA759wA/uoCsEfjAV/2TVzSudwTcuqVEOQv5Kik1TlecTNFx254odZ2B e+T2c1DLLd/A4L5iETEZkqs2FmfTavHHPULjRK9LDkLS2YIXJw4wL/HRXizyDOWPVEYHiomu0 MJGwD7CvLwS/A12cMReTdZ0IAhH+/im/3baIyaxYHuKYNvRjuRtIYV7qKu3SKOdkAfzqwshQa 6igP9tbHaRKYD7KsObYu4a4pdxohzUkfibBkSW0buJBXIqpEjaUd2lGvw8NEPnv8KUgod0A36 i5JfLq1nd7gHOpwNYxblH24jm882oHLXdF2NWK+YPqZa1SJlNTCxRSjBBFjP0+hgehry+4QnV byIeLr+vIGmOWp7vOcDJ0uEY4AuBO1JKjN+hCWcsEZqOnOJZ7BavuZ407Oz/PWLZhey6zD4NQ EBSenmSyrjqOZEhCUM0myLxGc1jnz3JOstGVBep+nGb7J4AMh965cgdSu8owz2YtdSvikvezx oBibfr88QjDhgQDPGt5hhtP1YGV/UI7It+JJvcJEwN1ydhwacLnnydbZX85i61SV+NJ/KI9wj c1kCsA/frhEROdO28BqW9vKzDGdycxffpy3QCvGT9FOgv3zXGukxoXlfQ23z6UiEFdpVTihj1 5B/VqI4n/gGzyAmW/Jz2hlied5l7izsuNY+3vW9CoCR3Od9ckYZFr40JDJRoopc71fevac7Vz Zlc2fPbbxtdzQm1Bo19jLwS6zPH1m0khnRx2jzFX7LMRz2F/QdMx7OBOSE329xO8XtOpjWv3A yNuLvekwOkUPmVQYA8dcfmgWWGkLf/M791QRUPtSDjagnxOC3WydMqpnOC8FlYNe2VfzESBpt p+adrA+QYkosMS7cky/fVVaUhHYJVAyZ+8DirUoFkHK1S26BcZmVdR0BpLXJRGhkkMajMMHmS xDCJSEB0FL+ZuDYmAFCWnT9ZzhuIAY2J5l+Xm4CvQ8rymD/++yz/hZJNxPmfr4XJSY//lnRWe WcDSjcARpY+P2BqGSKfjsU59XaoORVc6NmtGRCGsUbdDuJpd8jhQfn8x4qzYZqaThC1U5A0Eh pZMflwyEBN4lQkbqBiiAgM3XWbu2uhHtFnf8X1368NBEy4Q3+Ma86pv/hLNoFv3/L4S+Tcdfj 9a5GoiTojNkzdmjKoAkHh2KLKopWvfT5LLLCzFIWZQQd98yN1832gK0tle4+9/atW4lvkjASj YX76SBSQZ/fqcfhgqD9V6FGpNEAGlqbOiPVMPyaNMTGAk6KpmyqbnPQwLBDF5WOFBqWwk5ZWD zn5aa5QU/pEnbWiDReuaFg8HmwKe+Em3Jjl4t6IwNZXJG605JxLTYMV1zIaD/C6RNxs9/UET4 HudG+I1tvYJPflIiF1t43Uq2c8Esop0CBs9uCwNQULYY15noGdIJNuNPKwd68vNngzNW6XPyY 1Grcnb/Vwtv7VdGRKzttV6keVdr2Bg4EQahXuPmFTZVaSHTu6HKUJl2t/VR9lyB9HfvZzrRGh /QWTQ58MWUP0CvXz7FEmbgrrfW1NpPx953gHqOWjfiAEXL5Gx1/TzcigVvmuJJYN7Txs/YGuM d4CiRPonp0QdyWwyZ+zePF+dz5vDQq3xUbK8w8YhpJXXfDFQ+oookUSlIgEM0EkEvHXT9WOnO 5YWTl9P/zhEb/z/l+dzu/BvgFmsZEUZGgcxpJKyPNBO3R7Hmd4RvfVhqhSqrSySRpVz2U+3ZI guH1xGO4TjT2uk3Lj/u7WYgGofhviExZWb1osoFiDF7C7a5svID2iGxTMYCt4iS2c9ZgTytP5 ZM5a5/Zce7SBAPYtN4bD4MEFCasLFALWvNbriNM6+8s5lZuZwMqMuFQDZiIcfpqMfFuKzuy7m cayWOdG/9JCE25KRl7sCJNUnQXglByNWLm3sKNbbujaQhD2Mayp46ZzF3myAsMTtbattb6YQe EQRAOOCOsF87dJMwTJXkGUDXpKWXBY9UT6BoXl7xA6SRouRHrlfns9F1WQArW8HHB4+sM1Yde bjClENP8s58BzEPRjG0OV4kfRmXUUfe8dsvZxZ0H1io4tXKCHrMgvTtidkEu3JGwyt1jQzEOm kQsUyQmsTCqc1JE4QJ5ZdlfN6HYRAPWwPW3SPTBOPPj86HhP/YAmCzYFgyuEv28q4Sj2Esuvv 5NzbjXNgxfAiMgPb26zA1SlquDtB3tmcL4/tP6gps7xV9RQepApClvXgH6oZaYeBjE5ecKLpH bqzNhCd2j9pWDhv0sCvLFkS/YlErTXvdP3leACI1CjEyIGPqqeGSIfw2SsLwYlIlFXkglLPyq f1zEe85TfL+hwhxWE28xKG0NRTVSSwZEqH2sJrtIcfv7xUvYpmZ9W/Pl0+IE8VcpTsnr5nt8E rekpoKZugOmMmLEb8xS8jzFCtdE6Ag8IX52iCfQ39dlBwig9ZpuMuoHLKkOYOjwnhLNtr2Q2Z oJSTg3mbk0su03gunC5EAMbdJpLo9FKfgGjiXAytm2CREVOXxBwZmPq6lArNIX1e+6GrRDQJ2 v/3/ZlMjgTCHHaPvCq/t4wtktJGYve2tFtbXO75dhKe3kIzfTblIJlU603Y6wI75b5J2nEAB8 c0eaDNYpQ2emC+0S/LZuGg9A+pGcU4fGgRB2QZKM05Sp1L13QNPmmlt9ewKgw0hm8mXeOO0Bi qYn3C48Zi/i3ZYNONoYfJYO+goLHzuPJi5IoKboUdPpEcDgA+RFSS11Y2spfKcJAHAvLCJrGI CfFuyqoCTUqQIbk5+JY4jgAoEKCegVfRvzF9Tj4y/6bz91ZT4jWG7oTrE/JdFmMfwCYREJJOn V72KtjTGptAUpsaeNpPmta4oIclOcmgvOPrdfWA+McD67ctCzt2WKVN/q7KtWtnhxjK/byNqb d84qT3ITaOdDTVVRlI0GrHZoxhTU15Ih8o+34v2wlASI+r50gaxVQw+l5ywko1cSzTg7cwdHm rB2dyUBCoj7zqEUM8s4IWAQEXQitX2TxmfR9l4BjnFQrmjw/rruRCpkOj3uduKYVRSJH3um87 YpPrTCYHw5AsRcJMSRDS8SF4GWQniZLYcjjiCgRhuT/Jg/EyM0fIJWoVlRk16HMPlxE8xWJy7 QmgQgBYonikkp86ioF+Tm7U7N82c9Y/O5Ttr3B0gMJvxbR2xwP4uW7izpClf+bkzBhbqlW0f9 cAc5LS14yck67DuZAfjj8DCZPsaYnGvbVcNjpDxMrRmEsf81M7BaODDt/zwOR6ebmHTBm0gMw 0bQiEuWfKYEnI4jP36Ef/C+LbQSNtU0jHiOD5guDeyYxJyvp+s1QuplsCe+Qt0bQa9cKvS5Pc MUoTJ9j6Xa6B2OZ16THZJ11VXikPbmyxTsoCE2td0D9tIUG4iDtS+Cn3cQ8eWdwvAe495W7mD E+BLT+szzNSPh90UZy3HBngz4FxOulGH8gdVG07N+S9SS9XN6bduFKjykY4XX62n9coEi5ZxO ZIDnBxLAh4N8q3IaQWhzBppq+Ms1C50Zv0fx2a2SeOoc9u+WBVHLCHAEQLdUGR6lpq7XnR2VX VD9q8G3HFvLij1FlOOHaZMpnnqF7Gq40Oe4xBQczrTp6t72ZBiXCiEXCfbyTf/iGtlF1iSGVk dInk3c9yGsGrW8ACbWmg/86P80SHyfEwJwedJ3Ec6xioaWEv2YLRmePE0geXiMBQmAuO/0knP UTvKiou1/+niInEwblBS7evj8GijNAFy6UVGr2Uir/PkOxu+dZKMZoY3zQs4fxoLGhKwco7cK 36BrAZ92M4e8nu1IfoRKW9rXSTCvryOZgmhQI= Message-ID-Hash: TADKHA4QHMUWCB7Q5XAOVMSI3HLHWWED X-Message-ID-Hash: TADKHA4QHMUWCB7Q5XAOVMSI3HLHWWED X-MailFrom: chris.bormann@gmx.de X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-jose.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Christian Bormann , jose@ietf.org, oauth X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bjose=5D_Re=3A_=5BOAUTH-WG=5D_New_I-D=3A_draft-bormann-jwp-modul?= =?utf-8?q?ar-bbs?= List-Id: Javascript Object Signing and Encryption Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_2FF214E6-4EDA-4B61-8CAB-334102EA6CE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi David, I=E2=80=99ve tried to make the initial design simple on purpose - for a = lot of these I had thought about more complex solutions, but realised it = would likely be beneficial to propose a simpler version and discuss = trade-offs of more complex parts from there. It was also my lessons learned from starting an implementation for most = of the parts of this construction: the current version feels like a = somewhat natural replacement for business logic currently using SD-JWT = VC type credentials, while keeping the complexity of the implementation = rather low (apart from some of the crypto parts). > 1. The new =E2=80=9Ccmap=E2=80=9D issuer header has overlap with the = =E2=80=9Cclaims=E2=80=9D header in JPT. I notice one significant = difference is a document substitution/structural mapping approach to = support sub-claims - rather than using a path/pointer primitive to = define the name of each top level claim or sub-claim, it replicates a = claim/sub-claim tree and provides positional metadata. >=20 > This somewhat surprised me, as the sd-jwt vc draft = (https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-13.html#name-e= xample-2) and OpenID4VP ( = https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-c= laims-path-pointer ) both seem to use more of a pointer syntax to = decompose the document. While not yet published, I have been working = based on feedback that this is more of the direction that implementors = preferred, so I=E2=80=99m curious if there was a particular set of = motivations to go with the =E2=80=9Ccmap" format. I had called it =E2=80=9Cclaims=E2=80=9D initially before I realized it = clashed with JPT definitions. As I had shown at October 2025 IIW I had = also started with a more complex design based on a JSON path logic = (basically the DCQL paths from OpenID4VP), but realized that there was = very little real-world gain compared to a static mapping at a lot of = additional complexity. I did an implementation of both and decided to = start with this proposal as a starting point. Happy to discuss how to best align between the different constructions. > 2. The scalar encoding is defined as an ASCII decimal encoding of the = integer value. I have two related observations here: >=20 > 2a. When operating in scalar=3Dtrue mode, I=E2=80=99m curious why this = is not an I2OSP big-endian representation of the integer value. JSON = numbers are a complicated substrate for exact integer handling, as JSON = implementations typically use double-precision floats for numeric = values, which both allow for decimals and lose integer accuracy above 53 = bits. A binary representation seems like it would decouple from these = issues. >=20 > 2b. I=E2=80=99m curious whether it is worth limiting scalar claim = values as defined here to uint64, when they are meant to be disclosable = data.=20 >=20 > I have not designed these proof constructions myself, so I may be = missing something here. However, my assumption is that there may be an = efficiency case made between these two points: a proof over a bounded = binary value may be substantially simpler than a proof that can span the = scalar field and is currently allowed by the current decimal encoding. In general, there is a bit of discussion currently happening where to = define the scalar encoding and how to limit - I tried to make choices = that are easiest to implement, but my current mental model would be that = we will likely define the scalar encoding in the BBS blind signature = draft and only define how to convey that information in the Issuer = Header in data models / credential formats (since there might also be = additional type information depending on format). On the costs for full range: Yes, a range proof over the full range = would be roughly 4x as costly. We probably want to limit the range, the = question is if that happens as a general limitation in the BBS blind = signature draft, or as a policy that can be chosen by the issuer = (conveyed via issuer header). On the Why JSON: The canonical decimal encoding fully aligns with the = JSON serialization of the integer =E2=80=94> BBS message value and = disclosed payload are identical - otherwise we will very likely run into = weird implementation problems of conflicting representation of integers. On the float concern: the message is the integer denoted by those = octets, so nothing is ever round-tripped through a JSON number type. > 3. The encoding for the device binding key is little endian, which = surprised me considering both BBS and P-256 are big endian. Any = elaboration on the motivation behind this decision? That is the construction that was proposed in the paper for device = binding and how the sigma protocol currently works on the commitments: = https://www.ietf.org/archive/id/draft-cllz-cfrg-ecdsa-pop-00.html#section-= 4.2. I tried to touch as little crypto as possible for this proposal (or = rather reverted a lot of the initial proposal I had on those things). > 4. For decoys, I assume JWP-BBS-DECOY was chosen partially because it = isn=E2=80=99t a legal JSON Text value. Would it make sense if the = scalar=3Dtrue alternative was also defined to be a fixed, not valid = value that e.g. proofs could be written to check against? Yeah, we should definitely iterate over that mechanism and values. I = wanted to have a properly defined DECOY value to allow for things like = =E2=80=9Cproof all entires in this array=E2=80=9D - to allow the = verifier to validate that all other entires are invalid basically. Once = we properly define the max range of integer values, I=E2=80=99d make = propose to make sure the raw_scalar value is out of range (invalid). > 5. Device binding hits a case I hadn=E2=80=99t thought of, partly = because I hadn=E2=80=99t considered a case for payloads both being = candidates for disclosure and for commitments - that a conceptual = payload might need to be represented over more than one slot. Is = reserving space at a particular offset (e.g. the first four scalars) = going to be appropriate? For example, is there a potential for a = credential to be issued with more than one key encoded into it? I had thought about instead defining it as a claim and reserve more = message indexes, something like this: =E2=80=9Ckb=E2=80=9D: [0,1,2,3] But it again complicates parsing logic. There might be other proofs that = also need multiple message slots, so maybe it makes sense to shift the = design in that direction. Current proposal was the simplest I could come = up with that fulfils the use-cases we have in mind. > 6. For sub-proofs, my suspicion is that the metadata/setup would be = encoded into the presentation header, while the actual proof values = would be part of the presentation proofs sequence. Is that your = expectation as well? Commitments are protected via the core proof, we need to figure out if = we need to lock in the sub-proofs in that one as well (e.g., via the = presentation header). I left it out for the time being since I wasn=E2=80=99= t sure and the dangers of not binding seemed not too big? The paper = currently binds more into the sub-proofs than the current proposal of = mine does, but that is something I=E2=80=99d probably like to solve w/ = the presentation header (e.g., including all commitments in the header = to guarantee that nothing can be removed), but right now the BBS blind = signature draft proposal slightly differs from the LSZ25 proposal in = that in LSZ25 the commitments are inputs to core_proof, in the blind BBS = draft they are currently outputs. Since that is one of the things = currently being discussed with the BBS blind signature draft afaik, I = wanted to wait for a resolution of that before making sure we have the = right binding input to core & sub-proofs. Currently the whole sub-proof objects (alg, public inputs, proof bytes) = are self-contained entries in the proofs sequence - only the binding = runs through the core proof. > 7. The draft currently says that the =E2=80=9Ckb=E2=80=9D device = binding header must be present to denote that there are slots reserved = for holding the key, but also that the key MUST be asserted via a = sub-proof. Baking this usage policy in seems limiting, but I have not = yet come up with a concrete example to back that up. We could loosen that to allow something like =E2=80=9Ctraditional=E2=80=9D= device binding for certain high assurance use-cases as well. = Optionality always comes at a cost though - the MUST was a conservative = choice I made for the initial draft to keep things simple. > 8. For sub-claims in particular, I=E2=80=99m noodling over whether = this would be feasible to have in JWP rather than as an = algorithm-specific feature - partly because I could see other algorithms = wanting an identical facility in the future. There might be some = commonality in how the constructions work across some algorithms, but = certainly not all - and I suspect differences might be hard to reconcile = at the presentation header level (such as equality taking a BBS12-381 G1 = point as input). We could specify specifically e.g. range-proof for = BBS-MOD in a single registry, but=20 > I haven=E2=80=99t figured out if there=E2=80=99s a way to encourage = commonality or if that is just mapping out an overlapping namespace. Yeah, I was also contemplating where to best fit what. Given that we are = also using BBS blind signature instead of core BBS for the commitments, = my initial thought was to solve all problems in this draft right now and = then discuss which of these should move to other drafts (like the raw = scalars in the BBS blind signature draft). My goal was to basically use = what is available in terms of other drafts and define something that can = be (apart from some of the sub-proof details) implemented. I had initially also defined more concrete sub-proof constructions to = have a fully implementable draft, but chose to remove them since those = should definitely not live in this document (e.g., the device binding = proof). > 9. With the exclusion of the device binding claim above, it appears = all sub-claim usage is opt-in - such that a holder can support verifiers = with differing capabilities without needing different credentials. This = was a concern of mine with the BBS extensions published so far, and = I=E2=80=99m delighted to see this. Yes, that was exactly the idea of this construction. We=E2=80=99ve = roughly sketched out several bigger use-cases (age verification, = verifiable pseudonyms, identity credentials) that can easily be built on = top of such a construction with different sub-proof types. Best Regards, Christian > On 6. Jul 2026, at 16:00, David Waite = wrote: >=20 > Hello Christian - I=E2=80=99m excited to see this work! >=20 > Some initial comments and questions from a brief read (in no semblance = of priority order:) >=20 > 1. The new =E2=80=9Ccmap=E2=80=9D issuer header has overlap with the = =E2=80=9Cclaims=E2=80=9D header in JPT. I notice one significant = difference is a document substitution/structural mapping approach to = support sub-claims - rather than using a path/pointer primitive to = define the name of each top level claim or sub-claim, it replicates a = claim/sub-claim tree and provides positional metadata. >=20 > This somewhat surprised me, as the sd-jwt vc draft = (https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-13.html#name-e= xample-2) and OpenID4VP ( = https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-c= laims-path-pointer ) both seem to use more of a pointer syntax to = decompose the document. While not yet published, I have been working = based on feedback that this is more of the direction that implementors = preferred, so I=E2=80=99m curious if there was a particular set of = motivations to go with the =E2=80=9Ccmap" format. >=20 > Ideally I think I would like to see a credential profiling of JPT, = analogous to the SD-JWT VC work. That would motivate me to push for one = of =E2=80=9Ccmap=E2=80=9D or =E2=80=9Cclaims=E2=80=9D that can bend to = support both generalized JPT and specific credential use cases, = including the usage here. >=20 > 2. The scalar encoding is defined as an ASCII decimal encoding of the = integer value. I have two related observations here: >=20 > 2a. When operating in scalar=3Dtrue mode, I=E2=80=99m curious why this = is not an I2OSP big-endian representation of the integer value. JSON = numbers are a complicated substrate for exact integer handling, as JSON = implementations typically use double-precision floats for numeric = values, which both allow for decimals and lose integer accuracy above 53 = bits. A binary representation seems like it would decouple from these = issues. >=20 > 2b. I=E2=80=99m curious whether it is worth limiting scalar claim = values as defined here to uint64, when they are meant to be disclosable = data.=20 >=20 > I have not designed these proof constructions myself, so I may be = missing something here. However, my assumption is that there may be an = efficiency case made between these two points: a proof over a bounded = binary value may be substantially simpler than a proof that can span the = scalar field and is currently allowed by the current decimal encoding. >=20 > 3. The encoding for the device binding key is little endian, which = surprised me considering both BBS and P-256 are big endian. Any = elaboration on the motivation behind this decision? >=20 > 4. For decoys, I assume JWP-BBS-DECOY was chosen partially because it = isn=E2=80=99t a legal JSON Text value. Would it make sense if the = scalar=3Dtrue alternative was also defined to be a fixed, not valid = value that e.g. proofs could be written to check against? >=20 > 5. Device binding hits a case I hadn=E2=80=99t thought of, partly = because I hadn=E2=80=99t considered a case for payloads both being = candidates for disclosure and for commitments - that a conceptual = payload might need to be represented over more than one slot. Is = reserving space at a particular offset (e.g. the first four scalars) = going to be appropriate? For example, is there a potential for a = credential to be issued with more than one key encoded into it? >=20 > 6. For sub-proofs, my suspicion is that the metadata/setup would be = encoded into the presentation header, while the actual proof values = would be part of the presentation proofs sequence. Is that your = expectation as well? >=20 > 7. The draft currently says that the =E2=80=9Ckb=E2=80=9D device = binding header must be present to denote that there are slots reserved = for holding the key, but also that the key MUST be asserted via a = sub-proof. Baking this usage policy in seems limiting, but I have not = yet come up with a concrete example to back that up. >=20 > 8. For sub-claims in particular, I=E2=80=99m noodling over whether = this would be feasible to have in JWP rather than as an = algorithm-specific feature - partly because I could see other algorithms = wanting an identical facility in the future. There might be some = commonality in how the constructions work across some algorithms, but = certainly not all - and I suspect differences might be hard to reconcile = at the presentation header level (such as equality taking a BBS12-381 G1 = point as input). We could specify specifically e.g. range-proof for = BBS-MOD in a single registry, but=20 > I haven=E2=80=99t figured out if there=E2=80=99s a way to encourage = commonality or if that is just mapping out an overlapping namespace. >=20 > 9. With the exclusion of the device binding claim above, it appears = all sub-claim usage is opt-in - such that a holder can support verifiers = with differing capabilities without needing different credentials. This = was a concern of mine with the BBS extensions published so far, and = I=E2=80=99m delighted to see this. >=20 > -DW >=20 > =20 >=20 >=20 >> On Jul 3, 2026, at 2:02=E2=80=AFPM, Christian Bormann = wrote: >>=20 >> Dear JOSE & OAuth WG, >>=20 >> Sorry for cross-posting, but this seems to be a topic that would fit = both WGs and cross-posting seemed to be the best way. >>=20 >> I have submitted a new ID that proposes a digital credential format = building on top of JSON Web Proofs, SD-JWT VC, and blind BBS Signatures: >> Datatracker: = https://datatracker.ietf.org/doc/draft-bormann-jwp-modular-bbs/ - = GitHub: https://github.com/c2bo/draft-bormann-jwp-modular-bbs=20 >>=20 >> This document defines a digital credential format that uses JSON = Web >> Proofs (JWP) as its container format and Blind BBS Signatures as = its >> signature scheme combined with a modular framework for attaching >> zero-knowledge sub-proofs. This allows a Holder to reveal some >> attributes directly while proving predicates such as range or >> equality over the ones they keep hidden. A credential can >> additionally be bound to an ECDSA P-256 device key, with = possession >> of the key proven in every presentation without revealing the = public >> key. The credential type definition and data model follow SD-JWT = VC >> [I-D.ietf-oauth-sd-jwt-vc]. >>=20 >> The core idea behind this draft is to enable a credential format that = functions similar to SD-JWT VC, but powered by a modular Anonymous = Credentials framework. >> Instead of building on top of JWS/JWT, the container format is JWP = (currently JSON / compact serialisation only) and the core data model & = credential type system >> of SD-JWT VC are re-used. The core signature mechanism is BBS, = specifically the blind BBS draft, since it adds committed disclosure - = fresh Pedersen commitments >> to hidden messages at presentation time. >>=20 >> The proposed construction allows for a digital credential format with = unlinkable presentations where each claim/value can individually be >>=20 >> - hidden >> - disclosed >> - committed=20 >>=20 >> Commitments can then be used as inputs to chained sub-proofs (also = called Commit-and-Prove). This allows for sub-proofs like a range proof = over >> issuance or expiration time (proving that the credential is not = expired instead of disclosing the expiration time), or equality proofs = (e.g., proving two credentials >> contain the same name without disclosing the value). The draft = introduces a registry and a few core sub-proofs, with one important = sub-proof allowing for a key >> binding to a P-256 public key where a Zero Knowledge Proof of = Knowledge over a valid signature replaces the KB-JWT of SD-JWT. >> The concrete constructions for these sub-proofs will be leveraged = from existing work (e.g., for range proofs) and the key binding = sub-proof is expected to be a >> separate draft in CFRG: = https://datatracker.ietf.org/doc/draft-cllz-cfrg-ecdsa-pop/.=20 >>=20 >> The general idea for such a construction has been discussed for some = time in the context of EU Digital Identity Wallets / eIDAS and the draft = roughly follows the concepts of: >>=20 >> - = https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-techn= ical-specifications/blob/main/docs/technical-specifications/ts14-zkps-from= -mms.md >> - https://eprint.iacr.org/2025/1981 (Vision: A Modular Framework for = Anonymous Credential Systems)=20 >>=20 >> This is a rough first draft and especially the sub-proof parts = definitely need further work, but I=E2=80=99d love to get some feedback = on the draft and the general concept. >>=20 >> Given the reliance on JWP for serialisation, I thought JOSE would be = a natural home, but since some parts of SD-JWT VC are re-used, there = definitely >> is an argument to be made for OAuth as well. Are people interested in = this kind of work and if so where should it happen? >>=20 >> Happy to present the draft in Vienna if possible / still fits into = the agenda. >>=20 >> Best Regards, >> Christian >> _______________________________________________ >> OAuth mailing list -- oauth@ietf.org >> To unsubscribe send an email to oauth-leave@ietf.org >=20 > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-leave@ietf.org --Apple-Mail=_2FF214E6-4EDA-4B61-8CAB-334102EA6CE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi David,

I=E2=80=99ve = tried to make the initial design simple on purpose - for a lot of these = I had thought about more complex solutions, but realised it would likely = be beneficial to propose a simpler version and discuss trade-offs of = more complex parts from there.
It was also my lessons learned = from starting an implementation for most of the parts of this = construction: the current version feels like a somewhat natural = replacement for business logic currently using SD-JWT VC type = credentials, while keeping the complexity of the implementation rather = low (apart from some of the crypto = parts).

1. The new =E2=80=9Ccmap=E2=80=9D issuer = header has overlap with the =E2=80=9Cclaims=E2=80=9D header in JPT. I = notice one significant difference is a document substitution/structural = mapping approach to support sub-claims - rather than using a = path/pointer primitive to define the name of each top level claim or = sub-claim, it replicates a claim/sub-claim tree and provides positional = metadata.

This somewhat = surprised me, as the sd-jwt vc draft (https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-v= c-13.html#name-example-2) and OpenID4VP ( https://openid.net/specs/openid-4-verifiable-p= resentations-1_0.html#name-claims-path-pointer ) both seem to = use more of a pointer syntax to decompose the document. While not yet = published, I have been working based on feedback that this is more of = the direction that implementors preferred, so I=E2=80=99m curious if = there was a particular set of motivations to go with the =E2=80=9Ccmap" = format.

I had called it = =E2=80=9Cclaims=E2=80=9D initially before I realized it clashed with JPT = definitions. As I had shown at October 2025 IIW I had also started with = a more complex design based on a JSON path logic (basically the DCQL = paths from OpenID4VP), but realized that there was very little = real-world gain compared to a static mapping at a lot of additional = complexity. I did an implementation of both and decided to start with = this proposal as a starting point.

Happy to = discuss how to best align between the different = constructions.

2. The scalar encoding is defined = as an ASCII decimal encoding of the integer value. I have two related = observations here:

2a. When operating in = scalar=3Dtrue mode, I=E2=80=99m curious why this is not an I2OSP = big-endian representation of the integer value. JSON numbers are a = complicated substrate for exact integer handling, as JSON = implementations typically use double-precision floats for numeric = values, which both allow for decimals and lose integer accuracy above 53 = bits. A binary representation seems like it would decouple from these = issues.

2b. I=E2=80=99m curious whether it is = worth limiting scalar claim values as defined here to uint64, when they = are meant to be disclosable data. 

I have = not designed these proof constructions myself, so I may be missing = something here. However, my assumption is that there may be an = efficiency case made between these two points: a proof over a bounded = binary value may be substantially simpler than a proof that can span the = scalar field and is currently allowed by the current decimal = encoding.

In general, = there is a bit of discussion currently happening where to define the = scalar encoding and how to limit - I tried to make choices that are = easiest to implement, but my current mental model would be that we will = likely define the scalar encoding in the BBS blind signature draft and = only define how to convey that information in the Issuer Header in data = models / credential formats (since there might also be additional type = information depending on format).

On the costs = for full range: Yes, a range proof over the full range would be roughly = 4x as costly. We probably want to limit the range, the question is if = that happens as a general limitation in the BBS blind signature draft, = or as a policy that can be chosen by the issuer (conveyed via issuer = header).

On the Why JSON: The canonical decimal = encoding fully aligns with the JSON serialization of the integer =E2=80=94= > BBS message value and disclosed payload are identical - otherwise = we will very likely run into weird implementation problems of = conflicting representation of integers.
On the float concern: = the message is the integer denoted by those octets, so nothing is ever = round-tripped through a JSON number = type.

3. The encoding for the device binding = key is little endian, which surprised me considering both BBS and P-256 = are big endian. Any elaboration on the motivation behind this = decision?

That is the construction that = was proposed in the paper for device binding and how the sigma protocol = currently works on the commitments: = https://www.ietf.org/archive/id/draft-cllz-cfrg-ecdsa-pop-00.html#section-= 4.2. I tried to touch as little crypto as possible for this proposal (or = rather reverted a lot of the initial proposal I had on those = things).

4. For decoys, I assume JWP-BBS-DECOY = was chosen partially because it isn=E2=80=99t a legal JSON Text value. = Would it make sense if the scalar=3Dtrue alternative was also defined to = be a fixed, not valid value that e.g. proofs could be written to check = against?

Yeah, we should definitely = iterate over that mechanism and values. I wanted to have a properly = defined DECOY value to allow for things like =E2=80=9Cproof all entires = in this array=E2=80=9D - to allow the verifier to validate that all = other entires are invalid basically. Once we properly define the max = range of integer values, I=E2=80=99d make propose to make sure the = raw_scalar value is out of range = (invalid).

5. Device binding hits a case I hadn=E2=80= =99t thought of, partly because I hadn=E2=80=99t considered a case for = payloads both being candidates for disclosure and for commitments - that = a conceptual payload might need to be represented over more than one = slot. Is reserving space at a particular offset (e.g. the first four = scalars) going to be appropriate? For example, is there a potential for = a credential to be issued with more than one key encoded into = it?

I had thought about instead = defining it as a claim and reserve more message indexes, something like = this:

=E2=80=9Ckb=E2=80=9D: = [0,1,2,3]

But it again complicates parsing = logic. There might be other proofs that also need multiple message = slots, so maybe it makes sense to shift the design in that direction. = Current proposal was the simplest I could come up with that fulfils the = use-cases we have in mind.

6. For = sub-proofs, my suspicion is that the metadata/setup would be encoded = into the presentation header, while the actual proof values would be = part of the presentation proofs sequence. Is that your expectation as = well?

Commitments are protected via the = core proof, we need to figure out if we need to lock in the sub-proofs = in that one as well (e.g., via the presentation header). I left it out = for the time being since I wasn=E2=80=99t sure and the dangers of not = binding seemed not too big? The paper currently binds more into the = sub-proofs than the current proposal of mine does, but that is something = I=E2=80=99d probably like to solve w/ the presentation header (e.g., = including all commitments in the header to guarantee that nothing can be = removed), but right now the BBS blind signature draft proposal slightly = differs from the LSZ25 proposal in that in LSZ25 the commitments are = inputs to core_proof, in the blind BBS draft they are currently outputs. = Since that is one of the things currently being discussed with the BBS = blind signature draft afaik, I wanted to wait for a resolution of that = before making sure we have the right binding input to core & = sub-proofs.

Currently the whole sub-proof = objects (alg, public inputs, proof bytes) are self-contained entries in = the proofs sequence - only the binding runs through the core = proof.

7. The draft currently says that the = =E2=80=9Ckb=E2=80=9D device binding header must be present to denote = that there are slots reserved for holding the key, but also that the key = MUST be asserted via a sub-proof.  Baking this usage policy in = seems limiting, but I have not yet come up with a concrete example to = back that up.

We could loosen that to = allow something like =E2=80=9Ctraditional=E2=80=9D device binding for = certain high assurance use-cases as well. Optionality always comes at a = cost though - the MUST was a conservative choice I made for the initial = draft to keep things simple.

8. For = sub-claims in particular, I=E2=80=99m noodling over whether this would = be feasible to have in JWP rather than as an algorithm-specific feature = - partly because I could see other algorithms wanting an identical = facility in the future. There might be some commonality in how the = constructions work across some algorithms, but certainly not all - and I = suspect differences might be hard to reconcile at the presentation = header level (such as equality taking a BBS12-381 G1 point as input). We = could specify specifically e.g. range-proof for BBS-MOD in a single = registry, but 
I haven=E2=80=99t figured out if there=E2=80= =99s a way to encourage commonality or if that is just mapping out an = overlapping = namespace.

Yeah, I was = also contemplating where to best fit what. Given that we are also using = BBS blind signature instead of core BBS for the commitments, my initial = thought was to solve all problems in this draft right now and then = discuss which of these should move to other drafts (like the raw scalars = in the BBS blind signature draft). My goal was to basically use what is = available in terms of other drafts and define something that can be = (apart from some of the sub-proof details) implemented.
I had = initially also defined more concrete sub-proof constructions to have a = fully implementable draft, but chose to remove them since those should = definitely not live in this document (e.g., the device binding = proof).

9.  With the exclusion of the = device binding claim above, it appears all sub-claim usage is opt-in - = such that a holder can support verifiers with differing capabilities = without needing different credentials. This was a concern of mine with = the BBS extensions published so far, and I=E2=80=99m delighted to see = this.

Yes, that was exactly the idea of = this construction. We=E2=80=99ve roughly sketched out several bigger = use-cases (age verification, verifiable pseudonyms, identity = credentials) that can easily be built on top of such a construction with = different sub-proof types.

Best = Regards,
Christian

On 6. Jul 2026, at 16:00, David Waite = <david=3D40alkaline-solutions.com@dmarc.ietf.org> wrote:

Hello Christian - I=E2=80=99m excited to see this = work!

Some initial comments and questions from a = brief read (in no semblance of priority = order:)

1. The new =E2=80=9Ccmap=E2=80=9D = issuer header has overlap with the =E2=80=9Cclaims=E2=80=9D header in = JPT. I notice one significant difference is a document = substitution/structural mapping approach to support sub-claims - rather = than using a path/pointer primitive to define the name of each top level = claim or sub-claim, it replicates a claim/sub-claim tree and provides = positional metadata.

This somewhat surprised = me, as the sd-jwt vc draft (https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-v= c-13.html#name-example-2) and OpenID4VP ( https://openid.net/specs/openid-4-verifiable-p= resentations-1_0.html#name-claims-path-pointer ) both seem to = use more of a pointer syntax to decompose the document. While not yet = published, I have been working based on feedback that this is more of = the direction that implementors preferred, so I=E2=80=99m curious if = there was a particular set of motivations to go with the =E2=80=9Ccmap" = format.

Ideally I think I would like to see a = credential profiling of JPT, analogous to the SD-JWT VC work. That would = motivate me to push for one of =E2=80=9Ccmap=E2=80=9D or =E2=80=9Cclaims=E2= =80=9D that can bend to support both generalized JPT and specific = credential use cases, including the usage = here.

2. The scalar encoding is defined as = an ASCII decimal encoding of the integer value. I have two related = observations here:

2a. When operating in = scalar=3Dtrue mode, I=E2=80=99m curious why this is not an I2OSP = big-endian representation of the integer value. JSON numbers are a = complicated substrate for exact integer handling, as JSON = implementations typically use double-precision floats for numeric = values, which both allow for decimals and lose integer accuracy above 53 = bits. A binary representation seems like it would decouple from these = issues.

2b. I=E2=80=99m curious whether it is = worth limiting scalar claim values as defined here to uint64, when they = are meant to be disclosable data. 

I have = not designed these proof constructions myself, so I may be missing = something here. However, my assumption is that there may be an = efficiency case made between these two points: a proof over a bounded = binary value may be substantially simpler than a proof that can span the = scalar field and is currently allowed by the current decimal = encoding.

3. The encoding for the device = binding key is little endian, which surprised me considering both BBS = and P-256 are big endian. Any elaboration on the motivation behind this = decision?

4. For decoys, I assume JWP-BBS-DECOY = was chosen partially because it isn=E2=80=99t a legal JSON Text value. = Would it make sense if the scalar=3Dtrue alternative was also defined to = be a fixed, not valid value that e.g. proofs could be written to check = against?

5. Device binding hits a case I = hadn=E2=80=99t thought of, partly because I hadn=E2=80=99t considered a = case for payloads both being candidates for disclosure and for = commitments - that a conceptual payload might need to be represented = over more than one slot. Is reserving space at a particular offset (e.g. = the first four scalars) going to be appropriate? For example, is there a = potential for a credential to be issued with more than one key encoded = into it?

6. For sub-proofs, my suspicion is = that the metadata/setup would be encoded into the presentation header, = while the actual proof values would be part of the presentation proofs = sequence. Is that your expectation as well?

7. = The draft currently says that the =E2=80=9Ckb=E2=80=9D device binding = header must be present to denote that there are slots reserved for = holding the key, but also that the key MUST be asserted via a sub-proof. =  Baking this usage policy in seems limiting, but I have not yet = come up with a concrete example to back that = up.

8. For sub-claims in particular, I=E2=80= =99m noodling over whether this would be feasible to have in JWP rather = than as an algorithm-specific feature - partly because I could see other = algorithms wanting an identical facility in the future. There might be = some commonality in how the constructions work across some algorithms, = but certainly not all - and I suspect differences might be hard to = reconcile at the presentation header level (such as equality taking a = BBS12-381 G1 point as input). We could specify specifically e.g. = range-proof for BBS-MOD in a single registry, = but 
I haven=E2=80=99t figured out if there=E2=80=99s= a way to encourage commonality or if that is just mapping out an = overlapping namespace.

9.  With the = exclusion of the device binding claim above, it appears all sub-claim = usage is opt-in - such that a holder can support verifiers with = differing capabilities without needing different credentials. This was a = concern of mine with the BBS extensions published so far, and I=E2=80=99m = delighted to see = this.

-DW

 


On Jul 3, = 2026, at 2:02=E2=80=AFPM, Christian Bormann = <chris.bormann=3D40gmx.de@dmarc.ietf.org> wrote:

Dear JOSE & OAuth = WG,

Sorry for cross-posting, but this seems to = be a topic that would fit both WGs and cross-posting seemed to be the = best way.

I have submitted a new ID that = proposes a digital credential format building on top of JSON Web Proofs, = SD-JWT VC, and blind BBS Signatures:
Datatracker: h= ttps://datatracker.ietf.org/doc/draft-bormann-jwp-modular-bbs/  = - GitHub: = https://github.com/c2bo/draft-bormann-jwp-modular-bbs 

=
   This document defines a digital credential = format that uses JSON Web
   Proofs (JWP) as its = container format and Blind BBS Signatures as its
  =  signature scheme combined with a modular framework for = attaching
   zero-knowledge sub-proofs.  This = allows a Holder to reveal some
   attributes = directly while proving predicates such as range or
  =  equality over the ones they keep hidden.  A credential = can
   additionally be bound to an ECDSA P-256 = device key, with possession
   of the key proven in = every presentation without revealing the public
  =  key.  The credential type definition and data model follow = SD-JWT VC
  =  [I-D.ietf-oauth-sd-jwt-vc].

The core idea = behind this draft is to enable a credential format that functions = similar to SD-JWT VC, but powered by a modular Anonymous Credentials = framework.
Instead of building on top of JWS/JWT, the = container format is JWP (currently JSON / compact serialisation only) = and the core data model & credential type system
of SD-JWT = VC are re-used. The core signature mechanism is BBS, specifically the = blind BBS draft, since it adds committed disclosure - fresh Pedersen = commitments
to hidden messages at presentation = time.

The proposed construction allows for a = digital credential format with unlinkable presentations where each = claim/value can individually be

- = hidden
- disclosed
- = committed 

Commitments can then be used as = inputs to chained sub-proofs (also called Commit-and-Prove). This allows = for sub-proofs like a range proof over
issuance or expiration = time (proving that the credential is not expired instead of disclosing = the expiration time), or equality proofs (e.g., proving two = credentials
contain the same name without disclosing the = value). The draft introduces a registry and a few core sub-proofs, with = one important sub-proof allowing for a key
binding to a P-256 = public key where a Zero Knowledge Proof of Knowledge over a valid = signature replaces the KB-JWT of SD-JWT.
The concrete = constructions for these sub-proofs will be leveraged from existing work = (e.g., for range proofs) and the key binding sub-proof is expected to be = a
separate draft in CFRG: = https://datatracker.ietf.org/doc/draft-cllz-cfrg-ecdsa-pop/. 

The general idea for such a construction has been = discussed for some time in the context of EU Digital Identity Wallets / = eIDAS and the draft roughly follows the concepts = of:

- https://eprint.iacr.org/2025/19= 81 (Vision: A Modular Framework for Anonymous Credential = Systems) 

This is a rough first draft and = especially the sub-proof parts definitely need further work, but I=E2=80=99= d love to get some feedback on the draft and the general = concept.

Given the reliance on JWP for = serialisation, I thought JOSE would be a natural home, but since some = parts of SD-JWT VC are re-used, there definitely
is an = argument to be made for OAuth as well. Are people interested in this = kind of work and if so where should it = happen?

Happy to present the draft in Vienna if = possible / still fits into the agenda.

Best = Regards,
Christian
____= ___________________________________________
OAuth mailing list -- = oauth@ietf.org
To unsubscribe send an email to = oauth-leave@ietf.org

_________= ______________________________________
OAuth mailing list -- = oauth@ietf.org
To unsubscribe send an email to = oauth-leave@ietf.org

= --Apple-Mail=_2FF214E6-4EDA-4B61-8CAB-334102EA6CE3--