Re: [Id-event] Options regarding SPAGs

[Atul Tulshibagwale <[e-mail]>]

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