Re: [Ace] Adam Roach's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

[Adam Roach]

Thanks! Looks good to me.

/a

On 10/30/19 7:41 PM, Mike Jones wrote:

Thanks for your review, Adam.  The questionable comment syntax that you pointed 
out has been changed to the unsurprising representation /HMAC 256-256/ in 
https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-10#section-3.3.

Best wishes,
-- Mike

-Original Message-
From: Adam Roach via Datatracker 
Sent: Monday, October 28, 2019 11:07 PM
To: The IESG 
Cc: draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace-cha...@ietf.org; 
r...@cert.org; ace@ietf.org
Subject: Adam Roach's No Objection on 
draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

Adam Roach has entered the following ballot position for
draft-ietf-ace-cwt-proof-of-possession-09: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.htmldata=02%7C01%7CMichael.Jones%40microsoft.com%7C1c9c12805d7c4b7ed6f408d75c3641ff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637079260432123647sdata=yV4geJmqHs6nE2KEz1HxXf55xRRlGQJdLgHEeKkzxus%3Dreserved=0
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-cwt-proof-of-possession%2Fdata=02%7C01%7CMichael.Jones%40microsoft.com%7C1c9c12805d7c4b7ed6f408d75c3641ff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637079260432123647sdata=iOQpEcoj42%2FrW8qN8c38l931EGH%2BTM0qNgL1aC9aM3E%3Dreserved=0



--
COMMENT:
--


Thanks for the work everyone put into defining this mechanism. I have one very 
minor comment that the authors may wish to take into account.

§3.3:


 /alg/ 3 : /HMAC256//256/ 5,

This use of "//" seems problematic, given RFC 8610's vague reservation of this sequence 
for some kind of "comment to end of line" designation:

(There are currently no end-of-line comments.  If we want to add
them, "//" sounds like a reasonable delimiter given that we already
use slashes for comments, but we could also go, for example,
for "#".)

Given the potential ambiguity introduced by RFC 8610, perhaps consider some other syntax 
here instead of "//".




___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] I-D Action: draft-ietf-ace-cwt-proof-of-possession-10.txt

[Mike Jones]

This version addresses IESG comments from Adam Roach and Éric Vyncke, both of 
which resulted in local editorial improvements to the document.

-- Mike

-Original Message-
From: Ace  On Behalf Of internet-dra...@ietf.org
Sent: Wednesday, October 30, 2019 5:33 PM
To: i-d-annou...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] I-D Action: draft-ietf-ace-cwt-proof-of-possession-10.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments WG of the IETF.

Title   : Proof-of-Possession Key Semantics for CBOR Web Tokens 
(CWTs)
Authors : Michael B. Jones
  Ludwig Seitz
  Göran Selander
  Samuel Erdtman
  Hannes Tschofenig
Filename: draft-ietf-ace-cwt-proof-of-possession-10.txt
Pages   : 16
Date: 2019-10-30

Abstract:
   This specification describes how to declare in a CBOR Web Token (CWT)
   (which is defined by RFC 8392) that the presenter of the CWT
   possesses a particular proof-of-possession key.  Being able to prove
   possession of a key is also sometimes described as being the holder-
   of-key.  This specification provides equivalent functionality to
   "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC
   7800) but using Concise Binary Object Representation (CBOR) and CWTs
   rather than JavaScript Object Notation (JSON) and JSON Web Tokens
   (JWTs).


The IETF datatracker status page for this draft is:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-cwt-proof-of-possession%2Fdata=02%7C01%7CMichael.Jones%40microsoft.com%7C8f8fbd0554a54a425eac08d75d99d814%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080787671770750sdata=1DMKhvl%2BZrTderZqQO1dPMWxGvPpUBH0QakWZ7nhT%2Bw%3Dreserved=0

There are also htmlized versions available at:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-cwt-proof-of-possession-10data=02%7C01%7CMichael.Jones%40microsoft.com%7C8f8fbd0554a54a425eac08d75d99d814%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080787671770750sdata=I%2BL3A86s5uufPp8vRfK31GNJbtJrDC3umOhxH7z5rCI%3Dreserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-cwt-proof-of-possession-10data=02%7C01%7CMichael.Jones%40microsoft.com%7C8f8fbd0554a54a425eac08d75d99d814%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080787671770750sdata=ulFodpYOpfmgwrqzuX%2Fz6mTiNSL0vrjS3rnGX5mMuU0%3Dreserved=0

A diff from the previous version is available at:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-ace-cwt-proof-of-possession-10data=02%7C01%7CMichael.Jones%40microsoft.com%7C8f8fbd0554a54a425eac08d75d99d814%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080787671770750sdata=cchPquPB5ZSCFJfLp91Bp2azdFz7HhttSNk0W%2BvIPic%3Dreserved=0


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Ace mailing list
Ace@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Facedata=02%7C01%7CMichael.Jones%40microsoft.com%7C8f8fbd0554a54a425eac08d75d99d814%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080787671770750sdata=TaKbHEKFGIXDUdMrJoceYzSO4wsWDCVisMdWqQHZfUA%3Dreserved=0
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Mirja Kühlewind's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

[Mike Jones]

Thanks for the clarification, Ben.  I'm fine with this going either way (appeal 
to IESG or appeal to IANA).  Just drop me a note after the issue is discussed 
on the telechat and I'll turn around a new draft right away tomorrow, if 
requested.

Later,
-- Mike

-Original Message-
From: Ace  On Behalf Of Benjamin Kaduk
Sent: Wednesday, October 30, 2019 5:29 PM
To: Mike Jones 
Cc: Roman D. Danyliw ; ace-cha...@ietf.org; Mirja Kuehlewind 
; The IESG ; ace@ietf.org; 
draft-ietf-ace-cwt-proof-of-possess...@ietf.org; Barry Leiba 

