[Openid-specs-ab] Call for Adoption of the OpenID Provider Commands Specification
Dick Hardt
dick.hardt at gmail.com
Wed Mar 5 08:36:46 UTC 2025
There is an additional precedence in the OIDF related to the SSE topic. Not
only did the logout specs introduce the session concept and define the
`sid` claim for use in logout as well as in an ID Token, the back channel
logout used Security Event Token (SET) as its format for a command, despite
SecEvents explicitly stating "Security events are not commands issued
between parties."
https://www.rfc-editor.org/rfc/rfc8417.html#:~:text=Security%20events%20are%20not%20commands%20issued%20between%20parties
.
On Tue, Mar 4, 2025 at 6:38 PM Karl McGuinness <me at karlmcguinness.com>
wrote:
> There is prior art in the working group to what Dick and I proposed with
> defining the tenant claim within the OP Commands spec. The OpenID
> Connect Front-Channel Logout
> <https://openid.net/specs/openid-connect-frontchannel-1_0.html> spec
> registered the *sid* claim to identify a session in an ID Token which was
> defined assidOPTIONAL. Session ID - String identifier for a Session. This
> represents a Session of a User Agent or device for a logged-in End-User at
> an RP. Different sid values are used to identify distinct sessions at an
> OP. The sid value need only be unique in the context of a particular
> issuer. Its contents are opaque to the RP. Its syntax is the same as an
> OAuth 2.0 Client Identifier.
> The OpenID Connect Back-Channel Logout
> <https://openid.net/specs/openid-connect-backchannel-1_0.html> then
> reuses the *sid* claim registration used in ID Tokens as a Logout Token
> parameter.
>
> Sessions like tenants are just as fundamental of concept to an
> authentication system and stripe across many use cases that may be defined
> in different specs. The family of logout specs didn't pull out the *sid*
> claim to its own spec and require the reader/implementor to go read yet
> another spec, they instead defined the relevant parts within the spec and
> just reused the claim registration even if it's used in an ID Token. OP
> Commands is proposing a similar approach with the *tenant* claim. As
> Dick has stated on the working group call that over time it may then make
> sense to cut an OIDC 1.1 update that is similar in spirit to OAuth 2.1 that
> consolidates all these extensions that revises the core protocol and
> concepts in a single document.
>
> -Karl
>
> On Tue, Mar 4, 2025 at 8:43 AM Dick Hardt via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>> *Tenant*
>>
>> Here is what the OP Commands proposal has about OP tenants:
>>
>> >>>>>>
>>
>> -
>>
>> *tenant*
>> REQUIRED.
>> A JSON string. The Tenant identifier. MAY have the value personal,
>> organization or a stable OP unique value for multi-tenant OPs. The
>> personal value is reserved for when Accounts are managed by
>> individuals. The organization value is reserved for Accounts are
>> managed by an organization.
>> <https://dickhardt.github.io/openid-provider-commands/openid-provider-commands-1_0-00.html#section-4-6.6.1>
>>
>> The combination of iss and tenant uniquely identifies a Tenant.
>> >>>>>>
>>
>> I'm happy to see that I did call out that it is the combination of `iss`
>> and `tenant` that uniquely identifies a Tenant.
>>
>> I fail to see how it is a benefit to an implementer of OP Commands to
>> have this text in an independent document, nor why an OP can't start
>> including the tenant claim in ID Tokens if they choose to do so even if it
>> is defined in OP Commands. They are unlikely to care now about adding in
>> the tenant claim unless they are also looking to deploy OP Commands.
>>
>> *Tenant management / SSE*
>>
>> The only required command in OP Commands is the `tenant_metadata`
>> command, which lets the OP know which commands the RP supports for a given
>> OP tenant. This is the starting point of protocol negotiation between the
>> OP and the RP. Having that command be in a separate document does not make
>> sense.
>>
>> In order for an existing RP deployment to migrate to using OP Commands,
>> the OP will want to do an audit of what accounts the RP already has, so I
>> view the `tenant_audit` command to not be an extension, but a core command.
>>
>> While SSE is a novel approach to syncing, as part of developing OP
>> Commands is to experiment and see if SSE works better than pagination. I
>> think it will be based on my experience in implementing both pagination and
>> SSE. If not, then we can fall back to pagination.
>>
>> I think we want the audit command in the core document and I once again
>> fail to see the benefit to an implementer in having it in a separate
>> document.
>>
>> The other tenant commands are a tenant wide version of one of the other
>> commands.
>>
>> In other words "containing everything from the "Tenant Commands"
>> section" is not going to work as an independent document if you dive in and
>> think of what an implementer will need to do.
>>
>> *NOTE:* just because we have specified all this functionality, does not
>> mean that an RP must implement it all. All commands except for
>> tenant_metadata are optional. An RP can pick what it wants to deploy, and
>> can roll out new functionality as needed. For example, an RP may just do
>> `delete` and `unauthorize`.
>>
>> I'm reminded of how OAuth 2.0 got separated into RFC 6749 and RFC 6750
>> and the friction that added. I feel very strongly that this should all be
>> in one document.
>>
>> Karl and I have spent a bunch of time pondering how this works. We have
>> made many changes based on other's feedback that improved the doc. The
>> suggestion to break it apart does NOT improve things.
>>
>> /Dick
>>
>>
>>
>>
>> On Tue, Mar 4, 2025 at 4:11 PM Aaron Parecki <aaron at parecki.com> wrote:
>>
>>> The three work streams would be:
>>>
>>> - OpenID Connect Tenants - defines the "tenant" claim and adds the
>>> claim to ID tokens
>>> - OP Commands - containing most of the first half of the current OP
>>> Commands draft, describing the command request/response, the command
>>> tokens, account lifecycle commands. References the Tenants document for the
>>> tenant claim.
>>> - OP Tenant Management - containing everything from the "Tenant
>>> Commands" section, including defining the SSE streaming API.
>>>
>>> This enables us to standardize the concept of tenants in OpenID Connect
>>> Core, and lets the experimental use of SSE evolve independently of the more
>>> straightforward OP Command Tokens.
>>>
>>> Aaron
>>>
>>>
>>>
>>> On Tue, Mar 4, 2025 at 7:09 AM Michael Jones via Openid-specs-ab <
>>> openid-specs-ab at lists.openid.net> wrote:
>>>
>>>> As a point of clarification, what would these three work streams be?
>>>> As an exercise to make this abundantly clear, would you and/or Aaron
>>>> consider describing them in terms of a proposed document title and abstract
>>>> for each? In particular, the proposed abstract should say what problem is
>>>> being solved by the draft and possibly also describe how it is being solved.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> -- Mike (chair hat on)
>>>>
>>>>
>>>>
>>>> *From:* Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> *On
>>>> Behalf Of *Dean Saxe via Openid-specs-ab
>>>> *Sent:* Tuesday, March 4, 2025 7:02 AM
>>>> *To:* Dick.Hardt at gmail.com; Artifact Binding/Connect Working Group <
>>>> openid-specs-ab at lists.openid.net>
>>>> *Cc:* Dean Saxe <dean.saxe at beyondidentity.com>
>>>> *Subject:* Re: [Openid-specs-ab] Call for Adoption of the OpenID
>>>> Provider Commands Specification
>>>>
>>>>
>>>>
>>>> After spending time talking with Aaron and others about this draft
>>>> during OSW, I support Aaron’s position. There is a lot of good that can
>>>> come from this work. Breaking this into three separate work streams is the
>>>> best path to move forward and ensure robust discussion on each of the
>>>> component parts.
>>>>
>>>>
>>>>
>>>> -dhs
>>>>
>>>> --
>>>>
>>>> Dean H. Saxe, CIDPRO <https://idpro.org/cidpro/> (he/him)
>>>>
>>>> Principal Engineer
>>>>
>>>> Office of the CTO
>>>>
>>>> Beyond Identity
>>>>
>>>> dean.saxe at beyondidentity.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Feb 22, 2025 at 11:06:20 AM, Dick Hardt via Openid-specs-ab <
>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>
>>>> I strongly disagree with you based on the feedback I got on earlier
>>>> drafts that I circulated, and your arguments are not convincing me
>>>> otherwise.
>>>>
>>>> The tenant and audit functionality was not in the earliest drafts. I
>>>> added the tenant and audit functionality based on feedback from early
>>>> reviews.
>>>>
>>>> *tenant*
>>>>
>>>>
>>>>
>>>> While not standardized in OpenID Connect, the tenant concept is
>>>> captured in Microsoft and Google ID Tokens. OpenID has had many years
>>>> to work on standardizing the tenant claim, but has not, and we now have a
>>>> world of bespoke tenant claims. Given that some OPs will require RPs
>>>> to understand tenants, I view the tenant claim as a requirement for OP
>>>> Commands. Additionally, the concept of a tenant needs to be a first class
>>>> concept for all the commands as it provides a context within an issuer. If
>>>> an OpenID Connect Core 1.1 comes along, then it can add it as a claim in
>>>> the ID Token, but let's help interoperability for OP Commands by embracing
>>>> the tenant concept as a first class concept and not try tacking it on
>>>> later.
>>>>
>>>>
>>>>
>>>> *audit*
>>>>
>>>>
>>>>
>>>> While not all RPs will need to support audit some will for either brown
>>>> field, or to ensure the OP and RP are in sync. How to sync was a common
>>>> question on the first draft, and I consider it a required feature in OP
>>>> Commands for many RPs to adopt. RPs that don't need it can ignore that
>>>> section, just as they do with many other specs. Those that do are not
>>>> forced to go look at a different document.
>>>>
>>>>
>>>>
>>>> Similarly, many clients do not need refresh tokens in OAuth 2.0. It was
>>>> a concept that did not exist in OAuth 1.0, but it enabled long lived
>>>> authorization for those that needed it. While refresh tokens could have
>>>> been a different spec, that would have added complexity and confusion.
>>>> Separating OAuth 2.0 into what became RFC 6749 and RFC 6750 was a mistake
>>>> driven by Erin, that I regret not taking the time to reverse before
>>>> publication. We are fixing that in OAuth 2.1, which also incorporates a
>>>> number of other drafts that were created after 2.0.
>>>>
>>>>
>>>>
>>>> *SSE*
>>>>
>>>>
>>>>
>>>> Audit requires sending a large amount of data from the RP to the OP
>>>> when the number of users scales. Sending that as a single response to a
>>>> request becomes impractical at some point. SCIM solved it with pagination,
>>>> and I would argue as an afterthought when someone realized that sending a
>>>> single response would be impractical. Pagination is hard to implement
>>>> at scale because you have to maintain the state of what you have sent so
>>>> far across sessions.
>>>>
>>>>
>>>>
>>>> While SSE may not be what we land on for audit, I think it is much
>>>> simpler for an RP to implement than pagination. The RP can get the data
>>>> however it wants and start writing it to the stream. Session disconnections
>>>> are handled by the libraries transparently at both the server and client.
>>>>
>>>>
>>>>
>>>> I don't expect anyone to be sold yet on SSE being the right choice, but
>>>> having it in the document gives us something to discuss, and makes it clear
>>>> that there are challenges with pagination.
>>>>
>>>>
>>>>
>>>> /Dick
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Feb 21, 2025 at 11:50 PM Aaron Parecki <aaron at parecki.com>
>>>> wrote:
>>>>
>>>> Thanks for the detailed response, this context is helpful.
>>>>
>>>>
>>>>
>>>> I think the fact that you're able to say this much about the tenant
>>>> concept and SSE in this reply speaks a great deal to how these are
>>>> relatively complex topics that warrant their own discussion. I'm not
>>>> comfortable adopting this draft wholesale, because I don't think this draft
>>>> is necessarily the right layer to introduce these concepts to OpenID
>>>> Connect.
>>>>
>>>>
>>>>
>>>> The tenant problem is a great example as you mentioned, since Google
>>>> and Microsoft both have different ways they handle the tenant concept. This
>>>> should ultimately be standardized in OpenID Connect Core so that there is a
>>>> standard way to include the tenant in ID tokens regardless of whether the
>>>> OP is using OP Commands.
>>>>
>>>>
>>>>
>>>> I am still not convinced that SSE is actually an easier alternative to
>>>> pagination compared to what is being done in SCIM. I suspect there are also
>>>> plenty of edge/error cases that will come up with SSE as a syncing
>>>> mechanism that will require their own creative solutions down the road. Yes
>>>> there are currently server-side client libraries of SSE, but they are not
>>>> necessarily being used for data synchronization the way SSE is applied
>>>> here. Plus, as you mentioned, SSE is used for the tenant audit which is for
>>>> brownfield implementations, so it's entirely possible an implementation
>>>> would never need to build this, which suggests this would be better as a
>>>> separate draft as well.
>>>>
>>>>
>>>>
>>>> Yes, having separate drafts can make things more complex for readers in
>>>> the short term. But OAuth 2.1 brings together a carefully selected set of
>>>> drafts from the past 12 years of OAuth. If OAuth had been created all as a
>>>> massive single draft at the beginning, it would be even more of a mess than
>>>> it is today. So I don't think putting these three new concepts into a
>>>> single new OpenID draft is a good path forward.
>>>>
>>>>
>>>>
>>>> Aaron
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Feb 21, 2025 at 1:14 PM Dick Hardt <dick.hardt at gmail.com>
>>>> wrote:
>>>>
>>>> Hey Aaron, thanks for the feedback.
>>>>
>>>>
>>>>
>>>> I think these are important points to discuss, but that I would prefer
>>>> to have the discussion once the WG has decided to adopt the draft so that
>>>> we can capture all the discussion in the repo rather than this list so that
>>>> it is easier for others to find the discussion.
>>>>
>>>> With that being said, and knowing that I will need to copy this content
>>>> into the repo later on, here is why I think we want to keep tenant and SSE
>>>> concepts in the draft:
>>>>
>>>> *tenant*
>>>>
>>>>
>>>> The tenant concept is threaded through all of the draft, not just the
>>>> tenant commands. The "tenant" claim is required in all of the commands.
>>>>
>>>> While the tenant concept has not been standardized in OpenID, Google
>>>> includes a tenant claim "hd" in Google Workspace ID Tokens, and Microsoft
>>>> includes "tid" in their ID Tokens. Microsoft has a unique issuer for each
>>>> tenant, but Google does not. In order for Google to adopt OP Commands, we
>>>> need to provide a standard tenant mechanism, otherwise they will need to
>>>> add a non-standard claim to their commands to communicate with the tenant.
>>>> I would like to keep the barrier to adoption by Google as low as possible,
>>>> and for RP libraries not to have custom code to support Google.
>>>>
>>>>
>>>>
>>>> The tenant commands include the tenant_metadata, the only command that
>>>> an RP MUST implement. The tenant_audit command is needed for brown field
>>>> adoption for the RP to add OP Commands, and an OP to understand the current
>>>> state. IE, the OP needs it to get the starting state when OP Commands are
>>>> enabled. A brand new RP could decide to not support tenant_audit for
>>>> simplicity, but not having tenant_audit would be a barrier for adoption for
>>>> some existing RP / OP deployments.
>>>>
>>>> The other commands are tenant wide versions of the other commands. An
>>>> RP can choose to not support them. I did notice in the OpenID Slack
>>>> wg-sharedsignals that someone wanted to know how to send a signal for a
>>>> tenant, and it was suggested the set the subject to:
>>>>
>>>>
>>>>
>>>> {
>>>>
>>>> "format": "complex",
>>>>
>>>> "tenant": "tenant-whose-users-were-revoked"
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>> I agree that the tenant claim is not OP Commands specific, and that it
>>>> may make sense to have a separate document for it, and If the WG wants to
>>>> specify the tenant claim as a separate document, I'm fine with that, but I
>>>> strongly believe the tenant claim needs to be used in OP Commands, and so
>>>> we should adopt the document as is and then we can decide if we want to
>>>> separate them out or not, as the tenant claim doc would need to exist for
>>>> it to be used by OP Commands.
>>>>
>>>> Per the motivation to create OAuth 2.1, I also think having a large
>>>> number of documents makes it harder for people to grasp everything, so I
>>>> would argue that perhaps OP Commands introduces the tenant claim and gets
>>>> it registered in IANA. Note that OP Commands is also defining the group
>>>> claim, which is currently underspecified.
>>>>
>>>>
>>>>
>>>> *SSE*
>>>>
>>>>
>>>>
>>>> You are correct that using SSE between servers is a non-traditional use
>>>> of SSE, and that client libraries are not as abundant as server libraries
>>>> for SSE. The fact that there are client libraries indicates that there are
>>>> server implementations. Also it is the OP that is the client here, which is
>>>> the party where we want to push complexity, and server libraries are
>>>> readily available for an RP to use.
>>>>
>>>>
>>>>
>>>> I think it adds complexity long term to have more than one way for the
>>>> RP to send a response, and given that SSE is pretty straightforward and
>>>> addresses one of the complexity challenges in SCIM (pagination) we should
>>>> keep it in the draft so that we are forced to address how the RP will send
>>>> a large response back to the OP in an audit. While we might not decide on
>>>> SSE -- we don't want to punt on a mechanism for working at scale.
>>>>
>>>> From an implementation point of view, simple, new RPs don't need SSE if
>>>> they don't need to support any tenant commands other than tenant_metadata,
>>>> which is required.
>>>>
>>>>
>>>>
>>>> /Dick
>>>>
>>>>
>>>>
>>>> On Fri, Feb 21, 2025 at 4:56 PM Aaron Parecki via Openid-specs-ab <
>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>
>>>> I took another look at the draft after the discussion on the last call,
>>>> and I have concerns about the current state of the document and think it
>>>> should be revised before adopting it. I realize changes are possible after
>>>> adoption, but I believe the scope of the current document is too broad, and
>>>> should be narrowed before adoption.
>>>>
>>>>
>>>>
>>>> In general I am supportive of a lighter weight way to achieve most of
>>>> what is described in this draft. I like that the command tokens leverage
>>>> the existing signing key that RPs already use to validate ID tokens. The
>>>> account lifecycle commands are well thought out and I appreciate the state
>>>> transition diagram in the draft.
>>>>
>>>>
>>>>
>>>> However, I have concerns about the Tenant commands as well as the use
>>>> of Server-Sent Events.
>>>>
>>>>
>>>>
>>>> The Tenant commands bring in a new concept that does not exist
>>>> elsewhere in OpenID Connect today. I understand the goal here, but I am not
>>>> convinced this draft is the right place to introduce this concept. This
>>>> would be better off as a separate OpenID Connect extension that extends
>>>> both OpenID Connect Core and OP Commands to add the Tenant concept.
>>>>
>>>>
>>>>
>>>> The use of Server-Sent Events is somewhat unusual here. It technically
>>>> works, but the API is actually defined in HTML as an API to allow a web
>>>> server to stream content to a web browser. I am personally a huge fan of
>>>> SSE as it's easier to deploy in web servers compared to Websockets. Using
>>>> it for server-to-server communications is a somewhat non-traditional
>>>> application of the technology. While it would work, I am concerned that it
>>>> is not the best tool for the job, since there are far fewer server-side SSE
>>>> client libraries since most of the use is where the client is the web
>>>> browser. That said, I am not entirely opposed to using it this way, I just
>>>> worry that bringing it in to the OP Commands draft this early might
>>>> backfire on the other more easily understood patterns in the draft.
>>>>
>>>>
>>>>
>>>> This is all to say that I would support adopting a version of this
>>>> draft that describes only the account lifecycle commands with HTTP delivery
>>>> as described in the first half of the document, and remove the Tenant
>>>> commands and SSE delivery mechanisms.
>>>>
>>>>
>>>>
>>>> Aaron
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Feb 20, 2025 at 1:18 PM Michael Jones via Openid-specs-ab <
>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>
>>>> This starts a two-week call for feedback on whether to adopt the OpenID
>>>> Provider Commands specification contributed to the working group by Dick
>>>> Hardt and Karl McGuiness as an OpenID Connect Working Group specification.
>>>> Please reply-all by Thursday, March 6th saying whether you are favor
>>>> of adoption or not, briefly also saying why.
>>>>
>>>>
>>>>
>>>> You can read more about the decision made on today’s working group call
>>>> to start a call for adoption in the minutes written by John Melati
>>>> <https://lists.openid.net/pipermail/openid-specs-ab/2025-February/010620.html>
>>>> .
>>>>
>>>>
>>>>
>>>> Writing as a working
>>>> group chair,
>>>>
>>>> -- Mike
>>>>
>>>>
>>>>
>>>> *From:* Dick Hardt <dick.hardt at gmail.com>
>>>> *Sent:* Wednesday, January 15, 2025 4:30 AM
>>>> *To:* openid-specs-ab at lists.openid.net
>>>> *Cc:* Karl McGuinness <me at karlmcguinness.com>; Michael Jones <
>>>> michael_b_jones at hotmail.com>; Nat Sakimura <sakimura at gmail.com>; John
>>>> Bradley <ve7jtb at ve7jtb.com>
>>>> *Subject:* OpenID Provider Commands - proposed WG specification
>>>>
>>>>
>>>>
>>>> Hello WG (and chairs)
>>>>
>>>> Karl (cc'ed) and I have been working on a new protocol that complements
>>>> OpenID Connect for an OP to centrally manage account lifecycles at RPs. We
>>>> have also defined an Unauthorize Command which undoes whatever actions an
>>>> RP did in a previous OpenID Connect login -- useful if an OP suspects an
>>>> account or device had been compromised -- instructs an RP to "kill all the
>>>> sessions and tokens"
>>>>
>>>>
>>>>
>>>> We contribute the IP in the attached HTML and Markdown files to the
>>>> OpenID Foundation per the Foundations IPR.
>>>>
>>>>
>>>>
>>>> We have a FAQ as a note at the top, that I am including below for your
>>>> convenience.
>>>>
>>>>
>>>>
>>>> We hope this work is of interest to others in the WG, and that together
>>>> we can improve the security posture of implementers.
>>>>
>>>>
>>>>
>>>> /Dick & Karl
>>>>
>>>> *1. How does SCIM compare to OpenID Provider (OP) Commands?*
>>>>
>>>> The SCIM protocol is a general purpose protocol for a client to manage
>>>> resources at a server. When the SCIM protocol is used between an IdP and an
>>>> RP, the schema is defined by the RP. The resources managed are in the
>>>> context of the RP Tenant in a multi-tenant RP. Any extensions to the schema
>>>> are defined by the RP. This provided an interoperable protocol to manage RP
>>>> resources. OpenID Provider Commands are an extension of a user Account
>>>> created by OpenID Connect. It uses the same identity Claims that the OP
>>>> issues for the user. It uses the same token Claims, and is verified the
>>>> same way. OpenID Provider Commands are issued in the context of the OP
>>>> Tenant in a multi-tenant OP.
>>>>
>>>> *2. How do Shared Signals / RISC compare to OpenID Provider Commands?*
>>>>
>>>> Shared Signals and RISC are events that one party is sharing with
>>>> another party. The actions a receiving party takes upon receiving a signal
>>>> are intentionally not defined. The actions taken by the RP when receiving
>>>> an OpenID Provider Command is specified. This gives an OP control over the
>>>> Account at the RP.
>>>>
>>>> *3. Are OpenID Provider Commands a replacement for SCIM, Shared
>>>> Signals, or RISC?*
>>>>
>>>> No. These standards are deployed by organizations that have complex
>>>> requirements, and these standards meet there needs. Most OP / RPs do not
>>>> deploy any of these standards, as the implementation complexity is not
>>>> warranted. OpenID Provider Commands are designed to build on OpenID
>>>> Connect, allowing RPs using OpenID Connect an easy path to offer OPs a
>>>> standard API for security and lifecycle operations.
>>>>
>>>> *4. Why are there only groups? Why not roles and entitlements?*
>>>>
>>>> OpenID Provider Commands are used to project the Tenant data managed
>>>> centrally by the OP. Groups are a common term used by OPs to manage a
>>>> collection of Accounts. The terms roles and entitlements tend to be RP
>>>> specific. Generally, groups from the OP will be mapped to roles and/or
>>>> entitlements that are RP specific, at the RP.
>>>>
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250305/87b1758a/attachment-0001.htm>
More information about the Openid-specs-ab
mailing list