Subject: [Id-event] Thread: sub optionality

From: Phil Hunt <[email-masked]>
Date: Thu, 2 Mar 2017 08:00:17 -0800

Continuing in the Yaron thread series, Yaron asked: 
"Why is "sub" optional? Do we have any good examples of events where this value is not required?”

PLEASE ANSWER 1, 2, or 3 (give reasons if 2 or 3)...

I had indicated that the original sense was that some future events might be about things that are not users, e.g. IP Addresses (e.g. to blacklist) or devices (e.g. phone).  Early on, a number of us had discussions should “sub” be the subject of the event as in the english language meaning, or more specifically as defined by OpenID Connect (which also requires iss for uniqueness).  The spec was written to be agnostic and thus “sub” was actually optional.

Just observing the various conversations around the various communities, I am sensing the group might be shifting towards “sub” is simply always the subject of the event regardless of the type of entity.  The specific type of Event would establish the correct value for “sub”.

At this time, does the group prefer:
1.  The current optional “sub" (meaning events can define their own claims to identify the subject of the event)
2.  Making “sub” required (but still not not necessarily sufficient) to always identify the thing/person/entity that is the subject of event
3.  Define a new json object called “esub” (event subject) which can have multiple sub-attributes used to uniquely identify a subject (in the english sense of the word).  “esub” and the sub attributes would be strictly defined to be used in all cases.  Events could not define new attributes to identify event subjects.

Note: in 1 or 2 of the above, additional claims can be used to uniquely identify a subject (e.g. iss) and are added to the payload of the event type.

If you specify 2 or 3, please share some reasoning as to why you think it best.

Thanks,

Phil

Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

---

From: Mike Jones <[email-masked]>
Date: Thu, 2 Mar 2017 17:04:33 +0000

I prefer the existing semantics in which “sub” (subject) is optional, for the reasons already heavily discussed on the mailing list.  Reviewing those reasons, it’s up to the application defining an event what claims are needed to represent that event.  The existing decision making “sub” optional is simply a special case application of this general principle.

Lest people wonder when you might not need a “sub” claim, one example is when the event is about the issuer itself.  In that case, the “iss” claim accompanied by the issuer’s signature on the JWT completely identify the subject of the event.  Artificially adding a “sub” claim in this case would be superfluous, redundant, and confusing – leading to more possible error cases, not less.

                                                                     -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Thursday, March 2, 2017 8:00 AM
To: ID Events Mailing List <[email-masked]>
Subject: [Id-event] Thread: sub optionality

Thanks,

Phil

Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 2 Mar 2017 16:30:20 -0800

Option 1 makes sense to me. Each event type can define requirements around
sub.

That being said, I cannot come up with an example where sub can be omitted.
Mike, what event type would only use iss?

Marius

On Thu, Mar 2, 2017 at 9:04 AM, Mike Jones <[email-masked]>
wrote:

> I prefer the existing semantics in which “sub” (subject) is optional, for
> the reasons already heavily discussed on the mailing list.  Reviewing those
> reasons, it’s up to the application defining an event what claims are
> needed to represent that event.  The existing decision making “sub”
> optional is simply a special case application of this general principle.
>
>
>
> Lest people wonder when you might not need a “sub” claim, one example is
> when the event is about the issuer itself.  In that case, the “iss” claim
> accompanied by the issuer’s signature on the JWT completely identify the
> subject of the event.  Artificially adding a “sub” claim in this case would
> be superfluous, redundant, and confusing – leading to more possible error
> cases, not less.
>
>
>
>                                                                      --
> Mike
>
>
>
> *From:* Id-event [mailto:[email-masked]] * On Behalf Of *Phil
> Hunt
> *Sent:* Thursday, March 2, 2017 8:00 AM
> *To:* ID Events Mailing List <[email-masked]>
> *Subject:* [Id-event] Thread: sub optionality
>
>
>
> I had indicated that the original sense was that some future events might
> be about things that are not users, e.g. IP Addresses (e.g. to blacklist)
> or devices (e.g. phone).  Early on, a number of us had discussions should
> “sub” be the subject of the event as in the english language meaning, or
> more specifically as defined by OpenID Connect (which also requires iss for
> uniqueness).  The spec was written to be agnostic and thus “sub” was
> actually optional.
>
>
>
> Just observing the various conversations around the various communities, I
> am sensing the group might be shifting towards “sub” is simply always the
> subject of the event regardless of the type of entity.  The specific type
> of Event would establish the correct value for “sub”.
>
>
>
> 2.  Making “sub” required (but still not not necessarily sufficient) to
> always identify the thing/person/entity that is the subject of event
>
> 3.  Define a new json object called “esub” (event subject) which can have
> multiple sub-attributes used to uniquely identify a subject (in the english
> sense of the word).  “esub” and the sub attributes would be strictly
> defined to be used in all cases.  Events could not define new attributes to
> identify event subjects.
>
>
>
> Note: in 1 or 2 of the above, additional claims can be used to uniquely
> identify a subject (e.g. iss) and are added to the payload of the event
> type.
>
>
>
> www.independentid.com
> [email-masked]
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>
>