Subject: [Id-event] Fwd: New Version Notification for draft-hunt-idevent-token-02.txt

From: Phil Hunt <[email-masked]>
Date: Thu, 11 Aug 2016 14:52:22 -0700

This is an updated draft and contains a lot of the items from the discussion today.

Based on feedback from OpenID RISC and Connect WG calls, I have moved the “sub” in the examples to the event extension area. This allows each event spec to decide how they define or address a subject. It also avoids conflicts around “iss” when the event issuer is not the namespace of the “sub” claim.

The examples now show a consistent parsing pattern where the top level of the JSON structure is essentially an “envelope” that describes and validates the event from a publisher to a subscriber, and the nested JSON objects are the “payload” for the event.

The spec has been renamed to Security Event Token as part of making the terminology more consistent and to reflect that some events are not specifically about identity but are about other related things like IP addresses, sessions, tokens, web resources etc.

I recognize we don’t yet have consensus on this draft, but I’ve gone ahead and published draft 02 so the broader community can compare draft 02 with draft 01 to see the differences in event formats.  I expect to see more changes as the discussion continues.

Phil

@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-hunt-idevent-token-02.txt
> Date: August 11, 2016 at 1:25:50 PM PDT
> To: "William Denniss" <[email-masked]>, "Phil Hunt" <[email-masked]>, "Morteza Ansari" <[email-masked]>
> 
> 
> A new version of I-D, draft-hunt-idevent-token-02.txt
> has been successfully submitted by Phil Hunt and posted to the
> IETF repository.
> 
> Name:		draft-hunt-idevent-token
> Revision:	02
> Title:		Security Event Token (SET)
> Document date:	2016-08-11
> Group:		Individual Submission
> Pages:		15
> URL:            https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-hunt-idevent-token/
> Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-token-02
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-hunt-idevent-token-02
> 
> Abstract:
>   This specification defines the Security Event token which may be
>   distributed via a protocol such as HTTP.  A Security Event Token
>   (SET) is based on the JSON Web Token and may be optionally signed
>   and/or encrypted.  A SET describes a statement of fact that may be
>   shared by an event publisher with registered subscribers.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 17 Aug 2016 07:21:12 -0700

Vladimir,

Cc'ing back to the id-event list. 

I will put these in for consideration for the next draft. I have already re-worked some of the text based on feedback from Sarah as well. Hope to check into github later today. 

One thing for the group to discuss: 

Do we want?:
Option A: a single value event type attribute with an optional extensions attribute to force only a single main event type per SET?

Option B: Or, stay with current approach and clarify draft text that the intent is a single event with extensions (but a combo event would still be possible)?

Please respond on the id-event list. 

Phil

> On Aug 16, 2016, at 10:30 PM, Vladimir Dzhuvinov <[email-masked]> wrote:
> 
> 
>> On 16/08/16 19:39, Phil Hunt wrote:
>> Vladimir,
>> 
>> The discussion on the id-event list has been that only a single event should be expressed at a time.
> Thanks Phil for clarifying that a SET describes a single event. Could
> that be stated explicitly in the spec?
> 
> 
>> The reason for multi-event uris is to allow for extensions.  For example, you could have an OIDC logout event, but you might also have an extension to categorize the security event as a threat/observation/indicator (CTI Cybox terms) etc.  In figure 1 there is an example of an account reset having an extension showing the number of resets.
> I see now. I think I got confused by the name of the "events" attribute.
> What if it's named "event" instead?
> 
>> The other use case is that the same state change might infer two events from overlapping profiles.  For example an account reset in SCIM could be expressed as both a SCIM Account reset and a RISC account reset — since different specs may have overlapping definitions that are not quite the same.  Should a publisher publish one combined event to reflect that an event can be interpreted in two ways, or should two separate events be published for the same state change?  The discussion so far has been it should be two separate events because the “aud” is likely different.
>> 
>> So to sum up, I think the current thought is that an event should be one main event type plus any additional extensions for a single event.
> 
> I would like to propose the following wording in section 2.1:
> 
> event: A multi-valued String that contains one or more URIs representing
> the types of the event. [...]
> 
> 
> 
> Vladimir
> 
> PS: The second last paragraph on p. 4 has some bits of text left over
> from a previous edit.
> 
>> Phil
>> 
>> @independentid
>>> On Aug 16, 2016, at 8:55 AM, Vladimir Dzhuvinov via Openid-specs-ab <[email-masked]> wrote:
>>> 
>>> Hi Phil,
>>> 
>>> The spec appears well structured. Putting "sub" into an unambiguous context was a great idea! 
>>> 
>>> I have a question about the proposed format:
>>> 
>>> Each event in the "events" array is an URI, and may be enriched with extra info / context represented as a top-level JSON object that has the event URI as key. What if the issuer needs to emit multiple events with identical URIs in the "events" array, and they all require an additional context?
>>> 
>>> 
>>> 
>>> {
>>>     "events":[
>>>       "https://example.com/event-abc" <https://example.com/event-abc>,
>>>       "https://example.com/event-abc" <https://example.com/event-abc>
>>>     ],
>>>     "https://example.com/event-abc" <https://example.com/event-abc>:{
>>>        "xyz":5
>>>     },
>>>     "https://example.com/event-abc" <https://example.com/event-abc>:{
>>>        "xyz":10
>>>     }
>>> }
>>> 
>>> 
>>> Vladimir
>>> 
>>> 
>>> 
>>>> On 12/08/16 00:52, Phil Hunt via Openid-specs-ab wrote:
>>>> www.independentid.com <http://www.independentid.com/> <http://www.independentid.com/> <http://www.independentid.com/>[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> Begin forwarded message:
>>>>> 
>>>>> From: [email-masked] <mailto:[email-masked]>
>>>>> To: "William Denniss" <[email-masked]> <mailto:[email-masked]>, "Phil Hunt" <[email-masked]> <mailto:[email-masked]>, "Morteza Ansari" <[email-masked]> <mailto:[email-masked]>
>>>>> 
>>>>> 
>>>>> URL:            https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-02.txt <https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-02.txt>
>>>>> Status:         https://datatracker.ietf.org/doc/draft-hunt-idevent-token/ <https://datatracker.ietf.org/doc/draft-hunt-idevent-token/>
>>>>> Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-token-02 <https://tools.ietf.org/html/draft-hunt-idevent-token-02>
>>>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-hunt-idevent-token-02 <https://www.ietf.org/rfcdiff?url2=draft-hunt-idevent-token-02>
>>>>> 
>>>>> Abstract:
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> [email-masked] <mailto:[email-masked]>
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>>> -- 
>>> Vladimir Dzhuvinov
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
> 
> -- 
> Vladimir Dzhuvinov :: [email-masked]
> 
>