[Openid-specs-risc] [openid/sharedsignals] dd60ca: added caep interoperability profile doc

Tue Nov 28 00:37:43 UTC 2023

Hello Atul,

#2 - all the items that I have described are marked as OPTIONAL in the
latest draft hence interop profile should call it out as REQUIRED

On Mon, Nov 27, 2023 at 4:59 PM Atul Tulshibagwale <atul at sgnl.ai> wrote:

> *This message originated outside your organization.*
>
> ------------------------------
>
> Thanks Shayne and Apoorva, for your reviews. Here are some responses, we
> should discuss this in tomorrow's meeting:
>
>    1. (Apoorva) CAEP Transmitter  -> SSF Transmitter - I'm OK with using
>    SSF as the terminology. If no one else has any objections, I will change
>    the terminology in the interop profile to read "SSF Transmitter" (and SSF
>    Receiver)
>    2. (Apoorva) Those fields that are mentioned as "required" (MUST have,
>    etc.) in the SSF draft, do not need to be specified separately in the
>    interop draft. The interop draft only talks about those optional things
>    from SSF that have some specific subset of those options that need to be
>    implemented by interoperable implementations
>    3. (Apoorva) Stream Control - I've left the ability to pause and
>    restart streams out of the interop draft. We should discuss this tomorrow.
>    4. (Apoorva) Verification: The intent was for interoperable
>    Transmitters to support verification. I will add the sentence for clarity
>    5. (Apoorva) Receivers: "iss-sub" support: I will add this to the draft
>    6. (Apoorva) Reason-admin: I will add "reason_admin" as a required
>    field in the use cases.
>    7. (Shayne) Why PUSH only: I'm proposing that interoperable
>    implementations MUST support the push method. They can support the poll
>    method if they want, but that doesn't affect their interoperability status.
>    Let's discuss this tomorrow
>    8. (Shayne) Implicit Subjects: SSF doesn't require each subject in the
>    stream to be added using AddSubject. The interop profile clarifies that any
>    interoperable Transmitter should automatically add all subjects to a stream
>    and need not support AddSubject / RemoveSubject methods. Let's discuss this
>    tomorrow.
>
> Atul
>
> On Tue, Nov 21, 2023 at 11:00 AM Shayne Miel (smiel) <smiel at cisco.com>
> wrote:
>
>> Thanks for putting this together. I have two issues:
>>
>>    1. Why are we restricting this to PUSH only? That will make it harder
>>    for Receivers to join us in the interop.
>>    2. I'm confused about section 3.2.2. What mechanism is being proposed
>>    here? I am not aware of any ability to have implicitly added subjects in
>>    the Transmitter, except for possibly the wildcard complex subjects.
>>
>> Thanks,
>> Shayne
>> ------------------------------
>> *From:* Openid-specs-risc <openid-specs-risc-bounces at lists.openid.net>
>> on behalf of Apoorva Deshpande via Openid-specs-risc <
>> openid-specs-risc at lists.openid.net>
>> *Sent:* Tuesday, November 21, 2023 12:48 AM
>> *To:* openid-specs-risc at lists.openid.net <
>> openid-specs-risc at lists.openid.net>; Atul Tulshibagwale <atul at sgnl.ai>
>> *Subject:* Re: [Openid-specs-risc] [openid/sharedsignals] dd60ca: added
>> caep interoperability profile doc
>>
>> Thank you Atul for this profile.
>>
>> Please find my early feedback -
>>
>>    - We should stick to "SSF Transmitter/Receiver terminology" and
>>    replace existing occurrences of "CAEP Transmitter/Receiver"
>>       - eg, An SSF Transmitter or Receiver is able to respectively
>>       generate or respond to the CAEP session-revoked event (provides the same
>>       understanding)
>>       - Transmitter common requirements
>>       - We should indicate The Transmitter Configuration Metadata MUST
>>       include
>>          1. "jwks_uri" which contains the signing keys of the
>>          transmitter ( as signing is a MUST requirement )
>>          2. configuration_endpoint, status_endpoint, and
>>          verification_endpoint are required as config and status and verification
>>          operations are required.
>>          - Stream Control
>>          1. Stream Update - We may need to include stream update as a
>>          required API as it provides the ability for the receiver to update the
>>          stream status on the transmitter. The status endpoint is listed as required.
>>          2. Stream Verification - We should add another sentence " A
>>          transmitter MUST be able to generate a verification event to request stream
>>          liveliness from the receiver"
>>          - Receivers
>>       - Event Subjects - We need to add flexibility around this
>>       statement. I suggest including iss_sub to that list as an email
>>       could be mutable for user identities and trusted parties may want to rely
>>       on different identifiers.
>>    - Use cases
>>       - It's easier to drive the use cases when the underlying reason
>>       has surfaced. Hence suggesting that reason_admin should be a MUST
>>       for CAEP events
>>
>>
>> On Mon, Nov 20, 2023 at 5:27 PM Atul Tulshibagwale via Openid-specs-risc <
>> openid-specs-risc at lists.openid.net> wrote:
>>
>> *This message originated outside your organization.*
>>
>> ------------------------------
>>
>> Hi all,
>> This is the first draft of the CAEP interoperability profile. In order
>> for you to read the formatted document, I've created a temporary repo
>> <https://github.com/SGNL-ai/caep-interop> from where you can see the formatted
>> doc here
>> <https://urldefense.com/v3/__https://sgnl-ai.github.io/caep-interop/caep-interoperability-profile-1_0.html__;!!PwKahg!7D-1jdD9G2Eb-E9xt9j19VrRRRWbrqvlc4cRAUPy-gLIx4VkL9FsWhwZix8K0rUmpsxPfyNyOIL5jsXniKIGuYQuVG3jd8DlPE6JWQ$>
>>
>> Please review and provide your feedback to this mailing list.
>>
>> Thanks,
>> Atul
>>
>> On Mon, Nov 20, 2023 at 5:25 PM Atul Tulshibagwale via Openid-specs-risc <
>> openid-specs-risc at lists.openid.net> wrote:
>>
>>   Branch: refs/heads/interop-profile
>>   Home:   https://github.com/openid/sharedsignals
>>   Commit: dd60cac3f75ef37f0b0926c5c222ecfbf1efb435
>>
>> https://github.com/openid/sharedsignals/commit/dd60cac3f75ef37f0b0926c5c222ecfbf1efb435
>>   Author: Atul Tulshibagwale <atultulshi at gmail.com>
>>   Date:   2023-11-20 (Mon, 20 Nov 2023)
>>
>>   Changed paths:
>>     M .github/workflows/build-everything.yml
>>     A caep-interoperability-profile-1_0.md
>>
>>   Log Message:
>>   -----------
>>   added caep interoperability profile doc
>>
>>
>> _______________________________________________
>> Openid-specs-risc mailing list
>> Openid-specs-risc at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-risc
>> <https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-risc__;!!PwKahg!7D-1jdD9G2Eb-E9xt9j19VrRRRWbrqvlc4cRAUPy-gLIx4VkL9FsWhwZix8K0rUmpsxPfyNyOIL5jsXniKIGuYQuVG3jd8BnlBRlyg$>
>>
>> _______________________________________________
>> Openid-specs-risc mailing list
>> Openid-specs-risc at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-risc
>> <https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-risc__;!!PwKahg!__zLv-RWw2smVICxjwTgeiVNMTtMi7Y9Sz9vI1NIrPtGg6epJvOzFmYj84vI_lumozjKEraWiIozVpNSeA$>
>>
>>
>>
>> --
>> Thanks,
>> Apoorva
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20231127/a15a3b86/attachment.html>