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

From: Phil Hunt <[email-masked]>
Date: Thu, 29 Sep 2016 15:39:00 -0700

This is a minor update to the SET Token draft.  Based on the mailing list feedback, I made some revisions to the text on transactions and sequencing.  I dropped the term “idempotency” as this is not really the correct usage of the word.  

The issue I was trying to get at was whether SETs can be delivered in any sequence or whether there sequence is critical. For example in an Idempotent service, one cannot modify a resource that has not yet been created.  So while commands may be repeated achieving the same result, the sequence of different commands is critical. 8)

My gut feeling on sequencing (when needed) is most likely resolved by specs that profile SET Tokes by adding sequencing claim or defining “txn” for the purpose. There may be some delivery methods that can provide sequencing, but I think that has more to do with deployment architecture rather than protocol. For example, in a distributed system, the way events are delivered to a Feed Publishing Service might enable the Feed Publisher to guarantee order.  That’s not to say I haven’t overlooked a “duh” simple solution. 

This draft should be a good starting place for the SEC Event WG proposed charter.

Thanks,
 
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-06.txt
> Date: September 29, 2016 at 3:20:45 PM PDT
> To: "Michael B. Jones" <[email-masked]>, "William Denniss" <[email-masked]>, "Phil Hunt" <[email-masked]>, "Morteza Ansari" <[email-masked]>, "Michael Jones" <[email-masked]>
> 
> 
> A new version of I-D, draft-hunt-idevent-token-06.txt
> has been successfully submitted by Phil Hunt and posted to the
> IETF repository.
> 
> Name:		draft-hunt-idevent-token
> Revision:	06
> Title:		Security Event Token (SET)
> Document date:	2016-09-29
> Group:		Individual Submission
> Pages:		19
> URL:            https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-06.txt
> Status:         https://datatracker.ietf.org/doc/draft-hunt-idevent-token/
> Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-token-06
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-hunt-idevent-token-06
> 
> Abstract:
>   This specification defines the Security Event token, which may be
>   distributed via a protocol such as HTTP.  The Security Event Token
>   (SET) specification profiles the JSON Web Token (JWT) and may be
>   optionally signed and/or encrypted.  A SET describes a statement of
>   fact that may be shared by an event publisher with event 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: Alan Karp <[email-masked]>
Date: Thu, 29 Sep 2016 17:15:25 -0700

Phil Hunt <[email-masked]> wrote:

For example, in a distributed system, the way events are delivered to a
Feed Publishing Service might enable the Feed Publisher to guarantee
order.  That’s not to say I haven’t overlooked a “duh” simple solution.

Having worked with distributed systems for more years than I care to admit,
I doubt that you overlooked a "duh" solution.

--------------
Alan Karp