[Openid-specs-risc] Unsigned SETs in SSF events

[Atul Tulshibagwale]

Thanks Phil,
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.

Atul


On Mon, Feb 27, 2023 at 11:34 AM Phillip Hunt <phil.hunt at independentid.com>
wrote:

> Atul,
>
> 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.  :-)
>
> As I recall it all boils down to the same trade-off for unsigned JWTs.
>
> I myself use unsigned JWTs for lab testing (sig alg none) in
> point-to-point scenarios.
>
> 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”.
>
> Phillip Hunt
> phil.hunt at independentid.com
>
>
>
>
>
> On Feb 27, 2023, at 10:00 AM, Atul Tulshibagwale via Openid-specs-risc <
> openid-specs-risc at lists.openid.net> wrote:
>
> Hi all,
>
> 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 SSF spec
> <https://github.com/openid/sharedsignals/blob/main/openid-sharedsignals-framework-1_0.txt>
> does not specify that the SETs should be signed, and the SET spec
> <https://www.rfc-editor.org/rfc/rfc8417.html#section-5.1> (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."
>
> So since the DELIVERYPUSH and DELIVERYPOLL methods offer integrity
> protection, neither of the specs require SETs to be signed.
>
> Is my understanding correct?
>
> Thanks,
> Atul
>
> _______________________________________________
> Openid-specs-risc mailing list
> Openid-specs-risc at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-risc
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20230227/d97b35ae/attachment.html>