Re: [Id-event] Push Delivery: working group last call

[Marius Scurtescu <[e-mail]>]

comments inline...

On Wed, Dec 5, 2018 at 3:54 PM Richard Backman, Annabelle <richanna=
[e-mail]> wrote:

> Thanks for the feedback, Marius. Please see my [richanna]comments
> inline[/richanna].
>
>
>
> --
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *Id-event <[e-mail]> on behalf of Marius
> Scurtescu <marius.scurtescu=[e-mail]>
> *Date: *Wednesday, December 5, 2018 at 2:25 PM
> *To: *"[e-mail]" <[e-mail]>
> *Subject: *Re: [Id-event] Push Delivery: working group last call
>
>
>
> Hi all,
>
> I realize we are past December 2, not sure what the procedure is for
> feedback at this point. Nevertheless, here are a few comments and
> observations:
>
> - At the end of section 1 it is stated "have an out-of-band mechanism for
> exchanging configuration metadata". Does "out-of-band" exclude discovery
> mechanisms? Should we drop "out-of-band" and make the sentence more general?
>
> [richanna]
>
> The words “out-of-band” were intended to indicate that the mechanism is
> separate and apart from this delivery mechanism, and may occur over
> drastically different channels. (e.g., a web console, an email between
> admins, URLs written on a cocktail napkin :D) It is important that this
> text allow for offline mechanisms as well as online ones. Happy to consider
> alternate text that captures this better.
>
> [/richanna]
>
>
>
I was just worried that "out-of-band" is too strong and I was suggesting to
drop only that term. I think that all the options you mention are allowed.
Not feeling too strong about this.



> - Section 1.2, we also need a definition for "SET Recipient".
>
>
>
> [richanna]
>
> SET Recipient is defined in RFC8417
> <https://tools.ietf.org/html/rfc8417#section-1.2>. We could add a stub
> definition that points back to 8417, if having SET Transmitter defined here
> but not SET Recipient is confusing. Something like:
>
>
>
> SET Recipient
>
>    An entity that receives SETs through some distribution method, as
> defined in RFC8417.
>
> [/richanna]
>
>
Yes, I think either both or none. The definition above sounds good to me.
Do we want to add "as defined in RFC8417" to the definition of transmitter
as well?



> - Section 2, list of validations: should we add that the Recipient should
> also validate that it is willing to receive events from the given
> transmitter? In other words, the transmitter/issuer must be whitelisted.
>
> [richanna]
>
> Agreed.
>
> [/richanna]
>
>
> - Section 2, last paragraph: there is also the case when no response at
> all is received from the Recipient, in which case re-transmitting should be
> an option.
>
> [richanna]
>
> Agreed.
>
> [/richanna]
>
>
> - Figure 1: there is no signature. Should we add a signature so the
> example is more realistic?
>
>
>
> [richanna]
>
> Yes, our examples should demonstrate best practices.
>
> [/richanna]
>
>
>
> - Section 2.3: only 400 is mentioned as possible status code. What about
> 401, 403 or 429? For example, 403 is the appropriate status code if the SET
> is perfectly valid but the Recipient is not willing to accept events from
> the given transmitter/issuer.
>
>
>
> [richanna]
>
> The consensus at IETF 101 was to return everything as 400, and leave HTTP
> status codes to HTTP.
>
> [/richanna]
>

I see. The 403 case is important IMO, the fact that the SET is perfectly
valid but the recipient is not willing to accept from this transmitter. Is
the "jwtIss" error code meant to cover this case? I guess there is nothing
to change here then.


>
>
> Happy to send a pull request for these changes (if we agree on them). Let
> me know.
>
>
>
> [richanna]
>
> Yes, please! :D
>
> [/richanna]
>

Should I clone/fork off https://github.com/richanna/Identity-Events (you
sent me instructions at some point)?


>
> Best,
>
> Marius
>
>
>
> On 18/11/2018 10:05, Yaron Sheffer wrote:
>
> > Dear SecEvent participants,
>
> >
>
> >
>
> > This is to start a 2-week working group last call on
>
> > draft-ietf-secevent-http-push-03
>
> > <https://datatracker.ietf.org/doc/draft-ietf-secevent-http-push/> <https://datatracker.ietf.org/doc/draft-ietf-secevent-http-push/%3E,>;, until
>
> > Dec. 2. Please send any comments to the list. In addition, if you have
>
> > no comments but support publication of this document as-is, please make
>
> > your voice heard.
>
> >
>
> >
>
> > Thanks,
>
> >
>
> >
>
> >      Dick and Yaron
>
> >
>
>
>