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

From: Mike Jones <[email-masked]>
Date: Sat, 12 Nov 2016 04:04:43 +0000

I just reviewed the changes in draft-hunt-idevent-token-06 and, for the record, I’m fine with them.

                                                       -- Mike

From: scim [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Thursday, September 29, 2016 3:39 PM
To: [email-masked]
Cc: [email-masked] WG <[email-masked]>; [email-masked] Ab <[email-masked]>; [email-masked]
Subject: [scim] Fwd: New Version Notification for draft-hunt-idevent-token-06.txt

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]<mailto:[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]<mailto:[email-masked]>>, "William Denniss" <[email-masked]<mailto:[email-masked]>>, "Phil Hunt" <[email-masked]<mailto:[email-masked]>>, "Morteza Ansari" <[email-masked]<mailto:[email-masked]>>, "Michael Jones" <[email-masked]<mailto:[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<http://tools.ietf.org>.

The IETF Secretariat