[Openid-specs-risc] Notes from today's call

Atul Tulshibagwale atul at sgnl.ai
Tue Jan 21 19:52:29 UTC 2025


Hi all,
Thanks to all who attended. Here are the notes for today's call. They are
also stored here
<https://docs.google.com/document/d/1ewCvh1OTIbw-pKX3EWHepETS06WyVPyq-75fZ4CURBA/edit?usp=sharing>
.

Atul

-- 

 Atul Tulshibagwale

 CTO

  <https://www.linkedin.com/in/tulshi/> <atul at sgnl.ai>
<https://x.com/zirotrust>

London 2025 Gartner CAEP Interop
Retrospective of Dec 2024 interop

   -

   (Mark Haine) It felt like there were quite a few attendees who were
   confused and walked away. I had to stand-in as a receptionist to provide an
   introduction to Shared Signals, which was good for the attendees.
   -

   (Shayne) Attendees in Dallas appeared far less confused than in London.
   Perhaps due to more awareness about Shared Signals. Agree that we should
   have a receptionist
   -

   (Garry) The monday session would have helped.
   -

   (Elizabeth) I did play that role in Dallas.



   -

   (Iulia) Who were the attendees of the interop? Were they customers or
   vendors. I was surprised to see many vendors. Is that a perception others
   share?
   -

      (Mark) Good question. It would help to have more formality through
      the receptionist role, and log who walks in.
      -

      (Elizabeth) Gartner scanned everyone. Can we get that data from
      Gartner? - I can ask them.
      -

      (Yair) There was a mix of vendors / customers, but also others who
      wanted to know more about SSF. The most questions I got was about the
      nature of SSF. People had a hard time understanding it for some reason.
      -

      (Atul) Perhaps we can have some posters that outline the basics.
      -

      (Elizabeth) I can help with that

Ideas about rules for the London 2025 interop

   -

   (Shayne) If we are talking about putting up posters to explain the
   basics, what if the implementer next to the poster could demonstrate what
   was described.
   -

   (Atul) I’d like it to be easier for new entrants, while raising the bar
   for more mature implementations
   -

   (Atul) Should we require some level of passing the conformance tests
   before someone can participate
   -

   (Mark) We will need support to help people become conformant
   -

   (Thomas) We currently have an alpha version. This will be presented in
   the workshop next week. It’ll show how you can configure your clients and
   run the tests against them, and inspect the results. The tests are still
   under development (alpha), and have been tested against 6 vendors. Each
   implementation behaves a bit differently, and deviates from the spec. So
   there is a lot of room to align the implementations. Some tests may be
   wrong too.
   -

   (David McNeely) What if there’s a way to publish to a website the
   configuration for each integration, so customers / other implementers can
   go to that website and do the right configuration and automatically import
   the configuration.
   -

   (Yair) We might not have a way for external parties to readily configure
   a public endpoint. Opening it up beyond that could be problematic
   -

   (David) It only needs to have configuration data, and not credentials.
   The ones with the credentials should be able to automatically import the
   configuration.
   -

   (Yair) In our case, every instance is a different entity, which involves
   a provisioning step.
   -

   (David) Drawing an analogy to SAML, where the SAML vendors publish a
   catalog wherein the customer can just point and click to obtain the
   configuration.
   -

   (Thomas) Regarding a website that enables clients to easily connect with
   each other: A lot of vendors support different sets of event types. There’s
   no way to know that ahead of time. It would be nice to have that in the
   metadata.
   -

   (Mark) Here’s a page
   <https://nordicapis.com/13-api-directories-to-help-you-discover-apis/>
   that has 13 different API directories. You may want to take inspiration
   from them.
   -

   (Atul) Dean, as a new implementer, what would help you participate
   -

      (Dean) Nothing in particular, but having the conformance tests early,
      or being able to download them, etc. would be super helpful to everyone
      -

      (James - Beyond Identity) I’ve been using the specs to build the unit
      tests and to make sure it conforms. By interop testing and
recommendations
      outside the spec on how to onboard receivers, and provisioning them would
      help.
      -

      (Dean) Do we need a FastFed for shared signals? This came up in the
      context of IPSIE too.
      -

      (Yair) What we did in Texas was that we had a list of all
      participants and what are they doing (Tx or Rx, which events,
etc.) We can
      repeat that. It’s less complicated, but good enough for interoperability
      purposes.
      -

      (Mark) It’ll help to have a better description of what each
      implementer can do. In E-KYC, we have done something like that, and we
      could come up with an OpenAPI spec (non-normative), to describe each
      implementation.
      -

   (Mike Schwartz) As someone who is joining late to the effort, it is a
   little confusing to me to make the connection to the business cases, which
   perhaps existing implementers take for granted. Interop sometimes goes down
   to the components (e.g. AuthZEN). Achieving interoperability there is not
   just a matter of one layer. So you could say the business problem we want
   to solve is “token revocation”, and the scenarios could be defined such
   that the business cases are outlined.
   -

      (Mark) Mike, there is a Special Topic Group (STG) that has been
      formed
      -

      (Mike) Let’s take global revocation as a concrete example. Here’s how
      we can use CAEP to do a session logout, and here’s how we can plugin
      different vendors, but without this kind of context people may
have a hard
      time understanding what CAEP is good for.
      -

   (Mike Schwartz) Is there a way to participate virtually?
   -

      (Atul) Virtual participation is limited to being included in the
      results of the interoperability event.
      -

   (Mark) I’m interested in risk signals. Once you have received events,
   you make a decision, which also needs to be conveyed to others
   -

   (David) I’m interested in SCIM and to reduce risk for customers.
   -

   (James Slocum) I’ll definitely second Mark on that. I’d love to think
   about ITDR type events.
   -

   (Mark) It feels to me that it might deserve a separate profile.
   -

   (Yair) We had a few demos that we recorded and presented in the Dallas
   event.  We would like to share it with others.
   -

   (Atul) Could we highlight these videos on the Shared Signals website?
   -

      (Elizabeth) Sure
      -

      (Mark) also promote these in the outreach for the interop
      -

   (Peter) One comment on hosting the videos: If we have to put them on an
   open website, we might need to add context and introduction so that it is
   understandable by anyone on the internet.



   -

   (Atul) Any thoughts on production implementation versus “in development”
   implementation
   -

      (Mike) The demo version won’t be a production implementation
      -

      (James) I’d think that as a standards body, it is outside the scope
      of whether something is a demo implementation or a production
      implementation, but if you wanted to go a certification route, then you
      might require something to be in production.
      -

      (Mike) I’m going to push back although I agree with some points. When
      an enterprise buys software, they need to know that they are going to be
      supported for the next few years. I don’t think it is something that we’d
      want to specify, and could be confusing.
      -

   (Iulia) One last thing to verify: In order to attend the London event,
   we don’t need to demo a production implementation, however we are looking
   to pass a conformance test
   -

      (Thomas) I’d like to add that there isn’t much to “pass” yet, except
      that we’ll get warnings on some tests. It’d be nice if vendors
are able to
      run the tests to get a better idea of how aligned their implementations
      are. After getting feedback from each implementer, we could build a
      stricter version of the tests
      -

         In the workshop next week I will go through a bunch of technical
         steps to get the conformance tests working
         -

      (Mark) In support of Thomas: The development of conformance tests
      requires input from implementers. The conformance testing team itself is
      meeting at Reykjavik in person at the OAuth Security Workshop
      <https://oauth.secworkshop.events/osw2025>, so if anyone wants to go
      there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250121/c6161069/attachment-0001.htm>


More information about the Openid-specs-risc mailing list