Hi all, <div>The minutes from yesterday’s working group call are below.</div><div><br></div><div>Cheers,</div><div>Joe</div><div><br></div><div><br><div><br></div><div><div># OpenID AB Minutes for March 6</div><div><br></div><div># Attendees</div><div>- Michael Jones, Chair</div><div>- Joe DeCock, Notetaker</div><div>- Brock Allen</div><div>- Axel Nennker</div><div>- Aaron Parecki</div><div>- Alex B Chalmers</div><div>- Andy Barlow</div><div>- Brian Campbell</div><div>- Dick Hardt</div><div>- Karl McGuinness</div><div>- Lukasz Jarowin</div><div>- Elizabeth Garber</div><div>- Andrii Deinega</div><div>- Filip Skokan</div><div><br></div><div># Upcoming Events</div><div>## IETF 122, Mar 15-21, Bangkok, Thailand</div><div>- Lots of interesting things happening there</div><div>- Links with discount codes</div><div>- Please register</div><div><br></div><div>## OpenID Workshop and IIW, Apr 7-10, Mountain View, California</div><div>- <a href="https://openid.net/attend-the-oidf-workshop-prior-to-iiw-spring-2025-on-7th-april-2025/">https://openid.net/attend-the-oidf-workshop-prior-to-iiw-spring-2025-on-7th-april-2025/</a></div><div>- Plus side meetings for DCP, W3C WebAuthn, and W3C FedID</div><div>- <a href="https://www.eventbrite.co.uk/e/oidf-dcp-wg-mtg-prior-to-iiw-mon-07-april-2025-google-sunnyvale-ca-tickets-1255718069549">https://www.eventbrite.co.uk/e/oidf-dcp-wg-mtg-prior-to-iiw-mon-07-april-2025-google-sunnyvale-ca-tickets-1255718069549</a></div><div>- <a href="https://www.eventbrite.co.uk/e/oidf-dcp-wg-mtg-post-iiw-fri-11th-april-2025-apple-cuppertino-ca-tickets-1270606250499">https://www.eventbrite.co.uk/e/oidf-dcp-wg-mtg-post-iiw-fri-11th-april-2025-apple-cuppertino-ca-tickets-1270606250499</a></div><div><br></div><div>## OpenID Federation Interop, April 28-30, hosted by SUNET in Stockholm</div><div>- Sign up in the attendee spreadsheet</div><div><br></div><div># Discussion about OIDF Intent to Create Content for Developers</div><div><br></div><div>Facilitated by Elizabeth Garber, Strategy and Marketing for OIDF</div><div><br></div><div>Joe: Like the idea of content for developers along the lines of, given constraints, here is guidance or a profile</div><div>Elizabeth's question for the working group: Should we point to content outside the foundation?</div><div>Neil supports, as the specs are somewhat dry, broad/general. Docs and samples and concreteness are helpful.</div><div>  Example - Authlete docs</div><div>  Challenge: how do you maintain quality? How do you avoid endorsement/implication of endorsement?</div><div>Dick points out that there are many audiences for the OIDF website. Some people are looking for the spec. What are the goals of this content?</div><div>Elizabeth: The goal is, for in demand standards, to do more hand-holding</div><div>Dick: There is a lot of existing content outside of the foundation. Perhaps we don't need to produce more of it.</div><div>Karl: Actually implementing the specs is not something most developers should do. Instead, they should use a certified implementation.</div><div>Alex: More visibility into the certification process might be helpful. Direct developers to certified implementations</div><div>Lukasz: Supports idea of vendor agnostic getting started content for simple scenarios</div><div>Aaron: We should make a distinction between spec tutorials vs conceptual guidance. From the point of view of a developer new to this space, conceptual guidance is most important </div><div>Mike: The idea is that there is lots of vendor content, and while OIDF wants to avoid endorsement, we can link to it.</div><div><br></div><div>## Outcomes</div><div>- Please send content to <a href="mailto:elizabeth.garber@oidf.org">elizabeth.garber@oidf.org</a> or via slack</div><div>- Elizabeth will continue to think about this, and follow up at IIW</div><div><br></div><div># OpenID Provider Commands</div><div>- Call for adoption ends now</div><div>- Lots of productive discussion</div><div><br></div><div>## Consensus</div><div>There was general consensus that OpenId Provider Commands solves an important problem, and that a simplified approach is helpful. </div><div><br></div><div>## Debate</div><div>There was debate about two topics: the introduction of the tenant concept, and the use of SSE.</div><div><br></div><div>### Tenant Concept</div><div>Karl: </div><div>  Google, Microsoft, etc. need the tenant concept</div><div>Brian: </div><div>  Tenancy is out of scope</div><div>  Suggestion is to remove tenant concept</div><div>  Allow vendors to continue doing their proprietary tenant extensions</div><div>Aaron:</div><div>  Tenancy problem exists back in Core, so we should address the problem in Core</div><div>Karl:</div><div>  Trying to do something small, without doing all the work necessary in Core</div><div>Aaron:</div><div>  This is one possible solution to a real problem, but if you do it this way, then it gets into the ecosystem without considering the wider implications</div><div>Mike:</div><div>  Connect doesn't solve tenancy, and it is a significant problem, but we don't want that to stop consideration of this specification</div><div>Brian:</div><div>  We can still take it out of this work. If it is left in, it will be harder to remove after after adoption</div><div><br></div><div>### SSE</div><div>Karl:</div><div>  Interested to see what developers do with the SSE implementation and get feedback</div><div>Aaron:</div><div>  Great, let's try things</div><div>  But, if you make too large of a change, then that undermines confidence</div><div>  Suggestion is to divide the document to make experimental nature of SSE more obvious</div><div>Mike:</div><div>  On the other hand, iteration may actually be good</div><div>  Breaking changes happened during early days of Connect</div><div>Brian:</div><div>  Trying to position it as a simple solution to a well-understood problem is somewhat undermined by using less-proven technology like SSEs</div><div>Mike:</div><div>  We would need volunteers to write additional specs if someone wants to tackle the full tenant problem</div><div>Brian:</div><div>  We could still divide it</div><div>Dick:</div><div>  We need it together</div><div>Mike:</div><div>  Working group is empowered to make changes of any kind</div><div>  Breaking changes are allowed, many examples of doing so in this group</div><div>  Hope is that implementors will give feedback</div><div><br></div><div>## Support/Opposition</div><div>  Support or support with reservations for doing the work    </div><div>    - Dick Hardt</div><div>    - Karl McGuiness</div><div>    - Niels van Dijk</div><div>    - Mike Schwartz</div><div>    - Andrii Deinega</div><div><br></div><div>  Support with changes</div><div>    - Aaron Parecki</div><div>    - Andy Barlow</div><div>    - Dean Saxe</div><div>    - Brian Campbell</div><div>    - Brock Allen</div><div><br></div><div>  Opposed to doing the work</div><div>    - None</div><div><br></div><div>## Outcome</div><div>The chairs believe there is sufficient support for adoption</div><div>  - Bias for action</div><div>  - Technical criticisms are valid</div><div>  - Request to authors to create a working group draft</div><div>  - Run Mark Haine's content validation tool on it</div></div><div><br></div></div>