Subject: Re: [Ace] Mirja Kühlewind's No Objection on 
draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

Just to be clear, IANA raising the issue to the IESG is described in Section 
5.3 of RFC 8126, which would be the default expectations if an individual 
document/registry did not give other instructions.

-Ben

On Thu, Oct 31, 2019 at 12:13:58AM +, Mike Jones wrote:
> I'm in the process of creating -10, which addresses the IESG comments other 
> than Mirja's.  I'm reluctant to change the registration instructions, as they 
> are currently identical to those for CWTs (and many other specifications 
> going back to at least RFC 6749, modulo the name of the mailing list).  That 
> said, if the IESG *really* wants to change the party to appeal to in the case 
> of non-action from the Designated Experts from the IESG to IANA, I'm amenable 
> to also making that change tomorrow, immediately following the telechat, so 
> we can send the spec on to the RFC Editor.  Let me know what you decide.
> 
>   Thanks again,
>   -- Mike
> 
> -Original Message-
> From: Barry Leiba 
> Sent: Monday, October 28, 2019 2:00 PM
> To: Mike Jones 
> Cc: Mirja Kuehlewind ; Benjamin Kaduk 
> ; Roman D. Danyliw ; ace-cha...@ietf.org; 
> The IESG ; ace@ietf.org; 
> draft-ietf-ace-cwt-proof-of-possess...@ietf.org
> Subject: Re: [Ace] Mirja Kühlewind's No Objection on 
> draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)
> 
> The issue isn't using a mailing list.  The issue is the instructions to IANA 
> about how to do management and tracking, stuff that they do just fine without 
> working groups trying -- will all good intentions -- to tell them how.
> 
> The fact that there are a lot of RFCs that do it just says that working 
> groups do this frequently, and most ADs don't notice or don't care.  And the 
> reality is that IANA will manage the registration process how they do it, 
> accommodating reasonable special instructions when they can.  The point is 
> that documents shouldn't be giving special instructions unless there really 
> is something special needed for a particular reason.
> 
> Barry
> 
> On Mon, Oct 28, 2019 at 12:19 PM Mike Jones  
> wrote:
> >
> > The practice of using a mailing list for registration requests to enable 
> > public visibility of them goes back at least to .well-known URI 
> > registrations 
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5785data=02%7C01%7CMichael.Jones%40microsoft.com%7C0b217822fdab454c213408d75d995cec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080785592172015sdata=dvBR4fRzp1xSMcqXyaSa68Px7AJs3alwwTPJVH4YyMA%3Dreserved=0
> >  by Mark Nottingham in April 2010.  OAuth 2.0 followed this practice in RFC 
> > 6749, as did the JOSE specs and JWT in RFCs 7515-19.  The rest is history, 
> > as they say.
> >
> > -- Mike
> >
> > -Original Message-
> > From: Mirja Kuehlewind 
> > Sent: Monday, October 28, 2019 8:54 AM
> > To: Benjamin Kaduk 
> > Cc: Barry Leiba ; Roman D. Danyliw 
> > ; ace-cha...@ietf.org; The IESG ; 
> > ace@ietf.org; draft-ietf-ace-cwt-proof-of-possess...@ietf.org
> > Subject: Re: [Ace] Mirja Kühlewind's No Objection on
> > draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)
> >
> > These are all quite recents examples, so maybe the procedures are changing 
> > at the moment. I guess we as the IESG should be aware and figure out what 
> > the right procedure actually should be here.
> >
> > > On 28. Oct 2019, at 16:31, Benjamin Kaduk  wrote:
> > >
> > > On Fri, Oct 25, 2019 at 12:31:42PM -0400, Barry Leiba wrote:
> > >> Yeh, it's very common for authors to try to tell IANA how to 
> > >> handle registrations, and I often push back on that as inappropriate.
> > >> There are certainly special conditions that IANA should be told 
> > >> about, but this is standard work-flow management stuff that ought 
> > >> to be left to IANA.  I do think it should be changed before this 
> > >> is published, probably just removing that last sentence.
> > >
> > > While I'm not opposed to normalizing on a default procedure, I 
> > > think the authors were just trying to follow existing examples.
> > >
> > > RFC 7519:
> > >
> > >   Values are registered on a Specification Required [RFC5226] basis
> > >   after a 

Re: [Ace] Éric Vyncke's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

[Mike Jones]

Thanks for your review, Éric.  The "iss" claim is now explained on first use at 
https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-10#section-3 
(paralleling the treatment of the first use of the "sub" claim).

Thanks again,
-- Mike

-Original Message-
From: Éric Vyncke via Datatracker  
Sent: Wednesday, October 30, 2019 6:46 AM
To: The IESG 
Cc: draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace-cha...@ietf.org; 
r...@cert.org; ace@ietf.org
Subject: Éric Vyncke's No Objection on 
draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-ace-cwt-proof-of-possession-09: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.htmldata=02%7C01%7CMichael.Jones%40microsoft.com%7Cac997d452a7b4e78a10408d75d3f6f7a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080399363452091sdata=jEXnivuGKVwaa0Yq%2FxDxF4PF4hQGRiU96rA%2Bv5jfAME%3Dreserved=0
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-cwt-proof-of-possession%2Fdata=02%7C01%7CMichael.Jones%40microsoft.com%7Cac997d452a7b4e78a10408d75d3f6f7a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080399363452091sdata=VeFFk%2BcqykLKnsynNFWQgS9ERD28gGD%2Ba7chtRh0CYo%3Dreserved=0



