Re: [Id-event] Dealing with issuer conflict

I believe that the solution already discussed is the best one.  If the event issuer is different than a logical issuer associated with the event subject, then put the logical “iss” and “sub” values inside the event.  Any “sub” at the top-level (if any) should be associated with the “iss” at the top-level, which is always the event issuer.

Any proposal that requires duplicating information, such as requiring “subIss” even when it’s always identical to “iss”, is not a great architectural choice, since it creates unnecessary error conditions that would not otherwise be possible.  (How should implementations handle the case where two values are required to match but don’t?)

                                                                -- Mike

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Thursday, May 18, 2017 7:31 AM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: ID Events Mailing List <id-event@ietf.org>
Subject: Re: [Id-event] Dealing with issuer conflict

??

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<mailto: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<mailto: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<mailto:Id-event@ietf.org>
https://www.ietf.org/mailman/listinfo/id-event<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=p1Vsd1Hb7BX87sV4x9MhtsGbORcuiacHxujwThSnWh4&s=ATYzOXXGto5afit3OgTjh19KczxKCvaBwC7ftofHMrs&e=>
--
Subscribe to the HARDTWARE<https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=p1Vsd1Hb7BX87sV4x9MhtsGbORcuiacHxujwThSnWh4&s=NGbCAfBEl5TtskWdjjWOY2cQJA3Fsy9QvntPnstyIkc&e=> mail list to learn about projects I am working on!
_______________________________________________
Id-event mailing list
Id-event@ietf.org<mailto: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=