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

From: Erik Wahlström neXus <[email-masked]>
Date: Thu, 12 Nov 2015 19:26:17 +0000

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

---

From: Erik Wahlström neXus <[email-masked]>
Date: Thu, 12 Nov 2015 20:01:24 +0000

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 <[email-masked]> 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: 
>> 
>> "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
>> 
>> 
>> _______________________________________________
>> COSE mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/cose

---

From: Mike Jones <[email-masked]>
Date: Thu, 12 Nov 2015 20:38:29 +0000

FYI - I also wrote about this at http://self-issued.info/?p=1476 and as @selfissued<https://twitter.com/selfissued>.

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Erik Wahlström neXus
Sent: Thursday, November 12, 2015 11:26 AM
To: <[email-masked]>
Subject: [OAUTH-WG] A draft on CBOR Web Tokens (CWT)

Hi,

Abstract:

/ Erik

OAuth mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Thu, 12 Nov 2015 16:02:05 -0500

Thanks very much, Eric.

As we promised in Yokohama, the chairs of the COSE working group are currently running a consensus call thread about this very topic, and I’d encourage others to join that discussion. The thread starts here:

http://www.ietf.org/mail-archive/web/cose/current/msg00747.html

 — Justin

> On Nov 12, 2015, at 2:10 PM, Erik Wahlström neXus <[email-masked]> wrote:
> 
> Hi,
> 
> https://datatracker.ietf.org/doc/draft-wahlstroem-oauth-cbor-web-token/ <https://datatracker.ietf.org/doc/draft-wahlstroem-oauth-cbor-web-token/>
> 
> Abstract: 
> [1] https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00 <https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00>
> 
>

---

From: William Denniss <[email-masked]>
Date: Thu, 12 Nov 2015 19:19:26 -0800

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 <
[email-masked]> wrote:

> 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
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 12 Nov 2015 20:45:04 +0100

Hi Erik,

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Nov 2015 19:40:58 +0100

[only posting to OAuth list]

Hi William,

thanks for your quick review comments.

On 11/13/2015 04:19 AM, William Denniss wrote:
> 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
> <https://mailarchive.ietf.org/arch/search/?email_list=id-event&gbt=1&index=7qNUnaE9lt2LyayMnmNyWpZSIEM> in
> <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).
> 

For this IANA registry issue we have essentially two options:

a) Single registry: JWT and CWT claims listed in the same registry

b) Separate registries for JWT claims and for CWT claims.

The drawback about using two registries is the additional effort in
registering many, if not all, claims twice (with the potential risk to
get them misaligned). The advantage is to avoid confusion when some
entries are only applicable to the CWT or the JWT registry, respectively.

Note that we had the same question with regard to the token
introspection registry* where I argued that we should use a single
registry and we ended up defining two registries in the end.

In this specific case I believe there is value in using one registry
only since I don't see a reason for web and smart phone apps not using
the CBOR-based encoding. During the last few years I witnessed a lot of
activities that aimed to reduce the message size of protocols used in
the mobile space.

(*): I believe that Erik should update his token introspection draft
(see
https://tools.ietf.org/html/draft-wahlstroem-ace-oauth-introspection-01)
by registering the CWT claims to the token introspection defined registry.

> (https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#section-4)?

Maybe that section is not well motivated and should rather be placed
into the IANA consideration section instead. All it does is to
summarizes the CBOR-relevant information into a table.

> <https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#section-6>

Missing references will be fixed.

Ciao
Hannes

> 
> On Thu, Nov 12, 2015 at 12:01 PM, Erik Wahlström neXus
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>     Hi Carsten,
> 
>     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 <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > Hi Erik,
>     >
>     >> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 16 Nov 2015 15:09:11 +0000

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:[email-masked]]
Sent: 12 November 2015 19:19
To: Erik Wahlström neXus
Cc: Carsten Bormann; Hannes Tschofenig; Mike Jones; [email-masked]; <[email-masked]>; [email-masked]
Subject: Re: [COSE] A draft on CBOR Web Tokens (CWT)

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Carsten,

/ Erik

> On 12 Nov 2015, at 20:45, Carsten Bormann <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Erik,
>
>> [email-masked]<mailto:[email-masked]>

_______________________________________________
COSE mailing list
[email-masked]<mailto:[email-masked]>
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.

---

From: William Denniss <[email-masked]>
Date: Mon, 16 Nov 2015 13:31:55 -0800

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 <
[email-masked]> 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:[email-masked]]
> *Sent:* 12 November 2015 19:19
> *To:* Erik Wahlström neXus
> *Cc:* Carsten Bormann; Hannes Tschofenig; Mike Jones; [email-masked]; <
> [email-masked]>; [email-masked]
> *Subject:* Re: [COSE] A draft on CBOR Web Tokens (CWT)
>
>
>
> same claims defined twice in CWT and JWT with possibly conflicting meanings
> (and needless confusion even when they do match).
>
>
>
> Comparing
> this didn't need a separate entry in CWT too, but could just apply directly
> Is Section 4 "Summary of CBOR major types used by defined claims"
> normative (
> ------------------------------
>
> -- 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.
>

---

From: Bill Mills <[email-masked]>
Date: Mon, 16 Nov 2015 21:54:52 +0000 (UTC)

If there are structural differences in what CBOR can support it would be worthwhile to note that.  Examples of things supported in JWT that you can't do in CBOR could be very helpful to implementers.

     On Monday, November 16, 2015 1:32 PM, William Denniss <[email-masked]> wrote:

 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 <[email-masked]> 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:[email-masked]]
