<div dir="ltr">Dick, <div><br></div><div>I think I got it now... once I realized the RP needed an Internet facing endpoint, it made more sense. I like the use of JWTs to send the commands, that does solve one of the big problems with SCIM interoperability where they say the endpoint is "OAuth protected" ... but not a whole lot more. This use of JWT tokens for authorization fits perfectly in my view of "Token Based Access Control" ("TBAC"). That's exactly what I've been saying about how our old models for RBAC, ReBAC and ABAC are too human centric. This domain-to-domain communication wouldn't fit in any of the older access control mechanisms. <div><br></div><div>Honestly, my conversion of the non-human-readable version of your draft (by ChatGPT) left out some important info. Since you published the human-readable version, it makes a lot more sense :-) I was previously thinking that the RP could be a mobile app or browser based app, which is clearly not the case in your design, which seems targeted at organization-to-organization communication (dare I say "federation"?). </div><div><br></div><div>I thought Aaron had some interesting comments... I have to think more about what he said. But net-net, I like the direction this is going. For the thousands of B2B services out there, this could be a good thing. </div><div><div><br></div><div>- Mike</div><div><br></div><div>PS: Looking forward to discussing this topic with you and Karl on Identerati Office Hours Livestream, Episode 99, Thursday 3/27/2025 10:00 PST, see <a href="https://gluu.co/ioh-99">https://gluu.co/ioh-99</a> It should be a good warm up for IIW. </div></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, Mar 2, 2025 at 5:59 AM Dick Hardt <<a href="mailto:dick.hardt@gmail.com">dick.hardt@gmail.com</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"><div dir="ltr"><div dir="ltr">Hi Michael, I just saw this email, sorry for the delayed response ...</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 17, 2025 at 9:12 PM Michael Schwartz via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@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"><div dir="ltr"><div>Dick, </div><div><br></div><div>1. I don't really see the relationship between SCIM and SAML. Gluu customers use SCIM to update all kinds of account information. Whether they use SAML or OpenID depends on the RP. But I agree that more RPs support SAML in B2B websites... it just seems like a non-sequitur. </div></div></blockquote><div><br></div><div>SCIM does provisioning & OP Commands does provisioning. </div><div>SCIM is a way to manage a resource. The users and groups are independent, though often related, to SSO. </div><div><br></div><div>OP Commands allows an OP to manage accounts from the OP at an RP.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>2. You could in fact make a SCIM extension to send this kind of information. For example, Gluu defined a FIDO SCIM extension because there was no way to get a list of passkeys for a user, or to delete a user's lost key. </div></div></blockquote><div><br> SCIM is based on the resource vs the OP data model</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>3. Are you intending to specify that the RP will expose a non-SCIM stable Internet facing backchannel web URL endpoint? </div></div></blockquote><div><br></div><div>Yes<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>4. How would you protect this endpoint? SCIM left security out of scope. And thus SCIM client libraries might or might not work, depending on how they handle "OAuth" security.</div></div></blockquote><div><br>This is one of the key advantages of OP Commands over SCIM. The commands are signed the same way that an ID Token is signed. IE reuses the existing JWKS endpoint. Does not need to use the same key as the ID Token, but public key is found same way by following `iss` value<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>5. So your solution does not want to support mobile or browser based clients? </div></div></blockquote><div><br>If there is a userpool, it is in a server.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>6. Per my <a href="https://www.linkedin.com/posts/nynymike_token-status-list-activity-7295937395122655233-F7Rs?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAArUy4Bb5Ha4b5n1mmyBhevew7nxXkSV14" target="_blank">post</a> on Linkedin, I still think a pull based solution (i.e. based on OAuth Status List) would be more lightweight. If you "push" messages, you will need an RP endpoint or a long lived connection. Your spec could accomplish all its goals by publishing a new kind of "Account JWT", and enabling the RP to check the status of the JWT to see if anything changed. The advantage of this is that the RP can get an update for **all** account tokens issued by an OP at one time. Plus the status token is very small. Once the RP is aware of the change, then it can interact with the OP, perhaps through an authorization request to get updated userinfo. Also, no need to deal with how to protect this very sensitive RP endpoint. One more thought... if Google has a billion users, as an RP do I really need to know about all the accounts that got compromised, even if they logged into my system only once in the past? I'd rather just check the account status when I see the person again.</div></div></blockquote><div><br>I think that is significantly more complicated. :)<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>So I'm agreeing with your idea, just not with your approach on how to solve it :-) </div><div><br></div><div>- Mike </div><div><br></div><div>--------------------------------------<br>Michael Schwartz<br>Gluu<br>Founder/CEO<br><a href="mailto:mike@gluu.org" target="_blank">mike@gluu.org</a><br><a href="https://www.linkedin.com/in/nynymike" target="_blank">https://www.linkedin.com/in/nynymike</a></div><div dir="ltr" class="gmail_signature"><div dir="ltr"></div></div></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>_______________________________________________<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>
</blockquote></div></div>
</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>