--
COMMENT:
--

Thank you for the work put into this document. The document is easy to read. I 
only one nit in section 3 and feel free to ignore all of it: While "sub" is 
explained as being the "subject", nothing is written about "iss" claim on the 
first time this term is used, it is only explained the 2nd time.

For my IESG colleagues, I second Mirja's comment about adding a IANA registry 
entry based on email.

Regards,

-éric


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Mirja Kühlewind's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

[Benjamin Kaduk]

Just to be clear, IANA raising the issue to the IESG is described in
Section 5.3 of RFC 8126, which would be the default expectations if an
individual document/registry did not give other instructions.

-Ben

On Thu, Oct 31, 2019 at 12:13:58AM +, Mike Jones wrote:
> I'm in the process of creating -10, which addresses the IESG comments other 
> than Mirja's.  I'm reluctant to change the registration instructions, as they 
> are currently identical to those for CWTs (and many other specifications 
> going back to at least RFC 6749, modulo the name of the mailing list).  That 
> said, if the IESG *really* wants to change the party to appeal to in the case 
> of non-action from the Designated Experts from the IESG to IANA, I'm amenable 
> to also making that change tomorrow, immediately following the telechat, so 
> we can send the spec on to the RFC Editor.  Let me know what you decide.
> 
>   Thanks again,
>   -- Mike
> 
> -Original Message-
> From: Barry Leiba  
> Sent: Monday, October 28, 2019 2:00 PM
> To: Mike Jones 
> Cc: Mirja Kuehlewind ; Benjamin Kaduk ; 
> Roman D. Danyliw ; ace-cha...@ietf.org; The IESG 
> ; ace@ietf.org; draft-ietf-ace-cwt-proof-of-possess...@ietf.org
> Subject: Re: [Ace] Mirja Kühlewind's No Objection on 
> draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)
> 
> The issue isn't using a mailing list.  The issue is the instructions to IANA 
> about how to do management and tracking, stuff that they do just fine without 
> working groups trying -- will all good intentions -- to tell them how.
> 
> The fact that there are a lot of RFCs that do it just says that working 
> groups do this frequently, and most ADs don't notice or don't care.  And the 
> reality is that IANA will manage the registration process how they do it, 
> accommodating reasonable special instructions when they can.  The point is 
> that documents shouldn't be giving special instructions unless there really 
> is something special needed for a particular reason.
> 
> Barry
> 
> On Mon, Oct 28, 2019 at 12:19 PM Mike Jones  
> wrote:
> >
> > The practice of using a mailing list for registration requests to enable 
> > public visibility of them goes back at least to .well-known URI 
> > registrations 
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5785data=02%7C01%7CMichael.Jones%40microsoft.com%7C085270914a0b42e5007908d75be9e2ea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637078932422930532sdata=bwglng9A7A8OGaV4vicvLAAcd%2FqcK7Q%2Fv9cnywn8fDo%3Dreserved=0
> >  by Mark Nottingham in April 2010.  OAuth 2.0 followed this practice in RFC 
> > 6749, as did the JOSE specs and JWT in RFCs 7515-19.  The rest is history, 
> > as they say.
> >
> > -- Mike
> >
> > -Original Message-
> > From: Mirja Kuehlewind 
> > Sent: Monday, October 28, 2019 8:54 AM
> > To: Benjamin Kaduk 
> > Cc: Barry Leiba ; Roman D. Danyliw 
> > ; ace-cha...@ietf.org; The IESG ; 
> > ace@ietf.org; draft-ietf-ace-cwt-proof-of-possess...@ietf.org
> > Subject: Re: [Ace] Mirja Kühlewind's No Objection on 
> > draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)
> >
> > These are all quite recents examples, so maybe the procedures are changing 
> > at the moment. I guess we as the IESG should be aware and figure out what 
> > the right procedure actually should be here.
> >
> > > On 28. Oct 2019, at 16:31, Benjamin Kaduk  wrote:
> > >
> > > On Fri, Oct 25, 2019 at 12:31:42PM -0400, Barry Leiba wrote:
> > >> Yeh, it's very common for authors to try to tell IANA how to handle 
> > >> registrations, and I often push back on that as inappropriate.  
> > >> There are certainly special conditions that IANA should be told 
> > >> about, but this is standard work-flow management stuff that ought 
> > >> to be left to IANA.  I do think it should be changed before this is 
> > >> published, probably just removing that last sentence.
> > >
> > > While I'm not opposed to normalizing on a default procedure, I think 
> > > the authors were just trying to follow existing examples.
> > >
> > > RFC 7519:
> > >
> > >   Values are registered on a Specification Required [RFC5226] basis
> > >   after a three-week review period on the jwt-reg-rev...@ietf.org
> > >   mailing list, on the advice of one or more Designated Experts.
> > >   However, to allow for the allocation of values prior to publication,
> > >   the Designated Experts may approve registration once they are
> > >   satisfied that such a specification will be published.
> > >
> > >   Registration requests sent to the mailing list for review should use
> > >   an appropriate subject (e.g., "Request to register claim: example").
> > >
> > >   Within the review period, the Designated Experts will either approve
> > >   or deny the registration request, communicating this decision to the
> > >   review list and IANA.  Denials should include an 

Re: [Ace] Mirja Kühlewind's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

[Mike Jones]

I'm in the process of creating -10, which addresses the IESG comments other 
than Mirja's.  I'm reluctant to change the registration instructions, as they 
are currently identical to those for CWTs (and many other specifications going 
back to at least RFC 6749, modulo the name of the mailing list).  That said, if 
the IESG *really* wants to change the party to appeal to in the case of 
non-action from the Designated Experts from the IESG to IANA, I'm amenable to 
also making that change tomorrow, immediately following the telechat, so we can 
send the spec on to the RFC Editor.  Let me know what you decide.

