Subject: [Id-event] minutes from Singapore side meetings

From: Dick Hardt <[email-masked]>
Date: Fri, 1 Dec 2017 11:26:40 -0800

*Meeting Notes Summary from Nov 6,7,8 meetings. Core topic was SET draft.*
*Notes from Annabelle Richard Backman.*

*Overall Comments*

   - Mike: If we were to be starting from scratch, this would be fine, but
   we are not. Draft is “full of breaking changes” relative to current IETF
   -03 draft.
   - Tony: We need to be able to batch events (acknowledges that the
   current draft doesn’t support batching events, and wants to change that)
   - Justin: Planned use cases put forward by people in the secevents
   session don’t align with one another, or intent behind current draft.
   - Jon: We had implicit assumptions about how items in the events claim
   would be related, discovering others had different assumptions.

*“exp” Claim*

   - Justin: Guidance/context for using “exp” claim is good, but NOT
   RECOMMENDED is too strong.
   - Phil: A SET expiring suggests “history erases itself” which doesn’t
   make sense.
   - Jon: “exp” is useful for de-duping tokens; NOT RECOMMENDED may be
   overkill.
   - Leif: Receiver may use “exp” to decide if it should trust the SET.
   - Justin: SETs may stick around for a long time as an audit trail. Maybe
   need a “freshness” claim that matches our desired semantics.
   - *Open issue:* Should “exp” be NOT RECOMMENDED? Should we introduce a
   “freshness” claim?

*“toe” Claim*

   - Justin: “toe” should be in event payload.
   - Leif: Should be REQUIRED that recipients interpret “iat” as “toe” when
   “toe” is omitted.
   - Annabelle: Transmitter might not know the time of event or want to
   share it.
   - *Consensus:* “toe” claim should be in event payload, renamed
   “event_time”. If not present, the recipient MUST consider the time of event
   as unknown.

*“txn” Claim*

   - Leif: Don’t need it if we have grouping events.
   - Mike: Was intended to be general purpose, beyond just SET.
   - *Consensus:* Move “txn” to a separate document. Add “event_id” as an
   OPTIONAL payload claim.

*“event_subject” Payload Claim*

   - *Consensus: *Event payload claims should have different names from JWT
   claims, e.g. “event_type”, “event_subject”.
   - Leif: “event_subject” payload claim should be mandatory.
   - Miike: Should be OPTIONAL, sometimes subjects are implicit.
   - *Consensus:* “event_subject” payload claim should be REQUIRED, with a
   subject identifier type that indicates if a subject is implicitly known.
   - Mike: Don’t need to specify the subject identifier type; use duck
   typing.
   - Marius: In some situations, we need both issuer+subject and email.
   With explicit types, we’d need an array of subjects. With duck typing, can
   just combine the subjects.
   - Annabelle: Profiles that need multiple subjects could define a
   separate event payload claim, e.g. “subject_aliases”
   - Leif: Need subject type to avoid identifier conflicts, help recipient
   interpret the SET.
   - Justin: Could have a registry for subject claims.
   - Justin: Value in defining email/phone/iss+sub subjects in SET: then
   they’re immediately available for everyone who wants to use them.
   - Mike: Whatever we register should just use simple names, e.g. “email”,
   not URNs.
   - *Open issue:* Duck typing with a registry of subject claims, or
   explicit typing with a registry of subject identifier types?
   - *Consensus: *Use simple names for subject types or subject claims
   (whichever one we end up having a registry for).
   - Phil: Need to canonicalize identifiers.
   - Marius: Concerned about compatibility with OIDC since it doesn’t
   canonicalize identifiers.
   - *Rough consensus: *Canonicalize the identifiers in the subject
   types/claims defined in SET. Profiles that need non-canonicalized variants
   can define them.
   - *Open issue:* What language do we need for canonicalizing email, phone
   number, etc.?

