IETF Logo Mail Archive

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

Mike Jones <Michael.Jones@microsoft.com> Tue, 07 March 2017 01:03 UTC

Return-Path: <Michael.Jones@microsoft.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 51D9312956C for <id-event@ietfa.amsl.com>; Mon, 6 Mar 2017 17:03:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 DURUTiXHypDd for <id-event@ietfa.amsl.com>; Mon, 6 Mar 2017 17:02:59 -0800 (PST)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0098.outbound.protection.outlook.com [104.47.41.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB33A129532 for <id-event@ietf.org>; Mon, 6 Mar 2017 17:02:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=z6iuBuLSpIrMXurXqAmJjrZM8dLocwnJnSe9qWHQEsI=; b=MekFbKd7BiIR1VqUN2oXD5+1jUp794DROQgKhoCyGS6BJtQink8Lp90AIa84FlcVpq/xr3TlU9TLzn/DkMGmjYgUkiL6V0k/+nXWHF1aXKLBEoRkVQapTkTfRYuGLKO4RZ5c4G8buCy24jA9TGVxVB55Y9BUPh5NQDNl4NlyjFw=
Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.0; Tue, 7 Mar 2017 01:02:57 +0000
Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.0947.007; Tue, 7 Mar 2017 01:02:57 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Benjamin Kaduk <bkaduk@akamai.com>, Justin Richer <jricher@mit.edu>, "Phil Hunt (IDM)" <phil.hunt@oracle.com>
Thread-Topic: [Id-event] Thread: Clarifying use of sub and iss in SET tokens
Thread-Index: AQHSkrmW5tqPJIY8NEisvT0PLETCCaGFT4mAgAAhegCAAM4FAIACUTGggAAFSICAAAF0sA==
Date: Tue, 07 Mar 2017 01:02:57 +0000
Message-ID: <CY4PR21MB0504B001DBF5BFBC1F572536F52F0@CY4PR21MB0504.namprd21.prod.outlook.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> <6e1e3988-43c7-5ac1-529d-4160ced6cc90@akamai.com>
In-Reply-To: <6e1e3988-43c7-5ac1-529d-4160ced6cc90@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:1::36]
x-ms-office365-filtering-correlation-id: a8c9f919-96e4-4280-3908-08d464f5b16e
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR21MB0504;
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0504; 7:ZxE0UqnYTNL+DQw/hYnymNeQkAfggx3+XBWCsJLhvOsA2yszZiKCOuryQZAm6a0QFtadqp2bfAgKDzhqqRS+lImpc8MaiCGZDa0mXNk9Hzvuxwj7zynTfrk/zGathZDIjFRR5JbYBacw2Y1/s8UR83P/5vrulBAm9RuDN8+PpH+HQ1gDRfYdjmr/Vl221owFOFWwa8xhacg8T/fWokCXfn5Fd9+Uo+MpPgPoTEpPHkURERdXShF6ILO28qY3rlcotLGNV9+j1uSIWLqHYK6z5GieA3T6pLKH7j7Ew8vCxTvIskZmMcj0cKKWr1dSwkHlckv6S9343yh9Dzw1A/WUETqDRCxpA8Ya1HtKMB7olSE=
x-microsoft-antispam-prvs: <CY4PR21MB05047D3198954707BB2561F4F52F0@CY4PR21MB0504.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(21748063052155)(146099531331640);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:CY4PR21MB0504; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0504;
x-forefront-prvs: 0239D46DB6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39850400002)(39450400003)(39410400002)(39840400002)(24454002)(377454003)(50986999)(6306002)(53936002)(122556002)(2950100002)(53546006)(93886004)(25786008)(4326008)(102836003)(6246003)(76176999)(6116002)(2171002)(86362001)(38730400002)(7696004)(55016002)(5660300001)(6506006)(9686003)(92566002)(54896002)(77096006)(6436002)(790700001)(10090500001)(106116001)(54356999)(8990500004)(3660700001)(229853002)(2900100001)(99286003)(3280700002)(8676002)(10290500002)(74316002)(189998001)(81166006)(7736002)(33656002)(2906002)(5005710100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0504; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504B001DBF5BFBC1F572536F52F0CY4PR21MB0504namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2017 01:02:57.0646 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0504
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/LuDuoKqM2AEWRem3lfciKp4wrxY>
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 01:03:01 -0000

I agree that if the two pieces of information in two fields are allowed to be different but happen to be the same, that both fields should be carried in the SET with identical values.  What I was talking about was the case in which two fields are required to be identical.  That's the case in which duplication is harmful.

                                                                -- Mike

From: Benjamin Kaduk [mailto:bkaduk@akamai.com]
Sent: Monday, March 6, 2017 4:55 PM
To: Mike Jones <Michael.Jones@microsoft.com>; Justin Richer <jricher@mit.edu>; Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

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

v2.23.0 | Report a Bug | By Email