Re: [Id-event] WG Last Call for draft-ietf-secevent-token-02

Thanks for the useful review comments, Marius.  The proposed resolutions that Annabelle and I discussed in-person are as follows.

From: Id-event [mailto:id-event-bounces@ietf.org] On Behalf Of Marius Scurtescu
Sent: Wednesday, August 2, 2017 2:46 PM
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: SecEvent <id-event@ietf.org>
Subject: Re: [Id-event] WG Last Call for draft-ietf-secevent-token-02

The abstract mentions "issuer" and "receiver" in the last sentence. "receiver" does not sound right (that should be used in the context of a transmitter), but I don't have a better suggestion. Audience?

JWT [RFC 7519], JWS, JWE, etc. uniformly use the term “recipient” for this concept.  I believe we should do the same.

The last paragraph of section 1 mentions "subscriber". I think it should be either "receiver" or "audience".

“recipients” seems right here again, both for consistency sake, and because the plain English meaning matches the intended semantics.

The explanation for figure 1 states that the issuer denotes the transmitter. If the issuer and the transmitter are assumed to be the same entity, then the transmitter definition in section 1.2 should make that clear.

I believe that the “transmitter” is intended to be able to be different than the “issuer”.  JWT uses the term “issuer” and not “transmitter”, FYI.  I believe that some of the uses of “transmitter” should actually be “issuer” – in particular this needs to be changed “An "iss" claim, denoting the Event Transmitter.”  An “Event Issuer” definition probably needs to be also added.  I’ll take a crack and normalizing this terminology usage, both to match JWT, and to make the “issuer” / “transmitter” distinction clear.

Figure 3, I think the "sub" claim should be nested in the event, next to the issuer that provides the correct context. The "iss" and "sub" definitions in 2.1 also touch on this, providing conflicting advice.

OK, in this case, I think I’m fine with the proposed change.

Section 2,1, definition of "nbf". The definition says that this is the event time. I see two problems:
- the name suggest "not before", not exactly the same as event time
- there can be multiple events
maybe this claim should be dropped?

At least Annabelle and I agreed with you that dropping this claim description from the SET makes sense, as it’s described usage is currently kind of a hack.  (“nbf” could still be used by some profiles in its usual JWT manner without the SET spec saying anything about it.)  We propose replacing it with the “toe” (time of event) claim described in the thread “[Id-event] Replacing "nbf" claim with a new "toe" claim”.

Section 2.1, definition of "exp". Omitting this claim is the short term solution to the confusion issue. Why not mention that and that it SHOULD NOT be used?

It’s said that it should not be used because it’s one of the most commonly used claims in other JWTs and this paragraph gives us a place to describe the rationale for not using it in SET profiles.

Section 2.1, definition of "events". It states that all events must refer to the same logical event. Lately in discussions we reached the conclusion that all events in a SET should be defined in the same profile, which is a stronger requirement. I think this definition should mention that.

I’m OK adding a statement that they should all be from profiles with compatible claims usage, which I think is what you’re actually after.

Regarding events and profiles. There was a proposal to add a new claim to uniquely identify the profile. I think we need to discuss that.

As discussed on the list, the problem with adding a new “profile” claim is that it duplicates information already derivable from the event URIs.  This can lead to error conditions that are otherwise impossible, because inconsistencies can arise.  Also, per the previous reply events need to be from compatible profiles – not necessarily the same profile – and so a singleton “profile” claim wouldn’t actually work in the general case.

Figure 5. Maybe a signed example would be better, especially that the next paragraph mentions that signatures or encryption should be used.

Unsigned keeps the draft shorter. ;-)

Section 4.5, second paragraph. Mentions that "nonce" is also required, but that is not actually true. Id Tokens issued at the token endpoint for example will not have it. I suggest we drop the whole paragraph.

Good catch.  It should really be qualified to say “it would not contain the correct "nonce" claim value for the ID Token to be accepted in contexts for which substitution is possible”.

                                                                Thanks again, Marius!
                                                                -- Mike
Marius

On Mon, Jul 31, 2017 at 1:40 PM, Yaron Sheffer <yaronf.ietf@gmail.com<mailto:yaronf.ietf@gmail.com>> wrote:
This is to announce working group last call on this draft (https://datatracker.ietf.org/doc/draft-ietf-secevent-token/).

Please send your comments to the list. Even if you are perfectly happy with the draft, please let us know that you support its publication as-is by posting to the list.

Because of the summer holidays, this last call is open for 3 weeks, until Aug. 21.

Thanks,
    Dick and Yaron

_______________________________________________
Id-event mailing list
Id-event@ietf.org<mailto:Id-event@ietf.org>
https://www.ietf.org/mailman/listinfo/id-event