Subject: [Id-event] small changes to draft-ietf-secevent-delivery

From: Marius Scurtescu <[email-masked]>
Date: Fri, 2 Mar 2018 10:30:29 -0800

I have a few other suggestions:

1. In section 1.2 we could drop the definition of Identity Provider and
Relying Party. I don't think these are necessary in this spec.

2. In section 2.1, the description of the PUSH delivery mode states that
the response must contain "Content-Type: application/json". I think that is
the case only for error responses, I think on success no Content-Type is
needed at all.

3. In section 2.2, it is stated that "the Event Receiver SHALL indicate an
HTTP Status 400 error with an error code as described in Section 2.4". I
think that some error codes should be matched by other 4xx codes (for
example 401 and 403). I think it would be useful to list all the possible
error codes and corresponding HTTP Status codes in this section and not
refer to 2.4,

4. In section 2.3.1, the description of maxEvents, at the very end. A
conflict between zero request events and returnImmediately is described and
the later should be ignored. I think this should not be a silent ignore but
an error condition,

The current spec is at:
https://tools.ietf.org/html/draft-ietf-secevent-delivery-01

I am happy to send pull requests for all these changes. Let me know.

Thanks,
Marius

---

From: Phil Hunt <[email-masked]>
Date: Fri, 2 Mar 2018 11:55:20 -0800

Marius,

Thanks.

Item 1 and 2 look reasonable.

for Item 3, 4, I think the group should review. See below.

Given the submission deadline is Monday, it would be good to wait group confirmation of your proposals.

Phil

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

> On Mar 2, 2018, at 10:30 AM, Marius Scurtescu <[email-masked]> wrote:
> 
> 1. In section 1.2 we could drop the definition of Identity Provider and Relying Party. I don't think these are necessary in this spec.
> 
> 2. In section 2.1, the description of the PUSH delivery mode states that the response must contain "Content-Type: application/json". I think that is the case only for error responses, I think on success no Content-Type is needed at all.
> 
> 3. In section 2.2, it is stated that "the Event Receiver SHALL indicate an HTTP Status 400 error with an error code as described in Section 2.4". I think that some error codes should be matched by other 4xx codes (for example 401 and 403). I think it would be useful to list all the possible error codes and corresponding HTTP Status codes in this section and not refer to 2.4,

<PH>The 4xx messages are assumed by the HTTP RFCs while the errors in sec 2.4 related to errors around jwt processing. We can call out specific 4xx errors that are likely to occur, but I find that people then have issues wondering if they can ever use the complete set of error conditions from RFC7231. 

Would people find it useful to clarify or give examples of how 7231 errors might occur?

I’m not sure which of the sec 2.4 error codes could be matched with 401 or 403. These are mostly JWT error conditions. Can you elaborate?

> 
> 4. In section 2.3.1, the description of maxEvents, at the very end. A conflict between zero request events and returnImmediately is described and the later should be ignored. I think this should not be a silent ignore but an error condition,
<PH>The value of 0 is used to allow a poller to acknowledge previously received SETs without having to process or wait for new events. Thus returnImmediately is assumed. Thus the value of returnImmediately is ignored.

Some participants indicated a desire to keep acknowledgement threads separate from SET polling threads.  Others wanted to be able to do both at the same time.
> 
> The current spec is at:
> https://tools.ietf.org/html/draft-ietf-secevent-delivery-01 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D01&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ne_ktq-vH7-ENPz2hHpvEBD9gZ8NVol5ZAKe9EeHvu8&s=Hlxm0ufeHaSgSiJeOwFFJrFyiarhtBVMckB9QCslj3Q&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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ne_ktq-vH7-ENPz2hHpvEBD9gZ8NVol5ZAKe9EeHvu8&s=uhRVJB8aZnVZHEY_MgIwN8ZjrBDaxt7YDmif4wyv6jg&e=

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 2 Mar 2018 16:00:33 -0800

> Item 1 and 2 look reasonable.

Sounds good.

> for Item 3, 4, I think the group should review. See below.

I also commented inline.

> confirmation of your proposals.

What that does mean in practical terms? If no one has objections we can go
ahead? By when?

> www.independentid.com
> [email-masked]
> <PH>The 4xx messages are assumed by the HTTP RFCs while the errors in sec
> 2.4 related to errors around jwt processing. We can call out specific 4xx
> errors that are likely to occur, but I find that people then have issues
> wondering if they can ever use the complete set of error conditions from
> RFC7231.
>
> I’m not sure which of the sec 2.4 error codes could be matched with 401 or
> 403. These are mostly JWT error conditions. Can you elaborate?
>

I think jwtAud and jwtIss should be 403 and not 400.

setType and dup may also need something else than 400.

> <PH>The value of 0 is used to allow a poller to acknowledge previously
> received SETs without having to process or wait for new events. Thus
> returnImmediately is assumed. Thus the value of returnImmediately is
> ignored.
>

