Subject: [Id-event] Review of draft-ietf-secevent-subject-identifiers-05

From: Phillip Hunt <[email-masked]>
Date: Wed, 8 Jul 2020 10:15:22 -0700

Per the chairs request, here are my initial comments on the draft.

Technically I am ok with the proposal. I do however have some suggestions that should improve the flow of the document regarding Secs 3 and 4.

Section 1.0

I think breaking into two paragraphs makes it a bit clearer.

Replace:
   ...depending on the nature and needs of the transmitter and
   receiver. Even within the context of a given transmitter and
   receiver relationship, it may be appropriate to identify different
   accounts in different ways, for example if some accounts only have
   email addresses associated with them while others only have phone
   numbers.  Therefore it can be necessary to indicate within a SET the
   mechanism by which the subject of the security event is being
   identified.

With:
   ...depending on the nature and needs of the transmitter and
   receiver.
  <new paragraph>
   Within the context of a given transmitter and receiver relationship, 
   accounts may be identified in different ways. For example, some 
   accounts only have email addresses associated with them while others 
   only have phone numbers. Because of the variability in ways of 
   identification across entities, this specification provides a mechanism 
   to indicate the mechanism by which the subject of the security event is 
   being identified.

Having a combination of figures 5 and 6 in the introduction as an example might be helpful to give the reader a quick look at what is being defined.

Section 3 and 4:

General:

Terms:
The terms “schema” and “payload claim” are not defined or referenced.  The use seems inconsistent with RFC8417. A “payload" is not just a jSON object, but rather in 8417 the payload was a set of sub-claims placed within an event uri value object. Payload claims don’t have to be registered JWT claims because they fall within their own event-uri object space. In contrast, “sub_id” is a registered claim to be placed in the top level of the JWT/SET.  For example:
{
     "iss": "https://server.example.com <https://server.example.com/>",
     "sub": "248289761001",
     "aud": "s6BhdRkqt3",
     "iat": 1471566154,
     "jti": "bWJq",
     “sub_id”|"sid": <JSON Value>,
     "events": {
       “e <http://schemas.openid.net/event/backchannel-logout>vent-uri": {
       <payload claims here>
        }
     }
}

Flow:
I was confused reading section 3 before section 4. I think spec might flow better with 3 and 4 reversed.  Note: I believe it is ok to have examples with parts that are not yet defined.  Or, you can do something like “<subject-identifier-object>” in place of the value of a “sub_id” in the example. 

Figure 7 seems confusing. Why would a duplicate identifier be sent in both sub and sub_id?  Does figure 7 imply that the identifiers are aliases? Some explanatory text (e.g. backwards compatibility) might be helpful. Also, is sub_id intended to replace “sub”?

Figure 8, seems incorrectly composed. Why not use the alias subject type to express there are multiple email aliases?  

Sec 4.1.  The sub claim should be referenced to Sec 4.1.2 of RFC7519.

I would prefer a SHOULD that implementers should operationally use either “sub” or “sub_id” in any single JWT or SET. This avoids confusing situations and logic around “implied” aliases such as in Figure 7 or 8. It feels like a better practice to use the alias subject identifier when explicitly saying two emails are aliases for the same subject.

Section 5

You may want some more general advice on transmission PII and identifiers in general rather than just the alias case.

Aside: it may be worth while spending more time on Alias. Is the point to convey multiple identifiers of the same type?  Why wouldn’t an issuer not know how the receiver identifies a subject?  Some of the use of alias may seem to be “spaghetti on the wall” event matching.
—> I’m not against alias. I just suspect we need to justify and clarify its appropriate uses.

Reference RFC8417 Section 6 and Sec 5.1 as applying here?

Section 6 - assuming RFC8417 (SET) and RFC7797 (JWT) as foundational considerations?

Hope this helps.

Phil Hunt
@independentid
[email-masked] <mailto:[email-masked]>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 9 Jul 2020 22:23:04 +0000

Thanks for the review, Phil! Comments/follow ups [richanna] inline [/richanna].

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/

From: Id-event <[email-masked]> on behalf of Phillip Hunt <[email-masked]>
Date: Wednesday, July 8, 2020 at 10:18 AM
To: ID Events Mailing List <[email-masked]>
Subject: [EXTERNAL] [Id-event] Review of draft-ietf-secevent-subject-identifiers-05

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

Section 1.0

Replace:

   ....depending on the nature and needs of the transmitter and

   identified.

With:

   receiver.

  <new paragraph>

   being identified.

Section 3 and 4:

General:

Terms:

{

     "iss": "https://server.example.com<https://server.example.com/>",

     "sub": "248289761001",

     "aud": "s6BhdRkqt3",

     "iat": 1471566154,

     "jti": "bWJq",

     "events": {

       “e<http://schemas.openid.net/event/backchannel-logout>vent-uri": {

       <payload claims here>

        }

     }

}

[richanna]
Agreed, I think “claim” and “payload claim” can be replaced less semantically-loaded terms (e.g., “property”), or “member” where we are actually referring to members of a JSON object. And we can reword the Subject Identifier Type definition to avoid use of the word “schema” altogether.
[/richanna]

Flow:

[richanna]
Since the “sub_id” JWT claim is just one way that Subject Identifiers may be used, I don’t think it makes sense to define it first. Are you looking for the doc to provide a bit more concrete grounding for Subject Identifiers before jumping into the definition? We could add examples to the introduction, showing Subject Identifiers in a couple of different use cases.
[/richanna]

[richanna]
I primarily see this as being used for interoperability/backwards compatibility, in particular when migrating systems to use one versus the other.
[/richanna]

[richanna]
Figure 8 does not express that there are multiple email addresses. While the value of the “sub” claim resembles an email address, nothing in the JWT indicates that it actually is one. Since a recipient of the JWT cannot be certain that the “sub” value is an email address without relying on information obtained through some non-standard out-of-band mechanism, simultaneous usage of “sub” and “sub_id” cannot be used to express multiple email subject identifiers for the subject in an interoperable fashion.

Figure 8 is an admittedly contrived example for a corner case that is permitted by the syntax. One use case might be an organization taking the sub-to-sub_id migration as an opportunity to also make changes to their identifiers, e.g., normalizing email addresses from @team1.example.com, @team2.example.com, etc. to @example.com).
[/richanna]

[richanna]
A SHOULD on the issuer side introduces room for interoperability issues as systems with legitimate needs for issuing JWTs with both run up against processors that treat that as an error case. However I think it would be appropriate to constrain consumer behavior, e.g.,:

“When processing a JWT implementations SHOULD determine the subject using one of the “sub” or “sub_id” claims, and SHOULD NOT depend on both for this purpose.”

Maybe it’s worth explicitly calling out the “both” use case as intended to support interop?
[/richanna]

Section 5

[richanna]
It’s pretty common in the consumer IdP space, because clients don’t always do the “right” thing and link identities based on “iss”+”sub”. Or the subject identifier may be going into a message that is intended for a variety of parties, which need different subject identifiers  (e.g., different formats for the same identifier value).
[/richanna]

Hope this helps.

Phil Hunt
@independentid
[email-masked]<mailto:[email-masked]>