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

From: Marius Scurtescu <[email-masked]>
Date: Wed, 5 Dec 2018 14:25:04 -0800

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?

- Section 1.2, we also need a definition for "SET Recipient".

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

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

- Figure 1: there is no signature. Should we add a signature so the example
is more realistic?

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

Happy to send a pull request for these changes (if we agree on them). Let
me know.

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
>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 5 Dec 2018 14:27:39 -0800

I'm sure a PR would be appreciated Marius. Thanks for taking the time to
review!

On Wed, Dec 5, 2018 at 2:25 PM Marius Scurtescu <marius.scurtescu=
[email-masked]> wrote:

> - 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.
>
> - Figure 1: there is no signature. Should we add a signature so the
> example is more realistic?
>
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 6 Dec 2018 00:30:26 +0200

And additional reviews (or even emphatic support statements) would be 
highly appreciated. We cannot have the doc published with exactly one 
WGLC review.

Thanks,
	Yaron

On 06/12/2018 0:27, Dick Hardt wrote:
> On Wed, Dec 5, 2018 at 2:25 PM Marius Scurtescu 
> <marius.scurtescu=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi all,
> 
>     - 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?
> 
>     - 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.
> 
>     - 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.
> 
>     - 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.
> 
>     Happy to send a pull request for these changes (if we agree on
>     them). Let me know.
> 
>     Best,
>     Marius
> 
>     [email-masked] <mailto:[email-masked]>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 5 Dec 2018 23:54:18 +0000

Thanks for the feedback, Marius. Please see my [richanna]comments inline[/richanna].

--
Annabelle Richard Backman
AWS Identity

From: Id-event <[email-masked]> on behalf of Marius Scurtescu <marius.scurtescu=[email-masked]>
Date: Wednesday, December 5, 2018 at 2:25 PM
To: "[email-masked]" <[email-masked]>
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]

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

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

Happy to send a pull request for these changes (if we agree on them). Let me know.

[richanna]
Yes, please! :D
[/richanna]

Best,
Marius

> <https://datatracker.ietf.org/doc/draft-ietf-secevent-http-push/><https://datatracker.ietf.org/doc/draft-ietf-secevent-http-push/%3E,>;, until

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 5 Dec 2018 16:52:50 -0800

comments inline...

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

> *From: *Id-event <[email-masked]> on behalf of Marius
> Scurtescu <marius.scurtescu=[email-masked]>
> *Date: *Wednesday, December 5, 2018 at 2:25 PM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Id-event] Push Delivery: working group last call
>
>
>
> Hi all,
>
> 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.

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

> The consensus at IETF 101 was to return everything as 400, and leave HTTP

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

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

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 6 Dec 2018 20:57:39 +0000

Fork off of https://github.com/independentid/Identity-Events. That is the canonical location we have been using for work in progress; richanna/Identity-Events is itself a fork off that.

From: Id-event <[email-masked]> on behalf of Marius Scurtescu <marius.scurtescu=[email-masked]>
Date: Wednesday, December 5, 2018 at 4:53 PM
To: "richanna=[email-masked]" <richanna=[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Id-event] Push Delivery: working group last call

comments inline...

On Wed, Dec 5, 2018 at 3:54 PM Richard Backman, Annabelle <richanna=[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the feedback, Marius. Please see my [richanna]comments inline[/richanna].

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of Marius Scurtescu <marius.scurtescu=[email-masked]<mailto:[email-masked]>>
Date: Wednesday, December 5, 2018 at 2:25 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Push Delivery: working group last call

Hi all,

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.

[richanna]

SET Recipient

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?

[richanna]

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

[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