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