Right, but to me with 0 and returnImmediately present the request is
invalid and I don't think that returnImmediately should be simply ignored

> Some participants indicated a desire to keep acknowledgement threads
> separate from SET polling threads.  Others wanted to be able to do both at
> the same time.
>

Understood.

> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D01&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ne_ktq-vH7-ENPz2hHpvEBD9gZ8NVol5ZAKe9EeHvu8&s=Hlxm0ufeHaSgSiJeOwFFJrFyiarhtBVMckB9QCslj3Q&e=>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=
> RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ne_ktq-vH7-
> ENPz2hHpvEBD9gZ8NVol5ZAKe9EeHvu8&s=uhRVJB8aZnVZHEY_
> MgIwN8ZjrBDaxt7YDmif4wyv6jg&e=
>
>
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 2 Mar 2018 16:23:02 -0800

Inline
Phil

> On Mar 2, 2018, at 4:00 PM, Marius Scurtescu <[email-masked]> wrote:
> 
> On Fri, Mar 2, 2018 at 11:55 AM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> Marius,
> 
> Thanks.
> 
> What that does mean in practical terms? If no one has objections we can go ahead? By when?
>  
> 
> Phil
> 
> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=L-kCx-OLcYfkKdS1eUcIKOBY6y5Jf8PQhbsLU2hVSuc&s=Zm52eLyjaGG_ZPMSegoNV0nSi3xEFnKDLeC0gopCEjA&e=>[email-masked] <mailto:[email-masked]>
> 
>> On Mar 2, 2018, at 10:30 AM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
>> 

<PH>
jwtAud and jwtIss are issues with the payload.  403 indicates the wrong authorization credential was used. E.g. a bad authorization header.

It is important to distinguish between an http authorization header and a malformed SET.
> setType and dup may also need something else than 400.

<PH>
I think dup is no longer needed as we changed language to allow recovery.

setType - We should maybe update the terminology to setEventUri indicating the receiver is refusing a specific event type.

406 is the closest, yet that code is about media types not being acceptable.  406 can occur if someone requests application/xml for example.

> Right, but to me with 0 and returnImmediately present the request is invalid and I don't think that returnImmediately should be simply ignored 
<PH>
See section 2.3.3, in particular acknowledge only (2.3.3.2).  “maxEvents”:0 is what makes a request ack only. It can be expressed in a more obvious way, but I believe the discussion was this was simpler overall.

returnImmediately:true in the case of 2.3.3.2 is redundant. It isn’t an error because control always returns immediately.  returnImmediately:false would however would be an error because there is nothing to return in section 2.3.3.2.

Looking at the text, it looks like we need to clarify that either an error is returned or just an acceptance when maxEvents is 0.

>> [email-masked] <mailto:[email-masked]>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ne_ktq-vH7-ENPz2hHpvEBD9gZ8NVol5ZAKe9EeHvu8&s=uhRVJB8aZnVZHEY_MgIwN8ZjrBDaxt7YDmif4wyv6jg&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ne_ktq-vH7-ENPz2hHpvEBD9gZ8NVol5ZAKe9EeHvu8&s=uhRVJB8aZnVZHEY_MgIwN8ZjrBDaxt7YDmif4wyv6jg&e=>

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 3 Mar 2018 14:41:04 +0200

Marius,

given the timeline, please make whatever changes you see fit, and 
present them in London with the understanding that the group might ask 
you to backtrack.

Thanks,
	Yaron

On 03/03/18 02:00, Marius Scurtescu wrote:
>     www.independentid.com <http://www.independentid.com>
>     [email-masked] <mailto:[email-masked]>
> 
>>     On Mar 2, 2018, at 10:30 AM, Marius Scurtescu
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     1. In section 1.2 we could drop the definition of Identity
>>     Provider and Relying Party. I don't think these are necessary in
>>     this spec.
>>
>>     2. In section 2.1, the description of the PUSH delivery mode
>>     states that the response must contain "Content-Type:
>>     application/json". I think that is the case only for error
>>     responses, I think on success no Content-Type is needed at all.
>>
>>     3. In section 2.2, it is stated that "the Event Receiver SHALL
>>     indicate an HTTP Status 400 error with an error code as described
>>     in Section 2.4". I think that some error codes should be matched
>>     by other 4xx codes (for example 401 and 403). I think it would be
>>     useful to list all the possible error codes and corresponding HTTP
>>     Status codes in this section and not refer to 2.4,
> 
>     <PH>The 4xx messages are assumed by the HTTP RFCs while the errors
>     in sec 2.4 related to errors around jwt processing. We can call out
>     specific 4xx errors that are likely to occur, but I find that people
>     then have issues wondering if they can ever use the complete set of
>     error conditions from RFC7231.
> 
>     I’m not sure which of the sec 2.4 error codes could be matched with
>     401 or 403. These are mostly JWT error conditions. Can you elaborate?
> 
> 
>>     4. In section 2.3.1, the description of maxEvents, at the very
>>     end. A conflict between zero request events and returnImmediately
>>     is described and the later should be ignored. I think this should
>>     not be a silent ignore but an error condition,
>     <PH>The value of 0 is used to allow a poller to acknowledge
>     previously received SETs without having to process or wait for new
>     events. Thus returnImmediately is assumed. Thus the value of
>     returnImmediately is ignored.
> 
> 
>     separate from SET polling threads.  Others wanted to be able to do
>     both at the same time.
> 
> 
> Understood.
> 
>>
>>     The current spec is at:
>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ne_ktq-vH7-ENPz2hHpvEBD9gZ8NVol5ZAKe9EeHvu8&s=uhRVJB8aZnVZHEY_MgIwN8ZjrBDaxt7YDmif4wyv6jg&e=>
> 
> 
> 
> 
> https://www.ietf.org/mailman/listinfo/id-event
>

