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

Hi Justin, Atul,

I think this may be a reasonable way to extend the solution.

But I have a problem with Atul’s example below: the SPAG attribute that he’s proposing defines a scope (a.k.a. namespace) for the subject ID. I don’t think the receiver can act correctly on the event *unless* it understands the tenant ID. So this is not a benign extension that can be ignored by a receiver with no consequence.

The SecEvent mechanism to distinguish multiple tenants is not to embed the tenant’s identity in the event, rather it is to use separate event streams. In fact, this is enabled by the OpenID SSE document [1] which defines a profile of this solution: “Using path components enables supporting multiple issuers per host. This is required in some multi-tenant hosting configurations.”

Thanks,
	Yaron

[1] https://openid.net/specs/openid-risc-profile-1_0-ID1.html#rfc.section.3.2.1

From: Id-event <id-event-bounces@ietf.org> on behalf of Atul Tulshibagwale <atultulshi=40google.com@dmarc.ietf.org>
Date: Thursday, October 1, 2020 at 19:02
To: Justin Richer <jricher@mit.edu>
Cc: SecEvent <id-event@ietf.org>
Subject: 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 <mailto: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 <mailto:atultulshi=40google.com@dmarc.ietf.org> wrote:

Hi Annabelle,
After reviewing the 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 "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 "http://B.com" and "http://C.com". This can happen if "mailto:a@b.com" is an employee of the tenant http://B.com, but is on a contract for a project that is run by the tenant "http://C.com".

If the event received only has the subject:
"subject" : {
  "subject_type" : "email",
  "email" : "mailto:a@b.com"
}

Then it will be impossible for the receiver to determine whether the event applies to the tenant http://B.com or http://C.com. If on the other hand, an optional claim "spag_id" is added, then the subject looks like:

"subject" : {
  "subject_type" : "email",
  "email" : "mailto:a@b.com",
  "spag_id" : "http://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
mailto:Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

_______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event 