Sent: 12 November 2015 19:19
To: Erik Wahlström neXus
Cc: Carsten Bormann; Hannes Tschofenig; Mike Jones; [email-masked]; <[email-masked]>; [email-masked]
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 in Yokohama on the id-event list), 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 6Add xref to RFC7519 On Thu, Nov 12, 2015 at 12:01 PM, Erik Wahlström neXus <[email-masked]> wrote:Hi Carsten,

/ Erik

[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 16 Nov 2015 23:31:55 +0100

Bill Mills wrote:
> If there are structural differences in what CBOR can support it would be
> worthwhile to note that.  Examples of things supported in JWT that you
> can't do in CBOR could be very helpful to implementers.

Those don't exist, but there may be things you have to do in JSON that
you can (and want to) do in a better way in CBOR.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Nov 2015 07:22:39 +0000

Hi William,

You are indeed correct that the current document contains a list of one-by-one copies of claims from the JWT. The only difference is the data type. Probably it would have been better to just reference the semantic from the JWT spec and then state the new data type.

I fully understand the concern of defining CWT claims that have the same name as JWT claims but then different semantic. This would be terribly confusing.

Ciao
Hannes

From: William Denniss [mailto:[email-masked]]
Sent: 16 November 2015 22:32
To: Hannes Tschofenig
Cc: Erik Wahlström neXus; Carsten Bormann; Mike Jones; <[email-masked]>
Subject: Re: [COSE] A draft on CBOR Web Tokens (CWT)

On Mon, Nov 16, 2015 at 7:09 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi William,

Ciao
Hannes

From: William Denniss [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 12 November 2015 19:19
To: Erik Wahlström neXus
Cc: Carsten Bormann; Hannes Tschofenig; Mike Jones; [email-masked]<mailto:[email-masked]>; <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [COSE] A draft on CBOR Web Tokens (CWT)

1.

2.

3.

/ Erik

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Nov 2015 07:24:47 +0000

Hi Bill,

From what I can tell there are no differences in this regard. Of course, the data has to be encoded differently and so there is a need to state the new data type but beyond that I haven’t seen any restrictions yet. Of course, the COSE work is still ongoing and so it might be a bit too early to tell.

Ciao
Hannes

From: Bill Mills [mailto:[email-masked]]
Sent: 16 November 2015 22:55
To: William Denniss; Hannes Tschofenig
Cc: Carsten Bormann; <[email-masked]>
Subject: Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT)

On Monday, November 16, 2015 1:32 PM, William Denniss <[email-masked]<mailto:[email-masked]>> wrote:

Ciao
Hannes

1.

2.

3.

/ Erik

---

From: Bill Mills <[email-masked]>
Date: Tue, 17 Nov 2015 17:52:10 +0000 (UTC)

Is a data type mapping form JWT to CBOR sufficient then?

     On Monday, November 16, 2015 11:26 PM, Hannes Tschofenig <[email-masked]> wrote:

 #yiv5390846737 #yiv5390846737 -- _filtered #yiv5390846737 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv5390846737 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv5390846737 #yiv5390846737 p.yiv5390846737MsoNormal, #yiv5390846737 li.yiv5390846737MsoNormal, #yiv5390846737 div.yiv5390846737MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;}#yiv5390846737 a:link, #yiv5390846737 span.yiv5390846737MsoHyperlink {color:blue;text-decoration:underline;}#yiv5390846737 a:visited, #yiv5390846737 span.yiv5390846737MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv5390846737 p.yiv5390846737MsoAcetate, #yiv5390846737 li.yiv5390846737MsoAcetate, #yiv5390846737 div.yiv5390846737MsoAcetate {margin:0cm;margin-bottom:.0001pt;font-size:8.0pt;}#yiv5390846737 span.yiv5390846737EmailStyle17 {color:#1F497D;}#yiv5390846737 span.yiv5390846737BalloonTextChar {}#yiv5390846737 .yiv5390846737MsoChpDefault {} _filtered #yiv5390846737 {margin:72.0pt 72.0pt 72.0pt 72.0pt;}#yiv5390846737 div.yiv5390846737WordSection1 {}#yiv5390846737 Hi William,    You are indeed correct that the current document contains a list of one-by-one copies of claims from the JWT. The only difference is the data type. Probably it would have been better to just reference the semantic from the JWT spec and then state the new data type.    I fully understand the concern of defining CWT claims that have the same name as JWT claims but then different semantic. This would be terribly confusing.    Ciao Hannes    From: William Denniss [mailto:[email-masked]]
Sent: 16 November 2015 22:32
To: Hannes Tschofenig
Cc: Erik Wahlström neXus; Carsten Bormann; Mike Jones; <[email-masked]>
Subject: Re: [COSE] A draft on CBOR Web Tokens (CWT)    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 <[email-masked]> 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:[email-masked]]
Sent: 12 November 2015 19:19
To: Erik Wahlström neXus
Cc: Carsten Bormann; Hannes Tschofenig; Mike Jones; [email-masked]; <[email-masked]>;[email-masked]
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 in Yokohama on the id-event list), 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 Add xref to RFC7519   On Thu, Nov 12, 2015 at 12:01 PM, Erik Wahlström neXus <[email-masked]> wrote: Hi Carsten,

/ Erik

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Nov 2015 08:01:52 +0000

Hi Bill,

Ø  Is a data type mapping form JWT to CBOR sufficient then?

I initially thought but then I ran into the COSE work, which is not a mapping of the JOSE spec to CBOR. It is a re-write.
Ciao
Hannes

---

From: Justin Richer <[email-masked]>
Date: Wed, 18 Nov 2015 09:59:20 -0600

By the way, folks: 

If people disagree with COSE being a rewrite of JOSE, they should speak up in the COSE working group and say so. 

 — Justin

> On Nov 18, 2015, at 2:01 AM, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Bill,
>  
> [email-masked] <mailto:[email-masked]>