[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