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

[Phil Hunt <[e-mail]>]

Inline
Phil

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

> On Mar 2, 2018, at 4:00 PM, Marius Scurtescu <[e-mail]> wrote:
> 
> On Fri, Mar 2, 2018 at 11:55 AM, Phil Hunt <[e-mail] <mailto:[e-mail]>> wrote:
> Marius,
> 
> Thanks.
> 
> Item 1 and 2 look reasonable.
> 
> Sounds good.
> 
>  
> 
> for Item 3, 4, I think the group should review. See below.
> 
> I also commented inline.
> 
>  
> 
> Given the submission deadline is Monday, it would be good to wait group confirmation of your proposals.
> 
> What that does mean in practical terms? If no one has objections we can go ahead? By when?
>  
> 
> Phil
> 
> Oracle Corporation, Identity Cloud Services Architect
> @independentid
> 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=>[e-mail] <mailto:[e-mail]>
> 
>> On Mar 2, 2018, at 10:30 AM, Marius Scurtescu <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 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,
> 
> <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?
> 
> I think jwtAud and jwtIss should be 403 and not 400.

<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.

> 
> 
>> 
>> 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.
> 
> 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.


> 
> 
> 
> 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.
> 
>  
>> 
>> 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=>
>> 
>> I am happy to send pull requests for all these changes. Let me know.
>> 
>> Thanks,
>> Marius
>> _______________________________________________
>> Id-event mailing list
>> [e-mail] <mailto:[e-mail]>
>> 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=>