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

From: David Waite <[email-masked]>
Date: Mon, 13 Jul 2020 02:08:22 -0600

In the majority of cases I would prefer a subject identifier which is simply a string of the appropriate URI rather than a polymorphic structured object, e.g.:

3.1 Account Subject Identifier type: 
"acct:[email-masked] <mailto:[email-masked]>”

3.2.  Email Subject Identifier Type
“mailto:[email-masked] <mailto:[email-masked]>”

3.3. Phone Number Subject Identifier Type
“callto:+1.234.456.7890”

The iss-sub and aliases types appear to be the ones which do not have a pre-existing URI forms

The issuer, subject type unfortunately may have a canonical form (such as acct:<subject>@<issuer.domain>), but there is neither a set of canonicalization rules nor an existing endpoint (like an inverse webfinger) to perform this mapping.

“sub" may also not be reproducible or correlatable amongst different parties sending events. An example would be when using pairwise pseudonyms. Due to the common-place nature of pairwise pseudonyms in large public deployments, this appears to limit  use cases that can leverage this identifier type to events between a single relying organization and a single OP.

In 3.5, as Dave Tonge suggested this could be an array rather than a composite polymorphic type. However, a more significant issue is what a recipient should do with this information. An event received with an alias list implies that the sender believes these identifiers all correspond to the same subject, are there behaviors to prescribe to the recipient when they receive a list with aliases they do not know, or receive an event with aliases corresponding with what the recipient believes to be multiple subjects?

-DW