Subject: Re: [Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)

From: Mike Jones <[email-masked]>
Date: Fri, 30 Jun 2017 02:03:09 +0000

Thanks, Michael.  My editors draft now corrects the JSON -> CBOR issue.

Jim Schaad also commented on the second paragraph.  The editors draft relaxes its requirements to give profiles or applications full flexibility on how to identify the presenter.

After giving the editors of draft-ietf-ace-oauth-authz a chance to have a look at the new draft, I plan to publish it in a day or so.

I'd be glad to talk with you in person in Prague about the needs of the new work you mention below and how to meet them.

				Best wishes,
				-- Mike

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Monday, May 22, 2017 11:17 AM
To: Mike Jones <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ace] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)

Come to the discussion late, cleaning my inbox.

section 3 says:

     "The value of the cnf claim is a JSON object and the members of that object
     identify the proof-of-possession key."

And somehow, I think that the claim ought to be a CBOR object?
Same for the paragraph of 3.4.

I found the next paragraph about whether the sub or iss is the presenter to be obtuse.  Maybe it is lacking some ACE RS/C/AS terminology?

I am trying to figure out if the nonce-full mechanism that we describe in draft-ietf-anima-bootstrapping-keyinfra or anima-voucher, and later to be re-interpreted as CWT in draft-ietf-6tisch-dtsecurity-secure-join should reference RFC 7800 and this document instead.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-