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

Atul Tulshibagwale atul at sgnl.ai
Mon Nov 27 22:59:39 UTC 2023 

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
>
>
>
> --
> Thanks,
> Apoorva
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20231127/46edca37/attachment.html>

More information about the Openid-specs-risc mailing list