[Openid-specs-ab] Openid-specs-ab Digest, Vol 717, Issue 20
Michael Schwartz
mike at gluu.org
Thu Mar 6 14:59:07 UTC 2025
Here's a crazy idea... maybe we can vote on it?
- Mike
On Thu, Mar 6, 2025 at 8:33 AM <openid-specs-ab-request at lists.openid.net>
wrote:
> Send Openid-specs-ab mailing list submissions to
> openid-specs-ab at lists.openid.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
> or, via email, send a message with subject or body 'help' to
> openid-specs-ab-request at lists.openid.net
>
> You can reach the person managing the list at
> openid-specs-ab-owner at lists.openid.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Openid-specs-ab digest..."
>
>
> Today's Topics:
>
> 1. Re: Call for Adoption of the OpenID Provider Commands
> Specification (Brian Campbell)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 6 Mar 2025 07:32:28 -0700
> From: Brian Campbell <bcampbell at pingidentity.com>
> To: Dick.Hardt at gmail.com
> Cc: "Artifact Binding/Connect Working Group"
> <openid-specs-ab at lists.openid.net>, Wesley Dunnington
> <wesleydunnington at pingidentity.com>, Dean Saxe
> <dean.saxe at beyondidentity.com>, Karl McGuinness
> <me at karlmcguinness.com>
> Subject: Re: [Openid-specs-ab] Call for Adoption of the OpenID
> Provider Commands Specification
> Message-ID:
> <
> CA+k3eCQgin0Jnvpi31tkxAF1tuc33YF5Nb91skRSDURoNYS0tg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Dick:
>
> On Wed, Mar 5, 2025 at 1:32?AM Dick Hardt <dick.hardt at gmail.com> wrote:
>
> > Brian: I read your email. Did you read my email and Karl's? If so, it's
> > disappointing that you could not be bothered to respond to either my
> points
> > or Karl's points. That leads me to believe that you are not interested in
> > having a discussion.
> >
>
> I did read them. Did not find any of it to be persuasive. And have no
> obligation to respond to the many points you or Karl have stated, erroneous
> as some might be.
>
> I am interested in trying to steer this call for adoption to an outcome
> that isn't objectionable to myself and at least a few other WG
> participates. I understand that you don't like that. But that doesn't
> strike me as justification for the style of engagement you've chosen (both
> on-list and in private messages) for people who don't agree with you. That
> is disappointing. I guess disappointing is one thing we can agree on here.
>
>
>
> > Your response reminds me of my early presentations to the IETF. The
> > general consensus was that the IETF had protocols that solved identity.
> > After being told no 3 times, we took our toys and started the OpenID
> > Foundation to do the work.
> >
>
> That reminds me of the last time you told that story in a context where it
> wasn't really applicable. I trust that was an important moment in the
> collective history of this industry. And something you seem to be quite
> proud of. But not really germane.
>
>
>
> >
> > I received similar feedback from Erin about what became OAuth 2.0. He did
> > not agree with the approach and refused to let it be called OAuth, so we
> > called it WRAP. When we presented it at IIW, the community revolted
> against
> > Erin.
> >
>
> I think maybe you are recounting select bits of history as some kind of
> allegory for your prescience and the ignorance of those who disagreed with
> you. My takeaway from history is a bit different. One of my concerns here
> is that this will be another initiative in the standards arena that you
> start but are unwilling or unable to see through. Sometimes things have
> worked out well. Sometimes less so. Maybe this time will be different or
> result in one of the better outcomes. But there are definitely implications
> and costs borne by the wider industry and community.
>
>
>
> >
> > On Wed, Mar 5, 2025 at 12:01?AM Brian Campbell <
> bcampbell at pingidentity.com>
> > wrote:
> >
> >> I also generally support Aaron?s position.
> >>
> >> I have pushed back on adopting this work within this working group, in
> >> part due to concerns about yet another attempt to solve the same
> >> cross-domain account management problem. Introducing it here risks
> further
> >> crowding and confusing the landscape, especially given the implied
> >> endorsement and authority of the OIDF.
> >>
> >> The discussions so far haven?t really alleviated those concerns.
> However,
> >> I can understand the reasoning behind providing a simpler way for OPs to
> >> manage account lifecycles by leveraging existing OIDC
> >> constructs?specifically, using a token signed the same way as an ID
> token
> >> as the authentication and authorization mechanism for these calls.
> >>
> >> That said, the introduction of the tenancy concept and the rather
> >> unconventional use of part of the HTML living standard for
> server-to-server
> >> communication stray well beyond the premise of simplicity and leveraging
> >> established practices. I strongly object to WG adoption of the draft
> with
> >> those elements included.
> >>
> >> As a side note, SSE was originally the name of the working group
> >> responsible for RISC and CAEP before they changed the acronym to avoid
> >> conflicts with an analyst category. Using SSE in this context to refer
> to
> >> HTML?s server-sent events (and mistakenly calling it "Server-Side
> Events"
> >> in the link) adds an unnecessary and confusing layer for those familiar
> >> with the history of that working group.
> >>
> >>
> >>
> >>
> >> On Tue, Mar 4, 2025 at 8:01?AM Dean Saxe via Openid-specs-ab <
> >> openid-specs-ab at lists.openid.net> wrote:
> >>
> >>> 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
> >>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>
> >>>>>>
> >>>>
>
> --
> _CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged
> material for the sole use of the intended recipient(s). Any review, use,
> distribution or disclosure by others is strictly prohibited.? If you have
> received this communication in error, please notify the sender immediately
> by e-mail and delete the message and any file attachments from your
> computer. Thank you._
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250306/48ccefbf/attachment.htm
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
> ------------------------------
>
> End of Openid-specs-ab Digest, Vol 717, Issue 20
> ************************************************
>
--
*CONFIDENTIALITY NOTICE*
This message may contain confidential or
legally privileged information.
If you are not the intended recipient,
please immediately advise the sender by reply e-mail that you received this
message, and delete this e-mail from your system.
Thank you for your
cooperation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250306/2b7c44ab/attachment-0001.htm>
More information about the Openid-specs-ab
mailing list