Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

From: Samuel Erdtman <[email-masked]>
Date: Sun, 14 May 2017 12:40:06 +0200

Hi Jim,

Thanks for your review and comments, see some initial replies inline.

On Sat, Apr 22, 2017 at 8:47 PM, Jim Schaad <[email-masked]> wrote:

> Not ready to ship.
>
>
> * I find the text for NumericDate confusing and would suggest this is a
> cleaner wording.
>
> The "NumericDate" term has the same meaning, syntax and
> Processing rules as the "NumericDate" term defined in Section 2 of
> JWT [RFC7519], except that the CBOR numeric representation
> (Section 2.4.1 of [RC7049]) is used.  The encoding is modified so that
> the leading tag (6.1 or 0xC1) MUST be omitted.
>
> <Note above text kills the direct need for section 5.>
>

Could make sense, I created an issue in the issue tracker to look at this.

>
> * What is a "CWT NumericDate" ?  Why is this not just a "NumericDate"?  You
> should be consistent on how you are using this and the "StringOrURI" type
> identifier.  Either use the CWT prefix or don't.
>

Makes sense to me, created an issue in the issue tracker to address this.

>
> * s/except that a CWT StringOrURI/except that for a CWT, StringOrURI/
>

 Makes sense to me, created an issue in the issue tracker to address this.

> * The algorithm for doing nesting detection is a gross abuse of the content
> type parameter and can be far more easily done based on the already present
> tagging of the COSE object.
>

Could you please explain a bit more, we are using the COSE tags but have
made
them optional if the application for example only uses one thyme then it
would
always know what to do and would not need to parse the tag saving a byte.

>
> * Break section 8 into multiple paragraphs that deal with different types
> of
> issues.
>

Might be reasonable I have created an issue in the issue tracker so that
the
comment is not lost.

>
> * In section 8, the first sentence implies to me that you believe that COSE
> is more of a problem that breaking of cryptographic algorithms, trust of
> certificates/keys.  Not sure what needs to be done, but better clarity may
> be a good idea.
>

Added this to the previously mentioned issue to address this to since it is
in the same section

>
> * I have not done any validation of the examples.   You might want to have
> an example which uses the real for one of the time types.
>

Sorry, but I don´t get it could you add some more context.

>
> Jim
>
>
> -----Original Message-----
> From: Ace [mailto:[email-masked]] On Behalf Of Kepeng Li
> Sent: Thursday, April 20, 2017 2:53 PM
> To: [email-masked]
> Cc: Hannes Tschofenig <[email-masked]>
> Subject: [Ace] [ace] WGLC on draft-ietf-ace-cbor-web-token
>
> In Chicago, it was decided that we were going to WGLC the ACE CBOR Web
> Token
> draft.
>
> So this starts a working group last call for draft-ietf-ace-cbor-web-token
> for submission as a Standards Track RFC, ending on 24:00 PDT on Tuesday,
> May
> 2, 2017.
>
> The specification is available at:
> https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-04
>
> An HTML-formatted version is also available at:
> http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-04.html
>
> Thanks,
>
>
> Kind Regards
> Kepeng & Hannes
>
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Jim Schaad <[email-masked]>
Date: Sun, 14 May 2017 13:12:06 -0700

From: Samuel Erdtman [mailto:[email-masked]] 
Sent: Sunday, May 14, 2017 3:40 AM
To: Jim Schaad <[email-masked]>
Cc: ace <[email-masked]>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

Hi Jim,

On Sat, Apr 22, 2017 at 8:47 PM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

Not ready to ship.

Could you please explain a bit more, we are using the COSE tags but have made 
them optional if the application for example only uses one thyme then it would 
always know what to do and would not need to parse the tag saving a byte.

[JLS] The concept is pretty easy to explain.

If you are in a situation where the full description of the CWT – including nesting layering – is known from a profile, then there would be no need to have any COSE tags present on any layer of the CWT message.  I would however highly discourage using this situation for anything but a single layer CWT such as one that is based on the COSE_Encrypt0 message without any inner layering.  Doing otherwise is going to mean that libraries would be unable to automatically unwrap all of the layers on their own, but would need guidance on each layer as it was processed.

In the current document in step 5 of section 7.2, there is an assumption that a COSE tag is going to exist in order to distinguish between the different types of COSE messages – I would not that these tags are not explicitly called for in section 7.1 – so the algorithm that I am going to suggest means that they are supposed to be present not implicit in any event.

In section 7.2 in step 7 the algorithm becomes:

