<div dir="auto">Hello Atul,</div><div dir="auto"><br></div><div dir="auto">#2 - all the items that I have described are marked as OPTIONAL in the latest draft hence interop profile should call it out as REQUIRED </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 27, 2023 at 4:59 PM Atul Tulshibagwale <<a href="mailto:atul@sgnl.ai">atul@sgnl.ai</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<p><strong>This message originated outside your organization.</strong></p><br>
<hr><br>
</div><div dir="ltr">Thanks Shayne and Apoorva, for your reviews. Here are some responses, we should discuss this in tomorrow's meeting:<div><ol><li>(Apoorva) CAEP Transmitter -> SSF Transmitter - I'm OK with using SSF as the terminology. If no one else has any objections, I will change the terminology in the interop profile to read "SSF Transmitter" (and SSF Receiver)</li><li>(Apoorva) Those fields that are mentioned as "required" (MUST have, etc.) in the SSF draft, do not need to be specified separately in the interop draft. The interop draft only talks about those optional things from SSF that have some specific subset of those options that need to be implemented by interoperable implementations</li><li>(Apoorva) Stream Control - I've left the ability to pause and restart streams out of the interop draft. We should discuss this tomorrow.</li><li>(Apoorva) Verification: The intent was for interoperable Transmitters to support verification. I will add the sentence for clarity</li><li>(Apoorva) Receivers: "iss-sub" support: I will add this to the draft</li><li>(Apoorva) Reason-admin: I will add "reason_admin" as a required field in the use cases.</li><li>(Shayne) Why PUSH only: I'm proposing that interoperable implementations MUST support the push method. They can support the poll method if they want, but that doesn't affect their interoperability status. Let's discuss this tomorrow</li><li>(Shayne) Implicit Subjects: SSF doesn't require each subject in the stream to be added using AddSubject. The interop profile clarifies that any interoperable Transmitter should automatically add all subjects to a stream and need not support AddSubject / RemoveSubject methods. Let's discuss this tomorrow.</li></ol></div></div><div dir="ltr"><div><div>Atul</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 21, 2023 at 11:00 AM Shayne Miel (smiel) <<a href="mailto:smiel@cisco.com" target="_blank">smiel@cisco.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<div dir="ltr">
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Thanks for putting this together. I have two issues:</div>
<ol style="list-style-type:decimal">
<li style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;list-style-type:"1. ";color:rgb(0,0,0)">
<span style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Why are we restricting this to PUSH only? That will make it harder for Receivers to join us in the interop.</span></li><li style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;list-style-type:"2. ";color:rgb(0,0,0)">
<span style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">I'm confused about section 3.2.2. What mechanism is being proposed here? I am not aware of any ability to have implicitly
added subjects in the Transmitter, except for possibly the wildcard complex subjects.</span></li></ol>
<div><span style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Thanks,</span></div>
<div><span style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Shayne</span></div>
<div id="m_-6587708015404147471m_1850862286095647119appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="m_-6587708015404147471m_1850862286095647119divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Openid-specs-risc <<a href="mailto:openid-specs-risc-bounces@lists.openid.net" target="_blank">openid-specs-risc-bounces@lists.openid.net</a>> on behalf of Apoorva Deshpande via Openid-specs-risc <<a href="mailto:openid-specs-risc@lists.openid.net" target="_blank">openid-specs-risc@lists.openid.net</a>><br>
<b>Sent:</b> Tuesday, November 21, 2023 12:48 AM<br>
<b>To:</b> <a href="mailto:openid-specs-risc@lists.openid.net" target="_blank">openid-specs-risc@lists.openid.net</a> <<a href="mailto:openid-specs-risc@lists.openid.net" target="_blank">openid-specs-risc@lists.openid.net</a>>; Atul Tulshibagwale <<a href="mailto:atul@sgnl.ai" target="_blank">atul@sgnl.ai</a>><br>
<b>Subject:</b> Re: [Openid-specs-risc] [openid/sharedsignals] dd60ca: added caep interoperability profile doc</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr">Thank you Atul for this profile.
<div><br>
</div>
<div>Please find my early feedback -</div>
<div>
<ul>
<li>We should stick to "SSF Transmitter/Receiver terminology" and replace existing occurrences of "CAEP Transmitter/Receiver"</li><ul>
<li><span style="font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">eg, An SSF Transmitter or Receiver is able to respectively generate or respond to the CAEP session-revoked event (provides the same understanding)</span><br>
</li></ul>
<li><font face="Noto Sans, Arial, Helvetica, sans-serif"><span style="font-size:14px">Transmitter common requirements</span></font></li><ul>
<li><font face="Noto Sans, Arial, Helvetica, sans-serif"><span style="font-size:14px">We should indicate The Transmitter Configuration Metadata MUST include </span></font></li><ol>
<li><span style="font-size:14px;font-family:"Noto Sans",Arial,Helvetica,sans-serif">"</span><span style="font-size:14px"><font face="monospace">jwks_uri</font></span><span style="font-size:14px;font-family:"Noto Sans",Arial,Helvetica,sans-serif">" which contains
the signing keys of the transmitter ( as signing is a MUST requirement ) </span></li><li><span style="font-size:14px;font-family:"Noto Sans",Arial,Helvetica,sans-serif">configuration_endpoint, status_endpoint, and verification_endpoint are required as config and status and verification operations are required.<br>
</span></li></ol>
<li><font face="Noto Sans, Arial, Helvetica, sans-serif"><span style="font-size:14px">Stream Control</span></font></li><ol>
<li><font face="Noto Sans, Arial, Helvetica, sans-serif"><span style="font-size:14px"><span>Stream Update - We may need to include stream update as a required API as it provides the ability for the receiver
to update the stream status on the transmitter. The status endpoint is listed as required.</span></span></font></li><li><font face="Noto Sans, Arial, Helvetica, sans-serif"><span style="font-size:14px"><span>Stream Verification<b> </b>- We should add another sentence " A transmitter MUST be able to generate a verification
event to request stream liveliness from the receiver"</span><br>
</span></font></li></ol>
</ul>
<li><font face="Noto Sans, Arial, Helvetica, sans-serif"><span style="font-size:14px">Receivers</span></font></li><ul>
<li><span style="font-size:14px"><font face="Noto Sans, Arial, Helvetica, sans-serif">Eve</font><font face="arial, sans-serif">nt Subjects - We</font><font face="Noto Sans, Arial, Helvetica, sans-serif"> need to add flexibility around this statement. I suggest
including </font><font face="monospace">iss_sub</font><font face="arial, sans-serif"> to that list as an
</font><font face="monospace">email</font><font face="arial, sans-serif"> could be mutable for user identities and trusted parties may want to rely on different identifiers.</font></span></li></ul>
<li><font face="arial, sans-serif"><span style="font-size:14px">Use cases</span></font></li><ul>
<li>It's easier to drive the use cases when the underlying reason has surfaced. Hence suggesting that
<font face="monospace">reason_admin</font> should be a MUST for CAEP events</li></ul>
</ul>
</div>
</div>
<br>
<div>
<div dir="ltr">On Mon, Nov 20, 2023 at 5:27 PM Atul Tulshibagwale via Openid-specs-risc <<a href="mailto:openid-specs-risc@lists.openid.net" target="_blank">openid-specs-risc@lists.openid.net</a>> wrote:<br>
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p><strong>This message originated outside your organization.</strong></p>
<br>
<hr>
<br>
</div>
<div dir="ltr">Hi all,
<div>This is the first draft of the CAEP interoperability profile. In order for you to read the formatted document, I've created a
<a href="https://github.com/SGNL-ai/caep-interop" target="_blank">temporary repo</a> from where you can see the
<a href="https://urldefense.com/v3/__https://sgnl-ai.github.io/caep-interop/caep-interoperability-profile-1_0.html__;!!PwKahg!7D-1jdD9G2Eb-E9xt9j19VrRRRWbrqvlc4cRAUPy-gLIx4VkL9FsWhwZix8K0rUmpsxPfyNyOIL5jsXniKIGuYQuVG3jd8DlPE6JWQ$" target="_blank">
formatted doc here</a></div>
<div><br>
</div>
<div>Please review and provide your feedback to this mailing list.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Atul</div>
</div>
<br>
<div>
<div dir="ltr">On Mon, Nov 20, 2023 at 5:25 PM Atul Tulshibagwale via Openid-specs-risc <<a href="mailto:openid-specs-risc@lists.openid.net" target="_blank">openid-specs-risc@lists.openid.net</a>> wrote:<br>
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Branch: refs/heads/interop-profile<br>
Home: <a href="https://github.com/openid/sharedsignals" rel="noreferrer" target="_blank">https://github.com/openid/sharedsignals</a><br>
Commit: dd60cac3f75ef37f0b0926c5c222ecfbf1efb435<br>
<a href="https://github.com/openid/sharedsignals/commit/dd60cac3f75ef37f0b0926c5c222ecfbf1efb435" rel="noreferrer" target="_blank">
https://github.com/openid/sharedsignals/commit/dd60cac3f75ef37f0b0926c5c222ecfbf1efb435</a><br>
Author: Atul Tulshibagwale <<a href="mailto:atultulshi@gmail.com" target="_blank">atultulshi@gmail.com</a>><br>
Date: 2023-11-20 (Mon, 20 Nov 2023)<br>
<br>
Changed paths:<br>
M .github/workflows/build-everything.yml<br>
A caep-interoperability-profile-1_0.md<br>
<br>
Log Message:<br>
-----------<br>
added caep interoperability profile doc<br>
<br>
<br>
_______________________________________________<br>
Openid-specs-risc mailing list<br>
<a href="mailto:Openid-specs-risc@lists.openid.net" target="_blank">Openid-specs-risc@lists.openid.net</a><br>
<a href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-risc__;!!PwKahg!7D-1jdD9G2Eb-E9xt9j19VrRRRWbrqvlc4cRAUPy-gLIx4VkL9FsWhwZix8K0rUmpsxPfyNyOIL5jsXniKIGuYQuVG3jd8BnlBRlyg$" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-risc</a><br>
</blockquote>
</div>
_______________________________________________<br>
Openid-specs-risc mailing list<br>
<a href="mailto:Openid-specs-risc@lists.openid.net" target="_blank">Openid-specs-risc@lists.openid.net</a><br>
<a href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-risc__;!!PwKahg!__zLv-RWw2smVICxjwTgeiVNMTtMi7Y9Sz9vI1NIrPtGg6epJvOzFmYj84vI_lumozjKEraWiIozVpNSeA$" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-risc</a><br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
<span>-- </span><br>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif">
Thanks,
<div>Apoorva</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div></blockquote></div>
</blockquote></div></div>