Re: [Id-event] [UNVERIFIED SENDER] Re: AD review of draft-ietf-secevent-http-push-07

["Richard Backman, Annabelle" <[e-mail]>]

Pull request submitted: https://github.com/independentid/Identity-Events/pull/32

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/
 

On 4/27/20, 3:54 PM, "Richard Backman, Annabelle" <[e-mail]> wrote:

My impression was the changes were only in -push. If there some of these changes need to be made to -poll I can do that as well. Or is there a separate set of changes for -poll?

I will at least drop in on the virtual IIW. I am not sure how much of a presence I will be there, but happy to set aside some time to discuss either there or 1:1 via <video conference platform du jour as long as it isn't Zoom>.

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/
 

On 4/27/20, 3:30 PM, "Mike Jones" <[e-mail]> wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



Thanks Annabelle.  So you'll do Pull and I'll do Poll, right?  Let's check both of our changes into GitHub and review them for each other, and then publish together.

                                -- Mike

P.S.  Will you be at the virtual IIW this week, Annabelle?  Maybe we could virtually talk about the changes there, if doing so would be useful.

-----Original Message-----
From: Richard Backman, Annabelle <[e-mail]>
Sent: Monday, April 27, 2020 3:24 PM
To: Benjamin Kaduk <[e-mail]>
Cc: Mike Jones <[e-mail]>; [e-mail]; [e-mail]
Subject: [EXTERNAL] Re: [UNVERIFIED SENDER] Re: [Id-event] AD review of draft-ietf-secevent-http-push-07

Okay, I'll make the changes and get out an update.

Note that since all configuration of the transmitter/receiver relationship is out of scope per Section 1, saying that the expected identity for DNS-ID is "out of scope" is just rephrasing your suggestion of "the expected name will be configured" with language consistent with the rest of the text. __

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/


On 4/27/20, 3:08 PM, "Benjamin Kaduk" <[e-mail]> wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



On Mon, Apr 27, 2020 at 08:54:05PM +0000, Richard Backman, Annabelle wrote:
> I can put out an update, but I think I'm missing part of the conversation here.
>
> Here is what I understand the changes to be, all within -push:

I think that's right, as much as putting (3) out of scope pains me.

Thanks,

Ben

> 1. Section 1 should get the sentence "How SETs are defined and the process by which security events are identified for SET Recipients are specified in [RFC8417]."
>
> 2. In Section 5.3, replace "e.g., subject claims" with "PII" as was already done in -poll.
>
> 3. In Section 5.3, add text explaining that determining the expected service identity to match against using DNS-ID is out of scope.
>
> 4. In Privacy Considerations, add "SET Transmistters SHOULD attempt to deliver sets that are targeted to the specific business and protocol needs of subscribers", as already exists within -poll.
>
> –
> Annabelle Backman (she/her)
> AWS Identity
> https://aws.amazon.com/identity/
>
>
> On 4/24/20, 7:12 PM, "Mike Jones" <[e-mail]> wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> These suggestions make sense to me.  Do you want to do these Annabelle, or would you like me to?  If I do it, it will probably be early next week.
>
>                                 Thanks all,
>                                 -- Mike
>
> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Friday, April 24, 2020 5:44 PM
> To: Mike Jones <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [Id-event] AD review of draft-ietf-secevent-http-push-07
>
> Hi Mike,
>
> My apologies for yet another long delay.  I'll trim the bits that are in good shape (nearly all of them!).
>
> I also took another look at the "diff" (manually, that is) between push and poll, and found a few things in poll that should probably be here as well.
>
> Section 1 should get the sentence "How SETs are defined and the process by which security events are identified for SET Recipients are specified in [RFC8417]."
>
> In the thread for -poll we said that Section 5.3 of this document would get a s/e.g., subject claims/PII/ to match, but that doesn't seem to have happened yet.
>
> The poll Privacy Considerations have a note at the start of the section about "SET Transmistters SHOULD attempt to deliver sets that are targeted to the specific business and protocol needs of subscribers"; would a similar note make sense for us?
>
> On Fri, Feb 07, 2020 at 05:17:12PM +0000, Mike Jones wrote:
> > draft-ietf-secevent-http-push-08<https://tools.ietf.org/html/draft-ietf-secevent-http-push-08> was published to address these review comments.  (-09<https://tools.ietf.org/html/draft-ietf-secevent-http-push-09> addressed additional editorial nits.)  Descriptions of the changes made for these comments are inline, prefixed by "Mike>".
> >
> >
> >
> > -----Original Message-----
> > From: Id-event <[e-mail]> On Behalf Of Benjamin Kaduk
> > Sent: Tuesday, December 10, 2019 4:36 PM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: [Id-event] AD review of draft-ietf-secevent-http-push-07
> >
> >
> > Section 5
> >
> >
> >
> > I want to see how the discussion goes on poll's "Access Token Considerations" first, but we may want something like that as well.
> >
> >
> >
> > Mike> Yes, it makes sense to do that
>
> Since we no longer explicitly mention WWW-Authenticate in this document I won't insist on copying the Access Token Considerations over, but it could still be useful to do so.
>
> > Section 5.2
> >
> >
> >
> > RFC 6125 is great and I'm glad we're referencing it, but it does leave a couple of gaps to be specified for a full picture of application usage.
> >
> > Specifically, we should say what name from the certificate we validate (and, ideally, how the application knows what name it is expecting to see in that name field in the certificate).  Most applications these days will be using the DNS-ID, and perhaps something about wildcards and/or revocation info.  The last time I was making this comment on a document I pointed to RFC 8461 as a potential example to crib from, at least in terms of the types of things to talk about.
> >
> >
> >
> > Mike> I added DNS-ID.
>
> The DNS-ID is the part of the certificate that we compare a name against, but a comparison requires having two things -- since recipients are already configured, can't we say that the expected name will be configured as well?
>
> Thanks for all the updates!
>
> -Ben
>