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

From: Atul Tulshibagwale <[email-masked]>
Date: Wed, 25 Nov 2020 09:04:40 -0800

Pinging this topic as discussed in the CAEP call yesterday.

On Tue, Oct 13, 2020 at 11:44 AM Atul Tulshibagwale <[email-masked]>
wrote:

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