---

From: Marius Scurtescu <[email-masked]>
Date: Sun, 4 Mar 2018 18:27:38 -0800

Let's go with 1 and 2, sending a pull requests, and we can discuss more
about 3 and 4. Comments inline.

On Fri, Mar 2, 2018 at 4:23 PM, Phil Hunt <[email-masked]> wrote:

>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=L-kCx-OLcYfkKdS1eUcIKOBY6y5Jf8PQhbsLU2hVSuc&s=Zm52eLyjaGG_ZPMSegoNV0nSi3xEFnKDLeC0gopCEjA&e=>
>> [email-masked]
>>
>> 3. In section 2.2, it is stated that "the Event Receiver SHALL indicate
>> an HTTP Status 400 error with an error code as described in Section 2.4". I
>> I’m not sure which of the sec 2.4 error codes could be matched with 401
>> or 403. These are mostly JWT error conditions. Can you elaborate?
>>
>
> jwtAud and jwtIss are issues with the payload.  403 indicates the wrong
> authorization credential was used. E.g. a bad authorization header.
>

I am not suggesting 401, but 403. The request is perfectly valid, but the
iss or aud presented are not allowed to send events to this receiver.

> I think dup is no longer needed as we changed language to allow recovery.

Maybe you are right, we can probably drop "dup". I don't see any value in
it for a Transmitter.

>
> setType - We should maybe update the terminology to setEventUri indicating
> the receiver is refusing a specific event type.
>
> 406 is the closest, yet that code is about media types not being
> acceptable.  406 can occur if someone requests application/xml for example.
>

setEventIdentifier? To go with the latest terminology in the SET spec.

Even 403 might be a could status in this case. 406 seems to be related to
the "Accept" header, and that's not the case here. 415?

How about invalid "typ" claim in the SET header?  415?

Also, how about 429 for too many requests?

> See section 2.3.3, in particular acknowledge only (2.3.3.2).
>  “maxEvents”:0 is what makes a request ack only. It can be expressed in a
> more obvious way, but I believe the discussion was this was simpler overall.
>
> returnImmediately:true in the case of 2.3.3.2 is redundant. It isn’t an
> error because control always returns immediately.  returnImmediately:false
> would however would be an error because there is nothing to return in
> section 2.3.3.2.
>
> Looking at the text, it looks like we need to clarify that either an error
> is returned or just an acceptance when maxEvents is 0.
>

Agreed with all of the above. I was suggesting to return an error for
maxEvents:0 and returnImmediately:false.

>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv
>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYq
>> PkAI1aLcLN4KZNA&m=ne_ktq-vH7-ENPz2hHpvEBD9gZ8NVol5ZAKe9EeHvu
>> 8&s=uhRVJB8aZnVZHEY_MgIwN8ZjrBDaxt7YDmif4wyv6jg&e=
>>
>>
>

---

From: Marius Scurtescu <[email-masked]>
Date: Sun, 4 Mar 2018 18:29:22 -0800

On Sat, Mar 3, 2018 at 4:41 AM, Yaron Sheffer <[email-masked]> wrote:

> Marius,
>
> given the timeline, please make whatever changes you see fit, and present
> them in London with the understanding that the group might ask you to
> backtrack.
>

I will not be in London, unfortunately. These are minor changes, but
feedback from the group would be great.

Thanks,
Marius

>>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.
>>> ietf.org_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D01&d=
>>> DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FV
>>> zBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ne_ktq-vH7-ENPz2hHp
>>> vEBD9gZ8NVol5ZAKe9EeHvu8&s=Hlxm0ufeHaSgSiJeOwFFJrFyiarhtBVMc
>>> kB9QCslj3Q&e=>
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
>>> ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCg
>>> aWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXP
>>> puYqPkAI1aLcLN4KZNA&m=ne_ktq-vH7-ENPz2hHpvEBD9gZ8NVol5ZAKe9
>>> EeHvu8&s=uhRVJB8aZnVZHEY_MgIwN8ZjrBDaxt7YDmif4wyv6jg&e=>
>>>
>>
>>
>>
>>