Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT)

[William Denniss <[e-mail]>]

You raise some good points, and perhaps that is relevant to future claims.
The spec as drafted, is a one-for-one copy of the standard JWT claims,
which is why I raised this point.

Is the goal a CBOR representation of a JWT? If so, can it be defined in
terms of a JWT?  Would the CNF claim then inherit that representation
(treating the JWE and JWK as their CBOR equivalents)?

Perhaps if you go the separate registry route, those claims that *are*
defined the same should at least normatively reference JWT?  I want to
avoid the whole "on behalf of" / "act as" fiasco where things can get
re-defined, and muddled.

On Mon, Nov 16, 2015 at 7:09 AM, Hannes Tschofenig <
[e-mail]> wrote:

> Hi William,
>
>
>
> I have been trying to do a document update to see how well a combined
> registry works and I have been wondering whether it is really worth the
> effort.
>
> To make a good judgment I looked at the CNF claim defined in
> draft-ietf-oauth-proof-of-possession. The CNF claim may contain
> sub-elements, such as a JWE or a JWK.
>
>
>
> If we translate the same mechanisms to the CWT (which makes sense) then we
> need to point to the respective COSE structures instead. Those do not only
> use a different encoding but also the functionality does not match the JOSE
> structures 100%. So, there are potentially differences. I am also not sure
> whether we really want to translate the full functionality of all the
> claims from JWT over to the CWT equivalent. It basically puts the burden on
> someone defining new claims (either in JWT or in CWT) to create the
> corresponding structures in a format they may not necessarily be familiar
> with or even care about. I have seen that happening in the RADIUS world
> protocol designers had to also define the equivalent structures for use
> with Diameter and, guess what, most of the definitions were wrong (since
> the authors did not care about Diameter when working on RADIUS).
>
>
>
> Ciao
> Hannes
>
>
>
>
>
> *From:* William Denniss [mailto:[e-mail]]
> *Sent:* 12 November 2015 19:19
> *To:* Erik Wahlström neXus
> *Cc:* Carsten Bormann; Hannes Tschofenig; Mike Jones; [e-mail]; <
> [e-mail]>; [e-mail]
> *Subject:* Re: [COSE] A draft on CBOR Web Tokens (CWT)
>
>
>
> Regarding the draft itself, a few comments:
>
>
>
> 1.
>
> Can we unify the claim registry with JWT? I'm worried about having the
> same claims defined twice in CWT and JWT with possibly conflicting meanings
> (and needless confusion even when they do match).
>
>
>
> Comparing
> https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#section-3.1.2
> and https://tools.ietf.org/html/rfc7519#section-4.1.2 which are nearly
> identical, I just don't see the value in re-defining it.
>
>
>
> We may add new standard claims to JWT in the future (I proposed one
> <https://mailarchive.ietf.org/arch/search/?email_list=id-event&gbt=1&index=7qNUnaE9lt2LyayMnmNyWpZSIEM> in
> Yokohama on the id-event list
> <https://www.ietf.org/mailman/listinfo/id-event>), it would be good if
> this didn't need a separate entry in CWT too, but could just apply directly
> (separately, I think you should consider this claim, as it helps prevent
> tokens from being re-used in the wrong context).
>
>
>
> 2.
>
> Is Section 4 "Summary of CBOR major types used by defined claims"
> normative (
> https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#section-4)?
> What is the intention of this section? I feel like it could probably be
> fleshed out a bit.
>
>
>
> 3.
>
> Add a xref to draft COSE spec in section 6
> <https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#section-6>
>
> Add xref to RFC7519
>
>
>
> On Thu, Nov 12, 2015 at 12:01 PM, Erik Wahlström neXus <
> [e-mail]> wrote:
>
> Hi Carsten,
>
> Thanks, and I agree. I’ve heard arguments for all three work groups.
>
> Borrowed some of your words to define the content of the draft :)
> It’s it essentially a JWT, phrased in and profiled for CBOR to address ACE
> needs, where OAuth needs COSE functionality, for object security.
>
> I’m open for letting the AD’s move it around, but having it right next to
> JWT seems right to me. Also open for the ACE WG. Feel it has less place in
> COSE for the same reasons JWT is not in the JOSE WG.
>
> / Erik
>
>
>
> > On 12 Nov 2015, at 20:45, Carsten Bormann <[e-mail]> wrote:
> >
> > Hi Erik,
> >
> > having this draft is a good thing.
> >
> > One thing I'm still wondering is what WG is the best place to progress
> > this.  We probably don't need to spend too much time on this because,
> > regardless of the WG chosen, the people in another WG can look at it.
> > Still, getting this right might provide some efficiencies.
> >
> > What is the technical content of this draft?  Is it a new token that
> > OAuth needs specifically for the new COSE-based applications of OAuth?
> > Is it a new token that is specifically there for addressing ACE needs?
> > Or is it essentially the same substance as JWT, but phrased in and
> > profiled for CBOR?
> >
> > Depending on the answer, CWT should be done in OAuth, ACE, or COSE.
> > (I'd rather hear the answer from the authors than venture a guess
> myself.)
> >
> > Grüße, Carsten
> >
> >
> >
> > Erik Wahlström neXus wrote:
> >> Hi,
> >>
> >> In the ACE WG a straw man proposal of a CBOR Web Token (CWT) was defined
> >> in the draft "Authorization for the Internet of Things using OAuth 2.0”
> >> [1]. We just broke out the CBOR Web Token into a separate draft and the
> >> new draft is submitted to the OAUTH WG. It can be found here:
> >>
> >> https://datatracker.ietf.org/doc/draft-wahlstroem-oauth-cbor-web-token/
> >>
> >> Abstract:
> >> "CBOR Web Token (CWT) is a compact means of representing claims to be
> >> transferred between two parties.  CWT is a profile of the JSON Web Token
> >> (JWT) that is optimized for constrained devices. The claims in a CWT are
> >> encoded in the Concise Binary Object Representation (CBOR) and CBOR
> >> Object Signing and Encryption (COSE) is used for added application layer
> >> security protection.  A claim is a piece of information asserted about a
> >> subject and is represented as a name/value pair consisting of a claim
> >> name and a claim value."
> >>
> >> / Erik
> >>
> >>
> >> [1] https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00
> >>
> >>
> >> _______________________________________________
> >> COSE mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/cose
>
> _______________________________________________
> COSE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose
>
>
>
> ------------------------------
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>