If the payload starts with one the of COSE identification tags, then the message is recursive – go to step 1, wash rinse and repeat.

* Break section 8 into multiple paragraphs that deal with different types of
issues.

Might be reasonable I have created an issue in the issue tracker so that the 
comment is not lost.

Added this to the previously mentioned issue to address this to since it is in the same section 

[JLS] Use the value of “1444064944.5” for one of the time values.  Although I doubt that less than second resolution is needed in almost any case, having an example where it is given is still a good idea.
 
Jim

Jim

-----Original Message-----
From: Ace [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Kepeng Li
Sent: Thursday, April 20, 2017 2:53 PM
To: [email-masked] <mailto:[email-masked]> 
Cc: Hannes Tschofenig <[email-masked] <mailto:[email-masked]> >
Subject: [Ace] [ace] WGLC on draft-ietf-ace-cbor-web-token

In Chicago, it was decided that we were going to WGLC the ACE CBOR Web Token
draft.

So this starts a working group last call for draft-ietf-ace-cbor-web-token
for submission as a Standards Track RFC, ending on 24:00 PDT on Tuesday, May
2, 2017.

Thanks,

Kind Regards
Kepeng & Hannes

_______________________________________________
Ace mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/ace

---

From: Samuel Erdtman <[email-masked]>
Date: Mon, 15 May 2017 11:22:58 +0200

Thanks for clarifications Jim, see my comments inline.

Mike, there is a question for you inlined too.

On Sun, May 14, 2017 at 10:12 PM, Jim Schaad <[email-masked]> wrote:

>
>
>
>
> *From:* Samuel Erdtman [mailto:[email-masked]]
> *Sent:* Sunday, May 14, 2017 3:40 AM
> *To:* Jim Schaad <[email-masked]>
> *Cc:* ace <[email-masked]>
> *Subject:* Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token
>
>
>
> Hi Jim,
>
> If you are in a situation where the full description of the CWT –
> including nesting layering – is known from a profile, then there would be
> no need to have any COSE tags present on any layer of the CWT message.  I
> would however highly discourage using this situation for anything but a
> single layer CWT such as one that is based on the COSE_Encrypt0 message
> without any inner layering.  Doing otherwise is going to mean that
> libraries would be unable to automatically unwrap all of the layers on
> their own, but would need guidance on each layer as it was processed.
>
>
>
> In the current document in step 5 of section 7.2, there is an assumption
> that a COSE tag is going to exist in order to distinguish between the
> different types of COSE messages – I would not that these tags are not
> explicitly called for in section 7.1 – so the algorithm that I am going to
> suggest means that they are supposed to be present not implicit in any
> event.
>
>
>
> If the payload starts with one the of COSE identification tags, then the
> message is recursive – go to step 1, wash rinse and repeat.
>

I think I see your point. In the case of nested CWTs you would like to
mandate the inner layer to have a COSE tag indicating the message type. But
in cases where e.g. transport is done over CoAP you don´t feel it is as
important.
I personally would like to go all the way and mandate the COSE tag for all
CWT messages nested or not but that would add some extra bytes i.e. not
good in all cases.

Maybe a compromise and mandate it for inner object in nested CWTs.
@Mike would you like to comment to before we decide on a path forward.

> Makes sense, as you say it might not be a core case but there should be at
least one example of it if we support it. I have created a ticket to
address it.

---

From: Mike Jones <[email-masked]>
Date: Mon, 15 May 2017 21:16:50 +0000

I agree that for nested CWTs, it’s OK to mandate that the appropriate tags be prefixed to the inner CWT, if that’s the mechanism we decide to use to encode and detect nested JWTs.  That would then raise the question though, of whether we also would continue to mandate the use of the CWT content-type or whether we would drop this.  I think it’s better that we specify one mechanism for detecting nested CWTs, rather than having two.

Before we decide this, I’d like to confirm an assumption about COSE operations and COSE CBOR tags.  I believe that the COSE crypto operations *do not* cover the CBOR COSE tag, such as the COSE_Sign tag for signed objects.  If this is the case, it means that a COSE object without tags can have the appropriate tag prefixed to it without changing the crypto (and that similarly, a CWT tag could also be added without changing the crypto).  Is this correct?  If so, then using CBOR tags would be fine for the inner CWT in a nested CWT, since you could create the inner CWT without any tags and then later decide to put it in a nested CWT without re-signing, etc.  If this is the case, I’d be OK with always prefixing the inner CWT in a nested CWT with CWT and COSE CBOR tags.  Whereas if adding the tags requires redoing the crypto, I’d rather stay with the current approach.

                                                                -- Mike

From: Samuel Erdtman [mailto:[email-masked]]
Sent: Monday, May 15, 2017 2:23 AM
To: Jim Schaad <[email-masked]>; Mike Jones <[email-masked]>
Cc: ace <[email-masked]>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

On Sun, May 14, 2017 at 10:12 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:

From: Samuel Erdtman [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, May 14, 2017 3:40 AM
To: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Cc: ace <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

Hi Jim,

On Sat, Apr 22, 2017 at 8:47 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
Not ready to ship.

I think I see your point. In the case of nested CWTs you would like to mandate the inner layer to have a COSE tag indicating the message type. But in cases where e.g. transport is done over CoAP you don´t feel it is as important.
I personally would like to go all the way and mandate the COSE tag for all CWT messages nested or not but that would add some extra bytes i.e. not good in all cases.
Maybe a compromise and mandate it for inner object in nested CWTs.
@Mike would you like to comment to before we decide on a path forward.

[JLS] Use the value of “1444064944.5” for one of the time values.  Although I doubt that less than second resolution is needed in almost any case, having an example where it is given is still a good idea.
Makes sense, as you say it might not be a core case but there should be at least one example of it if we support it. I have created a ticket to address it.

Jim

Jim

-----Original Message-----
From: Ace [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kepeng Li
Sent: Thursday, April 20, 2017 2:53 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Subject: [Ace] [ace] WGLC on draft-ietf-ace-cbor-web-token

Thanks,

Kind Regards
Kepeng & Hannes

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 15 May 2017 23:25:21 +0200

I'd say use a tag unless there is information from the context, such as a media type or coap content format. 

Sent from mobile

> On 15. May 2017, at 11:22, Samuel Erdtman <[email-masked]> wrote:
>

---

From: Jim Schaad <[email-masked]>
Date: Mon, 15 May 2017 14:31:00 -0700

It is correct that the tag can be added and subtracted at will w/o changing anything.

From: Mike Jones [mailto:[email-masked]] 
Sent: Monday, May 15, 2017 2:17 PM
To: Samuel Erdtman <[email-masked]>; Jim Schaad <[email-masked]>
Cc: ace <[email-masked]>
Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token

                                                                -- Mike

From: Samuel Erdtman [mailto:[email-masked]] 
Sent: Monday, May 15, 2017 2:23 AM
To: Jim Schaad <[email-masked] <mailto:[email-masked]> >; Mike Jones <[email-masked] <mailto:[email-masked]> >
Cc: ace <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

On Sun, May 14, 2017 at 10:12 PM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

From: Samuel Erdtman [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Sunday, May 14, 2017 3:40 AM
To: Jim Schaad <[email-masked] <mailto:[email-masked]> >
Cc: ace <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

Hi Jim,

Not ready to ship.

 

 
Jim

Jim

-----Original Message-----
From: Ace [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Kepeng Li
Sent: Thursday, April 20, 2017 2:53 PM
To: [email-masked] <mailto:[email-masked]> 
Cc: Hannes Tschofenig <[email-masked] <mailto:[email-masked]> >
Subject: [Ace] [ace] WGLC on draft-ietf-ace-cbor-web-token

Thanks,

Kind Regards
Kepeng & Hannes

---

From: Mike Jones <[email-masked]>
Date: Mon, 15 May 2017 21:43:57 +0000

Thanks for confirming this, Jim.  Since that’s the case, I’m fine with us going with requiring tags for the inner nested CWTs and dropping the use of the CWT content-type for this purpose.

                                                                -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Monday, May 15, 2017 2:31 PM
To: Mike Jones <[email-masked]>; 'Samuel Erdtman' <[email-masked]>
Cc: 'ace' <[email-masked]>
Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token

To: Samuel Erdtman <[email-masked]<mailto:[email-masked]>>; Jim Schaad <[email-masked]<mailto:[email-masked]>>

                                                                -- Mike

To: Jim Schaad <[email-masked]<mailto:[email-masked]>>; Mike Jones <[email-masked]<mailto:[email-masked]>>

Hi Jim,

Jim

Jim

-----Original Message-----
From: Ace [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kepeng Li
Sent: Thursday, April 20, 2017 2:53 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Subject: [Ace] [ace] WGLC on draft-ietf-ace-cbor-web-token

Thanks,

Kind Regards
Kepeng & Hannes

---

From: Mike Jones <[email-masked]>
Date: Mon, 15 May 2017 22:16:57 +0000

I’ve gone through all the review feedback and agree with most of it.  There’s only two of the comments that I have issues with.

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.

I agree with the suggestion (tracked in https://github.com/erwah/ietf/issues/38) that we allow string-valued labels, but disagree that they should be restricted to non-production use.  Rather, per my comment in https://github.com/erwah/ietf/issues/40, I think we should use the same rules for allocating labels as COSE did.  That approach has already been widely reviewed and I believe is perfectly viable.  Note that this will also address the comment about the 1-65536 label range.

Thanks for your detailed review, as always, Jim.

                                                                -- Mike

From: Ace [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Monday, May 15, 2017 2:44 PM
To: Jim Schaad <[email-masked]>; 'Samuel Erdtman' <[email-masked]>
Cc: 'ace' <[email-masked]>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

                                                                -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Monday, May 15, 2017 2:31 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>; 'Samuel Erdtman' <[email-masked]<mailto:[email-masked]>>
Cc: 'ace' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token

                                                                -- Mike

Hi Jim,

Jim

Jim

-----Original Message-----
From: Ace [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kepeng Li
Sent: Thursday, April 20, 2017 2:53 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Subject: [Ace] [ace] WGLC on draft-ietf-ace-cbor-web-token

Thanks,

Kind Regards
Kepeng & Hannes

---

From: Jim Schaad <[email-masked]>
Date: Mon, 15 May 2017 16:31:37 -0700

Actually, I think both of those were Carsten not me

From: Mike Jones [mailto:[email-masked]] 
Sent: Monday, May 15, 2017 3:17 PM
To: Jim Schaad <[email-masked]>; 'Samuel Erdtman' <[email-masked]>
Cc: 'ace' <[email-masked]>
Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token

                                                                -- Mike

From: Ace [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Monday, May 15, 2017 2:44 PM
To: Jim Schaad <[email-masked] <mailto:[email-masked]> >; 'Samuel Erdtman' <[email-masked] <mailto:[email-masked]> >
Cc: 'ace' <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

                                                                -- Mike

From: Jim Schaad [mailto:[email-masked]] 
Sent: Monday, May 15, 2017 2:31 PM
To: Mike Jones <[email-masked] <mailto:[email-masked]> >; 'Samuel Erdtman' <[email-masked] <mailto:[email-masked]> >
Cc: 'ace' <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token

 

To: Samuel Erdtman <[email-masked] <mailto:[email-masked]> >; Jim Schaad <[email-masked] <mailto:[email-masked]> >

                                                                -- Mike

 

Hi Jim,

Not ready to ship.

 

 
Jim

Jim

-----Original Message-----
From: Ace [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Kepeng Li
Sent: Thursday, April 20, 2017 2:53 PM
To: [email-masked] <mailto:[email-masked]> 
Cc: Hannes Tschofenig <[email-masked] <mailto:[email-masked]> >
Subject: [Ace] [ace] WGLC on draft-ietf-ace-cbor-web-token

Thanks,

Kind Regards
Kepeng & Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 May 2017 00:26:29 +0200

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

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

---

From: Mike Jones <[email-masked]>
Date: Tue, 16 May 2017 22:58:28 +0000

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:[email-masked]] 
Sent: Tuesday, May 16, 2017 3:26 PM
To: Mike Jones <[email-masked]>
Cc: Jim Schaad <[email-masked]>; Samuel Erdtman <[email-masked]>; ace <[email-masked]>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Tue, 16 May 2017 16:58:09 -0700

As things currently stand, I do not know that there is any way for an issuer to say that you must understand this claim to use this.  This is partly profile, but not entirely.

Jim

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Tuesday, May 16, 2017 3:26 PM
To: Mike Jones <[email-masked]>
Cc: Jim Schaad <[email-masked]>; Samuel Erdtman <[email-masked]>; ace <[email-masked]>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Wed, 17 May 2017 16:14:52 -0700

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:[email-masked]] 
Sent: Tuesday, May 16, 2017 3:58 PM
To: Carsten Bormann <[email-masked]>
Cc: Jim Schaad <[email-masked]>; Samuel Erdtman <[email-masked]>; ace <[email-masked]>
Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token

				-- Mike

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Tuesday, May 16, 2017 3:26 PM
To: Mike Jones <[email-masked]>
Cc: Jim Schaad <[email-masked]>; Samuel Erdtman <[email-masked]>; ace <[email-masked]>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

Grüße, Carsten