-
Notifications
You must be signed in to change notification settings - Fork 19
Meeting on 2025‐11‐18
Atul Tulshibagwale edited this page Nov 18, 2025
·
1 revision
- Review issues list for "vFuture"
- 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)
- (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 as P0
-
(Sean) JWKS based Auth for Receivers instead of OAuth
- (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". 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.
- (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:
- (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.
Next week's call is cancelled due to Thanksgiving in the US.
- Implementers to run test suite again. Report any bugs, report any missing tests positive or negative.
- Joseph to review test requirements and sign off on current scope, ready to publish for self-cert
- 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
- Thomas to publish for self-certification on official conformance testing env
- First implementers to pass final, published self certification tests will be announced in press release
- Ashish to add comment to issue #298