Thanks again,
-- Mike

-Original Message-
From: Barry Leiba  
Sent: Monday, October 28, 2019 2:00 PM
To: Mike Jones 
Cc: Mirja Kuehlewind ; Benjamin Kaduk ; 
Roman D. Danyliw ; ace-cha...@ietf.org; The IESG 
; ace@ietf.org; draft-ietf-ace-cwt-proof-of-possess...@ietf.org
Subject: Re: [Ace] Mirja Kühlewind's No Objection on 
draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

The issue isn't using a mailing list.  The issue is the instructions to IANA 
about how to do management and tracking, stuff that they do just fine without 
working groups trying -- will all good intentions -- to tell them how.

The fact that there are a lot of RFCs that do it just says that working groups 
do this frequently, and most ADs don't notice or don't care.  And the reality 
is that IANA will manage the registration process how they do it, accommodating 
reasonable special instructions when they can.  The point is that documents 
shouldn't be giving special instructions unless there really is something 
special needed for a particular reason.

Barry

On Mon, Oct 28, 2019 at 12:19 PM Mike Jones  wrote:
>
> The practice of using a mailing list for registration requests to enable 
> public visibility of them goes back at least to .well-known URI registrations 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5785data=02%7C01%7CMichael.Jones%40microsoft.com%7C085270914a0b42e5007908d75be9e2ea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637078932422930532sdata=bwglng9A7A8OGaV4vicvLAAcd%2FqcK7Q%2Fv9cnywn8fDo%3Dreserved=0
>  by Mark Nottingham in April 2010.  OAuth 2.0 followed this practice in RFC 
> 6749, as did the JOSE specs and JWT in RFCs 7515-19.  The rest is history, as 
> they say.
>
> -- Mike
>
> -Original Message-
> From: Mirja Kuehlewind 
> Sent: Monday, October 28, 2019 8:54 AM
> To: Benjamin Kaduk 
> Cc: Barry Leiba ; Roman D. Danyliw 
> ; ace-cha...@ietf.org; The IESG ; 
> ace@ietf.org; draft-ietf-ace-cwt-proof-of-possess...@ietf.org
> Subject: Re: [Ace] Mirja Kühlewind's No Objection on 
> draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)
>
> These are all quite recents examples, so maybe the procedures are changing at 
> the moment. I guess we as the IESG should be aware and figure out what the 
> right procedure actually should be here.
>
> > On 28. Oct 2019, at 16:31, Benjamin Kaduk  wrote:
> >
> > On Fri, Oct 25, 2019 at 12:31:42PM -0400, Barry Leiba wrote:
> >> Yeh, it's very common for authors to try to tell IANA how to handle 
> >> registrations, and I often push back on that as inappropriate.  
> >> There are certainly special conditions that IANA should be told 
> >> about, but this is standard work-flow management stuff that ought 
> >> to be left to IANA.  I do think it should be changed before this is 
> >> published, probably just removing that last sentence.
> >
> > While I'm not opposed to normalizing on a default procedure, I think 
> > the authors were just trying to follow existing examples.
> >
> > RFC 7519:
> >
> >   Values are registered on a Specification Required [RFC5226] basis
> >   after a three-week review period on the jwt-reg-rev...@ietf.org
> >   mailing list, on the advice of one or more Designated Experts.
> >   However, to allow for the allocation of values prior to publication,
> >   the Designated Experts may approve registration once they are
> >   satisfied that such a specification will be published.
> >
> >   Registration requests sent to the mailing list for review should use
> >   an appropriate subject (e.g., "Request to register claim: example").
> >
> >   Within the review period, the Designated Experts will either approve
> >   or deny the registration request, communicating this decision to the
> >   review list and IANA.  Denials should include an explanation and, if
> >   applicable, suggestions as to how to make the request successful.
> >   Registration requests that are undetermined for a period longer than
> >   21 days can be brought to the IESG's attention (using the
> >   i...@ietf.org mailing list) for resolution.
> >
> > RFC 8414:
> >
> >   Values are registered on a Specification Required [RFC8126] basis
> >   after a two-week review period on the oauth-ext-rev...@ietf.org
> >   

Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01

[Daniel Migault]

Thank you for the response. Feel free to publish the updated version.
Please see my comments inline.
Yours,
Daniel

On Wed, Oct 30, 2019 at 12:13 PM Cigdem Sengul 
wrote:

