<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
fyi. probably something we should discuss.</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Id-event <id-event-bounces@ietf.org> on behalf of Phillip Hunt <phil.hunt@independentid.com><br>
<b>Sent:</b> Thursday, August 25, 2022 13:01<br>
<b>To:</b> ID Events Mailing List <id-event@ietf.org><br>
<b>Subject:</b> [Id-event] Late comment on experience with draft-ietf-secevent-subject-identifiers-12</font>
<div> </div>
</div>
<div class="" style="word-wrap:break-word; line-break:after-white-space">
<div class=""><br class="">
</div>
<div class=""><span class="" style="color:rgb(0,0,0)">Apologies for this late feedback. I felt it important to share my recent (right now) after recent review of interop with the OpenID Shared Signals draft and the new SCIM WG SCIM Events Profile draft (</span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-scim-events%2F&data=05%7C01%7Ctim.cappalli%40microsoft.com%7Cf8e6f8ebf6af460727a708da86bb7e0f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637970437110186712%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NkAhfsj7a59eZjf0lVveOp97rW3MC%2BpvC9QT1Rerkds%3D&reserved=0" originalsrc="https://datatracker.ietf.org/doc/draft-ietf-scim-events/" shash="Rxrdsi6PrhbNL1RHXJAhQYIXpWooEo5KqRCV3kUUc2s00FEZDAfbx6TmaxeWHc2aiBSjiCd9ZU1pXmcm3wFnwaHTDBjKb/TbSFDMaoN8niT0xHjTsUu20k/6V2r/5wuBZrMjs5cBNswBMQbKCZZalCwFNG3T3enSAY1ZLNUxezM=" class="">draft-ietf-scim-events-00</a>).</div>
<div class="" style="color:rgb(0,0,0)"><span class="" style="color:rgb(0,0,0)"><br class="">
</span></div>
<font color="#000000" class=""><span class="" style="">It appears there is potential for interop concerns or mistakes arising because the examples in this draft suggests profilers to embed subject identifiers inside of the events claim that may suggest multiple
events about different subjects are possible (contrary to RFC8417). A best practice would be to use the “sub_id” to hold such claims. It should be noted that the use of subject identifiers in event “payloads” should be supplemental to sub_id. A SET that
contains multiple events about the same transaction must be about the same top-level identifier “sub_id” (per section 2.0 of RFC8417). </span></font>
<div class=""><font color="#000000" class=""><span class="" style=""><br class="">
</span></font></div>
<div class=""><font color="#000000" class=""><span class="" style="">For example in SCIM Events</span></font>, a SET could be issued that contains both a provisioning event (urn:ietf:params:event:SCIM:prov:patch) AND a signal (urn:ietf:params:event:SCIM:sig:authMethod).
In the current draft the “sub” claim ties the events together to indicate the event occurs from the same transaction about the same subject.
<div class=""><font color="#000000" class=""><span class="" style=""><br class="">
</span></font></div>
<div class=""><font color="#000000" class=""><span class="" style="">In contrast, the OpenID RISC Profile embeds subjects in events:</span></font></div>
<div class=""><font color="#000000" class=""><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-risc-profile-specification-1_0-01.html&data=05%7C01%7Ctim.cappalli%40microsoft.com%7Cf8e6f8ebf6af460727a708da86bb7e0f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637970437110186712%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=P3dAFDqdDqaDhqJy17ks0KIvDFCuNQxzUnxGmrECM24%3D&reserved=0" originalsrc="https://openid.net/specs/openid-risc-profile-specification-1_0-01.html" shash="IzHbXmNdX5gfq36W/0rEf0w07WsdJriQlUpg+ciM8UDzmIX1ikNDmcEjlqAwTW1Irj0jTjDeGYQN6jPrbgrKYOrP4eQ2ZU1fLZdg3eqarTl4Uoxh+e0Ec+mVmaHGtRECjhnGACNh7CJ8yCtESFvwgY0fOhYKsoJGGTIODVMoNug=" class="">https://openid.net/specs/openid-risc-profile-specification-1_0-01.html</a></font></div>
<div class=""><font color="#000000" class=""><span class="" style=""><br class="">
</span></font></div>
<div class=""><font color="#000000" class="">The interop concern is:</font></div>
<div class=""><font color="#000000" class="">* Subject information located in differing places (top level sub_id claim or embedded in event payloads)</font></div>
<div class=""><font color="#000000" class="">* A possible impression a SET can contain multiple events with per event identifiers about different subjects contrary to section 2 RFC8417</font></div>
<div class=""><br class="">
</div>
<div class=""><font color="#000000" class="">I would like the authors to consider adjusting the draft to more strongly recommend “sub_id” as the main claim and that subject objects in event payloads SHOULD be specific to that event type (ie. as a supplemental context).</font></div>
<div class=""><font color="#000000" class=""><br class="">
</font></div>
<div class=""><font color="#000000" class="">From an inter-op perspective it is much easier to write code to look for sub_id and recognize it as a standard json object.</font></div>
<div class=""><font color="#000000" class=""><br class="">
</font></div>
<div class=""><font color="#000000" class="">I ran into this problem recently implementing SET for SCIM Events and testing interop with the implementation described at SharedSignals.guide. In this implementation, events are only accepted if subject is embedded
in the event “payload” rather than as a top-level claim (“sub-id”).</font></div>
<div class=""><font color="#000000" class=""><br class="">
</font></div>
<div class=""><font color="#000000" class="">Further I have been asked if SCIM Events could adopt support this draft. If SCIM were to support it, we would use the ’sub_id’ claim. Off the top, this would make SCIM incompatible with the implementation of sharedsignals.guide
which implements SSEF (<span class="" style=""><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-sse-framework-1_0-ID1.html&data=05%7C01%7Ctim.cappalli%40microsoft.com%7Cf8e6f8ebf6af460727a708da86bb7e0f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637970437110186712%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=YkXxDr%2F%2B644rJDiWPHjN%2BE2gr%2FROlPX7dXyxe%2BfiC9A%3D&reserved=0" originalsrc="https://openid.net/specs/openid-sse-framework-1_0-ID1.html" shash="i/Yp0qYaskb4cBDN18aNGJXKuUtmMPNVcaA756mSbfJYdufxDUj44BrFtEgrCAeraa8JLP/tpO4BhkaYIb3ISTYtqJDqCnVqdAZbnFChERhMk4ZkHm5ywoZ3t1TWJDD/CediHlYcKXsZCIH08pB/AxmVsyEaHGTlRjH14qCVf3A=" class="">https://openid.net/specs/openid-sse-framework-1_0-ID1.html</a>).</span></font></div>
<div class=""><br class="">
</div>
<div class="">
<div class="">
<div dir="auto" class="" style="color:rgb(0,0,0); letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none; word-wrap:break-word; line-break:after-white-space">
<div>Phillip Hunt</div>
<div>@independentid</div>
<div><a href="mailto:phil.hunt@independentid.com" class="">phil.hunt@independentid.com</a></div>
<div class=""><br class="">
</div>
</div>
<br class="x_Apple-interchange-newline">
<br class="x_Apple-interchange-newline">
</div>
<br class="">
</div>
</div>
</div>
</body>
</html>