*Related Events*

   - Justin: Recipients should be REQUIRED to understand all events in a
   related event, or ignore the entire thing. Can define other grouping events
   with different semantics (e.g. BatchEvent, LooselyCoupledBagOfEvents).
   - Leif: Could have a claim that identifies the semantics to use when
   interpreting related events, instead of different events for each.
   - Tony: Might want a list of events to represent a transaction with
   rollback/commit semantics. Or they could be independent events.
   - Justin: Could have an array of SETs as a separate JWT profile, rather
   than an array of event payloads inside one SET.
   - Tony: Not sure if Related Events event would meet our needs, may want
   a Batched Events event.
   - Dick: Adding Batched Events to the draft as another example would help
   demonstrate how these are supposed to be used, defined.
   - *Rough consensus:* Add a Batched Events event to the draft.
   - *Rough consensus:* Event payloads inside a related event can omit
   claims, and recipients MUST use whichever value for a claim is “nearest”,
   e.g. the one in the event payload if present, or the one in the outer
   Related Events payload if not.

*Extending Events*

   - Mike: Extensions may want to add claims to the SET envelope.
   - Phil: Don’t want two different structures for events and extensions
   that have to be parsed differently.
   - Dick: Why not use the same rules for event payload claims as JWT
   defines for JWT claims?
   - *Rough consensus:* Event extension guidance should just state that
   event payload claims MUST be Public Claims as defined in JWT.

*Meeting Notes from Nov 9 meeting. Core topic was the delivery
specifications.*
*Minutes from Marius*

Management API spec, split out a separate document defining meta data (room
consensus)
  - will be used by management APIs and also by delivery method specs to
specify what configuration they need

Delivery Spec:
- method optionality, we have 4 choices:
  - 1. keep as is
  - 2. split into 2 docs
  - 3. split into 3 docs, 3rd setting context
  - 4. split into 2 docs and add some common context to SET spec
- security considerations to mention DoS and authz (room consensus)
- push delivery method to define authorization header attribute (room
consensus)
- ask list if authorization header should specify a schema or receiver
should specify schema as well
- authorization header attribute should be write-only for security reasons
(room consensus)
  - it can be set by receiver, but when getting existing configuration
actual value will not be provided
  - care needed with get/update cycle
- push delivery wording needed to specify that SET signature is one form of
authorization (room consensus)

*Meetings Notes from Nov 10 meeting. Core topic was control Plane. *
*Summary by Adam Dawes, Minutes taken by Marius Scurtescu*

*Summary*

Group spent ~4 hours discussing approaches on SecEvents Control Plane and
stream management. We spent most of the time wrestling with basic question
of what should be defined at SecEvents level and what at the Profile level.

   - Secevents meant to be general spec and because JWT doesn't specify any
   mechanism for key signing, we don't want to couple SecEvents too closely to
   a particular protocol like OAuth.
   - If Profiles define control plane independently, then it will make
   adoption much more complicated for Receivers. Google pointed out that its
   Receivers won't care whether events are defined in OAuth, OIDC and RISC- it
   will add a lot of complexity to have to re-establish control plane for each
   of these separately. We want to send all these events to a single end point
   for each receiver since all of these events are ultimately tied back to the
   same logical OAuth client.
   - Independent stream config for each profile adds a lot of complexity
   for the Receiver and only a few large Receivers want to be able to send
   streams directly to each sub-system. It's reasonable to push this
   complexity on the large Receivers to set up routers for SecEvents going to
   the relevant sub-system.

The group finally agreed that to deal with the balance of flexibility at
the SecEvents level while also ensuring that multiple profiles could be
managed all with a single control plane, SecEvent streams would be defined
by the ability to get an access token from the Transmitter. The mechanism
to obtain an access token can be defined by the Transmitter. If a
Transmitter like Google wants to manage access tokens for the control plane
for all profiles the same way, Google is free to do so.

*NOTES*

SAML might be an issue, but we are not addressing it for now, focus on
OpenID Connect

Dynamic Registration is used by backchannel as control plane

RISC explicit could extend Dynamic Registration

we can break up the management api into: stream config, add/remove subject,
status, verification
- stream config could be just the schema of the stream config, and then let
each profile define the full api

