Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

Benjamin Kaduk <bkaduk@akamai.com> Tue, 07 March 2017 00:57 UTC

Return-Path: <bkaduk@akamai.com>
X-Original-To: id-event@ietfa.amsl.com
Delivered-To: id-event@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0322129A73 for <id-event@ietfa.amsl.com>; Mon, 6 Mar 2017 16:57:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 S8wBTHYZgUDX for <id-event@ietfa.amsl.com>; Mon, 6 Mar 2017 16:57:25 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 614BA129532 for <id-event@ietf.org>; Mon, 6 Mar 2017 16:55:15 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A16FD433414; Tue, 7 Mar 2017 00:55:14 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 8B563433412; Tue, 7 Mar 2017 00:55:14 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488848114; bh=4K/iuRBJAUP5kkBHdEqYK5561f/a8b6vrEsetXzr470=; l=5514; h=To:References:Cc:From:Date:In-Reply-To:From; b=Qy6w6dMaj5AyNqsovzfiCDE5gFQYSwdBLzBRuT2yD1Z3ibjOLcgrhEcGB3pb39szG 04sPnGNNH852EgnWB82KNqPQBNsEvOytq8hqIAhkdgLYEme9QNtFXtWjshU9vo57Mg /R5IGZ/T7+kkXwsVSgxikbh5JLfR51PuSKiPyo6Y=
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 3A0901FC88; Tue, 7 Mar 2017 00:55:14 +0000 (GMT)
To: Mike Jones <Michael.Jones@microsoft.com>, Justin Richer <jricher@mit.edu>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
References: <4611E3C8-9772-44EA-940D-077E1EA6247F@oracle.com> <7f44a710-0545-157c-b75e-d46853cf2e06@mit.edu> <4B014CCA-BCBE-4894-9F2F-17DA2541509A@oracle.com> <1bbfcb1f-c554-3baf-e260-fbd475c803bb@mit.edu> <CY4PR21MB0504F24541054228A72FC93FF52F0@CY4PR21MB0504.namprd21.prod.outlook.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <6e1e3988-43c7-5ac1-529d-4160ced6cc90@akamai.com>
Date: Mon, 06 Mar 2017 18:55:13 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <CY4PR21MB0504F24541054228A72FC93FF52F0@CY4PR21MB0504.namprd21.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------D893A40013C75A93FC5AD983"
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/dH_Oh-Ei-A7ABOydnVBcdrFB-ak>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." <id-event.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/id-event>, <mailto:id-event-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/id-event/>
List-Post: <mailto:id-event@ietf.org>
List-Help: <mailto:id-event-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/id-event>, <mailto:id-event-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Mar 2017 00:57:26 -0000

On 03/06/2017 06:39 PM, Mike Jones wrote:
>
> Justin, I suspect you didn’t see my earlier reply to Phil’s note that
> you also replied to, so I’m repeating it here and sending it to you
> directly.  (It wouldn’t be the first time that DMARC policies caused
> some of my contributions to be not received by some participants. :-( )
>
>  
>
> Agreed that this is unclear.  Duplicating information in a protocol
> **always** introduces an unnecessary error case – the need to define
> how to handle the situation in which two pieces of information that
> are required to be identical are different.  Information in a SET
> should occur at most once.
>
>

That seems a dangerous road to tread, as it requires care in defining
"information" -- duplicating the same data strings at different levels
of the hierarchy of a JSON object may very well not be duplicating
information, due to the extra context provided by the hierarchy.  In my
mind, it's not a clear case that you should never send the same
name/value multiple times in different parts of an object, as sometimes
it is good to keep the semantic separation clear.

-Ben