IETF Logo Mail Archive

Re: [Id-event] Dealing with issuer conflict

"Phil Hunt (IDM)" <phil.hunt@oracle.com> Thu, 18 May 2017 14:36 UTC

Return-Path: <phil.hunt@oracle.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 0CF9912951C for <id-event@ietfa.amsl.com>; Thu, 18 May 2017 07:36:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.23
X-Spam-Level:
X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 r3aKxc17q-sD for <id-event@ietfa.amsl.com>; Thu, 18 May 2017 07:36:02 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87DB1129AAD for <id-event@ietf.org>; Thu, 18 May 2017 07:30:41 -0700 (PDT)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v4IEUdR6027720 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 May 2017 14:30:40 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v4IEUduC005038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 May 2017 14:30:39 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v4IEUcH0022597; Thu, 18 May 2017 14:30:39 GMT
Received: from [192.168.1.13] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 May 2017 07:30:38 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail-DD2B9746-02C5-4193-8AE8-4FD07357F52E"
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" <phil.hunt@oracle.com>
X-Mailer: iPhone Mail (14E304)
In-Reply-To: <CAD9ie-unodo_BgMdH-iT64U6n7A4H_kEVOLCViWqDuLfRSRgSg@mail.gmail.com>
Date: Thu, 18 May 2017 07:30:37 -0700
Cc: ID Events Mailing List <id-event@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <262D32B6-940E-4B96-9981-079A5443ED3E@oracle.com>
References: <D1129EE9-8D49-4262-A569-FF373490EB85@oracle.com> <CAD9ie-unodo_BgMdH-iT64U6n7A4H_kEVOLCViWqDuLfRSRgSg@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/uB7h5eBns3u8Ua2cKCBRSRtS888>
Subject: Re: [Id-event] Dealing with issuer conflict
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: Thu, 18 May 2017 14:36:04 -0000

??

Happens in any case where sub is not globally identifiable. 

In Connect, since sub is not uniquely identified, the iss for the sub must be included. This creates a conflict if the issuer of the SET is not the issuer of the subject. 

Resolving the iss conflict has been on the list of issues since chicago. 

In RISC we were discussing account close events. I am assume one of the scenarios is RPs will notify IDPs when they close an account. They must use an iss not associated with sub. As things stand now, they will have to assert the extra iss value in their payload---which for most events is complex to parse since their are no other extra claims. 

Phil

> On May 18, 2017, at 6:36 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
> 
> Phil, would you clarify the use case and the requirement to ensure everyone on the list is aligned? Thanks
> 
>> On Wed, May 17, 2017 at 9:45 PM Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
>> In many cases where we are talking about events (eg risc) there is no need for extra claims other than the event type itself.
>> 
>> It occurs to me that in the case of RP issued events the current sectoken format requires an embedded iss to deal with the conflict with the set issuer. It seems to add a lot of complication for most events.
>> 
>> What if we defined a new sectoken top level attribute 'subIss' to mean "subject issuer" and keep iss reserved for the SET issuer.
>> 
>> I would suggest this as a recommended attribute even when iss and subIss are the same for parsing consistency.
>> 
>> Thoughts?
>> 
>> Phil
>> _______________________________________________
>> Id-event mailing list
>> Id-event@ietf.org
>> https://www.ietf.org/mailman/listinfo/id-event
> 
> -- 
> Subscribe to the HARDTWARE mail list to learn about projects I am working on!
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=p1Vsd1Hb7BX87sV4x9MhtsGbORcuiacHxujwThSnWh4&s=ATYzOXXGto5afit3OgTjh19KczxKCvaBwC7ftofHMrs&e=

v2.23.0 | Report a Bug | By Email