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

[Shayne Miel (smiel)]

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
        *   "jwks_uri" which contains the signing keys of the transmitter ( as signing is a MUST requirement )
        *   configuration_endpoint, status_endpoint, and verification_endpoint are required as config and status and verification operations are required.
     *   Stream Control
        *   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.
        *   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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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/20231121/6b50ef25/attachment-0001.html>