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

[Atul Tulshibagwale]

Sounds good.
In that case, should we make the "jwks_uri" field of a Transmitter
Configuration Metadata (section 6.1 of the SSF spec
<https://github.com/openid/sharedsignals/blob/main/openid-sharedsignals-framework-1_0.txt>)
optional instead of required?

On Mon, Feb 27, 2023 at 12:36 PM Phillip Hunt <phil.hunt at independentid.com>
wrote:

> Yes. That would be my assumption.
>
> Phil
>
> On Feb 27, 2023, at 11:47 AM, Atul Tulshibagwale <atul at sgnl.ai> wrote:
>
> 
> 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/2ffbcc66/attachment-0001.html>