Re: [Id-event] Subject Principals and Subject Principal Administrative Groupings

[Dick Hardt <[e-mail]>]

Well ... that was not quite what I was saying :) ... but it is another
question to ask. I would lean towards it being a subject modifier (a
property of the subject object) rather than somewhere else.

On Tue, Jul 14, 2020 at 9:25 AM Mike Jones <[e-mail]>
wrote:

> I agree with Dick that a key question is whether the SPAG belongs in the
> event or in the subject identifier.
>
>
>
> Note that this specification could still define a SPAG for inclusion in
> SET events, even though its primary purpose is defining subject identifiers
> for use in SETs.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Dick Hardt <[e-mail]>
> *Sent:* Tuesday, July 14, 2020 8:56 AM
> *To:* Atul Tulshibagwale <[e-mail]>
> *Cc:* Mike Jones <[e-mail]>om>; SecEvent <
> [e-mail]>
> *Subject:* Re: [Id-event] Subject Principals and Subject Principal
> Administrative Groupings
>
>
>
> Hi Atul
>
>
>
> If the SPAG has value in the event message, then it should be specified.
>
>
>
> I was proposing that the SPAG be determined at the transport layer rather
> then the event/message layer.
>
>
>
> An advantage of being in the event is that it is independent of transport.
> In a multi-tenant situation, where different components do different parts
> of the processing, and the original transport is no longer available, the
> SPAG would be always available rather than wrapping the event to include
> the SPAG.
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Jul 14, 2020 at 7:55 AM Atul Tulshibagwale <[e-mail]>
> wrote:
>
> A few points / responses:
>
>    1. Agree with Mike that spag_id should not be a required claim unless
>    it's actually required for every subject. So keeping it optional (if we
>    decide to have it at all) is the right thing to do.
>    2. IMO it will be far simpler for multi-tenanted hosts to use SPAGs
>    rather than manage multiple event streams (i.e. one per tenant)
>    3. A multi-tenanted architecture is increasingly very common, so this
>    will apply to a large number of organizations.
>    4. For single tenanted transmitters, the SPAG id may be inferred by
>    receivers. Single tenanted receivers may ignore the SPAG ids in the
>    subjects. So processing SPAGs in hybrid situations does not appear to be
>    cumbersome.
>    5. The use of SPAGs is not limited to tenant-level information, since
>    it may be applied to OUs or groups
>    6. If we agree that SPAG is a "meta concept" that applies in most
>    situations, then capturing it in the spec is probably important. What Dick
>    is proposing is a way to implement SPAGs without specifying them in a
>    standard, so each entity is free to define it the way they want. This
>    approach can cause incompatibilities.
>    7. Without SPAGs in the spec, if peers need to send events about
>    SPAGs, then they need to use the "iss-sub" catch all to send events about
>    enabling or disabling events about SPAGs. Since this is not standardized,
>    it could also cause proprietary and incompatible implementations.
>
> Atul
>
>
>
> On Mon, Jul 13, 2020 at 5:23 PM Mike Jones <[e-mail]>
> wrote:
>
> As I see it, the use cases that require a spag_id can use them when
> necessary (unless the working group decides on another way to do this) but
> I certainly would oppose requiring it when it’s unnecessary.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Id-event <[e-mail]> *On Behalf Of *Dick Hardt
> *Sent:* Monday, July 13, 2020 5:13 PM
> *To:* Atul Tulshibagwale <[e-mail]>
> *Cc:* SecEvent <[e-mail]>
> *Subject:* Re: [Id-event] Subject Principals and Subject Principal
> Administrative Groupings
>
>
>
> Would different URLs for each relationship not solve your issue of
> maintaining secrets for each SPAG? For example:
>
>
>
> https:/example.com/secevent/SPAG_ID_1
>
>
>
> https:/example.com/secevent/SPAG_ID_2
>
>
>
> https:/example.com/secevent/SPAG_ID_3
>
>
>
> Then the credential is independent of the SPAG, but we are not injecting
> an identifier (spag_id) that is only relevant to orgs that want to use the
> same credentials across SPAG relationships.
>
>
>
>
>
>
>
> On Mon, Jul 13, 2020 at 5:08 PM Atul Tulshibagwale <[e-mail]>
> wrote:
>
> I am OK with making the spag_id a required claim in every subject
> identifier. For single tenanted transmitters, it would be a constant value
> for all events they generate.
>
>
>
> On Mon, Jul 13, 2020 at 4:01 PM Dick Hardt <[e-mail]> wrote:
>
> So the receiver is using authentication sometimes to determine SPAG, and
> not at other times?
>
>
>
> I'm digging into this as I had always thought of the event being between
> two parties, where they are identified by the endpoint and/or the
> credentials.
>
>
>
> Adding a relationship identifier seems to be solving the problem at the
> wrong layer, unless it is in all events.
>
>
>
>
>
> On Mon, Jul 13, 2020 at 3:54 PM Atul Tulshibagwale <[e-mail]>
> wrote:
>
> Sorry for the terse message.
>
>
>
> If a single tenant transmitter is trusted by a multi-tenanted receiver for
> a specific tenant, then the SPAG-id need not be included if the subject is
> unique at the tenant level, because the receiver will automatically
> identify SPAG that the subject belongs to on its end (based on the
> authentication).
>
>
>
>
>
>
>
> On Mon, Jul 13, 2020 at 3:37 PM Dick Hardt <[e-mail]> wrote:
>
> Which part is not required?
>
>
>
> On Mon, Jul 13, 2020 at 3:33 PM Atul Tulshibagwale <[e-mail]>
> wrote:
>
> Not required, since the claim is optional.
>
>
>
> On Mon, Jul 13, 2020 at 3:25 PM Dick Hardt <[e-mail]> wrote:
>
> Would a transmitter that is only in one SPAG (a single tenant system) have
> to include its SPAG id in events sent to a receiver that accepts events
> from multiple SPAGs? But it would not include it in sending events to other
> receivers that have separate credentials for each relationship?
>
>
>
>
>
>
>
> ᐧ
>
>
>
> On Mon, Jul 13, 2020 at 3:05 PM Atul Tulshibagwale <[e-mail]>
> wrote:
>
> That could be true but there are a few ways in which it can be avoided:
>
>    1. The peers leverage some higher-level trust to accept / decline
>    events relating to lower level SPAGs. For example, if trust is established
>    at a tenant level, then an OU level SPAG need not have its own
>    authorization.
>    2. The secret required for establishing the authorization of a SPAG
>    may be temporary. For example:
>
>
>    1. An administrator signs in to their tenant in the transmitter's
>       administrator console
>       2. The admin obtains a temporary authorization (one-time code)
>       3. The admin signs in to their tenant in the receiver's
>       administration console and pastes in the one-time code
>       4. The receiver sends a request to enable the stream for the
>       specified SPAG with that one-time authorization.
>
> In the first case, there are no additional secrets required. In the second
> case, the secret is temporary.
>
>
>
>
>
>
>
> On Mon, Jul 13, 2020 at 2:34 PM Dick Hardt <[e-mail]> wrote:
>
> I see the SPAG lets the transmitter and receiver provide context, as the
> subject identifier may be the same across SPAGs.
>
>
>
> Now I'm trying to understand how the transmitter authenticates to the
> receiver if it does not have it's own secret (assuming that authentication
> model) -- IE, how does the receiver know the transmitter is authorized for
> that SPAG?
>
>
>
>
>
> On Mon, Jul 13, 2020 at 2:08 PM Atul Tulshibagwale <[e-mail]>
> wrote:
>
> Dick, your understanding is correct.
>
>
>
> To clarify the proposal here, Here's the text I'm proposing to be added:
>
>
> 3.  Subject Principals
>
>    Subject Principals are the management entities associated with
>    Subjects.  These may be human or robotic principals or devices or
>    other entities that are managed by transmitters and receivers.  For
>    example, the same Subject Principal may be referred to by an email
>    address or a phone number.  A transmitter or receiver will typically
>    manage subject principals and organize them into sub-groupings such
>    as tenants, groups, organizational units, etc.
>
>    Subjects are identified by Subject Identifiers defined below.
>
> 3.1.  SPAGs
>
>    Subject Principals MAY be grouped for administrative purposes into
>    "Subject Principal Administrative Groupings" or SPAGs.  For example,
>    all users belonging to one customer of a "multi-tenanted" Transmitter
>    may be in one SPAG.  Alternatively, an Organizational Unit or a group
>    of Subjects within a customer of a Transmitter (whether multi-
>    tenanted or not) may be one SPAG.  SPAGs may have overlapping sets of
>    Subjects.
>
>    A SPAG MAY be the Subject of certain stream update events defined
>    later in this spec, hence is defined as a Subject Type of its own
>    below..  A SPAG identifier MAY be included in other subject types to
>    disambiguate the subject.
>
>    A SPAG subject identifier is agreed to offline between a transmitter
>    and a receiver.
>
> The benefits of doing this are:
>
>    1. Multi-tenanted hosts do not need to maintain secrets per tenant and
>    per transmitter tenant if each tenant has to be an event transmitter and an
>    event receiver of its own.
>    2. An event stream may be established between two multi-tenanted
>    hosts, and so does not need to be managed at a per-tenant level
>    3. The same subject or subject principal may be a part of multiple
>    SPAGs, and identifying the SPAG that an event relates to can be achieved if
>    the standard allows for the SPAGs to be identified.
>
>
>
>
>
> On Mon, Jul 13, 2020 at 11:32 AM Dick Hardt <[e-mail]> wrote:
>
> To clarify, your proposal is driven by the implementation burden of
> maintaining separate secrets / streams between a transmitter and receiver?
>
> ᐧ
>
>
>
> On Mon, Jul 13, 2020 at 9:01 AM Atul Tulshibagwale <atultulshi=
> [e-mail] <40google.com@dmarc..ietf.org>> wrote:
>
> Hi all,
>
> Here's a quick background for the proposal
> <https://github.com/richanna/secevent/pull/1> for including Subject
> Principals and Subject Principal Administrative Groupings or SPAGs in the
> Subject Identifiers spec.
>
>
>
> *Use of Subject Identifiers in Shared Signals and Events*:
>
> The Shared Signals and Events (SSE) profile of SETs specifies that
> transmitters and receivers send and receive SETs that contain Subject
> Identifiers. These subject identifiers have the format that is now being
> discussed as a separate specification here.
>
>
>
> *Transmitters and Receivers in SSE*
>
> The SSE profile defines transmitters and receivers as hosts that manage
> streams between peers. The receiver authenticates to the transmitter using
> OAuth, requiring the use of a secret per receiver. In a multi-tenanted host
> that handles hundreds of thousands or millions of independent tenants,
> maintaining such a secret per instance of a receiver is cumbersome.
> Furthermore, since a transmitter and a receiver has to maintain a stream
> per pair, creating such per-tenant streams can add significant
> implementation overhead.
>
>
>
> *SPAGs*
>
> Therefore, we need a notion of a grouping of subjects within the same
> transmitter and receiver to distinguish between various administrative
> groupings that exist within a host. These groupings could include tenants,
> organizational units or user groups.. This grouping is captured in the
> notion of a SPAG. The uniqueness of a user identifier (subject identifier)
> may also be limited to a SPAG. For example, if a random unique ID
> represents a user, then that ID may be unique within a SPAG and not
> universally across a transmitter or receiver. This is because each
> transmitter and receiver may have multiple connections to other
> transmitters and receivers, and ensuring uniqueness across all such peers
> is probably an intractable problem.
>
>
>
> *Subject Principals*
>
> While what is represented within a subject identifier may be only an
> aspect of the management entity, the administrative grouping is about the
> management entity itself. This could be the user, device or other principal
> that the subject identifier represents. Therefore, an abstract notion of a
> Subject Principal is also required in order specify what the grouping
> within a SPAG is about.
>
>
>
> The above is captured in the "Subject Principal" and "SPAG" sections
> within the proposed PR <https://github.com/richanna/secevent/pull/1>.
>
>
>
> Thanks,
>
> Atul
>
>
>
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/id-event
>
>