Subject: [Id-event] I-D Action: draft-ietf-secevent-delivery-00.txt

From: [email-masked]
Date: Fri, 28 Jul 2017 22:19:13 -0700

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

        Title           : SET Token Delivery Using HTTP
        Authors         : Phil Hunt
                          Marius Scurtescu
                          Morteza Ansari
                          Anthony Nadalin
                          Annabelle Richard Backman
	Filename        : draft-ietf-secevent-delivery-00.txt
	Pages           : 28
	Date            : 2017-07-28

Abstract:
   This specification defines how a series of security event tokens
   (SETs) may be delivered to a previously registered receiver using
   HTTP POST over TLS initiated as a push to the receiver, or as a poll
   by the receiver.  The specification also defines how delivery can be
   assured subject to the SET Token Receiver's need for assurance.

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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-secevent-delivery-00
https://datatracker.ietf.org/doc/html/draft-ietf-secevent-delivery-00

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: Mon, 31 Jul 2017 09:20:35 -0700

As requested by Yaron, I have posted the delivery draft unchanged as the WG draft.

Marius made a suggestion that as per discussion in Prague that the Verify Event be removed from the Delivery draft and potentially placed in an upcoming control plane draft (to be proposed).

After some thinking, I propose the Verify Event be placed into the SET Token draft. It would actually be a good thing to have at least one “normative” event defined in SET Token. 

If the group is agreeable, I am happy to propose some modified Verify Event definition text to move into the SET Token spec.  Note: SET Token is or is about to be WGLC.  Chairs: Can we consider this?

I would suggest we only move Verify to Control Plane if there is a specific reason (eg. distinct or separate use cases that may be specific to some profiles) why it is better suited there.

If there is no objection, I will:
* Remove the Verify Event from the Delivery Spec on its next regular update
* Update SET Token Spec with Verify Event, subject to guidance in regards to WGLC.

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
> On Jul 28, 2017, at 10:19 PM, [email-masked] wrote:
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Ddelivery_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=-776NP5LxWSJp_f1PMNn10AECHMGYqhgPsPTqXr4srE&s=pc0m7nhCLHj3Mab6Ppgz8m3HF_kwzH4EKFO6jtzNYfE&e= 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D00&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=-776NP5LxWSJp_f1PMNn10AECHMGYqhgPsPTqXr4srE&s=6jsUPOsyCumT0ZD-nr6TrlbMzPGgPWZ4OVQjSEr1aOo&e= 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D00&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=-776NP5LxWSJp_f1PMNn10AECHMGYqhgPsPTqXr4srE&s=IX4vI17s3YIk7uq1W2aVRxUHH8ybXQZxgyNJLr1H_Ug&e= 
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=-776NP5LxWSJp_f1PMNn10AECHMGYqhgPsPTqXr4srE&s=M-c_zQSJ7nJg1SbvMQqc2f2yJFUnTDPT9IMX_-h9Fyw&e= 
> 
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=-776NP5LxWSJp_f1PMNn10AECHMGYqhgPsPTqXr4srE&s=aTnebfvP2aZrcA1xIr41D3o8_5Qpyx_NGC7S1km7uKE&e=

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 31 Jul 2017 19:42:06 +0300

Hi Phil,

 From a procedural point of view (not taking any stand on whether this 
is a good change or not), the SET draft is absolutely open to changes. 
At most, we might decide that there've been too many changes and will 
call for a second WGLC at some point. Not a big deal.

Thanks,
	Yaron

On 31/07/17 19:20, Phil Hunt wrote:
> Marius made a suggestion that as per discussion in Prague that the 
> Verify Event be removed from the Delivery draft and potentially placed 
> in an upcoming control plane draft (to be proposed).
> 
> After some thinking, I propose the Verify Event be placed into the SET 
> Token draft. It would actually be a good thing to have at least one 
> “normative” event defined in SET Token.
> 
> If the group is agreeable, I am happy to propose some modified Verify 
> Event definition text to move into the SET Token spec.  Note: SET Token 
> is or is about to be WGLC.  Chairs: Can we consider this?
> 
> I would suggest we only move Verify to Control Plane if there is a 
> specific reason (eg. distinct or separate use cases that may be specific 
> to some profiles) why it is better suited there.
> 
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
> 
>> On Jul 28, 2017, at 10:19 PM, [email-masked] 
>> <mailto:[email-masked]> wrote:
>>
>>
>> until the htmlized version and diff are available at tools.ietf.org 
>> <http://tools.ietf.org>.
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Mike Jones <[email-masked]>
Date: Mon, 31 Jul 2017 19:05:33 +0000

