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 <atultulshi@google.com>
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 <Michael.Jones@microsoft.com>
> 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 <id-event-bounces@ietf.org> *On Behalf Of *Dick Hardt
>> *Sent:* Monday, July 13, 2020 5:13 PM
>> *To:* Atul Tulshibagwale <atultulshi@google.com>
>> *Cc:* SecEvent <id-event@ietf.org>
>> *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 <atultulshi@google.com>
>> 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 <dick.hardt@gmail.com> 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 <atultulshi@google.com>
>> 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 <dick.hardt@gmail.com> wrote:
>>
>> Which part is not required?
>>
>>
>>
>> On Mon, Jul 13, 2020 at 3:33 PM Atul Tulshibagwale <atultulshi@google.com>
>> wrote:
>>
>> Not required, since the claim is optional.
>>
>>
>>
>> On Mon, Jul 13, 2020 at 3:25 PM Dick Hardt <dick.hardt@gmail.com> 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 <atultulshi@google.com>
>> 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 <dick.hardt@gmail.com> 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 <atultulshi@google.com>
>> 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 <dick.hardt@gmail.com> 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=
>> 40google.com@dmarc.ietf.org <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
>> Id-event@ietf.org
>> https://www.ietf.org/mailman/listinfo/id-event
>>
>>