Subject: [Id-event] Consensus :: Event Subject Claim

From: Dick Hardt <[email-masked]>
Date: Fri, 1 Dec 2017 08:49:58 -0800

Do we specify how a subject is included in a SET or let profiles define
that?
See event_subject claim in https://tools.ietf.org/html
/draft-backman-secevent-token-02#section-2.1as an example

We will track results here: https://github.com/IETF-SecEvent/Drafts/issues/2
<https://github.com/IETF-SecEvent/Drafts/issues/1>

Discussion to be on the mail list as usual, not in the issue tracker!

---

From: Justin Richer <[email-masked]>
Date: Mon, 4 Dec 2017 18:56:28 +0000

Yes, we should be clear that the event payload type specifies how to handle subjects and that the preferred method is via event_subject. 

We should also specify composition rules for plural events (at least the ones that we define).

 — Justin

> On Dec 1, 2017, at 4:49 PM, Dick Hardt <[email-masked]> wrote:
> 
> Do we specify how a subject is included in a SET or let profiles define that?
> See event_subject claim in https://tools.ietf.org/html/draft-backman-secevent-token-02#section-2.1 <https://tools.ietf.org/html/draft-backman-secevent-token-02#section-2.1>as an example
> 
> 
> We will track results here: https://github.com/IETF-SecEvent/Drafts/issues/2 <https://github.com/IETF-SecEvent/Drafts/issues/1>
> 
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 7 Dec 2017 11:33:22 -0800

+1

Defining an "event_subject" claim would help interop and add real value to
the SET spec.

We also need a way to specif multiple alternative subjects. We talked about
using a separate claim for that. Here is an example:

{
     "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
     "iss": "https://transmitter.example.com",
     "aud": [ "https://receiver.example.com" ],
     "iat": 1458496025,
     "event": {
       "event_type": "https://secevent.example.com/example_event",
       "event_subject": {
         "identifier_type": "urn:ietf:params:secevent:subject:email",
         "email": "[email-masked]"
       },
       "event_subject_alt": [
         {
           "identifier_type": "urn:ietf:params:secevent:subject:connect",
           "iss": "https://idp.example.com",
           "sub": "abc123",
         },
         {
           "identifier_type": "urn:ietf:params:secevent:subject:phone",
           "phone_number": "+40-123-456-789",
         },
       ],
       "event_time": 1458492425,
       "claim_1": "foo",
       "claim_2": "bar"
     }
   }

Important note: the event_subject and event_subject_alt claims are
orthogonal to the events vs event discussion, it can be applied to either.

Marius

On Mon, Dec 4, 2017 at 10:56 AM, Justin Richer <[email-masked]> wrote:

> Yes, we should be clear that the event payload type specifies how to
> handle subjects and that the preferred method is via event_subject.
>

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 7 Dec 2017 19:20:13 -0800

Hi Justin,

Clarifying what you said: do you mean the event payload type 
*determines* how to handle subjects? If so, this implies to me that we 
leave it to the profiles to decide what claim(s) define the subject, and 
what subject types are supported, with a preference to event_subject.

Did I get your meaning right?

Thanks,
	Yaron

On 04/12/17 10:56, Justin Richer wrote:
>> On Dec 1, 2017, at 4:49 PM, Dick Hardt <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> See event_subject claim in 
>> https://tools.ietf.org/html/draft-backman-secevent-token-02#section-2.1 <https://tools.ietf.org/html/draft-backman-secevent-token-02#section-2.1>as 
>> an example
>>
>>
>> We will track results here: 
>> https://github.com/IETF-SecEvent/Drafts/issues/2 
>> [email-masked] <mailto:[email-masked]>

---

From: Justin Richer <[email-masked]>
Date: Sun, 10 Dec 2017 11:25:20 -0500

Let me see if I can be more explicit. Given the proposed new event 
syntax, which I support fully and believe better captures my own goals 
and needs going into this WG in the first place, this is what I think 
our design space should be:

    An event has a type, that type determines what's inside of it and
    how to interpret it.

    SET defines not only the envelope and shell for an event (the stuff
    at the root level of the JWT) but also common elements, such as
    transactions, event times, and event subjects, available for use
    inside the payload. The same way that a JWT defines common elements
    for use inside the payload but allows arbitrary content based on the
    use case.

    SET defines the event_subject field, which is inside the event
    object, and also defines a set of common types for that field, such
    as email, phone, iss/sub, etc. These each have specific syntax and
    semantics.

    Since the event type gets to decide what its content *means* in the
    context of the event, it gets to decide whether to use the common
    event_subject field or make up its own bit of magic. It could also
    decide that it only makes sense to have certain types of event_subject.

Now what this does *NOT *mean is that the definition of event_subject, 
its content, and its syntax is left entirely up to profiles. Not at all! 
I believe we need to define a common structure, as the need for such a 
thing has already been expressed. If a profile wants a field named 
event_subject, it needs to use the one from SET. Same deal with "toe" 
and "txn" and anything else we want to add -- all of which, I argue, 
belong in the event object itself and not the envelope. Do you have a 
need to express an event time with different syntax (ISO date? julian 
calendar?), then you need to define a different field for that use. But 
go ahead, you're free to do that. It's your event, after all. And if you 
need a subject type, you could use the event_subject field and add your 
own type, or create a new field for your own use.

In the end, it's about interoperability. What are the common components 
that we care about? I fear that the WG participants are blinded by their 
own use cases and completely ignoring commonality. "I've got mine, 
forget everyone else" seems to be the mantra here. While I am very, very 
sensitive to the  argument of "it's been a long time, let's just ship 
it" -- I agree with Marius that ignoring feedback from people 
implementing this thing is foolhardy. That's not going to make SET 
stronger. It's going to make several different incompatible standards 
that people will need to manage.

It's been demonstrated that the new syntax works for more use cases 
without breaking current ones. The old structure demonstrably fails for 
several things that people want to use it for, which are clearly in 
scope for the problems it's meant to solve. We're not talking about 
making this spec do things it was never intended to. We're not talking 
about new use cases and scope creep. We're not talking about bike 
shedding. We're talking about taking real feedback from people trying to 
use the thing as-is who found it lacking. We ignore that at our peril, 
and to the detriment of the work here.

  -- Justin

On 12/7/2017 10:20 PM, Yaron Sheffer wrote:
> leave it to the profiles to decide what claim(s) define the subject, 
> and what subject types are supported, with a preference to event_subject.
>
>>> https://tools.ietf.org/html/draft-backman-secevent-token-02#section-2.1 
>>> <https://tools.ietf.org/html/draft-backman-secevent-token-02#section-2.1>as 
>>> an example
>>>
>>>