[Id-event] Review of draft-ietf-secevent-http-push-05

[Mark Dobrinic <[e-mail]>]

Hi id-event,

Read through draft 05, and here's some of my findings. With the
disclaimer that I am not fully aware of the historical discussions that
led to this draft.

- Section 2.0 mentions: "Once a SET has been validated and persisted,
the SET Recipient SHOULD immediately return a response ..."; there's a
bit of a gap on what to do when the SET was validated but failed to
persist. The errors don't (and probably shouldn't?) cover this, as this
might be considered business logic on the recipient's part? Section 2.2
talks about "appropriate retention requirements", which is nicely
formulated. This type of wording might be also snuck in to the language
of section 2.0's paragraph ("Once the SET has been validated and
persisted ..")

- Is the `description` field in the error response REQUIRED?

- Is there a reason why the `authentication_failed` failure response
should not return a HTTP/401 Unauthorized HTTP status code?

- Section 5.1 talks about the SET Issuer being authorized to deliver the
SET; should this not be the SET Transmitter?

- Section 5.4 on authenticating persisted SETs; Not sure if I understood
this correctly, but if a SET Transmitter can send a SET that was issued
by a different SET Issuer, how would the signature verification key be
resolved to authenticate the SET? 5.4 talks about the SET *Transmitter*
signing the SET, should this not be the SET *Issuer*? Or is this out of
scope?

Nitpicks:
- The sentence above the examples (e.g. in section 2.2) should always
end with a colon ':' ("The following is ... a SET:"), or end with a
period '.'. Don't care which, but looks nicer if it's the same
everywhere. I think only 2.2 falls out of line.

- The text above Figure 5 says "SET Receiver", should be "SET Recipient"

Hope this helps to wrap it up to publication :)


-- 
Regards,

Mark Dobrinic
Software Engineer and Identity Specialist
Curity AB

[e-mail]
www.curity.io