[Openid-specs-risc] Call notes
Atul Tulshibagwale
atul at sgnl.ai
Tue Nov 18 19:05:26 UTC 2025
Hi all,
The notes for today's call are stored in the SSWG Wiki here
<https://github.com/openid/sharedsignals/wiki/Meeting-on-2025%E2%80%9011%E2%80%9018>
.
They are copied below for your convenience.
Please note there is no call on Tuesday, 11/25 due to the Thanksgiving
holiday in the US.
Thanks to all who participated in today's meeting,
Atul
--
Atul Tulshibagwale
CTO
<https://www.linkedin.com/in/tulshi/> <atul at sgnl.ai>
--
WG Meeting: 2025-11-18 <#Agenda>Agenda
- Review issues list for "vFuture"
<#Attendees>Attendees
- Atul Tulshibagwale (SGNL)
- vatsal Gupta (Apple)
- Apoorva Deshpande (Okta)
- Ashish Kedia (Google)
- Sean O'Dell (Disney)
- Yair Sarig (Omnissa)
- Thomas (Tom) Darimont (OIDF)
- John Marchesini (Jamf)
<#Notes>Notes <#vFuture>vFuture
- (Ashish) We should identify blockers, and those should be labeled as
"immediate"
- (Atul) Should we label things with priority labels, e.g. p0, p1, …
- (Sean) This should help with the roadmap discussion that co-chairs
need to work on.
- (Sean) Priority could be bugs, features or blockers.
- (Apoorva) If the reporter comes up with a label, then in the WG
meeting we can decide whether its a bug or a feature
- We should provide guidance that people should just file issues, and
we can decide how to process them.
- (Sean) I agree, but our cadence in this group can be changed to
have smaller cohorts and report back.
- (Apoorva) That's fine, as long as we have clear communication on
Slack or email.
- (Sean and Atul) Created P0, P1, P2 labels in github for
prioritization
- (Apoorva) What is the goal of this?
- (Atul) The prioritization will help us to come up with a roadmap
- (Apoorva) What about the use-cases white paper
- (Atul) I can share the content for a white paper that SGNL will
publish shortly, SSWG can comment on it, and we can decide if it is
appropriate to publish in the SSWG.
- (Sean) Marked Issue #299
<https://github.com/openid/sharedsignals/issues/299> as *P0*
<#P0-Items-discussion>P0 Items discussion:
-
(Sean) JWKS based Auth for Receivers instead of OAuth
<https://github.com/openid/sharedsignals/issues/299>
- (Atul) Is this a way for Txs to discover Rxs?
- (Apoorva) It is about providing an alternative to OAuth
authentication.
- (Apoorva) It doesn't solve the discovery issue because there is no
metadata / directory
- (Ashish) Discovery for receivers is related. We could separate out
the discovery of receivers from the authentication / authorization.
- (Yair)
- (Ashish) Discovery might not be the right term, but perhaps "well
known" configuration for receivers.
- (Yair) Discovery is much larger than that.
- (Ashish) Potentially yes
- (Yair) I agree it should be two different topics.
- (Ashish) This is not really a blocker, because it is an alternative
to the existing authorization.
- (Sean) I agree. We need the discovery one though to be p0
- (Ashish) Discovery should be p0
-
(Ashish) The issue is: "Well Known Configuration for Receivers"
<https://github.com/openid/sharedsignals/issues/298>. This is p0
- (Yair) I won't call this discovery, because this is just providing a
well known URL.
- (Apoorva) I agree this isn't discovery, but just capability.
- (Ashish) Yes, let's call it "receiver capability"
- (Sean) I disagree. At a company, I can look my whole network, and
find out which receivers exist based on the well-known URL, so I will be
able to discover receivers.
- (Sean) I get the limitations in an industry wide context, but this
helps in the enterprise wide context.
- (Apoorva) Adding a registry will help in discovery.
- (Atul) There's no way to enforce it
- (Apoorva and Ashish) We can enforce it as a part of certification
- (Yair) I agree this is a good use case, but having a well-known
configuration, but we need to be clear what it means.
- (Apoorva) Is this p0?
- (Ashish) We really want this, because we want Transmitters to
understand the Google Receiver, and will open up auto adoption by Google
partners. Transmitters will be able to preconfigure a stream this way.
- (Vatsal) If registering receivers is important, should we make it a
part of the framework itself?
- (Atul) That's the work we are identifying by categorizing this
issue as p0
- (Yair) One thing we need to worry about is the tenancy. Each tenant
is a different customer. Is it discovering a different receiver, or a
different tenant.
- (Apoorva) I was going to same thing.
- (Ashish) I will clarify offline. Even if you have tenancy, you have
a well-known configuration per tenant.
- (Atul) I agree
- (Yair) Well-known has to have a path, so just knowing the host-name
won't be enough. Allowing to find whether a tenant exists might be a
security issue.
- (Yair) I think we need to work out the use cases a little bit.
- (Apoorva) We should prioritize based on these details.
- (Atul) Ashish to add the comment and share on mailing list. Please
respond to Ashish's comment, and we can decide the priority in the next
call.
<#Testing-discussion>Testing discussion
- (Gail) Hitting on Testing Conformance issues
- (Tom) Transmitter tests are ready so far, but we have only done
rudimentary testing. Do we need to do more?
- (Tom) Members of the group, please take another look at the
conformance tests for transmitters, and whether they are missing anything.
We should do one more run where everyone tries the tests and reports
issues. We will then be ready for offering it as a certification test.
- (Sean) Which environment should these tests be done on?
- (Tom) The demo environment:
<https://demo.certification.openid.net/index.html>
- (Tom) We need to clarify what the scope of the conformance testing for
transmitters is.
- (Tom) If we want to go for a specific scenario such as a "CAEP
interop", then we might have to limit the scope of the tests.
- (Gail) Scope for this launch is the CAEP interop spec.
<#Call-schedule>Call schedule
Next week's call is cancelled due to Thanksgiving in the US.
<#Tom-Satos-LinkedIn-Article>Tom Sato's LinkedIn Article:
- See here
<https://www.linkedin.com/pulse/nist-digital-identity-guideline-800-63-4-openidf-shared-tom-sato-05yoc>
-
<#Action-Items>Action Items
1. Implementers to run test suite again. Report any bugs, report any
missing tests positive or negative.
2. Joseph to review test requirements and sign off on current scope,
ready to publish for self-cert
3. WG to formally confirm that all positive and negative tests are
sufficient as currently in place, and give nod to move to
self-certification / publication
4. Thomas to publish for self-certification on official conformance
testing env <https://www.certification.openid.net/>
5. First implementers to pass final, published self certification tests
will be announced in press release
6. Ashish to add comment to issue #298
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20251118/96dcbe21/attachment.htm>
More information about the Openid-specs-risc
mailing list