Re: [arch-d] Call for Comment: <draft-iab-privacy-partitioning-03> (Partitioning as an Architecture for Privacy)

Tommy Pauly <> Wed, 24 January 2024 15:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E176FC14F68A for <>; Wed, 24 Jan 2024 07:29:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F0zSM7DDXecE for <>; Wed, 24 Jan 2024 07:29:00 -0800 (PST)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 21130C14F5FE for <>; Wed, 24 Jan 2024 07:29:00 -0800 (PST)
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Mar 28 2023)) with ESMTPS id <> for; Wed, 24 Jan 2024 07:28:59 -0800 (PST)
X-Proofpoint-ORIG-GUID: dW1fWPx_xtSCLyJWVGb1zhfi6hncIiHf
X-Proofpoint-GUID: dW1fWPx_xtSCLyJWVGb1zhfi6hncIiHf
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.1011 definitions=2024-01-24_06:2024-01-24, 2024-01-24 signatures=0
X-Proofpoint-Spam-Details: rule=interactive_user_notspam policy=interactive_user score=0 phishscore=0 malwarescore=0 mlxlogscore=999 mlxscore=0 spamscore=0 adultscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2401240112
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=1QQwIpdUovOLFCJvC89iaZQUeDcahVIwoi/G6kfHjH8=; b=SQawPdYl3b4NFBLeyBrMuFcQA4pTACWkNl2cdgXX536xeR1LC03u9vJ94hzUpFjx2dt9 oiNV76uwsO1tO+Mznh6JJImeOXzZ6Y2G0jeUVcrj3903Hq1+Bc8lWTlD89YbI3NEMGGZ NFC7pgFnKIvb3qAjsdoKlqaJmOKQ0MdXDCw1q1SbEYa2n4RZRQr41FhlitIKwz7wdQ42 CP5PaqW+EWB8LOfBblc2mo+2u25XuwGtMobvS5C5ryFHiU0lilKeg1b1yqiJ2lcW00P8 X3mLVu5r/m7Seud5XJ5Zqe7VqY3RP92osIypx1pLwEDUwdfGO7oFCpH9ngojLjlkf4NN 9A==
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Mar 28 2023)) with ESMTPS id <>; Wed, 24 Jan 2024 07:28:59 -0800 (PST)
Received: from by (Oracle Communications Messaging Server 64bit (built Mar 28 2023)) id <>; Wed, 24 Jan 2024 07:28:59 -0800 (PST)
X-Va-T-CD: 01a37c4388be431533d60b3d58eeb299
X-Va-E-CD: 4a022f60aed9854ba93772aa93951355
X-Va-R-CD: 4b6e91bc4d5fab385a145ac1f92fcfa6
X-Va-ID: aa50f2e8-4b3f-445f-8733-dcf53b31d87f
X-Va-CD: 0
X-V-T-CD: 01a37c4388be431533d60b3d58eeb299
X-V-E-CD: 4a022f60aed9854ba93772aa93951355
X-V-R-CD: 4b6e91bc4d5fab385a145ac1f92fcfa6
X-V-ID: 28d98519-dd59-4c19-b106-e31cec04f12c
X-V-CD: 0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.1011 definitions=2024-01-24_06:2024-01-24, 2024-01-24 signatures=0
Received: from ([]) by (Oracle Communications Messaging Server 64bit (built Mar 28 2023)) with ESMTPSA id <>; Wed, 24 Jan 2024 07:28:59 -0800 (PST)
From: Tommy Pauly <>
Message-id: <>
Content-type: multipart/alternative; boundary="Apple-Mail=_17921D61-28B3-431B-936D-3180B3102EAE"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\))
Date: Wed, 24 Jan 2024 07:28:53 -0800
In-reply-to: <>
To: Martin Thomson <>
References: <> <>
X-Mailer: Apple Mail (2.3774.300.61.1.2)
Archived-At: <>
Subject: Re: [arch-d] Call for Comment: <draft-iab-privacy-partitioning-03> (Partitioning as an Architecture for Privacy)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Jan 2024 15:29:01 -0000

Hi Martin,

Thanks for the review — we wanted to highlight that we’ve published a couple versions to update based on your review and GitHub issues. The current draft is -05 (, and the diff is here (

Some of the notable changes:

- Adding a section for selection of client identifiers, and how those impact the effectiveness of partitioned contexts
- Restructuring the list of ways context partitioning can be violated
- Clarifying more how partitioning is one tool in the tool box, but needs to be part of a more holistic analysis of privacy


> On Oct 8, 2023, at 5:19 PM, Martin Thomson <> wrote:
> This document feels incomplete.  I'll give a few examples of applications of the general concept that aren't covered.
> Separating identity from the right to communicate is a major concept that is not as fully explored as it could be.
> This is something that the draft does discuss in a way, because it talks about using intermediaries to shield the identity of entities that wish to initiate communication.
> The entire class of use for pseudonymous identifiers isn't really given a solid treatment.  I work with people who provide email aliases for privacy purposes.  There, the underlying concept is that an email address typically serves two distinct functions: a) an identifier, and b) authorization to communicate.
> When creating temporary email addresses, especially when these are unique for each context, we break the identification part (a).  We give the recipient the means to communicate with us, but deny them the means to identify.  Identification means correlation across multiple contexts.  (As an aside, that's a failing in RFC 6973, which treats identification and correlation as distinct threats rather than facets of the same and distinct only in degree.)
> A contextually-bound pseudonymous identifier provides no correlating power. Again, this relies on having intermediaries that can be trusted not to collude and reveal the true identity, so I believe that this qualifies as a partitioning.
> The same basic idea also underpins Web Push (RFC 8030).  Websites are given the means to send push messages to user agents, but are denied the means of identification.  Here, the privacy guarantees are stronger than email because the intermediary does not need to be entrusted with viewing the message contents.  End-to-end protected email is possible, but email comes with very different expectations.
> I believe that this identity separation concept is also a property that is inherent to ICN architectures, but I'm not as qualified to comment on that as others, including some IAB members.  Similarly, I believe that it would be possible to more fully capitalize on randomized IPv6 ULAs (RFC 4941), but there are folks on the IAB better positioned to handle that as well.
> Finally, it is maybe not in scope, but I wonder how the authors perceive the relation between this work and contextual integrity.  It seems like maybe this is a foundational principle that is implied throughout, perhaps along with other principles.  However, it's not really clear which aspects of privacy are potentially responsive to the types of partitioning that are discussed.  There is missed opportunity here, I think. Just looking at specific privacy risks (those listed in Section 5 of RFC 6973 are a good start), it is obvious how partitioning helps (or doesn't) with some, but not all.
> Cheers,
> Martin
> On Sat, Oct 7, 2023, at 04:50, IAB Executive Administrative Manager wrote:
>> This is an announcement of an IETF-wide Call for Comment on 
>> draft-iab-privacy-partitioning-03.
>> The document is being considered for publication as an Informational 
>> RFC within the IAB stream and is available for inspection at: 
>> <>
>> The Call for Comment will last until 2023-11-03. Please send comments 
>> to and
>> Abstract
>>  This document describes the principle of privacy partitioning, which
>>  selectively spreads data and communication across multiple parties as
>>  a means to improve privacy by separating user identity from user
>>  data.  This document describes emerging patterns in protocols to
>>  partition what data and metadata is revealed through protocol
>>  interactions, provides common terminology, and discusses how to
>>  analyze such models.
>> _______________________________________________
>> Architecture-discuss mailing list
>> <>
> _______________________________________________
> Architecture-discuss mailing list
> <>