Re: [Id-event] Options regarding SPAGs

[Dick Hardt <[e-mail]>]

Thanks for the update Atul!

Glad to see a crisper solution.
ᐧ

On Fri, Mar 19, 2021 at 5:33 PM Atul Tulshibagwale <[e-mail]>
wrote:

> Hi all,
> Based on recent discussions and consensus in the OpenID SSE working group,
> I'd like to note that the SSE draft no longer requires the use of SPAGs in
> subject identifiers. Other changes to the subject identifiers discussed in
> the SSE WG have already been reflected in the updated draft from Annabelle.
>
> We have instead settled on a new notion of "Complex Subject Types", which
> can contain multiple subject identifiers, each with a unique name. These
> names include things like "tenant" and "org_unit" instead of the generic
> "spag_id" that we had thought of earlier. If you'd like to take a look at
> the draft that introduces the new complex subject types, you can see it
> here:
> https://bitbucket.org/openid/risc/src/caep-draft-01/openid-sse-profile-1_0.txt
>
> Thanks,
> Atul
>
>
> On Tue, Dec 15, 2020 at 3:41 PM Atul Tulshibagwale <[e-mail]>
> wrote:
>
>> Hi Dick,
>> Ideally, we would be able to discuss the complexity of SecEvent tokens
>> and whether SPAG belongs in a subject-identifier separately. However in
>> this case they seem somewhat intertwined. Nevertheless, I'm limiting my
>> response with the assumption that there is only one subject claim in a
>> SecEvent.
>>
>> Right now, restricting a SecEvent to be about one SPAG can work for the
>> events we have real use-cases for in SSE. We will still need SPAG as a
>> subject type of its own for control plane SecEvents, but we can define that
>> in the SSE spec if it is too specialized of a use case for the general
>> SecEvents Subject Identifiers spec.
>>
>> That said, I'd like us to focus on what it means to have a "spag_id"
>> claim within a subject identifier. The way I see it, SPAGs basically
>> capture the namespace separation for referring to subjects that may
>> otherwise be ambiguous.
>>
>> If we do not allow for adding SPAGs to the spec, we are basically saying
>> to multi-tenanted hosts that need such separation to always use the
>> "iss-sub" subject_type and form their own pseudo-standard of how to
>> differentiate between subject principals that belong to different SPAGs. I
>> can think of transmitters defining a URL pattern for the "iss" claim that
>> can be parsed to figure out the sub-organization that the "sub" is about.
>> It'll work, but the opportunity to standardize something that many
>> transmitters and receivers need is lost.
>>
>> So, even if we do not think we should add SPAGs to the spec right now, I
>> feel we should not preclude higher-level specs from adding such common
>> claims as SPAGs (i.e. the option #2 in my first email).
>>
>> Thanks,
>> Atul
>>
>> On Thu, Dec 10, 2020 at 3:47 PM Dick Hardt <[e-mail]> wrote:
>>
>>> Hi Atul
>>>
>>> I echo Phil's concerns wrt. multi subject SecEvents.
>>>
>>> FYI: I am more interested in understanding the use cases so that we can
>>> explore the various solutions than review your proposed changes. A SAML
>>> subject type makes sense to me as it is another subject identifier that is
>>> commonly used.
>>>
>>> wrt. SPAG -- another option would be to wrap the secevent object in a
>>> SPAG object -- this would also enable binding multiple secevents together.
>>>
>>> Given what I understand of the use case, where one channel is being used
>>> to exchange SecEvents that belong to different transmitters and senders,
>>> wrapping the SecEvent preserves the semantics of a SecEvent, and the SPAG
>>> wrapper identifiers the SPAG on the channel. Would that not work?
>>>
>>> /Dick
>>> ᐧ
>>>
>>> On Fri, Dec 4, 2020 at 4:41 PM Atul Tulshibagwale <[e-mail]>
>>> wrote:
>>>
>>>> Hi Dick,
>>>> #4 may not always be an option if the event has more than one subject
>>>> claim (e.g. for an event like "device transfer").
>>>>
>>>> Regarding other additions:
>>>> *Subject Categories*:
>>>> Earlier, I had proposed that a subject identifier of any subject_type
>>>> have an optional common claim named "subject_category", which could
>>>> identify the type of subject principal the subject identifier refers to.
>>>> However, since the future of this request in the Subject Identifiers spec
>>>> wasn't clear, we decided to add a new "subject_type" in the SSE spec,
>>>> called "user-device-session". The SSE spec draft defines the algorithm to
>>>> figure out the category of the subject principal based on the content of
>>>> this subject identifier.
>>>>
>>>> As a result of this new subject type definition in the SSE spec draft,
>>>> "subject_category" is no longer a requirement for the SSE work. However,
>>>> since the SSE spec is still being drafted, if the Subject Identifiers spec
>>>> has the ability to add a subject category claim to any subject_type, then
>>>> we can possibly change the SSE spec to make use of it.
>>>>
>>>> *SAML Subject Type*:
>>>> I had proposed that a SAML subject type be introduced in the Subject
>>>> Identifiers. This will help us send and receive events relating to a
>>>> specific SAML-based federated session. I thought this would be a common
>>>> subject type of interest to the Subject Identifiers spec. However, we have
>>>> now added it as a subject type in the SSE draft spec. If the Subject
>>>> Identifiers draft were to include this, it would be very easy for us to
>>>> remove this from the SSE draft spec.
>>>>
>>>> BTW a good way to look at all my proposed changes to the Subject
>>>> Identifiers draft is by reviewing my pull request here:
>>>> https://github.com/richanna/secevent/pull/1
>>>>
>>>> Thanks,
>>>> Atul
>>>>
>>>>
>>>> On Thu, Dec 3, 2020 at 5:43 PM Dick Hardt <[e-mail]> wrote:
>>>>
>>>>> I think there is also a fourth option:
>>>>>
>>>>> 4. a SPAG identifier can be placed in a separate top level object or
>>>>> top level property
>>>>>
>>>>> Atul: in the other thread, you mentioned that there were other
>>>>> additions that the OpenID Shared Signals and Events WG is interested in.
>>>>> Would you enumerate them as well so that we can address all potential
>>>>> issues?
>>>>>
>>>>>
>>>>> ᐧ
>>>>>
>>>>> On Thu, Dec 3, 2020 at 3:04 PM Atul Tulshibagwale <atultulshi=
>>>>> [e-mail]> wrote:
>>>>>
>>>>>> Hi all,
>>>>>> Based on Dick's request, I'd like to summarize the situation with
>>>>>> SPAGs here.
>>>>>>
>>>>>> *Background*:
>>>>>> The present Subject Identifiers draft
>>>>>> <https://github.com/richanna/secevent/blob/1fd045d251ff3c6be9a500c6a78d895be3c6b2bf/draft-ietf-secevent-subject-identifiers.txt>
>>>>>> forbids a subject identifier of a specific subject_type from having any
>>>>>> claims that are not described in the subject_type. This prevents
>>>>>> higher-level specs from proposing any additional claims to be included in
>>>>>> subject identifiers of subject types that are defined in the Subject
>>>>>> Identifier spec.
>>>>>>
>>>>>> *SPAGs*:
>>>>>> Subject Principal Administrative Groupings or SPAGs are an addition
>>>>>> to the OpenID "Shared Signals and Events Profile of SETs"
>>>>>> <https://bitbucket.org/openid/risc/src/caep-draft-01/openid-sse-profile-2_0.txt>,
>>>>>> which is a revision of the "RISC Profile of SETs
>>>>>> <https://bitbucket.org/openid/risc/src/master/openid-risc-profile-1_0.txt>".
>>>>>> The present draft of the SecEvents Subject Identifiers spec is derived from
>>>>>> a section in this RISC Profile. The SSE Profile now refers to the SecEvents
>>>>>> Subject Identifiers draft.
>>>>>>
>>>>>> SPAGs are required to address the following needs:
>>>>>>
>>>>>>    1. Disambiguate a subject identifier if it belongs to more than
>>>>>>    one sub-organizations. For example, if the subject claim in an event is of
>>>>>>    the subject type "email", then a SPAG may be used to specify the
>>>>>>    sub-organization the specified email should be scoped down to. A dynamic
>>>>>>    organization may have the same email in multiple sub-organizations, and the
>>>>>>    event may apply to only one such sub organization.
>>>>>>    2. Provide a lighter weight mechanism to start and stop event
>>>>>>    streams for sub-organizations. These could be OUs or dynamic groups within
>>>>>>    an organization, or separate tenants in a multi-tenanted transmitter or
>>>>>>    receiver.
>>>>>>
>>>>>> *Requirements from Subject Identifiers*:
>>>>>>
>>>>>>    1. A SPAG may be specified as an additional attribute of a
>>>>>>    subject identifier with any subject type, in order to disambiguate and
>>>>>>    scope the event with that subject identifier.
>>>>>>    2. A SPAG may be a new subject type of its own when it is used in
>>>>>>    an event that specifies the starting or stopping of a stream.
>>>>>>
>>>>>> *Options*:
>>>>>> The following options are possible to address this requirement.
>>>>>>
>>>>>>    1. *Minimal Change to the present Subject Identifiers draft*:
>>>>>>    Remove the words "or not described" on line 247
>>>>>>    <https://github.com/richanna/secevent/blob/1fd045d251ff3c6be9a500c6a78d895be3c6b2bf/draft-ietf-secevent-subject-identifiers.txt#L247>.
>>>>>>    This way a higher-level spec that needs to add additional attributes to all
>>>>>>    subject identifiers used in that spec can add them and specify the
>>>>>>    additional attributes' optional or required nature. In this option, SPAGs
>>>>>>    will be defined in the SSE profile spec.
>>>>>>    2. *Include SPAGs in the Subject Identifiers spec*: Include
>>>>>>    language for SPAGs proposed earlier in this list, so that:
>>>>>>       1. Subject Principals and SPAGs are defined in the Subject
>>>>>>       Identifiers spec
>>>>>>       2. An additional attribute named "spag_id" is added as an
>>>>>>       optional attribute of any subject_type.
>>>>>>       3. An additional subject_type "spag" is defined (this is used
>>>>>>       primarily for "control plane" events.)
>>>>>>    3. *Do both 1. and 2*: With this, we will address the issue that
>>>>>>    higher-level specs cannot insert additional attributes in predefined
>>>>>>    subject types, and define SPAGs within the Subject Identifiers spec.
>>>>>>
>>>>>> Thanks,
>>>>>> Atul
>>>>>>
>>>>>> _______________________________________________
>>>>>> Id-event mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/id-event
>>>>>>
>>>>>