Receivers having to define explicit list of events is not clear at secevent
level

Stream Config Schema:
- delivery (distribution): method and endpoints, etc

One set of credentials defines one receiver and one stream

Allowing multiple streams per receiver allows receiver to send different
sets of events (or profiles) to different service providers or to different
sub-systems.

Asking Receivers to setup routers adds burden and also has privacy
implications.

Questions
 - Is every profile on the same stream with the same management?
    - Google wants this for ease of little guy
    - Microsoft is concerned about separation of
credentials/"service"/products
    - Dick notes that this will cause amalgamation of SaaS offerings, but
accepts it

Set of credential could be profile specific or it could span multiple
profiles (at secevent level).

Question: should events from multiple profiles be allowed on the same
stream?
- profiles could specify key management, but the actual signature and
encryption should be well specified only at secevent level
- concern with mixing profiles and avoiding authentication and key
resolution
- might need a "oauth" level spec for authentication, client id/secret,
access tokens, etc

If transmitter uses separate issuer that authorization server then trust
problem between the two issuers. How does a receiver know they are related
and trusted by each other.

Multiple keys can be published by the same authorization server, so
different keys could use and still resolvable by same issuer. But you are
less secure because any key can be used to sign both Id Tokens and SETs.

Multi tenant use case from Microsoft: IdP functionality provided for
multiple tenants, each tenant has a unique guid, client apps that want to
talk to all of these IdPs will be issued a single client id that works with
all, the issuer in each case is different and it has the guid in the path.
For 3LO flows the access token has the guid baked in (the user was
authenticated to one of the tenants). In 2LO flows it is not clear. If the
2LO flow requires the tenant as parameter to issue an Access Token then the
tenant is clear in all cases.

For different APIs in a management API we might need distinct OAuth 2
scopes to access management. For example: monitoring scope, stream config
reader, stream config writer, etc

Most likely access token issuer, access token used with management API, is
the same as SET issuer flowing on the given stream.

We shifted from client id+secret to access token as credentials. This
allows on issuer per stream. Multiple streams between issuer and a receiver
are possible, with different access tokens (if issuer chooses to offer that
flexibility). At the management API level no need to support multiple
streams.

AI: update RISC use case document
AI: define stream schema
AI: first round of spec changes based on agreements at IETF
AI: update the list with all discussions
AI: issue tracker for secevent
AI: next f2f week of December 11 potentially at Oracle, Phil is making
arrangements, 2 or 3 days

---

From: Mike Jones <[email-masked]>
Date: Fri, 1 Dec 2017 20:03:45 +0000

What’s not well captured in these notes is the context that Annabelle’s draft<https://tools.ietf.org/html/draft-backman-secevent-token-03> was being proposed in the Singapore side meetings as a total replacement for the working group SET draft<https://tools.ietf.org/html/draft-ietf-secevent-token-03>.  I believe that all the current working group draft editors and many others I’m aware of are opposed to starting over – which is what the new draft does.  Phil and I and others nonetheless had constructive conversations with Annabelle and Dick and others who did want to start over, providing actionable feedback on how to improve Annabelle’s draft, on the off chance that some parts of it would be used by the working group.  And I consciously left my name on as an author because if it would be adopted, I would want to remain involved.

