[Openid-specs-ab] OP Commands - alternative approaches for tenancy and bulk transfer

[Dean Saxe]

 Dick,

I’m confused.  As discussed yesterday in the IPSIE WG we agreed that the
items in https://github.com/openid/ipsie/issues/62 - which includes tenancy
- would best be resolved in AB Connect.  What’s the resistance to handling
those separately in AB Connect instead of tying them up in the provider
commands work?

A simple doc describing the tenancy parameters should be easy to complete
in the WG, supporting both your use case for provide commands and your
desire to have this available for IPSIE SL1.  I don’t see the risk of both
a tenancy doc and the provider commands doc happening in parallel if it
achieves the same outcome.

I’m not looking to pick a fight - on or off list - I simply want to resolve
this in the fastest way possible so we can move on with the work at hand.

-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 Mar 12, 2025 at 2:06:26 PM, Dick Hardt via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> And once again, that is not an option that is acceptable for me, tenancy
> is a requirement for my use case, as is bulk transfer. It is not a matter
> of like, or not like. Therefore it is NOT a legitimate alternative.
>
> Here is my analogy:
>
> I want eggs benedict.
>
> But you want it without hollandaise sauce, and you want bread instead of
> an English muffin, and you want the bread on the side.
>
> That is not eggs benedict -- it is just eggs and toast.
>
>
>
> On Wed, Mar 12, 2025 at 8:45 PM Brian Campbell <bcampbell at pingidentity.com>
> wrote:
>
>> Once again, the alternative I'm suggesting, which is absolutely a
>> legitimate alternative even if you don't like it, is removal of treatment
>> of tenancy and bulk transfer.
>>
>> On Wed, Mar 12, 2025, 1:21 PM Dick Hardt <dick.hardt at gmail.com> wrote:
>>
>>> Once again, per the subject line, we would welcome an alternative
>>> proposal Brian.
>>>
>>> Stating it is not appropriate is an opinion, not a solution.
>>>
>>> On Wed, Mar 12, 2025 at 6:20 PM Brian Campbell <
>>> bcampbell at pingidentity.com> wrote:
>>>
>>>> No one is pretending that multi-tenant OPs don't exist. It's that
>>>> trying to address one narrow aspect of tenancy in an ancillary document is
>>>> inappropriate.
>>>>
>>>> On Wed, Mar 12, 2025 at 9:59 AM Dick Hardt <dick.hardt at gmail.com>
>>>> wrote:
>>>>
>>>>> If you have an alternative approach to enabling multi-tenant OPs to
>>>>> signal which tenant they are acting on behalf of, I would be interested in
>>>>> hearing it.
>>>>>
>>>>> Pretending that multi-tenant OPs don't exist or should not exist is
>>>>> not an option.
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 12, 2025 at 3:52 PM Brian Campbell <
>>>>> bcampbell at pingidentity.com> wrote:
>>>>>
>>>>>> The suggestion has been that tenancy need not and should not be
>>>>>> modeled at all in OP Commands.
>>>>>>
>>>>>> On Fri, Mar 7, 2025 at 4:10 AM Dick Hardt <dick.hardt at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hey
>>>>>>>
>>>>>>> Karl and I are looking forward to rolling up our sleeves and working
>>>>>>> on OP Commands.
>>>>>>>
>>>>>>> While we have modelled OP tenants as a claim with a tenant
>>>>>>> identifier or type of tenant, we know there may be a better model. If
>>>>>>> someone has an idea for a potentially better model, you don't need to write
>>>>>>> up a draft -- you can just write up a clear explanation that we can all
>>>>>>> review and discuss.
>>>>>>>
>>>>>>> I plan on writing up the other options we looked at for sending a
>>>>>>> large response so that we can have a discussion on that topic. I also plan
>>>>>>> on writing a PoC using SSE and will share that here.
>>>>>>>
>>>>>>> /Dick & Karl
>>>>>>>
>>>>>>
>>>>>> *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.*
>>>>>
>>>>>
>>>> *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.*
>>>
>>>
>> *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.*
>
> _______________________________________________
> 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/20250312/5d3e2ae3/attachment.htm>