Subject: [Id-event] I-D Action: draft-ietf-secevent-token-01.txt

From: [email-masked]
Date: Thu, 09 Mar 2017 21:15:24 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Security Events of the IETF.

        Title           : Security Event Token (SET)
        Authors         : Phil Hunt
                          William Denniss
                          Morteza Ansari
                          Michael B. Jones
	Filename        : draft-ietf-secevent-token-01.txt
	Pages           : 18
	Date            : 2017-03-09

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), which can be
   optionally signed and/or encrypted.  A SET describes a statement of
   fact from the perspective of an issuer that it intends to share with
   one or more receivers.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-secevent-token/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-secevent-token-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-secevent-token-01

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Phil Hunt <[email-masked]>
Date: Thu, 9 Mar 2017 21:42:30 -0800

After a fair amount of feedback from the Seoul meeting and some feeback from the RISC group plus the recent discussions on the list, I did a substantial re-working of the editorial text.

Changes include:
* Adopting Transmitter/Receiver/Stream terminology
* Re-working of the sections into Data Plane vs. Control plane with new introductory text showing the relationship between transmitters and receivers (simplex and duplex).
* The Control Planes MTI only includes the GET request necessary for Receivers to check for errors.  
* The SCIM create and update features are moved to a separate OPTIONAL section

The optionality was also in aid to help some pilots get started. Some people would like to begin exchanging SETs and doing that with the GET was a simple way to get started.

Regarding the optionality of Create/Update in the Control Plane — there is some discussion in the group as to whether stream provisioning be automated or done through out-of-band administrative UIs. The early thinking in the RISC group was the number of relationships is small, so not a big priority. However some of us are exploring other event distribution systems and do have concerns about how IDPs and RPs tend to fan out in a hub and spoke fashion.  There may also some mobile scenarios.

This draft does not include any specific proposals (yet) for handling the subject enrolment requirement Dick has brought forward. I’d like to work through the use case some more before adding it.

Phil

Oracle Corporation, Identity Cloud Architect & Standards
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Mar 9, 2017, at 9:15 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 10 Mar 2017 18:39:16 +0200

I believe Phil is referring to his non-WG draft, 
https://datatracker.ietf.org/doc/draft-hunt-secevent-distribution/

Thanks,
	Yaron

On 10/03/17 07:42, Phil Hunt wrote:
> After a fair amount of feedback from the Seoul meeting and some feeback
> from the RISC group plus the recent discussions on the list, I did a
> substantial re-working of the editorial text.
>
> Changes include:
> * Re-working of the sections into Data Plane vs. Control plane with new
> introductory text showing the relationship between transmitters and
> receivers (simplex and duplex).
> The optionality was also in aid to help some pilots get started. Some
> people would like to begin exchanging SETs and doing that with the GET
> was a simple way to get started.
>
> Regarding the optionality of Create/Update in the Control Plane — there
> is some discussion in the group as to whether stream provisioning be
> automated or done through out-of-band administrative UIs. The early
> thinking in the RISC group was the number of relationships is small, so
> not a big priority. However some of us are exploring other event
> distribution systems and do have concerns about how IDPs and RPs tend to
> fan out in a hub and spoke fashion.  There may also some mobile scenarios.
>
> This draft does not include any specific proposals (yet) for handling
> the subject enrolment requirement Dick has brought forward. I’d like to
> work through the use case some more before adding it.
>
> Phil
>
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>
>
>
>
>
>
>
>> On Mar 9, 2017, at 9:15 PM, [email-masked]
>> <mailto:[email-masked]> wrote:
>>
>>