I am strongly opposed to defining a normative event in the SET spec, as it would be a layering violation.  The purpose of the SET spec is to define syntax and semantics that applies to *all* SETs.

The purpose of defining specific events is to meet the needs of a particular event profile for a particular class of applications.  Any normative event definition would have to meet all the Requirements for SET Profiles (as described at https://tools.ietf.org/html/draft-ietf-secevent-token-02#section-3), including defining the key management discipline for that event's profile.  (As Leif discussed in Prague, even for identity scenarios, there are numerous potential key management strategies, some depending upon Web PKI and some not.)  Adding all this to the SET spec would be a confusing distraction.  Among other things, it would raise the mostly unanswerable question "Why is this event more special than others?".

				-- Mike

-----Original Message-----
From: Id-event [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Monday, July 31, 2017 9:42 AM
To: Phil Hunt <[email-masked]>; ID Events Mailing List <[email-masked]>
Cc: Marius Scurtescu <[email-masked]>
Subject: Re: [Id-event] I-D Action: draft-ietf-secevent-delivery-00.txt (and Verify Event)

Hi Phil,

 From a procedural point of view (not taking any stand on whether this is a good change or not), the SET draft is absolutely open to changes. 
At most, we might decide that there've been too many changes and will call for a second WGLC at some point. Not a big deal.

Thanks,
	Yaron

On 31/07/17 19:20, Phil Hunt wrote:
> Event definition text to move into the SET Token spec.  Note: SET 
> Token is or is about to be WGLC.  Chairs: Can we consider this?
> 
> specific reason (eg. distinct or separate use cases that may be 
> specific to some profiles) why it is better suited there.
> 
> @independentid www.independentid.com <http://www.independentid.com> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf
>> .org_doc_draft-2Dietf-2Dsecevent-2Ddelivery_&d=DwICAg&c=RoP1YumCXCgaW
>> HvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4
>> C_lLIGk&m=-776NP5LxWSJp_f1PMNn10AECHMGYqhgPsPTqXr4srE&s=pc0m7nhCLHj3M
>> ab6Ppgz8m3HF_kwzH4EKFO6jtzNYfE&e=
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_h
>> tml_draft-2Dietf-2Dsecevent-2Ddelivery-2D00&d=DwICAg&c=RoP1YumCXCgaWH
>> vlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C
>> _lLIGk&m=-776NP5LxWSJp_f1PMNn10AECHMGYqhgPsPTqXr4srE&s=6jsUPOsyCumT0Z
>> D-nr6TrlbMzPGgPWZ4OVQjSEr1aOo&e=
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf
>> .org_doc_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D00&d=DwICAg&c=RoP1
>> YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEiv
>> zjWwlNKe4C_lLIGk&m=-776NP5LxWSJp_f1PMNn10AECHMGYqhgPsPTqXr4srE&s=IX4v
>> I17s3YIk7uq1W2aVRxUHH8ybXQZxgyNJLr1H_Ug&e=
>>
>>
>>
>> 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>.
>>
>> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_inter
>> net-2Ddrafts_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&
>> r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=-776NP5LxWSJp_f1PMNn1
>> 0AECHMGYqhgPsPTqXr4srE&s=M-c_zQSJ7nJg1SbvMQqc2f2yJFUnTDPT9IMX_-h9Fyw&
>> e=
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
>> lman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpk
>> KY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=-776NP5LxW
>> SJp_f1PMNn10AECHMGYqhgPsPTqXr4srE&s=aTnebfvP2aZrcA1xIr41D3o8_5Qpyx_NG
>> C7S1km7uKE&e=
>>
> 

_______________________________________________
Id-event mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/id-event