[Openid-specs-risc] Call notes

[Atul Tulshibagwale]

Hi Steve,
Regardless of where the JWTs are signed, the "jwks_uri" specifies the
signing key of the Transmitter, so the Receiver must assume that the
Transmitter has signed the JWT. In the event that the transport provides
the integrity protection, The Receiver can rely on that to confirm that the
bits it received were indeed what the Transmitter sent. However, if there
are components within the Receiver that need to verify that the JWT came
from the Transmitter independently of relying on the transport, then the
JWT needs to be signed. This could be "in line" during the processing of
the event at the Receiver, or post-fact, say when the Receiver is executing
some batch process later.

Atul


On Mon, Mar 13, 2023 at 7:17 AM Steve Venema <steve.venema at forgerock.com>
wrote:

>
>>    - Do SSF JWTs need to be signed? Current understanding is that they
>>    don’t need to be signed if sent on an integrity protected transport like TLS
>>
>> The SSF architecture seems to treat the SET (JWT) generator as separate
> from the Transmitter function. Do real implementations approximate this
> division or are the SET generator and transmitter functions typically
> combined? In any case, I imagine that a stream consumer would be much more
> interested in validating the *source* of the SET than the confidentiality
> or integrity specifics of the transmitter/receiver transport.
>
> -Steve
>
>
> On Tue, Mar 7, 2023 at 10:58 PM Atul Tulshibagwale via Openid-specs-risc <
> openid-specs-risc at lists.openid.net> wrote:
>
>> Hi all,
>> Sorry for leaving the call early. Here are the notes from today's call.
>> They are also stored here
>> <https://hackmd.io/@oidf-wg-sse/wg-meeting-20230308>.
>>
>> Atul
>>
>> --
>>
>> <https://sgnl.ai>
>>
>> Atul Tulshibagwale
>>
>> CTO
>>
>> <https://linkedin.com/in/tulshi> <https://twitter.com/zirotrust>
>> <atul at sgnl.ai>
>>
>> ---
>> Agenda
>>
>>    - [Atul] Review open issues
>>    <https://github.com/openid/sharedsignals/issues>
>>    - [Atul] Discuss making jwks_uri optional (Open Issue #44
>>    <https://github.com/openid/sharedsignals/issues/44>)
>>    - [Atul] Create stream issues (#45
>>    <https://github.com/openid/sharedsignals/issues/45> and #46
>>    <https://github.com/openid/sharedsignals/issues/46>)
>>
>> <https://hackmd.io/xJwP1JHKQs6YLhVDEtdLKQ?view#Attendees>Attendees
>>
>>    - Atul Tulshibagwale (SGNL)
>>    - Debora Comparin (Thales)
>>    - Eric Karlinsky (Okta)
>>    - Greg Brown (Axiad)
>>    - Peter Travers (Beyond Identity)
>>    - Shayne Miel (Cisco)
>>    - Topher Marie (Strata)
>>    - Tim Cappalli (Microsoft)
>>
>> <https://hackmd.io/xJwP1JHKQs6YLhVDEtdLKQ?view#Notes>Notes
>> <https://hackmd.io/xJwP1JHKQs6YLhVDEtdLKQ?view#JWKS-URI-44>JWKS URI (#44)
>>
>>    - Do SSF JWTs need to be signed? Current understanding is that they
>>    don’t need to be signed if sent on an integrity protected transport like TLS
>>    - Can we make the jwks_uri field in the Transmitter Configuration
>>    Metadata optional? Yes, [Eric], no objections
>>
>> <https://hackmd.io/xJwP1JHKQs6YLhVDEtdLKQ?view#Create-Stream-Issues-45>Create
>> Stream Issues (#45)
>>
>>    - Discovering “events_supported” before creating a stream:
>>    - Requirement seems real, we can alter the response to pull
>>    “events_supported” out of each stream’s configuration
>>    - We could add a separate endpoint to get the events supported
>>    - Separate endpoint is the preferred option in the call (Shayne, Tim
>>    and Peter). The endpoint couldbe called “get events supported”
>>    - We should not remove the “events_supported” field from the existing
>>    response to “get stream configuration” because the events supported may be
>>    different per stream
>>    - We should not have a “stream id” parameter to the new endpoint to
>>    “get supported events”
>>
>> <https://hackmd.io/xJwP1JHKQs6YLhVDEtdLKQ?view#Create-Stream-Issue-46>Create
>> Stream Issue (#46)
>>
>>    - Continue discussion next time
>>
>> <https://hackmd.io/xJwP1JHKQs6YLhVDEtdLKQ?view#Action-Items>Action Items
>> _______________________________________________
>> 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/20230313/c8c4850d/attachment.html>