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

From: Atul Tulshibagwale <[email-masked]>
Date: Thu, 1 Oct 2020 09:02:18 -0700

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 <[email-masked]> 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=[email-masked]> 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 "[email-masked]" 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 "[email-masked]" 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" : "[email-masked]"
> }
>
> 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" : "[email-masked]",
>   "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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>
>
>

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 02 Oct 2020 18:26:22 +0300

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 <[email-masked]> on behalf of Atul Tulshibagwale <atultulshi=[email-masked]>
Date: Thursday, October 1, 2020 at 19:02
To: Justin Richer <[email-masked]>
Cc: SecEvent <[email-masked]>
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:[email-masked]> 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=[email-masked]> 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:[email-masked]" 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:[email-masked]" 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:[email-masked]"
}

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:[email-masked]",
  "spag_id" : "http://B.com"
}

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

mailto:[email-masked]

_______________________________________________ Id-event mailing list [email-masked] https://www.ietf.org/mailman/listinfo/id-event

---

From: Atul Tulshibagwale <[email-masked]>
Date: Fri, 2 Oct 2020 16:13:52 -0700

Hi Yaron,

I agree that SPAGs would typically need to be understood by the transmitter
and receiver. However this claim need not be present in every subject
identifier, since it may not apply in many cases. Ignoring a SPAG value may
still be OK if, say, the receiver is a single tenanted receiver and the
SPAG in the subject identifier is a tenant identifier. Also, note that
SPAGs do not necessarily only identify tenants; they may identify other
subject principal groupings such as OUs, groups, etc.

In general, specifications that use the Subject Identifiers specification
could add claims that may have additional semantics relating to the
interpretation of those claims. The Subject Identifiers specification could
leave the interpretation of the additional claims open.

I believe SPAGs is going to be a common enough use case, so it should be
included in the Subject Identifiers specification as such. But I'm OK with
defining the SPAG claim in the SSE specification, if we have a way for the
Subject Identifiers specification to allow the addition of such a claim to
any subject identifier.

Thanks,
Atul

PS: There has been some discussion in the OpenID SSE WG about multiple
event streams versus using SPAGs to identify different subject groupings
within the same stream. A good venue to discuss this is the
[email-masked] mailing list, and now is a good time to bring
this up. The present work is captured in the SSE profile
<https://bitbucket.org/openid/risc/src/caep-draft-01/openid-sse-profile-2_0.txt>
draft spec (the one you referred to in your email was the RISC profile,
which could be replaced with this SSE profile spec when it's ready).

On Fri, Oct 2, 2020 at 8:26 AM Yaron Sheffer <[email-masked]> wrote:

> 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 <[email-masked]> on behalf of Atul
> Tulshibagwale <atultulshi=[email-masked]>
> After reviewing the
> https://github.com/richanna/secevent/blob/master/draft-ietf-secevent-subject-identifiers.txt
> For example, if the user "mailto:[email-masked]" 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:[email-masked]" 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".
>
> 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" : {
> 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
> [email-masked] https://www.ietf.org/mailman/listinfo/id-event
>
>
>

---

From: Atul Tulshibagwale <[email-masked]>
Date: Tue, 13 Oct 2020 11:44:12 -0700

Annabelle,

Could you please provide an update on whether this change (any of the two
proposed options) is possible in this Subject Identifiers specification?
The work in the OpenID SSE WG cannot proceed without this clarification.

Thanks,
Atul

On Fri, Oct 2, 2020 at 4:13 PM Atul Tulshibagwale <[email-masked]>
wrote:

> Hi Yaron,
>
> I agree that SPAGs would typically need to be understood by the
> transmitter and receiver. However this claim need not be present in every
> subject identifier, since it may not apply in many cases. Ignoring a SPAG
> value may still be OK if, say, the receiver is a single tenanted receiver
> and the SPAG in the subject identifier is a tenant identifier. Also, note
> that SPAGs do not necessarily only identify tenants; they may identify
> other subject principal groupings such as OUs, groups, etc.
>
> [email-masked] mailing list, and now is a good time to
> bring this up. The present work is captured in the SSE profile
>> 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]
>> 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" : {