<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Yes. That would be my assumption. <div><br></div><div><div><div dir="ltr">Phil</div><div dir="ltr"><br><blockquote type="cite">On Feb 27, 2023, at 11:47 AM, Atul Tulshibagwale <atul@sgnl.ai> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">Thanks Phil,<div>Yes, I can see it being a requirement in specific scenarios (e.g. where a component in the Receiver needs to verify the SET independently of the transport), but I take it that your response affirms that SSF does not require SETs to be signed in general.</div><div><br></div><div>Atul</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 27, 2023 at 11:34 AM Phillip Hunt <<a href="mailto:phil.hunt@independentid.com">phil.hunt@independentid.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>Atul,</div><div><br></div>I remember this conversation at IETF Sec Events WG. There are a number of layers of security for SETs that can be invoked which you alude to below. And yes, technically SETs can have signature alg=none. :-)<div><br></div><div>As I recall it all boils down to the same trade-off for unsigned JWTs.</div><div><br></div><div>I myself use unsigned JWTs for lab testing (sig alg none) in point-to-point scenarios.</div><div><br></div><div>Implementations should consider that SSEF Events may also be used for historical purposes (trend analysis, audit). Signed events can be re-authenticated outside the context of the TLS chennel is lost (e.g. over time). Signatures may also be critical if events are being relayed through SSEF servers acting as “gateways”.</div><div><br></div><div><div>
<div dir="auto" 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"><div dir="auto" 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"><div>Phillip Hunt</div><div><a href="mailto:phil.hunt@independentid.com" target="_blank">phil.hunt@independentid.com</a></div><div><br></div></div><br></div><br><br>
</div>
<div><br><blockquote type="cite"><div>On Feb 27, 2023, at 10:00 AM, 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:</div><br><div><div dir="ltr">Hi all,<div><br></div><div>In a discussion last week, the issue of perceived complexity of the Shared Signals Framework came up, and one question within that was whether SSF allows SETs to be unsigned. Section 11.1.8.1 of the <a href="https://github.com/openid/sharedsignals/blob/main/openid-sharedsignals-framework-1_0.txt" target="_blank">SSF spec</a> does not specify that the SETs should be signed, and the <a href="https://www.rfc-editor.org/rfc/rfc8417.html#section-5.1" target="_blank">SET spec</a> (section 5.1) also says that "Unless integrity of the JWT is ensured by other means, it MUST be signed using JWS [RFC7515] by an issuer that is trusted to do so for the use case so that the SET can be authenticated and validated by the SET recipient."</div><div><div><br></div><div>So since the DELIVERYPUSH and DELIVERYPOLL methods offer integrity protection, neither of the specs require SETs to be signed. </div><div><br></div><div>Is my understanding correct?</div></div><div><br></div><div>Thanks,</div><div>Atul</div><div><br></div></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://lists.openid.net/mailman/listinfo/openid-specs-risc" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-risc</a><br></div></blockquote></div><br></div></div></blockquote></div>
</div></blockquote></div></div></body></html>