Re: [Id-event] Draft-06 issue re: subject principal grouping

Hi Justin,
Agree with the theme of the language proposed in your email. I'd like to
propose something similar, like:

"Each subject_type may define required fields. Subject identifiers MUST
include all fields required by the subject_type, but MAY contain other
fields, either defined as optional fields within this Subject Identifiers
specification or elsewhere. A receiver MUST ignore fields in a Subject
Identifier that it does not understand."

Atul

On Wed, Sep 30, 2020 at 1:51 PM Justin Richer <jricher@mit.edu> wrote:

> Atul,
>
> I raised this in my review as well. I think the goal of the restriction
> was to make the subject identifier objects compact and easily processed
> without getting a bunch of arbitrary stuff strung onto them, but I think
> the MUST NOT might go too far toward that.
>
>
> I would like to see the requirement relaxed but also have guidance as to
> how and when to add additional members to the object. Maybe the
> subject_type field determines the REQUIRED fields and their semantics, but
> extensions MAY add new fields? And that a receiver MUST ignore fields they
> don’t understand?
>
>
>
>  — Justin
>
> On Sep 29, 2020, at 8:28 PM, Atul Tulshibagwale <
> atultulshi=40google.com@dmarc.ietf.org> wrote:
>
> Hi Annabelle,
> After reviewing the draft 06
> <https://github.com/richanna/secevent/blob/master/draft-ietf-secevent-subject-identifiers.txt>
> (document dated Sep 04), there's one issue that I feel needs to be
> addressed:
>
> The sentence on line 246 ("A Subject Identifier MUST NOT contain any
> members...") has the consequence that if we need to add claims in a
> specific subject identifier type (e.g. email), then we will need to define
> new subject identifier types.
>
> As discussed earlier, I am interested in adding a "Subject Principal
> Administrative Grouping" or SPAG as a property of any subject identifier.
> This is important because the same principal may appear in different
> administrative groupings, and without the disambiguation, it will be
> impossible to figure out which SPAG the event that includes a subject
> identifier applies to.
>
> For example, if the user "a@b.com" is present in two tenants of a service
> that acts as a SSE Receiver. Say the tenant names in which this user occurs
> is "B.com" and "C.com". This can happen if "a@b.com" is an employee of
> the tenant B.com, but is on a contract for a project that is run by the
> tenant "C.com".
>
> If the event received only has the subject:
> "subject" : {
>   "subject_type" : "email",
>   "email" : "a@b.com"
> }
>
> Then it will be impossible for the receiver to determine whether the event
> applies to the tenant B.com or C.com. If on the other hand, an optional
> claim "spag_id" is added, then the subject looks like:
>
> "subject" : {
>   "subject_type" : "email",
>   "email" : "a@b.com",
>   "spag_id" : "B.com"
> }
>
> This disambiguates the particular grouping that the event applies to.
>
> So, I feel there are at least two ways of addressing this concern:
>
>    1. Include SPAGs as a concept in the Subject Identifiers spec and
>    allow a "spag_id" claim in any subject identifier
>    2. Drop the requirement on line 246, and allow subject identifiers to
>    have additional claims, which may be defined elsewhere.
>
> Thanks,
> Atul
>
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.org
> https://www.ietf.org/mailman/listinfo/id-event
>
>
>