> Thank you for your comments Daniel (prefixed [CS])
> My comments are inside. I've also created the -v-02-WIP branch for the
> work in progress based on your and Jim's comments.
>
> On Thu, Oct 24, 2019 at 2:50 AM Daniel Migault  40ericsson@dmarc.ietf.org> wrote:
>
>> HI,
>>
>> Thanks for sending an update. Please find my comments of the draft.
>>
>>This document makes the same assumptions as the Section 4 of the ACE
>>framework [I-D.ietf-ace-oauth-authz] regarding Client and RS
>>registration with the AS and establishing of keying material.
>>
>>  The document seems mostly focuses on the latest version of MQTT,
>> I am wondering if we could encourage similarly the use of the latest
>> version of TLS that is 1.3 at the time of writing.
>>
>> It seems AS as not been defined previously, so maybe it should be
>> expanded there.
>> 
>>
>
> [CS] Can add a similar recommendation for TLS 1.3.
> AS is expanded.
>
>
>
>>
>>MQTTS
>>Secured transport profile of MQTT.  MQTTS runs over TLS.
>>The Server in MQTT acts as an intermediary between
>>Clients that publishes Application Messages, and the Clients
>>that made Subscriptions.  The Broker acts as the Resource
>>Server for the Clients.
>>
>> publishes
>>
> [CS] Fixed.
>
>
>
>>
>>Subscription
>>A subscription comprises a Topic Filter and a maximum Quality
>>of Service (QoS).
>>
>> Maybe that would be clearer to specify QoS level as well.
>>
>
> [CS] Added.
>
>
>
>>PINGREQ
>>A ping request sent from a Client to the Broker.  It signals
>>to the Broker that the Client is alive, and is used to
>>confirm that the Broker is still alive.
>>
>> It may look a bit strange to have PINGREQ without PINGRESP. You
>> might also indicate the keep alive period is provided in the
>> CONNECT
>>
>
> [CS] Added PINGRESP, clarified the Keep Alive period is set in the CONNECT
> in the definition of PINGREQ.
>
>
>>
>>Will
>>An application message published by the Server after the
>>network connection is closed in cases where the network
>>connection is not closed normally.  If the Will Flag is set,
>>then the payload of the CONNECT message has information about
>>the Will.  The Will consists of the Will Properties, Will
>>Topic, and Will Payload fields in the CONNECT message.
>>
>> 
>> The first sentence seems to be related to the Will message while the
>> intent, I suppose of teh definition was to define the generic conpet of
>> Will. It might be clearer to expose the principle of the wil, that is a
>> server sends a given message in case a client is disconnected
>> improperly.   It might be clearer to mention explicitly there is a Will
>> "concept" that is implemented a WillFlag WillQoS, WillRetain in the
>> CONNECT header as well as other Will Properties and Will Messages. This
>> mostly consists in the last sentence being moved up.
>> 
>>
>
> [CS] I reworded it - let me know if it is more clear.
>
will have a look.

>
>> 2.  Protocol Interactions
>>
>>This section describes the following exchanges between Clients, the
>>Broker, and the Authorization Server according to the MQTT v5.0.
>>
>>  Though english is not my first language, I have the impression the
>> text can be interpreted as MQTT enables clients to establish session
>> which does not seems correct to me. The text that follows clarifies this
>> as well.
>> 
>>
>
> [CS] Neither mine, I reworded that as: "Authorizing connection requests
> from the Clients to the Broker"
> Actually, I also went through the text to reword "establishment" to set-up
> which is simpler.
>
ok

>
>
>>
>> 2.1.  Authorizing Connection Establishment
>>
>> If the
>>Client is resource-constrained, a Client Authorisation Server may
>>
>> I have the impression an AS would be sufficient.
>>
>
> [CS] Client Authorization Server was the terminology used in the Actors
> draft - I've removed all other references but wanted to distinguish that
> this is separate than the AS granting access tokens.
> Can just say client's AS?
>
Maybe just explicitly saying it is different would be clearer. I will have
to re-read it.

