I don't know that I agree with several of the statements below. I have problems with the view that just doing a profile is sufficient for a very simple reason. What if I am presented with a CWT that is from a different profile?
In your example below, if an issuer was creating a "nbf" claim in an ID Token profile then it is not conforming to the profile and I would not have a real problem with the fact that the token could not be used by an entity that did not understand the profile. What happens to the space when the ID Token profile gets updated in five years and the "nbf" claim becomes a mandatory field to be included and understood? All of a sudden there is going to be a large number of entities in the system that are using the token without enforcing all of the constraints that are considered to be of importance to the issuer. This is a security problem. There is nothing that is being placed in a CWT to identify the profile that is being used. This means that if a token issuer is creating tokens that match different profiles and it does not use different keys for each of those profiles, then a token issued under one profile and with a specific set of assumptions about what is in the token and what it can be used for, can be provided to an application that is expecting the second profile and it might allow operations which would otherwise not be permitted. This is a security issue. Identifying the profile in the token is one possible answer, but it is one with lots of other problems. Who defines and identifies the profiles? How are they uniquely identified? How do you do the configuration on a small device to deal with company identified profiles? A more generic way of allowing for identification of what is and what is not so important might be one way to get around some of these issue Jim -----Original Message----- From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Tuesday, May 16, 2017 3:58 PM To: Carsten Bormann <c...@tzi.org> Cc: Jim Schaad <i...@augustcellars.com>; Samuel Erdtman <sam...@erdtman.se>; ace <Ace@ietf.org> Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token Profiles of CWTs will vary in which claims must be present, which are optional, and what the format of those claims are, when applicable. This is just like JWT, where application profiles provide that information. To make this concrete, OpenID Connect defines a profile of a JWT called an ID Token at http://openid.net/specs/openid-connect-core-1_0.html#IDToken. Note that is says which claims are REQUIRED and OPTIONAL. The profile also defines additional ID Token validation rules at http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation, which go beyond those in the JWT spec itself. This is how application profiles work. As a hypothetical example, it would be unhelpful for the ID Token profile if the underlying JWT spec had said that the "nbf" (not before) claim must be understood by all implementations, when this profile doesn't use it or contain validation rules for it. Even if a producer included a "nbf" claim, the consumer for this profile can safely ignore it, since no validation rules accompany it for ID Tokens. The same is true of all other JWT-defined claims. And the same needs to be true of the parallel CWT claims as well. For instance, we shouldn't force all CWT applications to understand and process "nbf" any more than we force all JWT applications to. There's nothing insecure about this but there is something efficient it that we must preserve - particularly for constrained implementations. -- Mike -----Original Message----- From: Carsten Bormann [mailto:c...@tzi.org] Sent: Tuesday, May 16, 2017 3:26 PM To: Mike Jones <michael.jo...@microsoft.com> Cc: Jim Schaad <i...@augustcellars.com>; Samuel Erdtman <sam...@erdtman.se>; ace <Ace@ietf.org> Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token On May 16, 2017, at 00:16, Mike Jones <michael.jo...@microsoft.com> wrote: > > I disagree with the suggestion (tracked in > https://github.com/erwah/ietf/issues/37) about claims that must be > understood. We shouldn’t force implementations to understand claims not used > by their application. See my comment in the issue. Not sure what is the “implementation” and what is the “application” here. If an application puts in a “must understand” claim key, I’m not sure who is forcing what here. If we don’t have “must understand” claim keys, then there is no way for an application to signal that necessity. Security issues with recipient applications that don’t correctly interpret the CWT they received, follow. Not good. Grüße, Carsten _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
