[Openid-specs-ab] Minutes for March 6 Working Group Meeting

[Joe DeCock]

Hi all,
The minutes from yesterday’s working group call are below.

Cheers,
Joe



# OpenID AB Minutes for March 6

# Attendees
- Michael Jones, Chair
- Joe DeCock, Notetaker
- Brock Allen
- Axel Nennker
- Aaron Parecki
- Alex B Chalmers
- Andy Barlow
- Brian Campbell
- Dick Hardt
- Karl McGuinness
- Lukasz Jarowin
- Elizabeth Garber
- Andrii Deinega
- Filip Skokan

# Upcoming Events
## IETF 122, Mar 15-21, Bangkok, Thailand
- Lots of interesting things happening there
- Links with discount codes
- Please register

## OpenID Workshop and IIW, Apr 7-10, Mountain View, California
-
https://openid.net/attend-the-oidf-workshop-prior-to-iiw-spring-2025-on-7th-april-2025/
- Plus side meetings for DCP, W3C WebAuthn, and W3C FedID
-
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-post-iiw-fri-11th-april-2025-apple-cuppertino-ca-tickets-1270606250499

## OpenID Federation Interop, April 28-30, hosted by SUNET in Stockholm
- Sign up in the attendee spreadsheet

# Discussion about OIDF Intent to Create Content for Developers

Facilitated by Elizabeth Garber, Strategy and Marketing for OIDF

Joe: Like the idea of content for developers along the lines of, given
constraints, here is guidance or a profile
Elizabeth's question for the working group: Should we point to content
outside the foundation?
Neil supports, as the specs are somewhat dry, broad/general. Docs and
samples and concreteness are helpful.
  Example - Authlete docs
  Challenge: how do you maintain quality? How do you avoid
endorsement/implication of endorsement?
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?
Elizabeth: The goal is, for in demand standards, to do more hand-holding
Dick: There is a lot of existing content outside of the foundation. Perhaps
we don't need to produce more of it.
Karl: Actually implementing the specs is not something most developers
should do. Instead, they should use a certified implementation.
Alex: More visibility into the certification process might be helpful.
Direct developers to certified implementations
Lukasz: Supports idea of vendor agnostic getting started content for simple
scenarios
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
Mike: The idea is that there is lots of vendor content, and while OIDF
wants to avoid endorsement, we can link to it.

## Outcomes
- Please send content to elizabeth.garber at oidf.org or via slack
- Elizabeth will continue to think about this, and follow up at IIW

# OpenID Provider Commands
- Call for adoption ends now
- Lots of productive discussion

## Consensus
There was general consensus that OpenId Provider Commands solves an
important problem, and that a simplified approach is helpful.

## Debate
There was debate about two topics: the introduction of the tenant concept,
and the use of SSE.

### Tenant Concept
Karl:
  Google, Microsoft, etc. need the tenant concept
Brian:
  Tenancy is out of scope
  Suggestion is to remove tenant concept
  Allow vendors to continue doing their proprietary tenant extensions
Aaron:
  Tenancy problem exists back in Core, so we should address the problem in
Core
Karl:
  Trying to do something small, without doing all the work necessary in Core
Aaron:
  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
Mike:
  Connect doesn't solve tenancy, and it is a significant problem, but we
don't want that to stop consideration of this specification
Brian:
  We can still take it out of this work. If it is left in, it will be
harder to remove after after adoption

### SSE
Karl:
  Interested to see what developers do with the SSE implementation and get
feedback
Aaron:
  Great, let's try things
  But, if you make too large of a change, then that undermines confidence
  Suggestion is to divide the document to make experimental nature of SSE
more obvious
Mike:
  On the other hand, iteration may actually be good
  Breaking changes happened during early days of Connect
Brian:
  Trying to position it as a simple solution to a well-understood problem
is somewhat undermined by using less-proven technology like SSEs
Mike:
  We would need volunteers to write additional specs if someone wants to
tackle the full tenant problem
Brian:
  We could still divide it
Dick:
  We need it together
Mike:
  Working group is empowered to make changes of any kind
  Breaking changes are allowed, many examples of doing so in this group
  Hope is that implementors will give feedback

## Support/Opposition
  Support or support with reservations for doing the work
    - Dick Hardt
    - Karl McGuiness
    - Niels van Dijk
    - Mike Schwartz
    - Andrii Deinega

  Support with changes
    - Aaron Parecki
    - Andy Barlow
    - Dean Saxe
    - Brian Campbell
    - Brock Allen

  Opposed to doing the work
    - None

## Outcome
The chairs believe there is sufficient support for adoption
  - Bias for action
  - Technical criticisms are valid
  - Request to authors to create a working group draft
  - Run Mark Haine's content validation tool on it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250307/b30ed795/attachment.htm>