>
>>carry out the token request on behalf of the Client, and later,
>>onboard the Client with the token.  Also, these interfaces may be
>>implemented using other protocols, e.g., CoAP or MQTT.
>> While the introduction and the figure mentions that HTTPS is used
>> as a transport, it might be worth mentioning that HTTPS is being used. I
>> propose to add "...other protocols than HTTPS, e.g ...
>> 
>>
>
> [CS] Added.
>
>
>> 2.1.1.  Client Token Request to the Authorization Server (AS)
>>
>>The first step in the protocol flow (Figure 1 

Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01

[Cigdem Sengul]

Just saw it in the core document as well. Thanks, Jim.

--Cigdem

On Wed, Oct 30, 2019 at 4:21 PM Jim Schaad  wrote:

> Just one quick comment below
>
>
>
> *From:* Cigdem Sengul 
> *Sent:* Wednesday, October 30, 2019 9:13 AM
> *To:* Daniel Migault 
> *Cc:* Jim Schaad ; ace@ietf.org;
> draft-ietf-ace-mqtt-tls-prof...@ietf.org
> *Subject:* Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01
>
>
>
> Thank you for your comments Daniel (prefixed [CS])
>
> My comments are inside. I've also created the -v-02-WIP branch for the
> work in progress based on your and Jim's comments.
>
>
>
> On Thu, Oct 24, 2019 at 2:50 AM Daniel Migault  40ericsson@dmarc.ietf.org> wrote:
>
> HI,
>
>
>
> Thanks for sending an update. Please find my comments of the draft.
>
>
>
>This document makes the same assumptions as the Section 4 of the ACE
>framework [I-D.ietf-ace-oauth-authz] regarding Client and RS
>registration with the AS and establishing of keying material.
>
>  The document seems mostly focuses on the latest version of MQTT,
> I am wondering if we could encourage similarly the use of the latest
> version of TLS that is 1.3 at the time of writing.
>
> It seems AS as not been defined previously, so maybe it should be
> expanded there.
> 
>
>
>
> [CS] Can add a similar recommendation for TLS 1.3.
>
> AS is expanded.
>
>
>
>
>
>
>
>MQTTS
>Secured transport profile of MQTT.  MQTTS runs over TLS.
>The Server in MQTT acts as an intermediary between
>Clients that publishes Application Messages, and the Clients
>that made Subscriptions.  The Broker acts as the Resource
>Server for the Clients.
>
> publishes
>
> [CS] Fixed.
>
>
>
>
>
>
>
>Subscription
>A subscription comprises a Topic Filter and a maximum Quality
>of Service (QoS).
>
> Maybe that would be clearer to specify QoS level as well.
>
>
>
> [CS] Added.
>
>
>
>
>
>PINGREQ
>A ping request sent from a Client to the Broker.  It signals
>to the Broker that the Client is alive, and is used to
>confirm that the Broker is still alive.
>
> It may look a bit strange to have PINGREQ without PINGRESP. You
> might also indicate the keep alive period is provided in the CONNECT
>
>
>
> [CS] Added PINGRESP, clarified the Keep Alive period is set in the CONNECT
> in the definition of PINGREQ.
>
>
>
>
>Will
>An application message published by the Server after the
>network connection is closed in cases where the network
>connection is not closed normally.  If the Will Flag is set,
>then the payload of the CONNECT message has information about
>the Will.  The Will consists of the Will Properties, Will
>Topic, and Will Payload fields in the CONNECT message.
>
> 
> The first sentence seems to be related to the Will message while the
> intent, I suppose of teh definition was to define the generic conpet of
> Will. It might be clearer to expose the principle of the wil, that is a
> server sends a given message in case a client is disconnected
> improperly.   It might be clearer to mention explicitly there is a Will
> "concept" that is implemented a WillFlag WillQoS, WillRetain in the
> CONNECT header as well as other Will Properties and Will Messages. This
> mostly consists in the last sentence being moved up.
> 
>
>
>
> [CS] I reworded it - let me know if it is more clear.
>
>
>
> 2.  Protocol Interactions
>
>This section describes the following exchanges between Clients, the
>Broker, and the Authorization Server according to the MQTT v5.0.
>
>  Though english is not my first language, I have the impression the
> text can be interpreted as MQTT enables clients to establish session
> which does not seems correct to me. The text that follows clarifies this
> as well.
> 
>
>
>
> [CS] Neither mine, I reworded that as: "Authorizing connection requests
> from the Clients to the Broker"
>
> Actually, I also went through the text to reword "establishment" to set-up
> which is simpler.
>
>
>
>
>
> 2.1.  Authorizing Connection Establishment
>
>
>
> If the
>Client is resource-constrained, a Client Authorisation Server may
>
> I have the impression an AS would be sufficient.
>
>
>
> [CS] Client Authorization Server was the terminology used in the Actors
> draft - I've removed all other references but wanted to distinguish that
> this is separate than the AS granting access tokens.
>
> Can just say client's AS?
>
>
>carry out the token request on behalf of the Client, and later,
>onboard the Client with the token.  Also, these interfaces may be
>implemented using other protocols, e.g., CoAP or MQTT.
> While the introduction and the figure mentions that HTTPS is used
> as a transport, it might be worth mentioning that HTTPS is being used. I
> propose to add "...other protocols than HTTPS, e.g ...
> 
>
>
>
> [CS] Added.
>
>
>
>
>
> 2.1.1.  Client Token Request 

Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01

[Jim Schaad]

Just one quick comment below

 

From: Cigdem Sengul  
Sent: Wednesday, October 30, 2019 9:13 AM
To: Daniel Migault 
Cc: Jim Schaad ; ace@ietf.org; 
draft-ietf-ace-mqtt-tls-prof...@ietf.org
Subject: Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01

 

Thank you for your comments Daniel (prefixed [CS])

My comments are inside. I've also created the -v-02-WIP branch for the work in 
progress based on your and Jim's comments. 

 

On Thu, Oct 24, 2019 at 2:50 AM Daniel Migault 
mailto:40ericsson@dmarc.ietf.org> > wrote:

HI, 

 

Thanks for sending an update. Please find my comments of the draft. 

 

   This document makes the same assumptions as the Section 4 of the ACE
   framework [I-D.ietf-ace-oauth-authz] regarding Client and RS
   registration with the AS and establishing of keying material.

 The document seems mostly focuses on the latest version of MQTT,
I am wondering if we could encourage similarly the use of the latest
version of TLS that is 1.3 at the time of writing.

It seems AS as not been defined previously, so maybe it should be
expanded there. 
 

 

[CS] Can add a similar recommendation for TLS 1.3. 

AS is expanded. 

 

 

 

   MQTTS
   Secured transport profile of MQTT.  MQTTS runs over TLS.
   The Server in MQTT acts as an intermediary between
   Clients that publishes Application Messages, and the Clients
   that made Subscriptions.  The Broker acts as the Resource
   Server for the Clients.

publishes

[CS] Fixed.

 

 

 

   Subscription
   A subscription comprises a Topic Filter and a maximum Quality
   of Service (QoS).

Maybe that would be clearer to specify QoS level as well.

 

[CS] Added. 

 

 

   PINGREQ
   A ping request sent from a Client to the Broker.  It signals
   to the Broker that the Client is alive, and is used to
   confirm that the Broker is still alive.

It may look a bit strange to have PINGREQ without PINGRESP. You
might also indicate the keep alive period is provided in the CONNECT

 

[CS] Added PINGRESP, clarified the Keep Alive period is set in the CONNECT in 
the definition of PINGREQ. 

 


   Will
   An application message published by the Server after the
   network connection is closed in cases where the network
   connection is not closed normally.  If the Will Flag is set,
   then the payload of the CONNECT message has information about
   the Will.  The Will consists of the Will Properties, Will
   Topic, and Will Payload fields in the CONNECT message.


The first sentence seems to be related to the Will message while the
intent, I suppose of teh definition was to define the generic conpet of
Will. It might be clearer to expose the principle of the wil, that is a
server sends a given message in case a client is disconnected
improperly.   It might be clearer to mention explicitly there is a Will
"concept" that is implemented a WillFlag WillQoS, WillRetain in the
CONNECT header as well as other Will Properties and Will Messages. This
mostly consists in the last sentence being moved up.  


 

[CS] I reworded it - let me know if it is more clear. 

 

2.  Protocol Interactions

   This section describes the following exchanges between Clients, the
   Broker, and the Authorization Server according to the MQTT v5.0.

 Though english is not my first language, I have the impression the
text can be interpreted as MQTT enables clients to establish session
which does not seems correct to me. The text that follows clarifies this
as well.  


 

[CS] Neither mine, I reworded that as: "Authorizing connection requests from 
the Clients to the Broker"

Actually, I also went through the text to reword "establishment" to set-up 
which is simpler. 

 

 

2.1.  Authorizing Connection Establishment

 

If the
   Client is resource-constrained, a Client Authorisation Server may

I have the impression an AS would be sufficient.

 

[CS] Client Authorization Server was the terminology used in the Actors draft - 
I've removed all other references but wanted to distinguish that this is 
separate than the AS granting access tokens. 

Can just say client's AS? 


   carry out the token request on behalf of the Client, and later,
   onboard the Client with the token.  Also, these interfaces may be
   implemented using other protocols, e.g., CoAP or MQTT. 
While the introduction and the figure mentions that HTTPS is used
as a transport, it might be worth mentioning that HTTPS is being used. I
propose to add "...other protocols than HTTPS, e.g ...


 

[CS] Added. 

 

 

2.1.1.  Client Token Request to the Authorization Server (AS)

   The first step in the protocol flow (Figure 1 (A)) is the token
   acquisition by the Client from the AS.  When requesting an access
   token from the AS, the Client MAY include parameters in its request
   as defined in Section 5.6.1 of the ACE framework
   [I-D.ietf-ace-oauth-authz].  The media 

Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01

[Cigdem Sengul]

Thank you for your comments Daniel (prefixed [CS])
My comments are inside. I've also created the -v-02-WIP branch for the work
in progress based on your and Jim's comments.

On Thu, Oct 24, 2019 at 2:50 AM Daniel Migault  wrote:

> HI,
>
> Thanks for sending an update. Please find my comments of the draft.
>
>This document makes the same assumptions as the Section 4 of the ACE
>framework [I-D.ietf-ace-oauth-authz] regarding Client and RS
>registration with the AS and establishing of keying material.
>
>  The document seems mostly focuses on the latest version of MQTT,
> I am wondering if we could encourage similarly the use of the latest
> version of TLS that is 1.3 at the time of writing.
>
> It seems AS as not been defined previously, so maybe it should be
> expanded there.
> 
>

[CS] Can add a similar recommendation for TLS 1.3.
AS is expanded.



>
>MQTTS
>Secured transport profile of MQTT.  MQTTS runs over TLS.
>The Server in MQTT acts as an intermediary between
>Clients that publishes Application Messages, and the Clients
>that made Subscriptions.  The Broker acts as the Resource
>Server for the Clients.
>
> publishes
>
[CS] Fixed.



>
>Subscription
>A subscription comprises a Topic Filter and a maximum Quality
>of Service (QoS).
>
> Maybe that would be clearer to specify QoS level as well.
>

[CS] Added.



>PINGREQ
>A ping request sent from a Client to the Broker.  It signals
>to the Broker that the Client is alive, and is used to
>confirm that the Broker is still alive.
>
> It may look a bit strange to have PINGREQ without PINGRESP. You
> might also indicate the keep alive period is provided in the CONNECT
>

[CS] Added PINGRESP, clarified the Keep Alive period is set in the CONNECT
in the definition of PINGREQ.


>
>Will
>An application message published by the Server after the
>network connection is closed in cases where the network
>connection is not closed normally.  If the Will Flag is set,
>then the payload of the CONNECT message has information about
>the Will.  The Will consists of the Will Properties, Will
>Topic, and Will Payload fields in the CONNECT message.
>
> 
> The first sentence seems to be related to the Will message while the
> intent, I suppose of teh definition was to define the generic conpet of
> Will. It might be clearer to expose the principle of the wil, that is a
> server sends a given message in case a client is disconnected
> improperly.   It might be clearer to mention explicitly there is a Will
> "concept" that is implemented a WillFlag WillQoS, WillRetain in the
> CONNECT header as well as other Will Properties and Will Messages. This
> mostly consists in the last sentence being moved up.
> 
>

[CS] I reworded it - let me know if it is more clear.

>
> 2.  Protocol Interactions
>
>This section describes the following exchanges between Clients, the
>Broker, and the Authorization Server according to the MQTT v5.0.
>
>  Though english is not my first language, I have the impression the
> text can be interpreted as MQTT enables clients to establish session
> which does not seems correct to me. The text that follows clarifies this
> as well.
> 
>

[CS] Neither mine, I reworded that as: "Authorizing connection requests
from the Clients to the Broker"
Actually, I also went through the text to reword "establishment" to set-up
which is simpler.


>
> 2.1.  Authorizing Connection Establishment
>
> If the
>Client is resource-constrained, a Client Authorisation Server may
>
> I have the impression an AS would be sufficient.
>

[CS] Client Authorization Server was the terminology used in the Actors
draft - I've removed all other references but wanted to distinguish that
this is separate than the AS granting access tokens.
Can just say client's AS?

>
>carry out the token request on behalf of the Client, and later,
>onboard the Client with the token.  Also, these interfaces may be
>implemented using other protocols, e.g., CoAP or MQTT.
> While the introduction and the figure mentions that HTTPS is used
> as a transport, it might be worth mentioning that HTTPS is being used. I
> propose to add "...other protocols than HTTPS, e.g ...
> 
>

[CS] Added.


> 2.1.1.  Client Token Request to the Authorization Server (AS)
>
>The first step in the protocol flow (Figure 1 (A)) is the token
>acquisition by the Client from the AS.  When requesting an access
>token from the AS, the Client MAY include parameters in its request
>as defined in Section 5.6.1 of the ACE framework
>[I-D.ietf-ace-oauth-authz].  The media format is 'application/
>ace+json'.  The profile parameter MUST be set to 'mqtt_tls'.  The
>OAuth 2.0 AS uses a JSON structure in the payload of its responses
>both to client and RS.
>
>  I understand that 

[Ace] Éric Vyncke's No Objection on draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-ace-cwt-proof-of-possession-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-cwt-proof-of-possession/



--
COMMENT:
--

Thank you for the work put into this document. The document is easy to read. I
only one nit in section 3 and feel free to ignore all of it: While "sub" is
explained as being the "subject", nothing is written about "iss" claim on the
first time this term is used, it is only explained the 2nd time.

For my IESG colleagues, I second Mirja's comment about adding a IANA registry
entry based on email.

Regards,

-éric


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-25.txt

[Ludwig Seitz]

Hello ACE,

this update of draft-ietf-ace-oauth-authz addresses the review comments 
made by Ben Kaduk.


Regards,

Ludwig


 Forwarded Message 
Subject: New Version Notification for draft-ietf-ace-oauth-authz-25.txt
Date: Wed, 30 Oct 2019 06:15:10 -0700
From: internet-dra...@ietf.org
To: Ludwig Seitz , Hannes Tschofenig 
, Goeran Selander 
, Samuel Erdtman , 
Erik Wahlstroem 



A new version of I-D, draft-ietf-ace-oauth-authz-25.txt
has been successfully submitted by Ludwig Seitz and posted to the
IETF repository.

Name:   draft-ietf-ace-oauth-authz
Revision:   25
Title:		Authentication and Authorization for Constrained Environments 
(ACE) using the OAuth 2.0 Framework (ACE-OAuth)

Document date:  2019-10-30
Group:  ace
Pages:  86
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-25.txt

Status: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/
Htmlized:   https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-25
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-25


Abstract:
   This specification defines a framework for authentication and
   authorization in Internet of Things (IoT) environments called ACE-
   OAuth.  The framework is based on a set of building blocks including
   OAuth 2.0 and CoAP, thus transforming a well-known and widely used
   authorization solution into a form suitable for IoT devices.
   Existing specifications are used where possible, but extensions are
   added and profiles are defined to better serve the IoT use cases.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




smime.p7s
Description: S/MIME Cryptographic Signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] I-D Action: draft-ietf-ace-oauth-authz-25.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments WG of the IETF.

