Re: [Id-event] Options regarding SPAGs

[Dick Hardt <[e-mail]>]

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
>>>
>>