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

[Atul Tulshibagwale <[e-mail]>]

Hi Dick,

Just a quick clarification: My request above is to allow attributes that
are not defined in specific subject_type descriptions in the SecEvents
Subject Identifiers specification to be allowed to be added by other
specifications that use it. The SPAG attribute is only an example of such
an addition that we are interested in for the OpenID Shared Signals and
Events WG.

Atul

On Wed, Dec 2, 2020 at 11:58 AM Dick Hardt <[e-mail]> wrote:

> Annabelle / Atul
>
> Has the SPAG issue been resolved?  Would be great to get resolution and
> consensus so we can propose a last call again for this draft.
>
> /Dick
> ᐧ
>
> On Wed, Nov 25, 2020 at 9:05 AM Atul Tulshibagwale <atultulshi=
> [e-mail]> wrote:
>
>> Pinging this topic as discussed in the CAEP call yesterday.
>>
>> On Tue, Oct 13, 2020 at 11:44 AM Atul Tulshibagwale <
>> [e-mail]> 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 <[e-mail]>
>>> 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
>>>> [e-mail] 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 <[e-mail]>
>>>> 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 <[e-mail]> on behalf of Atul
>>>>> Tulshibagwale <atultulshi=[e-mail]>
>>>>> Date: Thursday, October 1, 2020 at 19:02
>>>>> To: Justin Richer <[e-mail]>
>>>>> Cc: SecEvent <[e-mail]>
>>>>> 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:[e-mail]>
>>>>> 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=
>>>>> [e-mail]> 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:[e-mail]" 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:[e-mail]" 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:[e-mail]"
>>>>> }
>>>>>
>>>>> 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:[e-mail]",
>>>>>   "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:[e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/id-event
>>>>>
>>>>> _______________________________________________ Id-event mailing list
>>>>> [e-mail] https://www.ietf.org/mailman/listinfo/id-event
>>>>>
>>>>>
>>>>> _______________________________________________
>> Id-event mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/id-event
>>
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/id-event
>