Title   : Authentication and Authorization for Constrained 
Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)
Authors : Ludwig Seitz
  Goeran Selander
  Erik Wahlstroem
  Samuel Erdtman
  Hannes Tschofenig
Filename: draft-ietf-ace-oauth-authz-25.txt
Pages   : 86
Date: 2019-10-30

Abstract:
   This specification defines a framework for authentication and
   authorization in Internet of Things (IoT) environments called ACE-
   OAuth.  The framework is based on a set of building blocks including
   OAuth 2.0 and CoAP, thus transforming a well-known and widely used
   authorization solution into a form suitable for IoT devices.
   Existing specifications are used where possible, but extensions are
   added and profiles are defined to better serve the IoT use cases.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-25
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-25

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-25


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24

[Ludwig Seitz]

On 28/10/2019 22:06, Benjamin Kaduk wrote:


32.)
Section 5.6.1

The client sends a POST request to the token endpoint at the AS.  The
profile MUST specify how the communication is protected.  The content

In the previous section we said that maybe even other transports than
coaps or https would be possible; are we limited to those that have POST
verbs?
Also, a similar comment as above about what attributes the protection
entails seems to apply.


[LS] This will need a major rephrasing of the text.
I see two options here:

1.) We rewrite all parts to use a neutral language in general and specify
POST/GET etc. for transports that have these verbs.

