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

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 <mailto: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 <mailto: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 <mailto: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 <mailto: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:
> Include SPAGs as a concept in the Subject Identifiers spec and allow a "spag_id" claim in any subject identifier
> 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