IETF Logo Mail Archive

[Id-event] SecEvent consensus calls

Yaron Sheffer <yaronf.ietf@gmail.com> Wed, 20 December 2017 16:19 UTC

Return-Path: <yaronf.ietf@gmail.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 159B11242F7 for <id-event@ietfa.amsl.com>; Wed, 20 Dec 2017 08:19:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xIPLELw2un_5 for <id-event@ietfa.amsl.com>; Wed, 20 Dec 2017 08:19:11 -0800 (PST)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B0231200FC for <id-event@ietf.org>; Wed, 20 Dec 2017 08:19:11 -0800 (PST)
Received: by mail-wm0-x233.google.com with SMTP id g75so11016262wme.0 for <id-event@ietf.org>; Wed, 20 Dec 2017 08:19:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-language; bh=TMgDvSIan5imZUFV+N0UzwbEt1GEZbhZ4AwZcysUbpQ=; b=PfiBpvKIIZeL18Xq43IN6iDzxcFTohFue7bodOFuTe9U9UWlu6avqopLL9EggFcDaK nxeNlCG2H3sxSw+nfSLAAJEtyPBVsNcqM4lf6Ja5yl4GD+cucckcghGwkPeDqafXGttb qGXd5pBKIATkq6RpahE4SW4y/4ubl0vNq3q2NhNM6zL9bRpe/M6xBvyYIcBEgJSdefv7 bRMD7/MO100IZp+A4VOpFG3I3zTx4qHeyu+j/7DAUuXFA8LdW/56Iu/4WPRwVqC4bPfD 3mBK+2vDuyJEVhLIvehGK3WcQxeB7+GABGMR8TB6P9UoPJVxiyT0NMi75kOUd7TXYd0l SE9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-language; bh=TMgDvSIan5imZUFV+N0UzwbEt1GEZbhZ4AwZcysUbpQ=; b=UoT4Adne9TBjRA/BxnteQg6CrWMgU2Tfc2rhHgYGAZoFYRKjs6XOh0PgzyNim27o90 Lg8ll73/sTaqXJKacyurJBeLsYPIy3NKW+LnuAlfjd2Nv++POsomSKmYthuYOdjtRaQu vhaYZfWakxi9BIV4AAxkFFU7F6YLxfri7tF18ZQxS5cp2hVlBuCoQp6bmqvc2cJkGVCv ch1XLMKrEQCRl6m5DOW1rw9zvlp0zqfnlbvoeg3SnlIF6sWNYvzVv8BlfFQruTJg1Guf R10FiWns2xyqujE3+aMGqG31d3uWRvIQjcFqKhynsCgbdRB3yRKvQ/Xxz2dAXZXkVkH2 CMHg==
X-Gm-Message-State: AKGB3mKtBUdUew3W5oz4v75GtOMMvVyzcQ3v+5wXKobzkluy5t2lqBgu 0ebAA+YUfkrdW9mpn6OTwnJeKSrM
X-Google-Smtp-Source: ACJfBouWOVz0+jtpggBxM5LtZFXZqvXZ6yiCq1eJOt0ehrWnDRhA13naDJRgUcFdMzNZ1SBwra4bhA==
X-Received: by 10.80.182.92 with SMTP id c28mr6133007ede.244.1513786749344; Wed, 20 Dec 2017 08:19:09 -0800 (PST)
Received: from [172.18.129.55] (bzq-202-11.red.bezeqint.net. [212.179.202.11]) by smtp.gmail.com with ESMTPSA id s8sm12791095edh.51.2017.12.20.08.19.08 for <id-event@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Dec 2017 08:19:08 -0800 (PST)
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: SecEvent <id-event@ietf.org>
Message-ID: <4c0f6548-ac23-ea82-a982-a4d0e283bf7c@gmail.com>
Date: Wed, 20 Dec 2017 18:19:07 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------A91257F9817C57A97CFACE8C"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/XQIqx37YANApu-IEeeW9arzEj-0>
Subject: [Id-event] SecEvent consensus calls
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 20 Dec 2017 16:19:13 -0000

Dear SecEvent participants,

First, I would like to thank all those who shared their opinions on the 
list and worked to clarify the issues at stake for the benefit of all of us.

Three issues were discussed:

1. The syntax and semantics of the "events" claim, whether multiple 
events can be expressed, logical events vs. aspects of events etc.
2. Whether we want to define a standard "subject" claim within the event 
object.
3. Whether we want to predefine a number of subject types.

The bulk of the discussion was about issue #1, and in my opinion, if we 
untangle this issue, it would be much easier to reach consensus on #2 
and #3. Unfortunately, in my opinion, we have not reached (the IETF 
definition of) rough consensus on #1. While the majority of participants 
expressed the opinion that we should keep the current text as-is, a 
non-negligible minority had a detailed alternative text and a number of 
significant implementation-based concerns with the current text.

We cannot move forward without rough consensus, but clearly we all want 
to publish a SET RFC as soon as we can, to enable multiple profiles to 
be developed by other organizations. So if we want to get to an RFC as a 
group, we need to continue this discussion until we do reach technical 
consensus. I would like to give this discussion the remaining days of 
the year (until EOB on Dec. 31). If we have not reached consensus by 
then, Dick and I will ask Kathleen to decide on the next steps for this WG.

To lead into this discussion, I would like to raise some points that the 
discussion did not clarify to me:

- What is the value of a SET, in addition to its being "a kind of JWT". 
Specifically, let's assume a software architecture that consists of 
three layers: SET profile-specific library, generic SET processor, 
generic JWT library. What would be the functionality (or the added 
value) of the middle layer?

- What are the existing implementations that prevent change to the 
current spec, even changes as trivial as renaming "events" to "event"? 
Are there any production or near-production implementations in addition 
to the OIDC Back Channel Logout (which is arguably a trivial use of 
SET)? From an IETF process point of view, I'd like to point out that any 
I-D is completely open to changes until actual publication as an RFC, 
and certainly until it is delivered to the IESG.

- What are our interoperability expectations? One of the participants 
mentioned that his company will only send single events and will 
"prefer" to receive single events. Can such an implementation be 
interoperable with all RFC compliant implementations? If we leave too 
much of the SET semantics for profiles to define, are we sacrificing 
interoperability?

Lastly, I must say that both the WG draft and the alternative draft 
woefully lack worked out examples of concrete events ("logout", "email 
change" etc.), which would have clarified the similarities and 
differences between the drafts and might have made this discussion 
easier and shorter.

Thanks,
     Yaron

v2.23.0 | Report a Bug | By Email