2.) We state in the beginning that transports that do not use RESTful verbs
should use the best equivalent.

Option 1. would get a bit cluncky, while option 2. might be a bit confusing
Do you have a specific preference?

[JLS] I would suggest that this could fall under the punt to the new transport 
that does not have the same as these verbs in it to explain how they would map.


I agree that (1) is more effort than it's likely to be worth.  If we can
finagle a single-sentence disclaimer like "transports that do not use these
verbs will need to specify the requisite behavior" that would be great; if
not, then we can consider whether to just ignore it or do something more
complicated.


I'll go for this:

" Note that this document specifies
  protocol exchanges in terms of RESTful commands such as GET and POST.
  Future profiles using protocols that do not support these verbs MUST
  specify how the corresponding protocol messages are transmitted instead.
"

In the Overview section where we mention alternate transport protocols.

/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



smime.p7s
Description: S/MIME Cryptographic Signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [Gen-art] Genart telechat review of draft-ietf-ace-cwt-proof-of-possession-09

[Alissa Cooper]

Christer, thanks for your reviews. Mike, thanks for your responses. I entered a 
No Objection ballot.

Alissa


> On Oct 25, 2019, at 12:00 PM, Christer Holmberg via Datatracker 
>  wrote:
> 
> Reviewer: Christer Holmberg
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-ace-cwt-proof-of-possession-09
> Reviewer: Christer Holmberg
> Review Date: 2019-10-25
> IETF LC End Date: None
> IESG Telechat date: 2019-10-31
> 
> Summary: My comments on the previous version have been addressed, and the
> document is now ready for publication.
> 
> Major issues: N/A
> 
> Minor issues: N/A
> 
> Nits/editorial comments: N/A
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace