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

[Marius Scurtescu <[e-mail]>]

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 <[e-mail]> wrote:

> Inline
> Phil
>
> Oracle Corporation, Identity Cloud Services Architect
> @independentid
> www.independentid.com
> [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]> 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]
>>
>> On Mar 2, 2018, at 10:30 AM, Marius Scurtescu <[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.
>

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.


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

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?


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

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

>
>
>
>
>
>> 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]
>> 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=
>>
>>
>