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

[Atul Tulshibagwale]

Yup, that sounds reasonable. I've created this issue:
https://github.com/openid/sharedsignals/issues/44

We can discuss this in the next WG meeting.

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

>
> I would say required when signed.
>
> Phil
>
> On Feb 27, 2023, at 1:55 PM, Atul Tulshibagwale <atul at sgnl.ai> wrote:
>
> 
> 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/20230228/58e8dd24/attachment.html>