My listing as an author should not be taken as an endorsement for replacing the working group SET draft, which has already gone through working group last call, with Annabelle’s draft.  Annabelle’s draft contains unnecessary breaking changes (for instance, changing “events” to “event”) and is significantly more complicated (for instance, see the deeply nested “related events” structure in https://tools.ietf.org/html/draft-backman-secevent-token-03#section-3).  It introduces many new things, such as the subject identifiers structure and several kinds of new semantics that, if adopted, would have to be reviewed and discussed by the working group.  In my experience, making wholesale changes like this would likely introduce more than a year’s delay in completing the SET draft.  By that point, I suspect that many of the applications that hoped to use it will have moved on.

As I said in the side meetings, I believe it is highly counter-productive to the goal of producing a simple Security Event spec in a timely fashion to attempt to start over.  As I also said, the working group spec is already in production use and meets the needs of multiple use cases.  Might a different design work?  Of course.  Is a different design called for at this point in the working group’s deliberations?  Absolutely not.

As I said in the meetings, I will vigorously oppose attempts to make breaking changes in a draft that’s already in use and ready for prime time.  That way lies ongoing churn and delay, wasting everyone’s time.  Please, let’s not go there.

                                                                -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Friday, December 1, 2017 11:27 AM
To: SecEvent <[email-masked]>
Subject: [Id-event] minutes from Singapore side meetings

Meeting Notes Summary from Nov 6,7,8 meetings. Core topic was SET draft.
Notes from Annabelle Richard Backman.

Overall Comments

  *   Mike: If we were to be starting from scratch, this would be fine, but we are not. Draft is “full of breaking changes” relative to current IETF -03 draft.
  *   Tony: We need to be able to batch events (acknowledges that the current draft doesn’t support batching events, and wants to change that)
  *   Justin: Planned use cases put forward by people in the secevents session don’t align with one another, or intent behind current draft.
  *   Jon: We had implicit assumptions about how items in the events claim would be related, discovering others had different assumptions.

“exp” Claim

  *   Justin: Guidance/context for using “exp” claim is good, but NOT RECOMMENDED is too strong.
  *   Phil: A SET expiring suggests “history erases itself” which doesn’t make sense.
  *   Jon: “exp” is useful for de-duping tokens; NOT RECOMMENDED may be overkill.
  *   Leif: Receiver may use “exp” to decide if it should trust the SET.
  *   Justin: SETs may stick around for a long time as an audit trail. Maybe need a “freshness” claim that matches our desired semantics.
  *   Open issue: Should “exp” be NOT RECOMMENDED? Should we introduce a “freshness” claim?

“toe” Claim

  *   Justin: “toe” should be in event payload.
  *   Leif: Should be REQUIRED that recipients interpret “iat” as “toe” when “toe” is omitted.
  *   Annabelle: Transmitter might not know the time of event or want to share it.
  *   Consensus: “toe” claim should be in event payload, renamed “event_time”. If not present, the recipient MUST consider the time of event as unknown.

“txn” Claim

  *   Leif: Don’t need it if we have grouping events.
  *   Mike: Was intended to be general purpose, beyond just SET.
  *   Consensus: Move “txn” to a separate document. Add “event_id” as an OPTIONAL payload claim.

“event_subject” Payload Claim

  *   Consensus: Event payload claims should have different names from JWT claims, e.g. “event_type”, “event_subject”.
  *   Leif: “event_subject” payload claim should be mandatory.
  *   Miike: Should be OPTIONAL, sometimes subjects are implicit.
  *   Consensus: “event_subject” payload claim should be REQUIRED, with a subject identifier type that indicates if a subject is implicitly known.
  *   Mike: Don’t need to specify the subject identifier type; use duck typing.
  *   Marius: In some situations, we need both issuer+subject and email. With explicit types, we’d need an array of subjects. With duck typing, can just combine the subjects.
  *   Annabelle: Profiles that need multiple subjects could define a separate event payload claim, e.g. “subject_aliases”
  *   Leif: Need subject type to avoid identifier conflicts, help recipient interpret the SET.
  *   Justin: Could have a registry for subject claims.
  *   Justin: Value in defining email/phone/iss+sub subjects in SET: then they’re immediately available for everyone who wants to use them.
  *   Mike: Whatever we register should just use simple names, e.g. “email”, not URNs.
  *   Open issue: Duck typing with a registry of subject claims, or explicit typing with a registry of subject identifier types?
  *   Consensus: Use simple names for subject types or subject claims (whichever one we end up having a registry for).
  *   Phil: Need to canonicalize identifiers.
  *   Marius: Concerned about compatibility with OIDC since it doesn’t canonicalize identifiers.
  *   Rough consensus: Canonicalize the identifiers in the subject types/claims defined in SET. Profiles that need non-canonicalized variants can define them.
  *   Open issue: What language do we need for canonicalizing email, phone number, etc.?

Related Events

  *   Justin: Recipients should be REQUIRED to understand all events in a related event, or ignore the entire thing. Can define other grouping events with different semantics (e.g. BatchEvent, LooselyCoupledBagOfEvents).
  *   Leif: Could have a claim that identifies the semantics to use when interpreting related events, instead of different events for each.
  *   Tony: Might want a list of events to represent a transaction with rollback/commit semantics. Or they could be independent events.
  *   Justin: Could have an array of SETs as a separate JWT profile, rather than an array of event payloads inside one SET.
  *   Tony: Not sure if Related Events event would meet our needs, may want a Batched Events event.
  *   Dick: Adding Batched Events to the draft as another example would help demonstrate how these are supposed to be used, defined.
  *   Rough consensus: Add a Batched Events event to the draft.
  *   Rough consensus: Event payloads inside a related event can omit claims, and recipients MUST use whichever value for a claim is “nearest”, e.g. the one in the event payload if present, or the one in the outer Related Events payload if not.

Extending Events

  *   Mike: Extensions may want to add claims to the SET envelope.
  *   Phil: Don’t want two different structures for events and extensions that have to be parsed differently.
  *   Dick: Why not use the same rules for event payload claims as JWT defines for JWT claims?
  *   Rough consensus: Event extension guidance should just state that event payload claims MUST be Public Claims as defined in JWT.

Meeting Notes from Nov 9 meeting. Core topic was the delivery specifications.
Minutes from Marius
Management API spec, split out a separate document defining meta data (room consensus)
  - will be used by management APIs and also by delivery method specs to specify what configuration they need

Delivery Spec:
- method optionality, we have 4 choices:
  - 1. keep as is
  - 2. split into 2 docs
  - 3. split into 3 docs, 3rd setting context
  - 4. split into 2 docs and add some common context to SET spec
- security considerations to mention DoS and authz (room consensus)
- push delivery method to define authorization header attribute (room consensus)
- ask list if authorization header should specify a schema or receiver should specify schema as well
- authorization header attribute should be write-only for security reasons (room consensus)
  - it can be set by receiver, but when getting existing configuration actual value will not be provided
  - care needed with get/update cycle
- push delivery wording needed to specify that SET signature is one form of authorization (room consensus)
[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]

Meetings Notes from Nov 10 meeting. Core topic was control Plane.
Summary by Adam Dawes, Minutes taken by Marius Scurtescu

Summary

Group spent ~4 hours discussing approaches on SecEvents Control Plane and stream management. We spent most of the time wrestling with basic question of what should be defined at SecEvents level and what at the Profile level.
·  Secevents meant to be general spec and because JWT doesn't specify any mechanism for key signing, we don't want to couple SecEvents too closely to a particular protocol like OAuth.
·  If Profiles define control plane independently, then it will make adoption much more complicated for Receivers. Google pointed out that its Receivers won't care whether events are defined in OAuth, OIDC and RISC- it will add a lot of complexity to have to re-establish control plane for each of these separately. We want to send all these events to a single end point for each receiver since all of these events are ultimately tied back to the same logical OAuth client.
·  Independent stream config for each profile adds a lot of complexity for the Receiver and only a few large Receivers want to be able to send streams directly to each sub-system. It's reasonable to push this complexity on the large Receivers to set up routers for SecEvents going to the relevant sub-system.
The group finally agreed that to deal with the balance of flexibility at the SecEvents level while also ensuring that multiple profiles could be managed all with a single control plane, SecEvent streams would be defined by the ability to get an access token from the Transmitter. The mechanism to obtain an access token can be defined by the Transmitter. If a Transmitter like Google wants to manage access tokens for the control plane for all profiles the same way, Google is free to do so.

NOTES

SAML might be an issue, but we are not addressing it for now, focus on OpenID Connect

we can break up the management api into: stream config, add/remove subject, status, verification
- stream config could be just the schema of the stream config, and then let each profile define the full api

Receivers having to define explicit list of events is not clear at secevent level

Stream Config Schema:

Allowing multiple streams per receiver allows receiver to send different sets of events (or profiles) to different service providers or to different sub-systems.

Asking Receivers to setup routers adds burden and also has privacy implications.

Questions
 - Is every profile on the same stream with the same management?
    - Google wants this for ease of little guy
    - Microsoft is concerned about separation of credentials/"service"/products
    - Dick notes that this will cause amalgamation of SaaS offerings, but accepts it

Set of credential could be profile specific or it could span multiple profiles (at secevent level).

Question: should events from multiple profiles be allowed on the same stream?
- profiles could specify key management, but the actual signature and encryption should be well specified only at secevent level
- concern with mixing profiles and avoiding authentication and key resolution
- might need a "oauth" level spec for authentication, client id/secret, access tokens, etc

If transmitter uses separate issuer that authorization server then trust problem between the two issuers. How does a receiver know they are related and trusted by each other.

Multiple keys can be published by the same authorization server, so different keys could use and still resolvable by same issuer. But you are less secure because any key can be used to sign both Id Tokens and SETs.

Multi tenant use case from Microsoft: IdP functionality provided for multiple tenants, each tenant has a unique guid, client apps that want to talk to all of these IdPs will be issued a single client id that works with all, the issuer in each case is different and it has the guid in the path. For 3LO flows the access token has the guid baked in (the user was authenticated to one of the tenants). In 2LO flows it is not clear. If the 2LO flow requires the tenant as parameter to issue an Access Token then the tenant is clear in all cases.

For different APIs in a management API we might need distinct OAuth 2 scopes to access management. For example: monitoring scope, stream config reader, stream config writer, etc

Most likely access token issuer, access token used with management API, is the same as SET issuer flowing on the given stream.

We shifted from client id+secret to access token as credentials. This allows on issuer per stream. Multiple streams between issuer and a receiver are possible, with different access tokens (if issuer chooses to offer that flexibility). At the management API level no need to support multiple streams.

AI: next f2f week of December 11 potentially at Oracle, Phil is making arrangements, 2 or 3 days

---

From: Phil Hunt <[email-masked]>
Date: Fri, 1 Dec 2017 17:28:17 -0800

+1 to all of Mike's comments. 

Regarding the minutes, i believe Tony also acknowledged that the current wg draft currently works for his needs. 

Regard toe being in event payload. I bristle strongly against event time/toe being in the payload. The set draft should stay out of the payload area and should NOT specify payload claims for demarcation purposes. 

Also i believe event time should be a top level claim to re-enforce the idea that a single logical event is being expressed even though multiple payloads are expressed. 

Related and extensions - these are complications that if anything undermine any value, if any, in going to a single event object. 

After seeing the new draft I came away with many more concerns about problems created vs a debatable problem solved - making events singular. 

Phil

> On Dec 1, 2017, at 12:03 PM, Mike Jones <[email-masked]> wrote:
> 
> What’s not well captured in these notes is the context that Annabelle’s draft was being proposed in the Singapore side meetings as a total replacement for the working group SET draft.  I believe that all the current working group draft editors and many others I’m aware of are opposed to starting over – which is what the new draft does.  Phil and I and others nonetheless had constructive conversations with Annabelle and Dick and others who did want to start over, providing actionable feedback on how to improve Annabelle’s draft, on the off chance that some parts of it would be used by the working group.  And I consciously left my name on as an author because if it would be adopted, I would want to remain involved.
>  
> Mike: If we were to be starting from scratch, this would be fine, but we are not. Draft is “full of breaking changes” relative to current IETF -03 draft.
> Tony: We need to be able to batch events (acknowledges that the current draft doesn’t support batching events, and wants to change that)
> Justin: Planned use cases put forward by people in the secevents session don’t align with one another, or intent behind current draft.
> Jon: We had implicit assumptions about how items in the events claim would be related, discovering others had different assumptions.
>  
> “exp” Claim
> Justin: Guidance/context for using “exp” claim is good, but NOT RECOMMENDED is too strong.
> Phil: A SET expiring suggests “history erases itself” which doesn’t make sense.
> Jon: “exp” is useful for de-duping tokens; NOT RECOMMENDED may be overkill.
> Leif: Receiver may use “exp” to decide if it should trust the SET.
> Justin: SETs may stick around for a long time as an audit trail. Maybe need a “freshness” claim that matches our desired semantics.
> Open issue: Should “exp” be NOT RECOMMENDED? Should we introduce a “freshness” claim?
>  
> “toe” Claim
> Justin: “toe” should be in event payload.
> Leif: Should be REQUIRED that recipients interpret “iat” as “toe” when “toe” is omitted.
> Annabelle: Transmitter might not know the time of event or want to share it.
> Consensus: “toe” claim should be in event payload, renamed “event_time”. If not present, the recipient MUST consider the time of event as unknown.
>  
> “txn” Claim
> Leif: Don’t need it if we have grouping events.
> Mike: Was intended to be general purpose, beyond just SET.
> Consensus: Move “txn” to a separate document. Add “event_id” as an OPTIONAL payload claim.
>  
> Consensus: Event payload claims should have different names from JWT claims, e.g. “event_type”, “event_subject”.
> Leif: “event_subject” payload claim should be mandatory.
> Miike: Should be OPTIONAL, sometimes subjects are implicit.
> Consensus: “event_subject” payload claim should be REQUIRED, with a subject identifier type that indicates if a subject is implicitly known.
> Mike: Don’t need to specify the subject identifier type; use duck typing.
> Marius: In some situations, we need both issuer+subject and email. With explicit types, we’d need an array of subjects. With duck typing, can just combine the subjects.
> Annabelle: Profiles that need multiple subjects could define a separate event payload claim, e.g. “subject_aliases”
> Leif: Need subject type to avoid identifier conflicts, help recipient interpret the SET.
> Justin: Could have a registry for subject claims.
> Justin: Value in defining email/phone/iss+sub subjects in SET: then they’re immediately available for everyone who wants to use them.
> Mike: Whatever we register should just use simple names, e.g. “email”, not URNs.
> Open issue: Duck typing with a registry of subject claims, or explicit typing with a registry of subject identifier types?
> Consensus: Use simple names for subject types or subject claims (whichever one we end up having a registry for).
> Phil: Need to canonicalize identifiers.
> Marius: Concerned about compatibility with OIDC since it doesn’t canonicalize identifiers.
> Rough consensus: Canonicalize the identifiers in the subject types/claims defined in SET. Profiles that need non-canonicalized variants can define them.
> Open issue: What language do we need for canonicalizing email, phone number, etc.?
>  
> Related Events
> Justin: Recipients should be REQUIRED to understand all events in a related event, or ignore the entire thing. Can define other grouping events with different semantics (e.g. BatchEvent, LooselyCoupledBagOfEvents).
> Leif: Could have a claim that identifies the semantics to use when interpreting related events, instead of different events for each.
> Tony: Might want a list of events to represent a transaction with rollback/commit semantics. Or they could be independent events.
> Justin: Could have an array of SETs as a separate JWT profile, rather than an array of event payloads inside one SET.
> Tony: Not sure if Related Events event would meet our needs, may want a Batched Events event.
> Dick: Adding Batched Events to the draft as another example would help demonstrate how these are supposed to be used, defined.
> Rough consensus: Add a Batched Events event to the draft.
> Rough consensus: Event payloads inside a related event can omit claims, and recipients MUST use whichever value for a claim is “nearest”, e.g. the one in the event payload if present, or the one in the outer Related Events payload if not.
>  
> Extending Events
> Mike: Extensions may want to add claims to the SET envelope.
> Phil: Don’t want two different structures for events and extensions that have to be parsed differently.
> Dick: Why not use the same rules for event payload claims as JWT defines for JWT claims?
> Rough consensus: Event extension guidance should just state that event payload claims MUST be Public Claims as defined in JWT.
>  
>