<div dir="ltr">Here's a crazy idea... maybe we can vote on it?<div><br></div><div>- Mike </div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Mar 6, 2025 at 8:33 AM <<a href="mailto:openid-specs-ab-request@lists.openid.net">openid-specs-ab-request@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send Openid-specs-ab mailing list submissions to<br>
<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:openid-specs-ab-request@lists.openid.net" target="_blank">openid-specs-ab-request@lists.openid.net</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:openid-specs-ab-owner@lists.openid.net" target="_blank">openid-specs-ab-owner@lists.openid.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Openid-specs-ab digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Call for Adoption of the OpenID Provider Commands<br>
Specification (Brian Campbell)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 6 Mar 2025 07:32:28 -0700<br>
From: Brian Campbell <<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>><br>
To: <a href="mailto:Dick.Hardt@gmail.com" target="_blank">Dick.Hardt@gmail.com</a><br>
Cc: "Artifact Binding/Connect Working Group"<br>
<<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>>, Wesley Dunnington<br>
<<a href="mailto:wesleydunnington@pingidentity.com" target="_blank">wesleydunnington@pingidentity.com</a>>, Dean Saxe<br>
<<a href="mailto:dean.saxe@beyondidentity.com" target="_blank">dean.saxe@beyondidentity.com</a>>, Karl McGuinness<br>
<<a href="mailto:me@karlmcguinness.com" target="_blank">me@karlmcguinness.com</a>><br>
Subject: Re: [Openid-specs-ab] Call for Adoption of the OpenID<br>
Provider Commands Specification<br>
Message-ID:<br>
<<a href="mailto:CA%2Bk3eCQgin0Jnvpi31tkxAF1tuc33YF5Nb91skRSDURoNYS0tg@mail.gmail.com" target="_blank">CA+k3eCQgin0Jnvpi31tkxAF1tuc33YF5Nb91skRSDURoNYS0tg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Dick:<br>
<br>
On Wed, Mar 5, 2025 at 1:32?AM Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>> wrote:<br>
<br>
> Brian: I read your email. Did you read my email and Karl's? If so, it's<br>
> disappointing that you could not be bothered to respond to either my points<br>
> or Karl's points. That leads me to believe that you are not interested in<br>
> having a discussion.<br>
><br>
<br>
I did read them. Did not find any of it to be persuasive. And have no<br>
obligation to respond to the many points you or Karl have stated, erroneous<br>
as some might be.<br>
<br>
I am interested in trying to steer this call for adoption to an outcome<br>
that isn't objectionable to myself and at least a few other WG<br>
participates. I understand that you don't like that. But that doesn't<br>
strike me as justification for the style of engagement you've chosen (both<br>
on-list and in private messages) for people who don't agree with you. That<br>
is disappointing. I guess disappointing is one thing we can agree on here.<br>
<br>
<br>
<br>
> Your response reminds me of my early presentations to the IETF. The<br>
> general consensus was that the IETF had protocols that solved identity.<br>
> After being told no 3 times, we took our toys and started the OpenID<br>
> Foundation to do the work.<br>
><br>
<br>
That reminds me of the last time you told that story in a context where it<br>
wasn't really applicable. I trust that was an important moment in the<br>
collective history of this industry. And something you seem to be quite<br>
proud of. But not really germane.<br>
<br>
<br>
<br>
><br>
> I received similar feedback from Erin about what became OAuth 2.0. He did<br>
> not agree with the approach and refused to let it be called OAuth, so we<br>
> called it WRAP. When we presented it at IIW, the community revolted against<br>
> Erin.<br>
><br>
<br>
I think maybe you are recounting select bits of history as some kind of<br>
allegory for your prescience and the ignorance of those who disagreed with<br>
you. My takeaway from history is a bit different. One of my concerns here<br>
is that this will be another initiative in the standards arena that you<br>
start but are unwilling or unable to see through. Sometimes things have<br>
worked out well. Sometimes less so. Maybe this time will be different or<br>
result in one of the better outcomes. But there are definitely implications<br>
and costs borne by the wider industry and community.<br>
<br>
<br>
<br>
><br>
> On Wed, Mar 5, 2025 at 12:01?AM Brian Campbell <<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>><br>
> wrote:<br>
><br>
>> I also generally support Aaron?s position.<br>
>><br>
>> I have pushed back on adopting this work within this working group, in<br>
>> part due to concerns about yet another attempt to solve the same<br>
>> cross-domain account management problem. Introducing it here risks further<br>
>> crowding and confusing the landscape, especially given the implied<br>
>> endorsement and authority of the OIDF.<br>
>><br>
>> The discussions so far haven?t really alleviated those concerns. However,<br>
>> I can understand the reasoning behind providing a simpler way for OPs to<br>
>> manage account lifecycles by leveraging existing OIDC<br>
>> constructs?specifically, using a token signed the same way as an ID token<br>
>> as the authentication and authorization mechanism for these calls.<br>
>><br>
>> That said, the introduction of the tenancy concept and the rather<br>
>> unconventional use of part of the HTML living standard for server-to-server<br>
>> communication stray well beyond the premise of simplicity and leveraging<br>
>> established practices. I strongly object to WG adoption of the draft with<br>
>> those elements included.<br>
>><br>
>> As a side note, SSE was originally the name of the working group<br>
>> responsible for RISC and CAEP before they changed the acronym to avoid<br>
>> conflicts with an analyst category. Using SSE in this context to refer to<br>
>> HTML?s server-sent events (and mistakenly calling it "Server-Side Events"<br>
>> in the link) adds an unnecessary and confusing layer for those familiar<br>
>> with the history of that working group.<br>
>><br>
>><br>
>><br>
>><br>
>> On Tue, Mar 4, 2025 at 8:01?AM Dean Saxe via Openid-specs-ab <<br>
>> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br>
>><br>
>>> After spending time talking with Aaron and others about this draft<br>
>>> during OSW, I support Aaron?s position. There is a lot of good that can<br>
>>> come from this work. Breaking this into three separate work streams is the<br>
>>> best path to move forward and ensure robust discussion on each of the<br>
>>> component parts.<br>
>>><br>
>>> -dhs<br>
>>> --<br>
>>> Dean H. Saxe, CIDPRO <<a href="https://idpro.org/cidpro/" rel="noreferrer" target="_blank">https://idpro.org/cidpro/</a>> (he/him)<br>
>>> Principal Engineer<br>
>>> Office of the CTO<br>
>>> Beyond Identity<br>
>>> <a href="mailto:dean.saxe@beyondidentity.com" target="_blank">dean.saxe@beyondidentity.com</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On Feb 22, 2025 at 11:06:20?AM, Dick Hardt via Openid-specs-ab <<br>
>>> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br>
>>><br>
>>>> I strongly disagree with you based on the feedback I got on earlier<br>
>>>> drafts that I circulated, and your arguments are not convincing me<br>
>>>> otherwise.<br>
>>>><br>
>>>> The tenant and audit functionality was not in the earliest drafts. I<br>
>>>> added the tenant and audit functionality based on feedback from early<br>
>>>> reviews.<br>
>>>><br>
>>>> *tenant*<br>
>>>><br>
>>>> While not standardized in OpenID Connect, the tenant concept is<br>
>>>> captured in Microsoft and Google ID Tokens. OpenID has had many years<br>
>>>> to work on standardizing the tenant claim, but has not, and we now have a<br>
>>>> world of bespoke tenant claims. Given that some OPs will require RPs<br>
>>>> to understand tenants, I view the tenant claim as a requirement for OP<br>
>>>> Commands. Additionally, the concept of a tenant needs to be a first class<br>
>>>> concept for all the commands as it provides a context within an issuer. If<br>
>>>> an OpenID Connect Core 1.1 comes along, then it can add it as a claim in<br>
>>>> the ID Token, but let's help interoperability for OP Commands by embracing<br>
>>>> the tenant concept as a first class concept and not try tacking it on<br>
>>>> later.<br>
>>>><br>
>>>> *audit*<br>
>>>><br>
>>>> While not all RPs will need to support audit some will for either brown<br>
>>>> field, or to ensure the OP and RP are in sync. How to sync was a common<br>
>>>> question on the first draft, and I consider it a required feature in OP<br>
>>>> Commands for many RPs to adopt. RPs that don't need it can ignore that<br>
>>>> section, just as they do with many other specs. Those that do are not<br>
>>>> forced to go look at a different document.<br>
>>>><br>
>>>> Similarly, many clients do not need refresh tokens in OAuth 2.0. It was<br>
>>>> a concept that did not exist in OAuth 1.0, but it enabled long lived<br>
>>>> authorization for those that needed it. While refresh tokens could have<br>
>>>> been a different spec, that would have added complexity and confusion.<br>
>>>> Separating OAuth 2.0 into what became RFC 6749 and RFC 6750 was a mistake<br>
>>>> driven by Erin, that I regret not taking the time to reverse before<br>
>>>> publication. We are fixing that in OAuth 2.1, which also incorporates a<br>
>>>> number of other drafts that were created after 2.0.<br>
>>>><br>
>>>> *SSE*<br>
>>>><br>
>>>> Audit requires sending a large amount of data from the RP to the OP<br>
>>>> when the number of users scales. Sending that as a single response to a<br>
>>>> request becomes impractical at some point. SCIM solved it with pagination,<br>
>>>> and I would argue as an afterthought when someone realized that sending a<br>
>>>> single response would be impractical. Pagination is hard to implement<br>
>>>> at scale because you have to maintain the state of what you have sent so<br>
>>>> far across sessions.<br>
>>>><br>
>>>> While SSE may not be what we land on for audit, I think it is much<br>
>>>> simpler for an RP to implement than pagination. The RP can get the data<br>
>>>> however it wants and start writing it to the stream. Session disconnections<br>
>>>> are handled by the libraries transparently at both the server and client.<br>
>>>><br>
>>>> I don't expect anyone to be sold yet on SSE being the right choice, but<br>
>>>> having it in the document gives us something to discuss, and makes it clear<br>
>>>> that there are challenges with pagination.<br>
>>>><br>
>>>> /Dick<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Fri, Feb 21, 2025 at 11:50?PM Aaron Parecki <<a href="mailto:aaron@parecki.com" target="_blank">aaron@parecki.com</a>><br>
>>>> wrote:<br>
>>>><br>
>>>>> Thanks for the detailed response, this context is helpful.<br>
>>>>><br>
>>>>> I think the fact that you're able to say this much about the tenant<br>
>>>>> concept and SSE in this reply speaks a great deal to how these are<br>
>>>>> relatively complex topics that warrant their own discussion. I'm not<br>
>>>>> comfortable adopting this draft wholesale, because I don't think this draft<br>
>>>>> is necessarily the right layer to introduce these concepts to OpenID<br>
>>>>> Connect.<br>
>>>>><br>
>>>>> The tenant problem is a great example as you mentioned, since Google<br>
>>>>> and Microsoft both have different ways they handle the tenant concept. This<br>
>>>>> should ultimately be standardized in OpenID Connect Core so that there is a<br>
>>>>> standard way to include the tenant in ID tokens regardless of whether the<br>
>>>>> OP is using OP Commands.<br>
>>>>><br>
>>>>> I am still not convinced that SSE is actually an easier alternative to<br>
>>>>> pagination compared to what is being done in SCIM. I suspect there are also<br>
>>>>> plenty of edge/error cases that will come up with SSE as a syncing<br>
>>>>> mechanism that will require their own creative solutions down the road. Yes<br>
>>>>> there are currently server-side client libraries of SSE, but they are not<br>
>>>>> necessarily being used for data synchronization the way SSE is applied<br>
>>>>> here. Plus, as you mentioned, SSE is used for the tenant audit which is for<br>
>>>>> brownfield implementations, so it's entirely possible an implementation<br>
>>>>> would never need to build this, which suggests this would be better as a<br>
>>>>> separate draft as well.<br>
>>>>><br>
>>>>> Yes, having separate drafts can make things more complex for readers<br>
>>>>> in the short term. But OAuth 2.1 brings together a carefully selected set<br>
>>>>> of drafts from the past 12 years of OAuth. If OAuth had been created all as<br>
>>>>> a massive single draft at the beginning, it would be even more of a mess<br>
>>>>> than it is today. So I don't think putting these three new concepts into a<br>
>>>>> single new OpenID draft is a good path forward.<br>
>>>>><br>
>>>>> Aaron<br>
>>>>><br>
>>>>><br>
>>>>> On Fri, Feb 21, 2025 at 1:14?PM Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>><br>
>>>>> wrote:<br>
>>>>><br>
>>>>>> Hey Aaron, thanks for the feedback.<br>
>>>>>><br>
>>>>>> I think these are important points to discuss, but that I would<br>
>>>>>> prefer to have the discussion once the WG has decided to adopt the draft so<br>
>>>>>> that we can capture all the discussion in the repo rather than this list so<br>
>>>>>> that it is easier for others to find the discussion.<br>
>>>>>><br>
>>>>>> With that being said, and knowing that I will need to copy this<br>
>>>>>> content into the repo later on, here is why I think we want to keep tenant<br>
>>>>>> and SSE concepts in the draft:<br>
>>>>>><br>
>>>>>> *tenant*<br>
>>>>>><br>
>>>>>> The tenant concept is threaded through all of the draft, not just the<br>
>>>>>> tenant commands. The "tenant" claim is required in all of the commands.<br>
>>>>>> While the tenant concept has not been standardized in OpenID, Google<br>
>>>>>> includes a tenant claim "hd" in Google Workspace ID Tokens, and Microsoft<br>
>>>>>> includes "tid" in their ID Tokens. Microsoft has a unique issuer for each<br>
>>>>>> tenant, but Google does not. In order for Google to adopt OP Commands, we<br>
>>>>>> need to provide a standard tenant mechanism, otherwise they will need to<br>
>>>>>> add a non-standard claim to their commands to communicate with the tenant.<br>
>>>>>> I would like to keep the barrier to adoption by Google as low as possible,<br>
>>>>>> and for RP libraries not to have custom code to support Google.<br>
>>>>>><br>
>>>>>> The tenant commands include the tenant_metadata, the only command<br>
>>>>>> that an RP MUST implement. The tenant_audit command is needed for brown<br>
>>>>>> field adoption for the RP to add OP Commands, and an OP to understand the<br>
>>>>>> current state. IE, the OP needs it to get the starting state when OP<br>
>>>>>> Commands are enabled. A brand new RP could decide to not support<br>
>>>>>> tenant_audit for simplicity, but not having tenant_audit would be a barrier<br>
>>>>>> for adoption for some existing RP / OP deployments.<br>
>>>>>><br>
>>>>>> The other commands are tenant wide versions of the other commands. An<br>
>>>>>> RP can choose to not support them. I did notice in the OpenID Slack<br>
>>>>>> wg-sharedsignals that someone wanted to know how to send a signal for a<br>
>>>>>> tenant, and it was suggested the set the subject to:<br>
>>>>>><br>
>>>>>><br>
>>>>>> {<br>
>>>>>> "format": "complex",<br>
>>>>>> "tenant": "tenant-whose-users-were-revoked"<br>
>>>>>> }<br>
>>>>>><br>
>>>>>><br>
>>>>>> I agree that the tenant claim is not OP Commands specific, and that<br>
>>>>>> it may make sense to have a separate document for it, and If the WG wants<br>
>>>>>> to specify the tenant claim as a separate document, I'm fine with that, but<br>
>>>>>> I strongly believe the tenant claim needs to be used in OP Commands, and so<br>
>>>>>> we should adopt the document as is and then we can decide if we want to<br>
>>>>>> separate them out or not, as the tenant claim doc would need to exist for<br>
>>>>>> it to be used by OP Commands.<br>
>>>>>><br>
>>>>>> Per the motivation to create OAuth 2.1, I also think having a large<br>
>>>>>> number of documents makes it harder for people to grasp everything, so I<br>
>>>>>> would argue that perhaps OP Commands introduces the tenant claim and gets<br>
>>>>>> it registered in IANA. Note that OP Commands is also defining the group<br>
>>>>>> claim, which is currently underspecified.<br>
>>>>>><br>
>>>>>> *SSE*<br>
>>>>>><br>
>>>>>> You are correct that using SSE between servers is a non-traditional<br>
>>>>>> use of SSE, and that client libraries are not as abundant as server<br>
>>>>>> libraries for SSE. The fact that there are client libraries indicates that<br>
>>>>>> there are server implementations. Also it is the OP that is the client<br>
>>>>>> here, which is the party where we want to push complexity, and server<br>
>>>>>> libraries are readily available for an RP to use.<br>
>>>>>><br>
>>>>>> I think it adds complexity long term to have more than one way for<br>
>>>>>> the RP to send a response, and given that SSE is pretty straightforward and<br>
>>>>>> addresses one of the complexity challenges in SCIM (pagination) we should<br>
>>>>>> keep it in the draft so that we are forced to address how the RP will send<br>
>>>>>> a large response back to the OP in an audit. While we might not decide on<br>
>>>>>> SSE -- we don't want to punt on a mechanism for working at scale.<br>
>>>>>><br>
>>>>>> From an implementation point of view, simple, new RPs don't need SSE<br>
>>>>>> if they don't need to support any tenant commands other than<br>
>>>>>> tenant_metadata, which is required.<br>
>>>>>><br>
>>>>>> /Dick<br>
>>>>>><br>
>>>>>> On Fri, Feb 21, 2025 at 4:56?PM Aaron Parecki via Openid-specs-ab <<br>
>>>>>> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br>
>>>>>><br>
>>>>>>> I took another look at the draft after the discussion on the last<br>
>>>>>>> call, and I have concerns about the current state of the document and think<br>
>>>>>>> it should be revised before adopting it. I realize changes are possible<br>
>>>>>>> after adoption, but I believe the scope of the current document is too<br>
>>>>>>> broad, and should be narrowed before adoption.<br>
>>>>>>><br>
>>>>>>> In general I am supportive of a lighter weight way to achieve most<br>
>>>>>>> of what is described in this draft. I like that the command tokens leverage<br>
>>>>>>> the existing signing key that RPs already use to validate ID tokens. The<br>
>>>>>>> account lifecycle commands are well thought out and I appreciate the state<br>
>>>>>>> transition diagram in the draft.<br>
>>>>>>><br>
>>>>>>> However, I have concerns about the Tenant commands as well as the<br>
>>>>>>> use of Server-Sent Events.<br>
>>>>>>><br>
>>>>>>> The Tenant commands bring in a new concept that does not exist<br>
>>>>>>> elsewhere in OpenID Connect today. I understand the goal here, but I am not<br>
>>>>>>> convinced this draft is the right place to introduce this concept. This<br>
>>>>>>> would be better off as a separate OpenID Connect extension that extends<br>
>>>>>>> both OpenID Connect Core and OP Commands to add the Tenant concept.<br>
>>>>>>><br>
>>>>>>> The use of Server-Sent Events is somewhat unusual here. It<br>
>>>>>>> technically works, but the API is actually defined in HTML as an API to<br>
>>>>>>> allow a web server to stream content to a web browser. I am personally a<br>
>>>>>>> huge fan of SSE as it's easier to deploy in web servers compared to<br>
>>>>>>> Websockets. Using it for server-to-server communications is a somewhat<br>
>>>>>>> non-traditional application of the technology. While it would work, I am<br>
>>>>>>> concerned that it is not the best tool for the job, since there are far<br>
>>>>>>> fewer server-side SSE client libraries since most of the use is where the<br>
>>>>>>> client is the web browser. That said, I am not entirely opposed to using it<br>
>>>>>>> this way, I just worry that bringing it in to the OP Commands draft this<br>
>>>>>>> early might backfire on the other more easily understood patterns in the<br>
>>>>>>> draft.<br>
>>>>>>><br>
>>>>>>> This is all to say that I would support adopting a version of this<br>
>>>>>>> draft that describes only the account lifecycle commands with HTTP delivery<br>
>>>>>>> as described in the first half of the document, and remove the Tenant<br>
>>>>>>> commands and SSE delivery mechanisms.<br>
>>>>>>><br>
>>>>>>> Aaron<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> On Thu, Feb 20, 2025 at 1:18?PM Michael Jones via Openid-specs-ab <<br>
>>>>>>> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br>
>>>>>>><br>
>>>>>>>> This starts a two-week call for feedback on whether to adopt the<br>
>>>>>>>> OpenID Provider Commands specification contributed to the working group by<br>
>>>>>>>> Dick Hardt and Karl McGuiness as an OpenID Connect Working Group<br>
>>>>>>>> specification. Please reply-all by Thursday, March 6th saying<br>
>>>>>>>> whether you are favor of adoption or not, briefly also saying why.<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> You can read more about the decision made on today?s working group<br>
>>>>>>>> call to start a call for adoption in the minutes written by John<br>
>>>>>>>> Melati<br>
>>>>>>>> <<a href="https://lists.openid.net/pipermail/openid-specs-ab/2025-February/010620.html" rel="noreferrer" target="_blank">https://lists.openid.net/pipermail/openid-specs-ab/2025-February/010620.html</a>><br>
>>>>>>>> .<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> Writing as a<br>
>>>>>>>> working group chair,<br>
>>>>>>>><br>
>>>>>>>> --<br>
>>>>>>>> Mike<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> *From:* Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>><br>
>>>>>>>> *Sent:* Wednesday, January 15, 2025 4:30 AM<br>
>>>>>>>> *To:* <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
>>>>>>>> *Cc:* Karl McGuinness <<a href="mailto:me@karlmcguinness.com" target="_blank">me@karlmcguinness.com</a>>; Michael Jones <<br>
>>>>>>>> <a href="mailto:michael_b_jones@hotmail.com" target="_blank">michael_b_jones@hotmail.com</a>>; Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>>;<br>
>>>>>>>> John Bradley <<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>><br>
>>>>>>>> *Subject:* OpenID Provider Commands - proposed WG specification<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> Hello WG (and chairs)<br>
>>>>>>>><br>
>>>>>>>> Karl (cc'ed) and I have been working on a new protocol that<br>
>>>>>>>> complements OpenID Connect for an OP to centrally manage account lifecycles<br>
>>>>>>>> at RPs. We have also defined an Unauthorize Command which undoes whatever<br>
>>>>>>>> actions an RP did in a previous OpenID Connect login -- useful if an OP<br>
>>>>>>>> suspects an account or device had been compromised -- instructs an RP to<br>
>>>>>>>> "kill all the sessions and tokens"<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> We contribute the IP in the attached HTML and Markdown files to the<br>
>>>>>>>> OpenID Foundation per the Foundations IPR.<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> We have a FAQ as a note at the top, that I am including below for<br>
>>>>>>>> your convenience.<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> We hope this work is of interest to others in the WG, and that<br>
>>>>>>>> together we can improve the security posture of implementers.<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> /Dick & Karl<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> *1. How does SCIM compare to OpenID Provider (OP) Commands?*<br>
>>>>>>>><br>
>>>>>>>> The SCIM protocol is a general purpose protocol for a client to<br>
>>>>>>>> manage resources at a server. When the SCIM protocol is used between an IdP<br>
>>>>>>>> and an RP, the schema is defined by the RP. The resources managed are in<br>
>>>>>>>> the context of the RP Tenant in a multi-tenant RP. Any extensions to the<br>
>>>>>>>> schema are defined by the RP. This provided an interoperable protocol to<br>
>>>>>>>> manage RP resources. OpenID Provider Commands are an extension of a user<br>
>>>>>>>> Account created by OpenID Connect. It uses the same identity Claims that<br>
>>>>>>>> the OP issues for the user. It uses the same token Claims, and is verified<br>
>>>>>>>> the same way. OpenID Provider Commands are issued in the context of the OP<br>
>>>>>>>> Tenant in a multi-tenant OP.<br>
>>>>>>>><br>
>>>>>>>> *2. How do Shared Signals / RISC compare to OpenID Provider<br>
>>>>>>>> Commands?*<br>
>>>>>>>><br>
>>>>>>>> Shared Signals and RISC are events that one party is sharing with<br>
>>>>>>>> another party. The actions a receiving party takes upon receiving a signal<br>
>>>>>>>> are intentionally not defined. The actions taken by the RP when receiving<br>
>>>>>>>> an OpenID Provider Command is specified. This gives an OP control over the<br>
>>>>>>>> Account at the RP.<br>
>>>>>>>><br>
>>>>>>>> *3. Are OpenID Provider Commands a replacement for SCIM, Shared<br>
>>>>>>>> Signals, or RISC?*<br>
>>>>>>>><br>
>>>>>>>> No. These standards are deployed by organizations that have complex<br>
>>>>>>>> requirements, and these standards meet there needs. Most OP / RPs do not<br>
>>>>>>>> deploy any of these standards, as the implementation complexity is not<br>
>>>>>>>> warranted. OpenID Provider Commands are designed to build on OpenID<br>
>>>>>>>> Connect, allowing RPs using OpenID Connect an easy path to offer OPs a<br>
>>>>>>>> standard API for security and lifecycle operations.<br>
>>>>>>>><br>
>>>>>>>> *4. Why are there only groups? Why not roles and entitlements?*<br>
>>>>>>>><br>
>>>>>>>> OpenID Provider Commands are used to project the Tenant data<br>
>>>>>>>> managed centrally by the OP. Groups are a common term used by OPs to manage<br>
>>>>>>>> a collection of Accounts. The terms roles and entitlements tend to be RP<br>
>>>>>>>> specific. Generally, groups from the OP will be mapped to roles and/or<br>
>>>>>>>> entitlements that are RP specific, at the RP.<br>
>>>>>>>> _______________________________________________<br>
>>>>>>>> Openid-specs-ab mailing list<br>
>>>>>>>> <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
>>>>>>>> <a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
>>>>>>>><br>
>>>>>>> _______________________________________________<br>
>>>>>><br>
>>>>>><br>
>>>><br>
<br>
-- <br>
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged <br>
material for the sole use of the intended recipient(s). Any review, use, <br>
distribution or disclosure by others is strictly prohibited.? If you have <br>
received this communication in error, please notify the sender immediately <br>
by e-mail and delete the message and any file attachments from your <br>
computer. Thank you._<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250306/48ccefbf/attachment.htm" rel="noreferrer" target="_blank">http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250306/48ccefbf/attachment.htm</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Openid-specs-ab Digest, Vol 717, Issue 20<br>
************************************************<br>
</blockquote></div>
<br>
<div></div><div></div><div><font size="1"><img src="https://github.com/GluuFederation/docs-gluu-server-prod/blob/master/docs/source/small_logo.png?raw=true"><br></font></div><div><hr></div><div><font size="1"><b style="color:rgb(128,128,128);font-family:"Sans Serif"">CONFIDENTIALITY NOTICE</b><br></font></div><font face="Sans Serif" color="#808080" size="1">This message may contain confidential or legally privileged information.<br>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.<br>Thank you for your cooperation</font><br>